Как разогнать локальную Qwen3.8-Flash-Next 177B LLM на одной карте 48 ГБ: до 917 токенов в секунду

Месяц назад я запустил на одной видеокарте с 48 ГБ памяти модель, которая в файле занимает 104 ГБ. Она заработала — и сам по себе этот факт оказался интереснее, чем я ожидал. Но первые цифры были скромными: 212 tok/s на чтении входа и 35 tok/s на генерации. Сегодня та же модель на той же карте читает документы со скоростью 917 tok/s.

Ниже — что именно дало этот прирост, в порядке отдачи, с замерами на каждом шаге. Плюс честная часть: генерация за тот же месяц просела с 52 до 41 tok/s, и это осознанный размен, а не деградация. И список того, что не сработало, — он получился длиннее списка того, что сработало.

Сборка сервера, выбор слота, диагностика карты и проброс в виртуальную машину — в предыдущей статье. Здесь только настройка и замеры.

Что получилось в итоге

Почему 104 ГБ вообще работают на карте с 48 ГБ

Модель устроена как смесь экспертов: 48 слоёв, на каждом 512 небольших подсетей, и на каждый токен маршрутизатор включает всего 10 из них. Активных параметров при этом около 6 млрд из 177. Считается мало, но веса всех экспертов должны быть доступны в любой момент — отсюда и 104 ГБ на диске.

Это и позволяет разделить нагрузку: механизм внимания и часть экспертов держать на карте, остальных — в оперативной памяти сервера. Ключевое условие приёма — оперативной памяти должно хватить на все веса плюс запас. Без 192 ГБ этот режим невозможен в принципе, и никакая настройка тут не поможет.

Раскладка задаётся ключом -ot (override tensor): регулярным выражением указывается, эксперты каких слоёв уезжают на карту, а какие остаются в памяти процессора.

Рычаг первый: заполнить видеопамять экспертами

Стартовая точка была неприлично расточительной: все эксперты в оперативной памяти, карта занята на 5 ГБ из 48. Сорок три гигабайта простаивали, пока я радовался, что модель вообще запустилась.

Дальше — перебор до отказа:

Плюс 48 % к генерации и удвоение чтения — только за счёт того, что карту перестали держать пустой. Правило простое: заполнять до отказа и отступать на шаг назад.

Оговорка, которая стоила мне девяти слоёв: максимальная раскладка несовместима со зрением. Энкодеру изображений нужен примерно гигабайт видеопамяти, и при 27 слоях его не остаётся. Со сканами рабочая раскладка — 18 слоёв.

Рычаг второй: не читать модель с диска по частям

По умолчанию движок отображает файл весов в память и подгружает страницы по мере обращения. Для модели, у которой эксперты дёргаются вразнобой на каждом токене, это означает постоянные обращения к диску.

Ключ --no-mmap заставляет прочитать все 104 ГБ в оперативную память один раз при старте. Замер на одном и том же документе в 5 394 токена:

Чтение ускорилось в 1,8 раза, генерация не изменилась. Платите оперативной памятью — той самой, ради которой всё и затевалось.

Рычаг третий: большая пачка чтения

Входной текст обрабатывается пачками токенов. По умолчанию пачка — 512; ключи -b 2048 -ub 2048 увеличивают её вчетверо. Карта в этот момент занята вычислениями плотно, а не ждёт очередную порцию.

Генерация при этом просела на процент — с 42 до 41 tok/s. Размен очевидный: минус процент на генерации, плюс 128 % на чтении.

Пачки 3072 и 4096 я тоже пробовал — они не помещаются на карту даже если убрать экспертов до 17 и 15 слоёв. После настройки карта занята на 46,3 из 48,9 ГБ, и запаса больше нет.

Про честность цифры «212 → 917»

Базы у этих замеров разные, и я обязан это сказать. 212 tok/s — синтетический тест на входе в 512 токенов на одном движке; 917 tok/s — реальный документ на 18,6 тыс. токенов на другом. Сравнивать их напрямую некорректно.

Честные сравнения внутри одной базы такие: раскладка экспертов — 212 → 426 tok/s на синтетике; отказ от отображения файла — 201 → 365 tok/s на одном документе; большая пачка — 403 → 917 tok/s на другом. Общий множитель за месяц — примерно четырёхкратный, и он складывается из трёх независимых шагов.

Почему генерация стала медленнее

В начале сентября модель выдавала 51,9 tok/s, сейчас — 41–44. Это не поломка, а четыре сознательных решения:

Отдельно проверил подозрение, что скорость съедают сами слоты: один запрос при одном слоте и при четырёх идёт одинаково — 43,5 против 43,9 tok/s. Слоты сами по себе ничего не стоят; платить приходится, только когда они реально заняты.

Если зрение не нужно — откат на быстрый движок и 27 слоёв возвращает 52 tok/s. Я выбрал сканы.

Параллельность: больше работы, а не быстрее ответ

Сервер поднимает четыре слота с общим окном контекста. Ключ -np 4 ставить как раз не нужно — он делит окно на четыре части по 65 тыс. токенов каждая, и длинный документ перестаёт помещаться.

Отсюда правило, которое стоит записать на стене: параллельность повышает пропускную способность, а не скорость одного ответа. Пользователь, который ждёт ответа на экране, от четырёх потоков ничего не выигрывает — он проигрывает, если в этот момент рядом молотят три длинных разбора.

