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

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

Qwen часто берут как «универсальную» модель, но в проде её надо делить на три сценария: короткие ответы, длинный контекст и структурированный JSON. Для каждого — свой стек. Одна и та же модель в fp16, int8 и gguf даёт разную цену ошибки: где-то выигрывает latency, где-то падает точность на вложенных инструкциях.

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

В инференсе типичная ошибка — гнать всё через один и тот же шаблон. Для генерации текста лучше один system prompt и короткий контекст; для агента — строгий JSON schema и жёсткий post-validate; для саппорта — summarization каждые N сообщений. Иначе throughput есть, а качество плавает.

Если выбираете Qwen под прод, сначала тестируйте не «бенчмарк на бумаге», а свои 50–100 реальных запросов: извлечение, классификация, переформатирование, отказоустойчивость к шуму. Модель, которая проходит ваш формат без ручной правки, почти всегда дешевле любой «чуть умнее» на бумаге.