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

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

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

На практике проверка простая:
— для чатов с низкой задержкой нужен vLLM или TGI с батчингом;
— для локального запуска на слабых GPU чаще выигрывает gguf-квантизация и llama.cpp;
— если контекст растёт, смотри не только на заявленные 128k, а на деградацию качества после нескольких десятков тысяч токенов.

Ещё один частый промах — считать только размер весов. У модели с «лёгкими» 4-bit весами может резко вырасти расход памяти из-за длинного контекста и большого batch size. Поэтому перед выкладкой проверь: пиковую VRAM, tokens/sec на одном GPU, latency p95 и поведение на реальном промпте с твоим шаблоном.

Если нужен стабильный прод, тестируй DeepSeek не по одному бенчу, а по своей матрице: короткий чат, длинный диалог, tool-use и код. Именно там видно, где модель даёт экономию, а где съедает её на инфраструктуре.