DeepSeek в проде ломается не на «качестве», а на неправильной постановке режима инференса

DeepSeek в проде ломается не на «качестве», а на неправильной постановке режима инференса

Если брать deepseek_models для реальной работы, сначала разделяйте сценарии: генерация, код, длинный контекст, tool-use. Одна и та же модель может выглядеть отлично в чате и резко просесть на суммаризации или JSON-выдаче, если не совпали формат промпта, температура и лимиты по токенам.

Для self-hosted важны три вещи: квантование, движок и длина контекста. На 4-bit часть моделей ещё держит приемлемое качество для классификации и черновиков, но для сложного кода и строгого structured output лучше смотреть в сторону 8-bit или fp16. В проде часто упираются не в VRAM, а в throughput: vLLM обычно выигрывает на батчинге, TGI — когда важнее предсказуемая эксплуатация, llama.cpp — когда нужен дешёвый edge и GGUF.

Отдельный чек-лист перед выкладкой:
— фиксируйте шаблон чата;
— не смешивайте role/system/user как попало;
— ставьте стоп-слова для болтливых ответов;
— тестируйте 128k не по заявлению, а на своих задачах: у длинного контекста качество часто деградирует после средней части окна.

Для DeepSeek особенно полезен режим «сначала план, потом ответ»: он снижает мусор в ответе и помогает на агентных пайплайнах. Если задача — писать код или разбирать логи, лучше 2 коротких прохода, чем один длинный: сначала извлечение фактов, потом финальная генерация.

Итог простой: DeepSeek берут не «как универсальную замену», а как модель под конкретный pipeline. Сначала выберите формат вывода и движок, потом уже меряйте качество; иначе вы оцениваете не модель, а хаос в обвязке.