Фраза «DeepSeek V4 использует на 98% меньше памяти» звучит как готовый аргумент для закупки GPU. Но именно здесь легко перепутать разные вещи: сжатие KV cache и общую потребность модели во VRAM. По открытым источникам более надёжный вывод уже, но важнее: DeepSeek V4 действительно оптимизирует длинноконтекстный инференс, снижая размер KV cache и стоимость attention; однако публичные документы не подтверждают, что вся видеопамять при развёртывании модели уменьшается на 98% [5][
13][
14].
Самая безопасная формулировка
Корректнее говорить так:
DeepSeek V4 использует Hybrid Attention, Compressed Sparse Attention и Heavily Compressed Attention, чтобы заметно уменьшить давление KV cache при длинном контексте. Но имеющихся данных недостаточно, чтобы утверждать: вся VRAM для развёртывания модели сокращается на 98% [
13][
14].
Разница принципиальная. KV cache — это кэш ключей и значений, который нужен трансформерной модели при генерации, чтобы не пересчитывать заново прошлый контекст. В длинных документах, многоходовых диалогах и агентных сценариях он может стать одним из главных потребителей памяти. Но он не равен всей памяти, которую занимает модель и обслуживающий стек.
Что подтверждают официальные материалы
На странице новостей API DeepSeek указано, что DeepSeek-V4 Preview вышел 24 апреля 2026 года [5]. Модельная карта DeepSeek V4 перечисляет две версии — DeepSeek-V4-Pro и DeepSeek-V4-Flash — и описывает V4 как серию языковых моделей Mixture-of-Experts, то есть MoE. В ней также сказано, что V4 сохраняет DeepSeekMoE framework и стратегию Multi-Token Prediction, но добавляет архитектурные изменения, включая Hybrid Attention Architecture [
14].
Самое важное для темы памяти — то, как V4 работает с attention на длинном контексте. В технической статье NVIDIA говорится, что Compressed Sparse Attention использует dynamic sequence compression для сжатия KV entries и уменьшения footprint KV cache, а затем применяет DeepSeek Sparse Attention для разреживания attention matrices и снижения вычислительных затрат. Heavily Compressed Attention идёт дальше: объединяет KV entries для групп токенов в одну сжатую запись, что ещё сильнее уменьшает размер KV cache [13].
Иными словами, документы прямо поддерживают тезис: DeepSeek V4 оптимизирует KV cache и вычисления attention. Но это не то же самое, что официальное обещание снизить всю VRAM на тот же процент.
98%, 90% и 9,5× — это разные утверждения
Цифра 98% в доступных материалах наиболее явно встречается в пользовательской статье LinkedIn с заголовком о том, что DeepSeek Sparse Attention сокращает KV memory на 98% в реальном serving [21]. Такой источник можно использовать как повод для проверки слуха, но не как официальную спецификацию DeepSeek.
Более внятная сторонняя цифра — 10% KV cache. Wccftech пишет, что по сравнению с DeepSeek V3.2 модель DeepSeek V4 требует 27% single-token inference FLOPs и 10% key-value cache [20]. Если читать это буквально, речь идёт примерно о 90-процентном сокращении KV cache относительно V3.2. Но это всё равно не означает, что на 90% уменьшается вся VRAM при любых длинах контекста, batch size, настройках concurrency и конфигурациях железа [
20].
Есть и заголовок gHacks про 9,5× lower memory requirements [3]. Даже простая арифметика даёт здесь около 10,5% оставшейся потребности, то есть примерно 89,5% сокращения, а не 98%. Кроме того, без уточнения области сравнения непонятно, имеется ли в виду KV cache, конкретный длинноконтекстный сценарий или полное развёртывание модели [
3].
| Формулировка | Статус доказательств | Как читать аккуратно |
|---|---|---|
| Вся VRAM меньше на 98% | Официального подтверждения в доступных материалах нет | Не стоит вносить в закупочные требования, capacity planning или маркетинговые обещания [ |
| KV cache сильно сжат | Поддерживается техническими описаниями | CSA и HCA сжимают KV entries и уменьшают KV cache в длинном контексте [ |
| 10% KV cache | Сторонний материал с конкретным сравнением | Можно понимать как примерно 90% сокращения KV cache относительно V3.2, но не всей VRAM [ |
| 9,5× lower memory | Новостной заголовок | Примерно 89,5% сокращения при прямом пересчёте, но область сравнения нужно проверять [ |
Почему KV cache — это не вся видеопамять
Для длинного контекста KV cache действительно критичен. Hugging Face объясняет это на примере агентных задач: результаты инструментов постоянно добавляются в context, а каждый следующий токен платит attention cost по всё более длинной истории; поэтому важны два числа — single-token inference FLOPs и размер KV cache, и оба растут с длиной sequence [17]. В GitHub-версии того же материала типичные сбои длинных агентных задач описаны практично: trace выходит за context budget, KV cache заполняет GPU или круги tool-call начинают тормозить выполнение [
22].
Но при полном развёртывании LLM видеопамять расходуется не только на KV cache. Даже статья LinkedIn, где фигурирует 98%, отдельно перечисляет shared weights, expert weights, activations, KV cache и framework overhead [21]. Это как раз показывает, почему планирование памяти нельзя сводить к одному проценту: если KV cache в конкретном длинном контексте сильно сократился, из этого ещё не следует, что вся serving-система стала требовать на столько же меньше VRAM.
CSA/HCA — серьёзная инженерия, но не магическое число
Архитектурная идея DeepSeek V4 заслуживает внимания именно потому, что бьёт по одному из самых дорогих мест длинноконтекстного инференса: attention и хранению KV cache. По описанию NVIDIA, V4 снижает нагрузку через сжатие KV entries, разреживание attention matrices и объединение KV entries для нескольких наборов токенов в одну compressed entry [13].
Технический отчёт DeepSeek V4 также упоминает инфраструктурные оптимизации для обучения и инференса: например, single fused kernel для MoE modules, который перекрывает computation, communication и memory access [2]. Это важные улучшения эффективности. Но они всё равно не являются доказательством формулы «минус 98% всей VRAM».
Что проверять перед внедрением
Если вы оцениваете DeepSeek V4 для длинных документов, юридических или технических баз, многоходовых чатов или agent workflow, главный вопрос не в красивом числе 98%. Важно понять, где именно у вас узкое место. Если workload упирается в KV cache на длинном контексте, механизмы CSA/HCA могут быть очень полезны [13][
17][
22].
Для практической оценки нужны собственные тесты: длина context, batch size, concurrency, serving engine, схема квантизации и конкретные GPU могут заметно менять картину. Если ограничение находится в весах модели, activations, overhead фреймворка или стратегии параллелизма, сокращение KV cache не превратится автоматически в такое же сокращение общей VRAM [13][
21][
22].
