LLMCOD перешёл на Qwen 3.8: 2× параллельность, 32K контекст и MTP-ускорение на V100

Контекст задачи

До обновления API LLMCOD работал на Qwen 3.6. Модель справлялась, но по мере роста числа клиентов и усложнения промптов (длинные базы знаний, многошаговые диалоги, агенты) стало понятно: нужен более свежий бэкенд с лучшим качеством и более эффективным использованием GPU.

Цель — получить максимум от имеющегося железа (Tesla V100-SXM2-32GB), не покупая новый GPU.

Что сделали

1. Обновили модель

Перешли с Qwen 3.6 на Qwen 3.8 27B (Dense) в квантовании Q6_K_M (Ultra-Deduplicated). Модель — из серии UD-квантований I-Quants, оптимизированных под минимальную потерю качества при максимальном сжатии.

Размер модели на диске: ~12 ГБ. В VRAM после загрузки всех слоёв на GPU (-ngl 99) — ~18 ГБ.

2. Включили MTP-спекулятивный декодинг

Qwen 3.8 поддерживает Multi-Token Prediction (MTP) — механизм, при котором отдельная драфт-модель предсказывает несколько следующих токенов за один проход, а основная модель проверяет их за один forward. Если драфт угадал — генерация ускоряется; если нет — основная модель корректирует.

Мы используем MTP-модель в квантовании Q4_0 (~3 ГБ VRAM) с параметром --spec-draft-n-max 3 (до 3 токенов за шаг).

Эффект: MTP поднимает скорость генерации примерно на 40–50% по сравнению с обычным autoregressive decoding. В тестах:

• без MTP: ~30 ток/с

• с MTP: ~45 ток/с (одиночный запрос)

• с MTP, два параллельных: ~26 ток/с на каждый поток

3. Распределили контекст: 2×32K с KV-кэшем в q8_0

Главная задача — дать клиентам большой контекст (32K токенов на диалог) и при этом сохранить параллельную обработку двух запросов.

Проблема: KV-кэш для 2 слотов по 32K в формате f16 (по умолчанию) занимает ~10 ГБ VRAM. Вместе с весами модели (18 ГБ) и MTP-моделью (3 ГБ) получается ~31 ГБ — на грани OOM.

Решение: Квантование KV-кэша в q8_0 — флаги --cache-type-k q8_0 --cache-type-v q8_0. Это уменьшает размер кэша примерно вдвое при практически незаметной потере качества.

Итоговая конфигурация

iniExecStart=/opt/llama.cpp/build/bin/llama-server \  -m /opt/models/qwen38-27b/Qwen3.8-27B-UD-Q6_K_M.gguf \  -md /opt/models/qwen38-27b/MTP/mtp-Qwen3.8-27B-Q4_0.gguf \  --spec-type draft-mtp --spec-draft-n-max 3 \  -ngl 99 \  -c 65536 --cache-type-k q8_0 --cache-type-v q8_0 \  --port 8080 --host 0.0.0.0 \  --jinja --reasoning off \  --alias qwen3.8 --parallel 2

ExecStart=/opt/llama.cpp/build/bin/llama-server \  -m /opt/models/qwen38-27b/Qwen3.8-27B-UD-Q6_K_M.gguf \  -md /opt/models/qwen38-27b/MTP/mtp-Qwen3.8-27B-Q4_0.gguf \  --spec-type draft-mtp --spec-draft-n-max 3 \  -ngl 99 \  -c 65536 --cache-type-k q8_0 --cache-type-v q8_0 \  --port 8080 --host 0.0.0.0 \  --jinja --reasoning off \  --alias qwen3.8 --parallel 2

Бенчмарк: параллельная обработка

Для проверки параллельности отправили два запроса одновременно — «напиши 500 слов про космос» и «напиши 500 слов про океан». Оба стартовали в одну секунду (PID 20935 и 20936).

Разница во времени — меньше секунды. Оба слота работали независимо, без очереди.

Разбор по памяти

Для сравнения, KV-кэш в f16 занял бы ~10 ГБ, и итого было бы ~31 ГБ — на грани OOM.

Что получили клиенты

• Контекст 32K на каждый диалог — десятки тысяч слов, большие промпты, базы знаний.

• Два одновременных запроса без очереди — виджет и API могут работать параллельно.

• MTP-ускорение — генерация быстрее на 40–50% по сравнению с обычным режимом.

• OpenAI-совместимый API — ключи и эндпоинты не менялись, интеграции работают без изменений.

Деплой

Модель и сервер управляются через systemd (qwen-llama-server.service), автозапуск включён. При перезагрузке ОС сервис стартует автоматически с актуальными параметрами.

LLM API:  Чат без ключа: 

Дата: 10 сентября 2026 · LLMCOD · Tesla V100-SXM2-32GB · llama.cpp + MTP