DeepSeek в проде: где он выигрывает, а где лучше не трогать без теста

DeepSeek в проде: где он выигрывает, а где лучше не трогать без теста

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

Что проверять перед интеграцией:
— качество на ваших шаблонах, а не на общих бенчмарках;
— стабильность на коротких промптах и на длинном контексте;
— поведение под int4/int8: некоторые модели теряют точность сильнее, чем ожидается;
— инструменты сервинга: vLLM для throughput, TGI для предсказуемого API, llama.cpp для компактного локального деплоя.

Ещё один частый промах — считать только качество ответа и забывать про стоимость 1M токенов в проде. Если модель экономит 10% ошибок, но режет throughput вдвое, итоговая цена запроса может стать хуже, чем у более простой альтернативы. Для self-hosted это особенно заметно на пиках: очередь растёт быстрее, чем кажется по тесту на одном запросе.

Правило простое: DeepSeek берут не «за бренд», а под задачу, где reasoning реально монетизируется. Сначала замер latency и tokens/sec на своём промпте, потом уже решение о деплое.