DeepSeek в проде ломается не на модели, а на неправильном inference-стеке и контексте

DeepSeek в проде ломается не на модели, а на неправильном inference-стеке и контексте

DeepSeek-семейство часто берут за качество на reasoning и коде, но в проде важнее не «какая модель умнее», а как она ест VRAM, как держит длинный контекст и где у вас упирается throughput.

Первый фильтр — размер и режим запуска:
— 7B/8B можно ставить на одну GPU для low-latency сценариев.
— 14B/32B уже требуют аккуратной квантизации и батчинга.
— 70B без нормального шардирования превращается в дорогой эксперимент.

Второй фильтр — движок:
— vLLM хорош, когда нужен высокий throughput и динамический batching.
— TGI удобен для типового API-сервинга и предсказуемой эксплуатации.
— llama.cpp имеет смысл для жёсткого контроля памяти и GGUF, но не для максимальной пропускной способности.

Третий фильтр — контекст. 128k в карточке модели не означает, что его можно безболезненно держать на каждом запросе. Чем длиннее prompt, тем сильнее проседают latency и эффективный batch size. Если у вас саппорт, RAG или автогенерация, ограничивайте рабочий контекст и режьте мусор до входа в модель.

Четвёртый фильтр — квантизация. Для продакшена чаще всего смотрят на 4-bit и 8-bit, но проверять нужно не «влезло ли», а:
— не деградирует ли tool use;
— не ломается ли JSON;
— не растёт ли доля пустых или повторяющихся ответов.

Если DeepSeek нужен как рабочая лошадь, начинайте не с максимальной модели, а с минимальной, которая проходит ваши QA-метрики. Это почти всегда даёт лучший баланс качества, скорости и стоимости.