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. В тестах:

1. без MTP: ~30 ток/с
2. с MTP: ~45 ток/с (одиночный запрос)
3. с 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

Параметр Значение Модель Qwen 3.8 27B, Q6_K_M (UD)Драфт-модель MTP, Q4_0GPU Tesla V100-SXM2-32GB Общий контекст 65 536 токенов Контекст на слот 32 768 токенов Параллельных слотов 2KV-кэшq8_0 (K и V)VRAM всего~26.3 ГБ из 32 ГБ Запас VRAM~6.5 ГБСкорость (1 запрос)~45 ток/с Скорость (2 параллельных)~26 ток/с на поток

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

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

Космос Океан Prompt tokens 2323 Completion tokens 804777 Время генерации 30.7 сек 29.7 сек Скорость 26.2 ток/с 26.1 ток/с Draft accepted 447 из 1074435 из 1023

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

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

Компонент VRAM Веса модели (Q6_K_M, все слои на GPU)~18 ГБMTP-модель (Q4_0)~3 ГБKV-кэш 2×32K в q8_0~5 ГБ Прочее (CUDA context, буферы)~0.3 ГБ Итого~26.3 ГБ

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

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

1. Контекст 32K на каждый диалог — десятки тысяч слов, большие промпты, базы знаний.
2. Два одновременных запроса без очереди — виджет и API могут работать параллельно.
3. MTP-ускорение — генерация быстрее на 40–50% по сравнению с обычным режимом.
4. OpenAI-совместимый API — ключи и эндпоинты не менялись, интеграции работают без изменений.

Деплой

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

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

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