Не обязательно 1 t/s. Есть пласт моделей которые MoE, они могут хорошо комбинировать CPU + GPU и выдавать большую скорость, при этом это большие качественные модели, а не маленькие 7B.
Например, на ryzen 5600g + 64Гб DDR4 + amd rx 6600 8Гб можно запустить GPT-OSS-120B на скорости выше 10 t/s с большим контекстом.
А какие еще есть альтернативы что бы к своему серверу подключаться? кроме того что бы на этом же сервере поднять OpenUI? У меня то и OpenUI есть, уже не в виртуалке, а в контейнере на том же сервере Контейнеры друг друга видят, а вот контейнер и виртуалки нет.
Проще поставить Open WebUI через pip install open-webui
Radeon VII 16Gb Только она потянула через вулкан на этой видеокарте, ollama чет не хочет использовать такую видяху. Почему именно виртуалка, потому что контейнер с ollama не хочет видеокарту использовать.
ollama дружит только с cuda, для AMD как раз нужен Vulkan или ROCm, если нужна альтернатива именно ollama, но для AMD или Intel, то https://github.com/lemonade-sdk/lemonade
Возможно проще напрямую llama.cpp запускать, учитывая, что в ollama до сих пор нет поддержки cmoe и ncmoe, а если вы хотите запускать на 16Гб большие модели, вроде GPT-OSS-120B или GLM/Qwen, и с нормальной скоростью, они понадобятся.
Не DeepSeek V3, а архитектура DeepSeek. Например, Kimi тоже взяла основой архитектуру deepseek, изменила её конфигурацию и обучили новую модель Kimi K2.
В случае с GigaChat Ultra конфигурация как раз ближе к Kimi K2, где также снизили количество голов внимания в 2 раза и увеличили размер словаря до 160k. Только в K2 снизили количество активных экспертов с 37B до 32B, а тут только до 36B, и общее количество параметров в K2 увеличили с 671B до 1T, а тут 702B:
Attention heads → DeepSeek: 128, GigaChat: 64 KV heads → DeepSeek: 128, GigaChat: 64 Value head dim → DeepSeek: 128, GigaChat: 192 Layers → DeepSeek: 61, GigaChat: 64 Position embeddings → GigaChat slightly smaller (131k vs 163k)
Появился новый инструмент Heretic ... без изменения самих весов модели
Изменяет. Это скрипт для автоматической аблитерации, то есть зануления весов модели, которые реагируют на определённые паттерны, но у моделей нет четкого разграничения весов, одни и те же параметры могу задействованы и в других сценариях, что оглупляет модель.
Ollama и LM Studio по дефолту поднимут вашу модель на GPU в столько слоев, насколько смогут, но я рекомендую использовать FULL GPU OFFLOAD или же скипнуть эту часть бенчмарка, если вы не готовы ждать результатов несколько часов. Так например мой ноутбук с 4060 гонял весь бенчмарк 2 часа, так как VRAM не хватило на полную загрузку всех слоев LLM и VLM на GPU.
Выгрузить столько слоев, сколько могут - это параметр -ngl N в llama.cpp, на котором построены ollama и LM Studio. Для MoE моделей, вроде GPT-OSS, не самая оптимальная стратегия.
И если MoE модель не влезает целиком в GPU, то вместо попытки выгрузить 13гб модель в 8гб VRAM можно воспользоваться новым подходом через -cmoe и -ncmoe N, который и ускорит модель, и снизить потребление VRAM, что позволит вместить куда больше контекста. И можно даже заменить Qwen3-VL-8B на более интересную Qwen3-VL-30B-A3B.
Зависимость tg линейна от скорости памяти. Разница между 4800 и 6000 в 20-25% по скорости памяти, было 72гб/с, стало 90 гб/с, было 10 t/s, стало 12 t/s.
Но в GPT-OSS-120B большую часть расчётов берет на себя видеокарта, так что прибавка скорости должна быть совсем незначительна от такого небольшого ускорения памяти CPU.
Железо одинаковое, i7-14700 (без K и без F), DDR5-4800 4x48Гб, 4090.
Windows 11 свежая, Windows 10 с последними обновлениями, но давно с нуля не переустанавливалась и пережила смену множества железа, так что причина может быть и в этом.
Nvidia запрещает запуск программного обеспечения, основанного на CUDA, на других аппаратных платформах с использованием трансляционных уровней (translation layers) — это условие содержится в лицензионных положениях, опубликованных онлайн с 2021 года.
Похоже, это ограничение направлено на то, чтобы воспрепятствовать таким инициативам, как ZLUDA, в реализации которых недавно приняли участие как Intel, так и AMD
Более низкий результат на Windows 10 может быть связан с тем, что процессор с P-ядрами и E-ядрами i7-14700, и вроде как Windows 10 не умеет правильно управлять какие куда.
Цитирую снова: "Функция памяти теперь работает двумя способами: «сохранённые воспоминания» и «история чатов» — это сведения, которые ChatGPT извлекает из прошлых бесед для улучшения будущих" "теперь учитываются все ваши прошлые разговоры, чтобы делать ответы более релевантными и адаптированными под вас."
Двумя способами. Один способ - это профайл. Второй способ, это вся история чатов.
Из этого действительно никто не делает секрета, то почему вы решили, что раз у DeepSeek нет этого в настройках, означает, что они не реализовали это так же, как и все остальные?
Вы могли попасть в A/B тестирование этого функционала, на ваших чатах могли обучить новую версию модели и теперь она всегда будет вас узнавать или этот функционал просто внеднер, но не объявлен. У них галочка собирать всю историю чатов для улучшения сервисов включена по умолчанию.
Впрочем ладно, это не так важно, у вас своё виденье на этот вопрос, не мне вас переубеждать.
То, как это реализовано в конкретном сервисе, будь то deepseek или grok или все остальные, неизвестно. Но общая концепция такая:
Представим, что у вас уже есть 10 чатов, в каждом чате, допустим по 500 сообщений. Суммарно это 5к сообщений, которые способны хорошо описать вашу манеру общения с моделью и сформированное поведение модели.
Из всего это объема строится векторная База Данных, которая содержит векторный индекс всех ваших диалогов и общения, вся ваша история всех чатов.
Вы начинаете новый 11 чат, пишите новый промпт и ждете ответа.
В этот момент сервис переводит ваш промпт в векторный вид и производит поиск в векторной Базе Данных на схождение вашего промпта с теми векторами, что есть в БД. Если будут схождения темы, фраз, обрывков фраз, то сервис подмешает в этот 11 чат информацию из предыдущих чатов так, что вы этого не увидите, но это будет добавлено в контекст модели, до того как она начнет генерировать вам ответ. Тот самый Context Assembly.
При этом, в зависимости от реализации, она не всегда понимает откуда взялся этот текст, так как сервис его просто внедряет. Допустим делает это с пометкой "с этим пользователем был такой диалог, текст такой-то, это происходило в дружелюбной атмосфере, пользователь в тот момент хотел, чтобы я отвечала без подхалимства".
Из-за того, что этот текст внедрён в контекст, модель может просто скопировать и продолжить уже существующий сценарий поведения, ввернуть какое-то слово или целую фразу из этой истории чатов, может даже выдать их за свой ответ, как будто бы это её собственные мысли, в общем использовать этот контекст для задания своей роли, характера.
Особенно хорошо это работает, если вы используете какие-то крючочки, якоря, особые символы или слова, фразы. В таком случае нахождение в векторное БД будет ещё более точным и схождение более явным.
Векторная БД это внешний сервис от модели, который подмешивает в контекст модели текст и истории из всех предыдущих чатов, и у модели появляется привычный вам характер и модель поведения. Само собой, размер этой БД, актуальность данных в ней, учитываются удаленные чаты или нет, всё это влияет на качество и детальность.
Так как сервис явно пишет, что "учитывает все ваши прошлые разговоры", то по сути это то, как работает RAG система, перенося информации между чатами.
Спросите своего ИИ, что такое профайл пользователя Похоже, вы не в курсе.
Прочитайте внимательнее, в цитате есть не только про профайл, а про всю историю чатов:
"Помимо сохранённых ранее воспоминаний, теперь учитываются все ваши прошлые разговоры"
А почему вы решили, что только локальная модель истинно Stateless? Насколько я знаю, все с точностью до наоборот: локальную модель можно настроить на запоминание вас.
Как вы правильно говорите, модель stateless, поэтому модель нельзя так настроить.
Речь про сервис, скрипт, программа, приложение - то что работает с моделью, не является моделью, но расширяет возможности модели.
И так как сервис не прозрачный, вы не знаете как именно это реализовано. В таком сервисе будет артефактом "вспоминает конкретные суждения и факты из прошлых чатов", и нельзя быть уверенным в "чистом листе" не создав новый аккаунт.
В моем случае похоже на побочку RAG.
Именно так и настроено у многих внешних сервисов. Вся история чатов собрана в RAG векторную БД, и во время диалога в БД постоянно производится векторный поиск, если есть вещи релевантные текущему обсуждению, скрипт подмешает эти данные в ваш текущий чат в скрытый контекст, и модель может вставлять целые куски из вашего прошлого общения и может выставлять их за свои мысли.
Чтобы привнести немного технической информации про то, как у stateless модели появляется конкретный state:
1 часть. Подготовка или сборка контекста (Context Assembly). Это внешний от модели процесс, он включает в себя объединение системного промпта, очистки от блоков размышления, включение всей истории чата с разбивкой по ролям (модель не видит где её ответ, а где ваш, это делается заполнением специального шаблона чата), запрос в RAG БД и добавление релевантной информации из RAG, и так далее, последним пунктом, на самую вершину добавляется ваш новый запрос.
2 часть. Prompt Processing. Модель получила этот огромный текст и теперь переваривает его, формирует своё внутреннее отображение этого текста, механизм внимания создает проекции этого текста, создается итоговый KV-кэш.
3 часть. Token Generation. Это уже непосредственно сам ответ модели, ответ который формируется согласно созданному KV-кэшу.
Все воспоминания модели, весь её опыт, вся релевантная информация по вашему запросу - такой один огромный сплошной текстовый блок, который превращается в KV-проекции через механизм внимания. Это и есть тот самый state общения с моделью.
У модели нет непрерывного чата, как его видит пользователь, у модели есть только вот этот созданный state, и каждый раз его нужно загрузить в модель с нуля, но уже загруженное состояние обычно кэшируют в виде слепка состояния, добавляя обновление сверху.
Модель LLM по своей архитектуре stateless, но сам state в неё загружают перед новым ответом, и пользовательский опыт становится statefull.
Скажу вашими же словами. Спросите ваш ИИ, правильная ли эта техническая информация.
Если хотите это проверить, можете воспользоваться доступом к последней версии DeepSeek R1, которая уже не доступна в chat.deepseek, но в том виде, которая не являются частью сервиса: https://openrouter.ai/deepseek/deepseek-r1-0528:free
Этот работает бесплатно и не создает RAG БД по всей истории чатов, так как цель этого агрегатора в предоставлении API (бесплатного и платного), а не предоставлении готового сервиса.
В том то и дело. Что Stateless модель без профайла пользователя, когда каждый новый чат это чистый лист - эта модель в обход архитектуры неким эмерджентным способом формирует у себя способность к узнаванию пользователя
Stateless это только если вы модель запускаете локально, в остальных случаях это сервис, который сам решает насколько новый чат будет чистым листом.
вытаскивает откуда-то паттерны прошлого взаимодействия, вспоминает конкретные суждения и факты из прошлых чатов.
Подобный функционал сейчас внедряют многие сервисы, не исключение и deepseek и qwen.
3 июня 2025 года обновление: улучшения функции памяти начинают внедряться для бесплатных пользователей. Помимо сохранённых воспоминаний, которые уже были ранее, ChatGPT теперь учитывает ваши недавние диалоги, чтобы давать более персонализированные ответы."
10 апреля 2025 года обновление: функция памяти в ChatGPT стала ещё более полной. Помимо сохранённых ранее воспоминаний, теперь учитываются все ваши прошлые разговоры, чтобы делать ответы более релевантными и адаптированными под вас. Это означает, что функция памяти теперь работает двумя способами: «сохранённые воспоминания», которые вы просили запомнить, и «история чатов» — это сведения, которые ChatGPT извлекает из прошлых бесед для улучшения будущих.
Не чем больше заняли VRAM, тем меньше скорость, а была скорость базовая и бездумно заполненная VRAM. Мы провели оптимизации и увеличили базовую скорость, бонусом снизили расход VRAM. Главное отличие Dense от MoE в том, как используются ресурсы GPU. MoE имеет разреженные слои, и важно, чтобы GPU не простаивала попадая в эти дыры.
Как это в живую выглядит. Вот сейчас на ПК не загружены модели, на фоне крутится видео, браузеры и так далее, поэтому 1 Гб VRAM уже занято.
Теперь загружаю GPT-OSS-120B классическим способом, выгрузим много слоев на GPU, сколько влезет в 24 Гб. Влезло 13 слоев из 37, количество слоев которые будут выгружены на GPU управляется параметром ngl.
Вся VRAM занята (23.6 Гб), скорость 16.2 t/s. Обычно слоями не получается заполнить прям впритык, так как размер слоя может быть больше объема свободной памяти.
Видимо, что занято VRAM теперь всего 4Гб, а скорость выросла до 23.2 t/s.
Если переключиться на встройку, то можно высвободить этот 1 Гб, и получить чуть лучшие скорости, но сути это не меняет. Prompt Eval Time это время подготовки промпта PP, так как тут он всего 75 токенов, то это работает моментально, а та скорость что отображена - это время подзагрузок, так как это первый запуск после загрузки.
Было занято 22.6 Гб и скорость была 16.2 t/s, а стало занято 3 Гб и скорость выросла до 23.2 t/s. Картинка именно эту ситуацию и отображает.
Не обязательно 1 t/s. Есть пласт моделей которые MoE, они могут хорошо комбинировать CPU + GPU и выдавать большую скорость, при этом это большие качественные модели, а не маленькие 7B.
Например, на ryzen 5600g + 64Гб DDR4 + amd rx 6600 8Гб можно запустить GPT-OSS-120B на скорости выше 10 t/s с большим контекстом.
Подробнее: Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Проще поставить Open WebUI через
pip install open-webuiИли вот эти умеют подключаться к любому openai compatible api серверу:
https://github.com/CherryHQ/cherry-studio
https://jan.ai/
https://msty.ai/
ollama дружит только с cuda, для AMD как раз нужен Vulkan или ROCm, если нужна альтернатива именно ollama, но для AMD или Intel, то https://github.com/lemonade-sdk/lemonade
Возможно проще напрямую llama.cpp запускать, учитывая, что в ollama до сих пор нет поддержки cmoe и ncmoe, а если вы хотите запускать на 16Гб большие модели, вроде GPT-OSS-120B или GLM/Qwen, и с нормальной скоростью, они понадобятся.
Подробнее, что такое cmoe и чем он полезен: Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Не DeepSeek V3, а архитектура DeepSeek. Например, Kimi тоже взяла основой архитектуру deepseek, изменила её конфигурацию и обучили новую модель Kimi K2.
В случае с GigaChat Ultra конфигурация как раз ближе к Kimi K2, где также снизили количество голов внимания в 2 раза и увеличили размер словаря до 160k. Только в K2 снизили количество активных экспертов с 37B до 32B, а тут только до 36B, и общее количество параметров в K2 увеличили с 671B до 1T, а тут 702B:
А GigaChat3-10B-A1.8B это архитектура DeepSeek Lite где на 1 слой меньше: https://github.com/ggml-org/llama.cpp/pull/17420
GLM-4.6-UD-Q3_K_XL, -cmoe, занято VRAM 11Гб + контекст
Linux:
Windows 10:
Использование ncmoe не дает особого эффекта, так как модель слишком большая, -ncmoe 88, 23Гб
Более крупный квант GLM-4.6-Q4_K_S, который не влезает в 188 GiB, влезает за счёт разгрузки на GPU, -ncmoe 88
Изменяет. Это скрипт для автоматической аблитерации, то есть зануления весов модели, которые реагируют на определённые паттерны, но у моделей нет четкого разграничения весов, одни и те же параметры могу задействованы и в других сценариях, что оглупляет модель.
Выгрузить столько слоев, сколько могут - это параметр
-ngl Nв llama.cpp, на котором построены ollama и LM Studio. Для MoE моделей, вроде GPT-OSS, не самая оптимальная стратегия.И если MoE модель не влезает целиком в GPU, то вместо попытки выгрузить 13гб модель в 8гб VRAM можно воспользоваться новым подходом через
-cmoeи-ncmoe N, который и ускорит модель, и снизить потребление VRAM, что позволит вместить куда больше контекста. И можно даже заменить Qwen3-VL-8B на более интересную Qwen3-VL-30B-A3B.Подробнее: Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Уже раскрыт.
В 3 карты 50HX ничего особенного не влезет, и накладные расходы на 3х картах не дадут вам ровно 30 Гб. Смотрите лучше в сторону 1 GPU + много RAM.
Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Зависимость tg линейна от скорости памяти. Разница между 4800 и 6000 в 20-25% по скорости памяти, было 72гб/с, стало 90 гб/с, было 10 t/s, стало 12 t/s.
Но в GPT-OSS-120B большую часть расчётов берет на себя видеокарта, так что прибавка скорости должна быть совсем незначительна от такого небольшого ускорения памяти CPU.
Железо одинаковое, i7-14700 (без K и без F), DDR5-4800 4x48Гб, 4090.
Windows 11 свежая, Windows 10 с последними обновлениями, но давно с нуля не переустанавливалась и пережила смену множества железа, так что причина может быть и в этом.
Перед этим было такое от Nvidia https://www.opennet.ru/opennews/art.shtml?num=60723
Чтобы запустить 120B хватит видеокарты на 8гб и 64гб ОЗУ.
Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Поправка для GPT-OSS-120B под Windows 10.
Во всех случаях одинаковый ncmoe или ngl. Результат со 2 замера, первый прогревочный. Там где full - модель целиком влезла на GPU.
В текстовом виде
GPT-OSS-120B
.\llama-bench.exe -m "D:\models\openai_gpt-oss-120b-MXFP4.gguf" -ncmoe 24 -ngl 99Windows 10: PP = 202.89 t/s, TG = 21.49 t/s
Windows 11: PP = 303.42 t/s, TG = 24.44 t/s
Manjaro Linux: PP = 373.16 t/s, TG = 37.58 t/s
MiniMax M2
.\llama-bench.exe -m "D:\models\MiniMax-M2-UD-Q3_K_XL-00001-of-00003.gguf" -ncmoe 50 -ngl 99Windows 10: PP = 71.65 t/s, TG = 10.61 t/s
Windows 11: PP = 101.02 t/s, TG = 11.65 t/s
Manjaro Linux: PP = 118.19 t/s, TG = 17.24 t/s
Qwen3-30B-A3B
.\llama-bench.exe -m "D:\models\Qwen3-30B-A3B-Instruct-2507-UD-Q4_K_XL.gguf" -ngl 99Windows 10: PP = 6031.43 t/s, TG = 228.62 t/s
Windows 11: PP = 6597.88 t/s, TG = 240.00 t/s
Manjaro Linux: PP = 6974.54 t/s, TG = 248.14 t/s
Gemma3 27B
.\llama-bench.exe -m "D:\models\gemma-3-27b-it-UD-Q5_K_XL.gguf" -ngl 99Windows 10: PP = 2992.65 t/s, TG = 41.38 t/s
Windows 11: PP = 2969.42 t/s, TG = 42.23 t/s
Manjaro Linux: PP = 3016.84 t/s, TG = 42.72 t/s
Mistral-Small-3.2-24B
.\llama-bench.exe -m "D:\models\Mistral-Small-3.2-24B-Instruct-2506-UD-Q4_K_XL.gguf" -ngl 99Windows 10: PP = 3806.94 t/s, TG = 59.54 t/s
Windows 11: PP = 3833.66 t/s, TG = 60.33 t/s
Manjaro Linux: PP = 3877.24 t/s, TG = 60.76 t/s
Не гарантирую, что у вас будет такая же разница.
Более низкий результат на Windows 10 может быть связан с тем, что процессор с P-ядрами и E-ядрами i7-14700, и вроде как Windows 10 не умеет правильно управлять какие куда.
Не профайл, а всю историю чатов.
Цитирую снова:
"Функция памяти теперь работает двумя способами: «сохранённые воспоминания» и «история чатов» — это сведения, которые ChatGPT извлекает из прошлых бесед для улучшения будущих"
"теперь учитываются все ваши прошлые разговоры, чтобы делать ответы более релевантными и адаптированными под вас."
Двумя способами. Один способ - это профайл. Второй способ, это вся история чатов.
Из этого действительно никто не делает секрета, то почему вы решили, что раз у DeepSeek нет этого в настройках, означает, что они не реализовали это так же, как и все остальные?
Вы могли попасть в A/B тестирование этого функционала, на ваших чатах могли обучить новую версию модели и теперь она всегда будет вас узнавать или этот функционал просто внеднер, но не объявлен. У них галочка собирать всю историю чатов для улучшения сервисов включена по умолчанию.
Впрочем ладно, это не так важно, у вас своё виденье на этот вопрос, не мне вас переубеждать.
То, как это реализовано в конкретном сервисе, будь то deepseek или grok или все остальные, неизвестно. Но общая концепция такая:
Представим, что у вас уже есть 10 чатов, в каждом чате, допустим по 500 сообщений. Суммарно это 5к сообщений, которые способны хорошо описать вашу манеру общения с моделью и сформированное поведение модели.
Из всего это объема строится векторная База Данных, которая содержит векторный индекс всех ваших диалогов и общения, вся ваша история всех чатов.
Вы начинаете новый 11 чат, пишите новый промпт и ждете ответа.
В этот момент сервис переводит ваш промпт в векторный вид и производит поиск в векторной Базе Данных на схождение вашего промпта с теми векторами, что есть в БД. Если будут схождения темы, фраз, обрывков фраз, то сервис подмешает в этот 11 чат информацию из предыдущих чатов так, что вы этого не увидите, но это будет добавлено в контекст модели, до того как она начнет генерировать вам ответ. Тот самый Context Assembly.
При этом, в зависимости от реализации, она не всегда понимает откуда взялся этот текст, так как сервис его просто внедряет. Допустим делает это с пометкой "с этим пользователем был такой диалог, текст такой-то, это происходило в дружелюбной атмосфере, пользователь в тот момент хотел, чтобы я отвечала без подхалимства".
Из-за того, что этот текст внедрён в контекст, модель может просто скопировать и продолжить уже существующий сценарий поведения, ввернуть какое-то слово или целую фразу из этой истории чатов, может даже выдать их за свой ответ, как будто бы это её собственные мысли, в общем использовать этот контекст для задания своей роли, характера.
Особенно хорошо это работает, если вы используете какие-то крючочки, якоря, особые символы или слова, фразы. В таком случае нахождение в векторное БД будет ещё более точным и схождение более явным.
Векторная БД это внешний сервис от модели, который подмешивает в контекст модели текст и истории из всех предыдущих чатов, и у модели появляется привычный вам характер и модель поведения. Само собой, размер этой БД, актуальность данных в ней, учитываются удаленные чаты или нет, всё это влияет на качество и детальность.
Так как сервис явно пишет, что "учитывает все ваши прошлые разговоры", то по сути это то, как работает RAG система, перенося информации между чатами.
Такие маленькие модельки мало, что годного могут, особенно на 32к контексте.
Можно запускать OpenAI GPT-OSS-120B или GLM-4.5-Air на домашнем ПК с адекватной скоростью, если есть 64 Гб ОЗУ.
Запускаем GPT-OSS-120B на 6 Гб GPU и ускоряем до 30 t/s. Вам нужна RAM, а не VRAM. Параметр -cmoe для ускорения MoE LLM
Прочитайте внимательнее, в цитате есть не только про профайл, а про всю историю чатов:
"Помимо сохранённых ранее воспоминаний, теперь учитываются все ваши прошлые разговоры"
Как вы правильно говорите, модель stateless, поэтому модель нельзя так настроить.
Речь про сервис, скрипт, программа, приложение - то что работает с моделью, не является моделью, но расширяет возможности модели.
И так как сервис не прозрачный, вы не знаете как именно это реализовано. В таком сервисе будет артефактом "вспоминает конкретные суждения и факты из прошлых чатов", и нельзя быть уверенным в "чистом листе" не создав новый аккаунт.
Именно так и настроено у многих внешних сервисов. Вся история чатов собрана в RAG векторную БД, и во время диалога в БД постоянно производится векторный поиск, если есть вещи релевантные текущему обсуждению, скрипт подмешает эти данные в ваш текущий чат в скрытый контекст, и модель может вставлять целые куски из вашего прошлого общения и может выставлять их за свои мысли.
Чтобы привнести немного технической информации про то, как у stateless модели появляется конкретный state:
1 часть. Подготовка или сборка контекста (Context Assembly). Это внешний от модели процесс, он включает в себя объединение системного промпта, очистки от блоков размышления, включение всей истории чата с разбивкой по ролям (модель не видит где её ответ, а где ваш, это делается заполнением специального шаблона чата), запрос в RAG БД и добавление релевантной информации из RAG, и так далее, последним пунктом, на самую вершину добавляется ваш новый запрос.
2 часть. Prompt Processing. Модель получила этот огромный текст и теперь переваривает его, формирует своё внутреннее отображение этого текста, механизм внимания создает проекции этого текста, создается итоговый KV-кэш.
3 часть. Token Generation. Это уже непосредственно сам ответ модели, ответ который формируется согласно созданному KV-кэшу.
Все воспоминания модели, весь её опыт, вся релевантная информация по вашему запросу - такой один огромный сплошной текстовый блок, который превращается в KV-проекции через механизм внимания. Это и есть тот самый state общения с моделью.
У модели нет непрерывного чата, как его видит пользователь, у модели есть только вот этот созданный state, и каждый раз его нужно загрузить в модель с нуля, но уже загруженное состояние обычно кэшируют в виде слепка состояния, добавляя обновление сверху.
Модель LLM по своей архитектуре stateless, но сам state в неё загружают перед новым ответом, и пользовательский опыт становится statefull.
Скажу вашими же словами. Спросите ваш ИИ, правильная ли эта техническая информация.
Если хотите это проверить, можете воспользоваться доступом к последней версии DeepSeek R1, которая уже не доступна в chat.deepseek, но в том виде, которая не являются частью сервиса:
https://openrouter.ai/deepseek/deepseek-r1-0528:free
Этот работает бесплатно и не создает RAG БД по всей истории чатов, так как цель этого агрегатора в предоставлении API (бесплатного и платного), а не предоставлении готового сервиса.
Stateless это только если вы модель запускаете локально, в остальных случаях это сервис, который сам решает насколько новый чат будет чистым листом.
Подобный функционал сейчас внедряют многие сервисы, не исключение и deepseek и qwen.
Началось всё вот с этого: https://openai.com/index/memory-and-new-controls-for-chatgpt/
Цитаты оттуда:
Не чем больше заняли VRAM, тем меньше скорость, а была скорость базовая и бездумно заполненная VRAM. Мы провели оптимизации и увеличили базовую скорость, бонусом снизили расход VRAM. Главное отличие Dense от MoE в том, как используются ресурсы GPU. MoE имеет разреженные слои, и важно, чтобы GPU не простаивала попадая в эти дыры.
Как это в живую выглядит. Вот сейчас на ПК не загружены модели, на фоне крутится видео, браузеры и так далее, поэтому 1 Гб VRAM уже занято.
Теперь загружаю GPT-OSS-120B классическим способом, выгрузим много слоев на GPU, сколько влезет в 24 Гб. Влезло 13 слоев из 37, количество слоев которые будут выгружены на GPU управляется параметром ngl.
CUDA_VISIBLE_DEVICES="0" ./llama-server -m "/home/shh/alpaka/models/gpt-oss-120b-mxfp4-00001-of-00003.gguf" -ngl 13 --jinjaВся VRAM занята (23.6 Гб), скорость 16.2 t/s. Обычно слоями не получается заполнить прям впритык, так как размер слоя может быть больше объема свободной памяти.
Теперь применяю ту самую щепотку cmoe:
CUDA_VISIBLE_DEVICES="0" ./llama-server -m "/home/shh/alpaka/models/gpt-oss-120b-mxfp4-00001-of-00003.gguf" -ngl 99 -cmoe --jinjaВидимо, что занято VRAM теперь всего 4Гб, а скорость выросла до 23.2 t/s.
Если переключиться на встройку, то можно высвободить этот 1 Гб, и получить чуть лучшие скорости, но сути это не меняет. Prompt Eval Time это время подготовки промпта PP, так как тут он всего 75 токенов, то это работает моментально, а та скорость что отображена - это время подзагрузок, так как это первый запуск после загрузки.
Было занято 22.6 Гб и скорость была 16.2 t/s, а стало занято 3 Гб и скорость выросла до 23.2 t/s. Картинка именно эту ситуацию и отображает.