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

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

Если брать семейство DeepSeek как рабочий инструмент, сначала разделяй задачи: генерация кода, длинный reasoning, массовый чат, RAG. Для кода важнее стабильность и короткая латентность, для reasoning — запас по контексту и память под KV-cache, для массового чата — throughput на токенах.

У open-source моделей этой линейки типовая ошибка одна: их запускают в fp16 «на честность», а потом удивляются низкой плотности запросов на GPU. Для продакшена чаще нужен баланс: 4-bit/8-bit квантизация, paged attention, нормальный batching и лимит на длину ответа. Иначе один длинный диалог съедает очередь целиком.

Вторая ловушка — контекст. Большое окно само по себе не спасает: после определённой длины качество ответа падает, если не чистить prompt и не резать мусор в истории. Для RAG это критично: лучше 6 точных чанков, чем 20 сырых. И обязательно тестируй не только exact match, но и rate of refusal, галлюцинации на длинных вводах и поведение на шуме.

Третья вещь — лицензия и инфраструктура. Перед запуском проверь, можно ли модель использовать в коммерции, и закладывай monitoring на latency, OOM и длину очереди. Если модель хороша в бенчмарке, но рвёт память на реальном трафике — это не модель для прода.

Практика простая: сначала измеряешь tokens/sec и p95 latency на своём железе, потом уже выбираешь DeepSeek под задачу, а не по хайпу.