Поэтому очередь пришлось организовать на стороне приложения: не больше четырёх одновременных обращений к модели, приоритет у того, чего человек ждёт на экране, и жёсткий предел на длинные фоновые разборы — не больше трёх слотов из четырёх, один всегда свободен под интерактив. До этого один разбор большой спецификации занимал все четыре потока и держал интерфейс минутами.

И ещё одно ограничение общего окна: четыре запроса по 100 тыс. токенов одновременно не влезут. Очень большие документы параллельно друг другу запускать нельзя.

Что не сработало

Это самая полезная часть, потому что все перечисленные приёмы выглядят разумно и рекомендуются в сети.

Спекулятивное декодирование. Идея: маленькая модель пишет черновик, большая его проверяет. На гибридной смеси экспертов не работает — проверка каждой пачки догадок требует поднимать экспертов из оперативной памяти, и это дороже, чем сгенерировать токен честно.

Встроенный механизм многотокенного предсказания в этом файле весов отсутствует — движок честно сообщает, что нужных слоёв в модели нет.

Уменьшить число активных экспертов. Если на токен работает 10 из 512, может, хватит шести? Проверил:

На шести экспертах счётчик токенов радует, а модель уходит в рассуждения и не сходится к ответу. Мерить надо не токены в секунду, а время до готового результата — это разные метрики, и вторая единственная имеет отношение к работе.

Больше потоков процессора. 32 потока вместо 16 дают 28 tok/s против 41. Упор в шину памяти: лишние потоки дерутся за неё, а не помогают.

Резать документ на части ради скорости. Спецификация на 28 тыс. токенов целиком — 166 с и 38 корректных требований. Она же частями — 213 с и 107 «требований» с повторами и мусором. Дольше и хуже.

Быстрая модель вместо большой?

Логичный вопрос: зачем гибрид, если модель поменьше целиком влезает на карту и работает вдвое быстрее? Проверил на реальном наборе документов.

Причина провала на сканах у третьей модели любопытная: страница сжимается у неё в 317 токенов против 2 200 у основной. Изображение ужимается сильнее — мелкие цифры теряются, и в реквизитах появляются ошибки.

Вывод: маленькая модель быстрее, но на документах выдумывает. Цена одной выдуманной даты в договоре выше, чем выигрыш в десять секунд на разборе.

Рабочий рецепт

1. Оперативной памяти — не меньше размера весов плюс запас. Виртуальная машина на одном NUMA-узле с картой, динамическое выделение памяти выключено.
2. Заполнить видеопамять слоями экспертов до отказа и отступить на шаг: без зрения 27 слоёв, со зрением 18.
3. Один ключ -ot со всем перечислением через запятую. Несколько отдельных ключей сборка молча проигнорирует, оставив только последний.
4. --no-mmap — модель целиком в оперативную память.
5. -b 2048 -ub 2048, если помещается по видеопамяти.
6. -t 16 потоков процессора, не больше.
7. Кэш внимания в 8 бит (-ctk q8_0 -ctv q8_0) и flash attention (-fa on).
8. Не ставить -np, если окно контекста должно быть общим.
9. Число активных экспертов не трогать.
10. Размышления выключать на задачах извлечения данных, иначе модель израсходует лимит на внутренний монолог и вернёт пустой ответ.
11. Температура 0–0,3 на разборе документов.
12. Очередь и приоритеты — на стороне приложения, не на стороне модели.

Время ответа прикидывается так: токены входа поделить на 917, токены ответа — на 41, сложить. Русский текст — примерно 2,5 знака на токен; таблицы и текст из PDF дают заметно хуже.

Грабли

• Ключ -np N делит окно контекста на N частей. Без него четыре слота работают с общим окном — а это как раз то, что нужно.
• Несколько ключей -ot — работает только последний. Остальные молча игнорируются, и эксперты остаются в оперативной памяти. Проверять по занятой видеопамяти, а не по отсутствию ошибок.
• В файле службы обратные слэши в регулярных выражениях нужно удваивать, иначе раскладка тихо не применяется.
• Сервер по умолчанию слушает только локальный адрес — приложение с другой машины получает отказ соединения.
• Модель пишет блок размышлений даже при выключенных размышлениях — вырезать на стороне приложения.
• Межсетевой экран между машинами — приложение молча деградирует, когда порт модели закрыт. Отдельная проверка доступности спасает часы разбирательств.
• Максимальная раскладка экспертов несовместима со зрением — не хватает гигабайта на энкодер.

Выводы

• Модель на 177 млрд параметров на одной карте 48 ГБ — рабочий режим, а не трюк, если хватает оперативной памяти под все веса.
• Три рычага по порядку отдачи: заполнить карту экспертами, прочитать модель в память целиком, увеличить пачку чтения. Вместе — примерно четырёхкратное ускорение чтения на той же карте.
• Популярные ускорители на гибридной смеси экспертов не работают. Спекулятивное декодирование, урезание активных экспертов, лишние потоки процессора — всё проверено и всё вредит.
• Параллельность — это пропускная способность, а не скорость. Организовывать её нужно в приложении, с приоритетом интерактивным задачам.
• Скорость генерации разменивается на возможности. 52 tok/s без зрения против 41 со сканами — выбор, а не деградация.

Если вам нужно поднять такой контур под свои задачи — подобрать конфигурацию под конкретные модели и документы, выжать из уже купленной карты то, что она может, или честно посчитать, хватит ли одной карты, — напишите на 77rus@outlook.com. Начну с того, что скажу, где эта затея не окупится.