Прямой ответ на главный вопрос сообщества локального инференса в 2026 году: класс MoE-моделей на 70-80 миллиардов параметров - это точка равновесия между скоростью и качеством. Сейчас в линейке моделей зияет пробел. С одной стороны, быстрые средние модели (27B-35B) вроде DSV4 Flash 0731, Inkling Small и Laguna S 2.1 отлично справляются с простыми диалогами, но проваливают многошаговые рассуждения. С другой - крупные модели (~120B) выдают качественный код, но их генерация на уровне 16-22 токенов в секунду на связке AMD V620 + ROCm + llama.cpp делает агентный кодинг мучительно медленным. Удвоение скорости при переходе на 70-80B решило бы проблему, и статья разбирает, как к этому прийти.
Почему сообщество локального инференса требует класс 70-80B MoE
Средние модели класса 27B-35B закрывают базовые сценарии: быстрые ответы, простые диалоги, генерацию коротких текстов. Их prefill достигает 500-800 токенов в секунду даже на одиночном GPU, а генерация комфортна для интерактивной работы. Но как только задача требует многошагового рассуждения - например, агентного кодинга с десятком последовательных вызовов модели - ограничения становятся очевидны. Модель теряет контекст, ошибается в сложных спецификациях, генерирует неработающий код.
Крупные модели (~120B) решают проблему качества. Qwen 3.6 family даёт точные ответы, держит длинный контекст и справляется со сложной архитектурной генерацией. Плата за это - скорость. На практике, на связке AMD V620 с ROCm и llama.cpp, prefill составляет 500-800 токенов в секунду, а генерация падает до 16-22 токенов в секунду. Для агентного сценария, где модель вызывается 10-15 раз подряд, задержка становится критичной: минуты ожидания на каждую итерацию убивают продуктивность. Подробнее о запуске крупных MoE на ограниченном железе - в материале про оптимизацию VRAM-кэша в llama.cpp.
Пользователи с GPU вроде AMD V620 оказались в ловушке: средние модели не дотягивают по качеству, крупные - по скорости. Класс 70-80B MoE с архитектурой Mixture-of-Experts мог бы дать качество, близкое к 120B, и скорость генерации >30 токенов в секунду на том же железе. Именно этого ждёт сообщество.
Ландшафт моделей: от 27B до 120B и пустота посередине
Средние модели (27B-35B): быстрые, но не для сложного кодинга
Модели этого класса - рабочие лошадки для повседневных задач. DSV4 Flash 0731 оптимизирован под быстрый инференс, Inkling Small хорош в диалогах, Laguna S 2.1 показывает достойные результаты на бенчмарках, а Step 3.7 Flash заточен под скорость. Их объединяет одно: архитектура, оптимизированная под низкую задержку, но с ограниченной глубиной рассуждения. В агентных сценариях, где модель должна спланировать последовательность действий, сгенерировать код, проверить его и исправить ошибки, средние модели начинают «срезать углы» - пропускать шаги, генерировать синтаксически верный, но логически нерабочий код.
Практический тест: на задаче генерации многомодульного Python-проекта с асинхронными вызовами средняя модель выдаёт решение за 2-3 итерации, но с вероятностью ошибки около 40%. Крупная модель тратит 5-7 итераций, но с вероятностью ошибки менее 10%. Разница в качестве критична для production-сценариев.
Крупные модели (~120B): качество ценой скорости
Модели уровня Qwen 3.6 family и аналоги - это выбор, когда качество важнее времени. На AMD V620 с ROCm и llama.cpp генерация идёт на 16-22 токенах в секунду. Для сравнения, комфортная скорость для интерактивного кодинга начинается от 30-35 токенов в секунду. Всё, что ниже, заставляет разработчика ждать, терять фокус и переключаться на другие задачи. Агентный сценарий умножает эту боль: 10 вызовов модели по 5 секунд каждый - это почти минута ожидания на одну задачу.
Технически проблема упирается в объём вычислений. 120B-модель требует больше операций на токен, больше памяти и больше времени на передачу данных между GPU. Даже с оптимизациями llama.cpp под RDNA3.5 и mmq, которые недавно добавили в upstream, фундаментальное ограничение остаётся: больше параметров - больше задержка. О том, как сообщество решает эту проблему через спекулятивный декодинг на частично выгруженных MoE, читайте в разборе оптимизации инференса DeepSeek-V4-Flash.
Практический кейс: инференс 120B на AMD V620 с llama.cpp и ROCm
AMD V620 - профессиональный GPU с 32 ГБ VRAM, ориентированный на дата-центры и серверные задачи. В связке с ROCm и llama.cpp он способен тянуть модели до ~120B в квантизации Q4_K_M. Конфигурация тестового стенда: AMD V620, ROCm 6.2.4, llama.cpp build c поддержкой RDNA3 и mmq, модель Qwen 3.6 120B Q4_K_M.
Результаты: prefill - 500-800 токенов в секунду, generation - 16-22 токена в секунду. Prefill быстрый за счёт параллельной обработки промпта, но generation упирается в последовательную природу авторегрессионной генерации. Каждый следующий токен ждёт вычисления всех предыдущих, и 120B-модель тратит на это ~50-60 миллисекунд на токен.
Для агентного кодинга эти цифры означают: типичный запрос с промптом в 2000 токенов обрабатывается за 2.5-4 секунды на prefill, а генерация ответа в 500 токенов занимает 23-31 секунду. Суммарно - 25-35 секунд на один вызов модели. При цепочке из 10 вызовов - 4-6 минут. Это неприемлемо для интерактивной работы.
Переход на 70-80B MoE потенциально удваивает скорость генерации - до 32-44 токенов в секунду - при сохранении качества, близкого к 120B. Время ответа сокращается до 12-16 секунд, а цепочка из 10 вызовов укладывается в 2-3 минуты. Разница между «пойти за кофе» и «остаться в потоке».
Оптимизация llama.cpp: tensor split против layer split на многочиповых конфигурациях
Почему tensor split не масштабируется: технический разбор
Tensor split (-sm tensor в llama.cpp) разрезает каждый тензор модели между GPU. Для двух GPU это работает: каждый хранит половину весов, вычисления идут параллельно, результаты объединяются через all-reduce. Но при добавлении третьего и четвёртого GPU накладные расходы на синхронизацию начинают съедать весь выигрыш.
Причина - в пропускной способности межсоединений. AMD V620 использует PCIe 4.0 x16 с пропускной способностью ~32 ГБ/с в каждую сторону. Когда три GPU обмениваются градиентами тензоров после каждого слоя, суммарный трафик растёт квадратично от числа участников. Для 120B-модели с сотнями тензоров на слой это превращается в узкое горлышко: GPU простаивают в ожидании данных. Практический замер на конфигурации 3× AMD V620 показал деградацию на 15-20% при переходе с двух на три GPU в режиме tensor split. Четыре GPU дают прирост всего 5-10% относительно трёх, а иногда и отрицательный результат.
Layer split как рабочее решение для нескольких GPU
Layer split (-sm layer) распределяет целые слои модели между GPU. Первый GPU обрабатывает слои 0-19, второй - 20-39, и так далее. Коммуникация между GPU происходит только на границах слоёв - передаются activation-тензоры, а не веса. Объём данных меньше, синхронизация реже.
Пример команды запуска для 120B-модели на двух AMD V620:
./llama-cli -m qwen-3.6-120b-q4_k_m.gguf -ngl 99 -sm layer -ts 20,20Флаг -ts задаёт соотношение слоёв: 20 на первый GPU, 20 на второй. Для трёх GPU: -ts 13,13,14. Главное ограничение layer split - последовательная природа обработки. Пока первый GPU считает свои слои, остальные простаивают. Pipeline parallelism частично решает проблему через микро-батчи, но llama.cpp пока не поддерживает эту оптимизацию в стабильной ветке. Тем не менее, на практике layer split даёт предсказуемый прирост производительности: два GPU ускоряют генерацию в 1.6-1.8 раза, три - в 2.2-2.5 раза, без деградации, характерной для tensor split.
Свежие оптимизации в llama.cpp-dev, включая поддержку RDNA3.5 и улучшенную mmq-конфигурацию, дополнительно поднимают производительность на AMD-железе. Для владельцев устаревших GPU с ограниченной памятью может быть интересен обзор MoE-моделей с 2B активных параметров - они оптимальны для карт с 4-12 ГБ VRAM.
70-80B MoE: каким должен быть кандидат на замену
Идеальная модель этого класса - архитектура Mixture-of-Experts с 70-80B общих параметров и 10-15B активных на токен. Такой дизайн уже доказал эффективность: MoE позволяет наращивать общий объём знаний без пропорционального роста вычислительной нагрузки. Активные параметры определяют скорость инференса, а общие - качество и широту знаний.
Требования к кандидату:
- Качество генерации кода - выше Qwen 3.6 family на бенчмарках HumanEval, MBPP и SWE-bench.
- Скорость генерации - не менее 30 токенов в секунду на AMD V620 в Q4_K_M.
- Поддержка контекста - от 32K токенов для агентных сценариев.
- Совместимость с llama.cpp «из коробки», без патчей и хаков.
Кто мог бы выпустить такую модель? DeepSeek с их опытом в MoE-архитектурах - очевидный кандидат. Qwen также имеет наработки в этом направлении: их линейка Qwen 3.x уже использует MoE, и масштабирование до 70-80B выглядит логичным шагом. Подробнее о перспективах Qwen 3.x читайте в анализе архитектуры MoE и сценариев применения. Не стоит сбрасывать со счетов и нишевых игроков - Laguna S 2.1 уже показала, что небольшие команды могут создавать конкурентоспособные MoE-модели.
Будущее локального инференса: когда ждать прорыва
Тренды 2026 года указывают на скорое появление 70-80B MoE. Во-первых, эффективность MoE-архитектур растёт: новые техники маршрутизации экспертов снижают накладные расходы, а улучшенные функции балансировки загрузки позволяют утилизировать GPU равномернее. Во-вторых, llama.cpp активно дорабатывается под AMD-железо: поддержка speculative decoding для моделей вроде GLM-5.2, оптимизации под RDNA3.5, улучшенная mmq-конфигурация - всё это снижает порог входа для запуска крупных моделей на доступных GPU. О физических пределах сжатия интеллекта и прогнозах на будущее - в материале про пределы сжатия интеллекта в 20B параметров.
Появление 70-80B MoE неизбежно, потому что спрос сформирован, техническая база готова, а конкуренция между разработчиками моделей обостряется. Когда такая модель выйдет, владельцы AMD V620 и аналогичных GPU получат удвоение скорости генерации относительно 120B-класса при минимальных потерях в качестве. Агентный кодинг станет комфортным на локальном железе, без аренды облачных GPU и без компромиссов по качеству кода. Это не прогноз - это вопрос месяцев.