GTX 1080 Ti не сдаётся: выбираем лучшую MoE-модель для llama-server среди 35B, 120B и 176B

Привет, Хабр! В прошлой статье я рассказывал, как запустить 176B-класс Qwen3.8-Flash-Next на GTX 1080 Ti, и тогда это был, скорее, эксперимент на грани возможного. Но недавно я наткнулся на материал на ast-softpro.ru, где ребята запустили Qwen 3.8-27B на двух RTX 5060 Ti по 16 ГБ (32 ГБ суммарно). Если коротко, они подтвердили, что гибридная архитектура DeltaNet + attention позволяет эффективно работать с длинным контекстом, а на их стенде модель в квантизации Q4_K_M выдавала около 24 токенов/с. Именно это, а также комментарии на Хабре, подтолкнуло меня к серии экспериментов, о которых пойдёт речь. Забегу наперед, я был удивлён результату: на моём стенде, который я опишу ниже, результаты на одной из моделей, которая как минимум не хуже, оказались сопоставимыми.

Мой тестовый стенд

Конфигурация, на которой проводились все замеры, осталась прежней — той самой, что описана в моей предыдущей статье:

• GPU: NVIDIA GeForce GTX 1080 Ti — 11 GB VRAM;

• CPU: Intel Core i9-9900K;

• RAM: 64 GB;

• ОС: Ubuntu Linux;

• Сборка llama.cpp: с поддержкой архитектуры qwen4exp.

Именно на этой машине я запускал сервер llama-server для каждой из тестируемых моделей, и она не такая современная, как у экспериментаторов из AST-SoftPro.

Как я запускал сервер

Управление сервером я осуществлял из встроенного WebUI, который реализуется в последних версиях llama-server. Это очень удобный режим: достаточно открыть браузер по адресу http://127.0.0.1:8080 или иному, который можно указать при запуске сервера, и вы получаете полноценный интерфейс для чата, отладки и управления параметрами модели в реальном времени. Мне лично такой способ работы полностью подходит — он избавляет от необходимости использовать, для работы с сервером, различные harness оболочки.

Вот команда, которой я запускал сервер (с подстановкой нужной модели из списка):

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 включает использование шаблонов чата, что облегчает пользование сервером пользователю, а --parallel 1 ограничивает количество одновременных запросов одним — для моего сценария этого достаточно.

Модели, которые я тестировал

В ходе серии экспериментов я прогнал несколько MoE-моделей, каждая из которых имеет свои особенности:

• gpt-oss-120b-UD-Q8_K_XL.gguf — 120-миллиардная модель от OpenAI с архитектурой MoE и активными параметрами около 5.1B на токен. Квантизация Q8_K_XL сохраняет высокую точность, но требует значительного объёма памяти.

• Qwen3.8-Flash-Next-UD-Q3_K_XL-reap256.gguf — 125B MoE-модель (класс 176B с учётом n-gram embedding-таблиц) в агрессивной квантизации Q3_K_XL с обрезкой экспертов до 256 (reap256). Это облегчённая версия для запуска на ограниченных ресурсах (активными параметрами около 6B на токен).

• Qwen3.8-Flash-Next-UD-Q4_K_XL.gguf — та же 125B MoE-модель, но в более качественной квантизации Q4_K_XL. Требует больше памяти, но даёт лучшую точность.

• Qwen3.8-35B-A3B-Q4_K_M.gguf — 35B MoE-модель с примерно 3B активных параметров на токен, в сбалансированной квантизации Q4_K_M. Занимает около 21 ГБ, что позволяет разместить её частично в VRAM, а частично в RAM.

Результаты: кто оказался лучшим

Как показали модели на моей тестовой программе (написание кода простейшего погодного сервера на Go, с получением данных о погоде через API общедоступных погодных серверов):

• gpt-oss-120b оказалась быстрой, но на больших контекстах с кодом (при реализации дополнительных фишек) начинала ошибаться: зацикливалась в правках, которые приводили к новым ошибкам, уничтожала уже реализованный функционал . Для агентной работы с длинными сессиями это критично.

• Qwen3.8-Flash-Next в обеих квантизациях (Q3_K_XL и Q4_K_XL) показали себя очень медленными — они очень долго «думали» (скорость генерации текста максимум 11 tokens/s , и написание тестовой программы (с перерывами) заняло примерно 3 часа.

• Qwen3.8-35B-A3B-Q4_K_M оказалась явным фаворитом. Она быстро справилась с задачей, продемонстрировав Prompt processing speed до 400 tokens/s и Generation speed до 30 tokens/s в зависимости от значения --ctx-size. Что особенно важно: при увеличении контекста с 32K до 128K падение скорости составило всего около 10–15% — это очень достойный показатель. Код тестовой программы написала приблизительно за 15 минут (на одну итерацию кода уходит ~ 1,5 — 2 минуты), причём с соблюдением всех инструкций и без лишних правок.

Почему Qwen3.8-35B-A3B-Q4_K_M стала лучшей.

Подводя итог, могу выделить её главные достоинства:

• Скорость: она действительно быстрая даже на GTX 1080 Ti с частичной выгрузкой в RAM.

• Понимание кода: хорошо разбирается в программировании, генерирует рабочий код с первого раза.

• Гибкость: можно выбирать размерность объёма размышлений — от кратких ответов до подробных рассуждений.

• Следование инструкциям: слушается указаний пользователя и действует согласно системной инструкции, что критично для агентных сценариев.

Я рекомендую эту модель для локального запуска на схожей конфигурации. Она показала себя лучше, чем более крупные MoE-модели, и при этом потребляет меньше ресурсов. Если вы ищете баланс между скоростью, качеством и потреблением памяти — Qwen3.8-35B-A3B-Q4_K_M определённо стоит попробовать.