Что вообще влезает в 11 ГБ VRAM: рамки эксперимента
На GTX 1080 Ti с 11 ГБ VRAM запускаются MoE-модели класса 120B и 176B, и это не теория. Вопрос в том, какая из них доводит живую задачу до рабочего результата, а какая уходит в цикл на длинном контексте. В сравнении через llama-server участвовали три размера MoE: Qwen3.8-35B-A3B-Q4_K_M, gpt-oss-120b и Qwen3.8-Flash-Next в квантизациях Q3_K_XL и Q4_K_XL. Лучшей оказалась самая младшая из них.
Стенд: NVIDIA GeForce GTX 1080 Ti с 11 ГБ VRAM, Intel Core i9-9900K, 64 ГБ RAM и Ubuntu Linux. Сборка llama.cpp шла с поддержкой архитектуры qwen4exp. Запуск 176B-класса Qwen3.8-Flash-Next на этой карте описывался раньше и тогда был назван экспериментом на грани возможного. Теперь задача была шире: сравнить три размера на одной задаче и найти границу между «работает» и «работает, но бесполезно».
Почему MoE, а не плотные модели
В Mixture-of-Experts на каждый токен активируется лишь часть экспертов. У Qwen3.8-35B-A3B активных параметров около 3B из 35B, остальные веса лежат и ждут очереди. VRAM и вычисления тратятся только на активное подмножество, поэтому 120B и 176B вообще стартуют на 11 ГБ. Плотная модель такого размера держала бы в работе все параметры и не поместилась бы в память карты.
Схема распределения простая: активные эксперты и часть слоёв идут на GPU, неактивные веса живут в системной RAM и подтягиваются по мере генерации. Чем крупнее модель, тем больше обмен по PCIe и тем ниже скорость генерации.
Роль RAM и квантизации
64 ГБ RAM здесь не запас на будущее, а условие запуска. В системную память уходят неактивные эксперты и KV-кэш. Квантизации Q3_K_XL и Q4_K_XL сжимают веса и экономят сразу VRAM и RAM, но качество внимания при этом страдает. На коротких промптах это почти незаметно, на длинном контексте вылезает ошибками и потерей логики.
Как запускался llama-server: команда и флаги
Все модели запускались одной командой:
llama-server -m ~/GGUF/<Модель_из_списка> --host 127.0.0.1 --port 8080 --tools all -c 131072 -b 2048 -ub 1024 -fa auto --jinja --parallel 1
Разбор флагов:
--tools allактивирует все доступные инструменты, то есть tool calls.--jinjaвключает движок, обрабатывающий шаблоны чатов в формате Jinja; без указания своего файла используется шаблон, встроенный в GGUF.--parallel 1задаёт число слотов сервера, то есть ограничивает число одновременных запросов одним.-c 131072задаёт контекст 128K.-b 2048и-ub 1024- размер батча и microbatch.-fa autoвключает flash attention в авторежиме: значениеautoозначает, что llama.cpp включит механизм, если автоматическая проверка покажет, что он поддерживается в текущей конфигурации оборудования и модели.
Сборка llama.cpp с поддержкой qwen4exp и конкретный набор флагов нужны для воспроизводимости: смените шаблон чата или отключите инструменты, и результаты сравнения перестанут быть сопоставимыми. Другие движки ведут себя иначе, и разница видна в отдельном разборе TensorSharp против llama.cpp на CUDA и Vulkan, где новый движок местами выигрывает на префилле, а llama.cpp остаётся вне конкуренции в других сценариях.
Почему --tools all и --jinja обязательны для агентных задач
Без --tools all модель не увидит доступные вызовы инструментов, и погодный сервер останется без обращения к внешнему API. Без --jinja не подхватится корректный шаблон чата, роли пользователя и системного сообщения смешаются, и агентный сценарий развалится до первого вызова. Это не перестраховка, а условие воспроизводимости теста.
WebUI как способ управления без лишних скриптов
Управление шло из встроенного WebUI llama-server: достаточно открыть браузер по адресу http://127.0.0.1:8080. Ни клиентов на Python, ни обвязки не требуется, что упрощает прогон тестовой задачи и сравнение моделей между собой.
Ещё один момент: на 11 ГБ VRAM часть слоёв всё равно уходит на CPU, поэтому скорость упирается в i9-9900K и пропускную способность RAM. Прирост только от замены видеокарты без быстрой памяти и мощного процессора будет скромным.
Тестовая задача: погодный сервер на Go с внешним API
Задача: написать простой погодный сервер на Go, который обращается к внешнему API. Это не hello world. Внутри HTTP-сервер, вызов внешнего сервиса, разбор ответа, обработка ошибок. Такая задача проверяет три вещи: следование инструкциям, структуру кода и работу с tool calls.
Критерии оценки: время до рабочего результата (код компилируется и отвечает), стабильность следования инструкциям (модель не сменила язык, не выбросила обработку ошибок), поведение на контексте 32K и 128K. Точных замеров токенов/с в исходном материале нет, поэтому выводы качественные: быстрее или медленнее, стабильно или срывается. Схожий подход с прогоном одной задачи через разные локальные модели разбирался в тесте 9 LLM на одном промпте, и он тоже опирается на реальную задачу, а не на синтетический бенчмарк.
Результаты: 35B против 120B и 176B
Лучший результат показала Qwen3.8-35B-A3B-Q4_K_M: быстрее справилась с задачей и стабильно следовала инструкциям. Более крупные MoE, gpt-oss-120b и Qwen3.8-Flash-Next в Q3_K_XL и Q4_K_XL, оказались либо медленными, либо склонными к ошибкам и зацикливанию на длинных контекстах.
Логика предсказуемая. Чем больше модель и агрессивнее квантизация, тем больше слоёв уходит на CPU и тем сильнее просадка скорости. На длинном контексте крупные модели чаще теряют нить рассуждения. Детальных токенов/с в исходном материале нет, так что это выводы по факту выполнения задачи, а не по секундомеру.
Qwen3.8-35B-A3B-Q4_K_M: почему она выиграла
35B при примерно 3B активных параметров (A3B) - удачный компромисс для 11 ГБ VRAM. Меньше выгрузки на CPU, меньше давления на RAM, предсказуемое поведение. Квантизация Q4_K_M сохраняет больше качества, чем Q3_K_XL, и укладывается в бюджет памяти. Итог: быстрее, стабильнее, предсказуемее. На картах с 12 ГБ похожая логика работает и для плотных моделей в низких квантах, где выигрыш MoE не так очевиден, и тесты Qwen3.8 27B в Q2 и Q3 против Qwen3.6 35B-A3B MoE показывают, как квантование меняет баланс.
gpt-oss-120b: где начинаются проблемы
120B на 11 ГБ VRAM означает постоянный обмен между GPU и RAM. Отсюда медлительность: каждый токен требует подкачки экспертов из системной памяти. На длинном контексте добавляются ошибки и зацикливание. Модель не плохая, ей просто нужно больше VRAM, чем есть у GTX 1080 Ti.
Qwen3.8-Flash-Next (176B) в Q3_K_XL и Q4_K_XL
Запуск 176B-класса на GTX 1080 Ti остаётся экспериментом на грани возможного. Q3_K_XL и Q4_K_XL дают стартовать, но цена - скорость и стабильность. На длинных контекстах модель ошибается и зацикливается. Годится для разовых экспериментов, но не как рабочая лошадка. Для ориентира: на 12 ГБ VRAM эту же модель в квантовании IQ3_XXS запускали с 14-15 токенами/с и просадкой до 11,3 на 90-100K, о чём есть отдельный отчёт по Qwen3.8-Flash-Next. Это личный эксперимент одного пользователя, цифры не проверялись независимо, а методика описана не полностью.
Поведение на длинном контексте: 32K → 128K
Ключевой факт: при росте контекста с 32K до 128K 35B-модель теряла около 10-15% скорости. Для карты 2017 года с 11 ГБ VRAM это мягкая деградация. У крупных моделей картина хуже: либо просадка сильнее, либо ошибки и зацикливание вместо ответа.
Часть объяснения в архитектуре: гибридная схема DeltaNet + attention позволяет эффективно работать с длинным контекстом. Она и держит 35B-класс в рабочем режиме там, где крупные модели сдают.
Почему крупные модели сдают на 128K
Чем больше модель, тем больше KV-кэш и тем сильнее давление на VRAM и RAM. Агрессивная квантизация Q3_K_XL дополнительно бьёт по качеству внимания. Складываем одно с другим и получаем зацикливание и ошибки на длинных контекстах. Это не баг конкретной модели, а следствие компромиссов железа.
Практический вывод: если задача требует длинного контекста (большие файлы, длинные диалоги, агентные цепочки), Qwen3.8-35B-A3B на этом стенде - разумный выбор.
Стоит ли апгрейд: GTX 1080 Ti против двух RTX 5060 Ti
Точка сравнения: на стенде ast-softpro.ru Qwen 3.8-27B запускали на двух RTX 5060 Ti по 16 ГБ (32 ГБ суммарно), и в квантизации Q4_K_M она выдавала около 24 токенов/с. Современные карты дают заметно больше VRAM и предсказуемую скорость. При этом стоит учитывать, что это другой стенд и другая модель, а по RTX 5060 Ti 16 ГБ встречаются и куда более скромные пользовательские цифры - условия запуска сильно влияют на результат.
Если ваша задача - 35B-A3B-Q4_K_M и она укладывается в 11 ГБ VRAM, апгрейд не обязателен. Он оправдан в трёх случаях: нужен 120B/176B-класс на постоянку, нужен длинный контекст без просадок или нужны параллельные запросы при --parallel больше 1.
Практические выводы и ограничения сетапа
Для связки GTX 1080 Ti плюс 64 ГБ RAM оптимальный выбор - Qwen3.8-35B-A3B-Q4_K_M. 120B и 176B-класс годятся для экспериментов, но не для стабильной ежедневной работы.
Ограничения: 11 ГБ VRAM вынуждают выгружать слои на CPU, поэтому скорость зависит от i9-9900K и RAM. Квантизации Q3_K_XL и Q4_K_XL экономят память, но бьют по качеству. --parallel 1 - вынужденная мера, о параллельных запросах речи не идёт.
Кому подходит такой сетап
Подходит разработчикам и энтузиастам с GTX 1080 Ti, которым нужны локальные MoE-модели для кодовых и агентных задач без апгрейда. Не подходит тем, кому нужен 120B/176B-класс на постоянку, параллельные запросы или максимальное качество без квантизации.
Как проверить модель на своей задаче
Методика простая: запустить llama-server с той же командой, открыть WebUI по http://127.0.0.1:8080, дать модели свою реальную задачу, прогнать её на 32K и 128K, замерить время до рабочего результата и число правок. Такой прогон честнее любого синтетического бенчмарка, потому что показывает, доводит ли модель задачу до конца именно на вашем железе.