Qwen в проде ломается не на качестве, а на неправильном выборе размера и контекста

Qwen в проде ломается не на качестве, а на неправильном выборе размера и контекста

Если нужна модель для русского, англоязычного саппорта и tool-use, Qwen часто выигрывает не «магией», а стабильностью на длинных промптах. Но правило простое: чем меньше модель, тем жёстче нужен формат входа и тем короче должны быть цепочки рассуждений.

Для продакшена смотрите на 4 вещи:
— 7B/8B: дешёвый throughput, но быстро упирается в качество на сложных инструкциях
— 14B/32B: нормальный баланс для agentic-задач и извлечения структуры
— 72B+: уже про качество, но без серьёзного железа теряется смысл
— long context: работает только если вы реально контролируете длину истории, иначе latency и деградация растут нелинейно

По инференсу Qwen хорошо чувствует себя в vLLM для batch-запросов и в llama.cpp/gguf, когда важны локальный запуск и предсказуемая память. Если у вас много коротких запросов, важнее не «лучшая модель», а хороший scheduler, paged attention и нормальная квантизация.

Частая ошибка — брать большую Qwen и надеяться, что она сама вытянет плохой промпт. На практике 80% результата дают: жёсткий system prompt, ограничение длины ответа, шаблон JSON и фильтр на мусорный контекст.

Если нужен предсказуемый прод, начинайте с 14B, а масштабируйте только после замера latency и качества на своих задачах.