Qwen в проде ломается не на модели, а на неправильном выборе режима инференса

Qwen в проде ломается не на модели, а на неправильном выборе режима инференса

Если нужен универсальный стек под чат, extraction и tool-calling, Qwen обычно берут не «самую большую», а ту, что влезает в целевой latency budget. Для типовых задач важнее не голый quality score, а связка: размер модели, длина контекста, квантизация и сервер.

— Для high-QPS лучше vLLM: continuous batching, нормальная утилизация GPU, проще считать throughput на реальной очереди.
— Для edge и дешёвого железа чаще выигрывает llama.cpp: GGUF, агрессивная квантизация, быстрый старт, но ниже потолок по параллелизму.
— TGI удобен, если нужен предсказуемый production API и уже есть привычка жить в Hugging Face-экосистеме.

Самая частая ошибка — запускать Qwen в int4 и ожидать, что она удержит длинный контекст без деградации. На практике качество проседает первым делом в многошаговом reasoning и в извлечении структурированных полей. Если задача критична к точности, лучше оставить fp16/bf16 для старшей модели, а квантизировать только младшие слои или отдельный сервис под черновые ответы.

Ещё один важный момент — формат промпта и лимит output tokens. У Qwen хорошо заметна разница между «сырой болтовнёй» и жёстким шаблоном с ролями, JSON-схемой и стоп-условиями. Чем точнее контракт на входе, тем меньше мусора на выходе и тем дешевле rerun.

Если строите прод, начинайте не с «какая Qwen лучше», а с матрицы: задача → допустимая ошибка → целевой latency → доступная VRAM. Это почти всегда быстрее выводит на правильную конфигурацию, чем бесконечный перебор моделей.