Какую MoE-модель выбрать для локального кодинга на GTX 1080 Ti: перплексия против реальной скорости

В первой статье , посвященной тестированию возможности запуска локальной модели на домашнем ПК, с не самой сильной и новой видеокартой, я показал, что 176B-класс Qwen3.8-Flash-Next можно запустить на GTX 1080 Ti с 11 GB VRAM, если использовать llama.cpp, правильный offload и DeepSeek Harness. Скорость оказалась скромной - около 11 токенов/с, но схема работала.

Во второй статье для этого же оборудования был проведен отбор несколько MoE-моделей (35B, 120B, 176B) в реальной задаче - написание простого погодного сервера на Go. Победителем неожиданно стала Qwen3.8-35B-A3B-Q4_K_M: она показала 30 токенов/с и справилась с задачей за 15 минут, тогда как Flash-Next «думала» три часа.

После публикации в комментариях мне указали на несколько моделей, которые я пропустил. Я провёл свой «информационно-патентный поиск» и решил закрыть пробел: протестировать две основные модели, которые чаще всего упоминались, и одну дополнительную - Qwen3.8-35B-A3B-Distill.APEX-I-MiniPlus-V2.1.gguf, которая показалась мне интересной по описанию.

В этой статье я представлю результаты изменения перплексии (PPL) на двух корпусах: естественный язык WikiText-2 и Go-код, а также скорости генерации через llama-bench. Это даст более объективную картину, чем просто «написание программы на время».

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

Стенд не изменился с предыдущих статей:

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

• CPU: Intel Core i9-9900K;

• RAM: 64 GB;

• ОС: Ubuntu Linux;

• llama.cpp: сборка с поддержкой архитектуры qwen4exp, CUDA 12.x, CMAKE_CUDA_ARCHITECTURES=61;

• Модели: GGUF-файлы.

Все замеры PPL проводились с одинаковыми параметрами: n_ctx=512, batch_size=2048, n_seq=4. Число слоёв на GPU (-ngl) подбиралось так, чтобы модель помещалась без OOM - это влияет на скорость, но не влияет на перплексию.

Про приготовления

Для оценки на естественном языке использовался стандартный wiki.test.raw из WikiText-2. Для оценки на коде я собрал корпус Go-кода из GitHub-подмножества The Pile. Получилось 6,6 МБ, 237 923 строки, этого хватило на 4570 чанков при контексте 512, что даёт очень стабильную оценку.

Go выбран не случайно: в последнее время я пишу код именно на нём, и мне важно понимать, насколько модель «чувствует» этот язык, а не только Python из популярных бенчмарков.

Что тестировалось

Результаты: перплексия

WikiText-2 (естественный язык), n_ctx=512

Обратите внимание: у 27B Q4_K_M и 35B-A3B Q4_K_M практически одинаковая PPL - 6.96 против 6.956. При этом дополнительная MoE-версия в 1.7 раза быстрее. Эта модель чуть хуже по качеству (7.15), но ещё быстрее (4.09 сек/проход).

Go-корпус (код), n_ctx=512, 4570 чанков

На Go-коде 35B-A3B Q4_K_M показала лучшую PPL - 1.4849. Это заметно ниже, чем у 27B (1.5943) и дополнительной модели (1.5662). То есть MoE-модель лучше предсказывает Go-код, несмотря на меньшее число активных параметров.

Почему PPL на коде такая низкая?

Перплексия 1.48 - 1.59 на Go может показаться «слишком хорошей». Причина в том, что код гораздо более структурирован и предсказуем, чем естественный язык: повторяющиеся ключевые слова, отступы, скобки, типовые конструкции. Модель быстро выучивает эти паттерны. Поэтому абсолютные значения PPL на коде нельзя сравнивать с PPL на WikiText, это разные шкалы. Важно только соотношение между моделями на одном и том же корпусе.

Результаты: скорость (llama-bench)

Здесь картина однозначная:

• 27B - самая медленная по генерации (4.04 t/s) из-за плотной архитектуры: все 27B параметров участвуют в каждом токене.

• 35B-A3B Q4_K_M - 21.4 t/s, потому что активируется ~3B параметров.

• Distill IQ3_XXS - 31.66 t/s, самая быстрая. Меньший квант + MoE + больше слоёв на GPU дают почти 8-кратный отрыв от плотной 27B.

По обработке промпта (pp512) Distill тоже лидирует - 621 t/s.

Анализ: что важнее PPL или скорость?

Давайте сопоставим все данные в одной таблице.

35B-A3B Q4_K_M выигрывает по качеству на обоих корпусах: и на естественном языке, и на Go. При этом она в 5.3 раза быстрее плотной 27B по генерации.

Distill IQ3_XXS проигрывает по PPL совсем немного (7.15 против 6.96 на Wiki, 1.566 против 1.485 на Go), но даёт в 1.5 раза больше токенов/с. Для агентных задач, где важна скорость итераций, это может быть решающим.

27B UD-Q4_K_M не даёт ни лучшего качества, ни скорости. Единственное её преимущество - меньший размер (15.3 GiB против 20.2 GiB), что может быть важно при ограниченном диске или VRAM.

Рекомендации

Если вам нужен баланс качества и скорости

Qwen3.8-35B-A3B-Q4_K_M это оптимальный выбор. Лучшая PPL на обоих корпусах, 21.4 t/s генерации, 392 t/s обработки промпта. Именно её я рекомендовал в прошлой статье, и новые данные это подтверждают.

Если вам нужна максимальная скорость

Qwen3.8-35B-A3B-Distill.APEX-I-MiniPlus-V2.1 (IQ3_XXS) дает 31.66 t/s. Потеря качества минимальна (PPL 7.15 против 6.96), а скорость почти вдвое выше. Хороший выбор для длинных агентных сессий и пакетной обработки.

Если у вас мало места на диске

Qwen3.8-27B-UD-Q4_K_M — 15.3 GiB. Но будьте готовы к 4 t/s генерации. Для интерактивной работы это тяжело.

Чего я бы не советовал

Пытаться запустить плотную 27B на GTX 1080 Ti для агентных задач. Скорость 4 t/s делает многошаговые сценарии мучительно медленными. MoE-архитектура здесь выигрывает с огромным отрывом.

Общий вывод

Главный результат этого тестирования: MoE-архитектура - это не компромисс, а преимущество на слабом железе. Qwen3.8-35B-A3B в кванте Q4_K_M обходит плотную 27B и по качеству (PPL 6.956 против 6.964 на Wiki, 1.485 против 1.594 на Go), и по скорости (21.4 против 4.04 t/s). При этом активируется всего ~3B параметров на токен.

Distill-версия в IQ3_XXS показывает, что даже при агрессивном квантовании можно сохранить приемлемое качество и получить 31.66 t/s. Это делает её отличным кандидатом для агентных сред, где важна каждая секунда.

GTX 1080 Ti, выпущенная почти десять лет назад, продолжает оставаться рабочей лошадкой для локального ИИ — при условии правильного выбора модели и кванта. Перплексия и llama-bench дают объективную картину, которая хорошо согласуется с субъективным опытом написания кода.