Миллион токенов контекста — впечатляющая цифра в спецификации. На практике за ней скрывается проблема: при траектории агента в сотни вызовов инструментов KV cache забивает GPU, а каждый следующий токен стоит столько же FLOPs, сколько и первый. DeepSeek-V4 построен вокруг обратного принципа — не максимальная ёмкость контекста, а дешёвый длинный контекст, который агент может реально использовать без ущерба для производительности.

Почему длинный контекст ломает агентов

Когда агент работает с длинной траекторией задач — например, решает SWE-bench задачу, ведёт мультишаговый browse-сценарий или исполняет сотни команд в терминале — каждый вызов инструмента добавляет результат в контекст. Каждый следующий токен платит полную цену attention по всему накопленному контексту. Это называется standard multi-head self-attention: каждый token query взаимодействует с каждым key-value pair в последовательности. При 1M токенов это означает, что attention matrix на каждом слое — 1M × 1M.

Две метрики растут вместе с длиной последовательности. Первая — FLOPs на один токен: нужно вычислить dot product query со всеми 1M key векторами, умножить на value, просуммировать. Это вторая проблема: O(n²) complexity для attention — каждый новый токен делает все последующие вычисления дороже. Вторая метрика — размер KV cache, который нужно держать в GPU memory для всех 1M позиций. При стандартной архитектуре с grouped query attention (8 heads, BF16) KV cache для 1M токенов занимает примерно столько же памяти, сколько веса самой модели. Типичная 70B модель требует ~140GB для весов в BF16 — и ещё ~140GB для KV cache при 1M токенов. На практике это означает: либо обрезать контекст и терять критичную информацию, либо упираться в OOM на каждом длинном задании.

DeepSeek-V4 решает эту проблему на уровне архитектуры. Результат: при 1M токенов DeepSeek-V4-Pro требует 27% FLOPs от однотокенового инференса (сравните с V3.2), а V4-Flash — 10%. KV cache занимает 10% от V3.2 для Pro и 7% для Flash. В сравнении со стандартной GQA с 8 heads в bfloat16 — примерно 2% от размера cache. Это не оптимизация существующего механизма, а принципиально другой подход к хранению и обработке длинных последовательностей.

Гибридный attention: CSA и HCA

Эффективность достигается разделением attention на два механизма, которые чередуются по слоям.

Compressed Sparse Attention (CSA) сжимает KV записи в 4 раза по последовательности через softmax-gated pooling с обучаемым позиционным смещением. Механизм: на каждом шаге denoising или forward pass модель «сворачивает» 4 последовательных KV entry в один сжатый вектор. Это не просто downsampling — softmax gate определяет, какая информация критична для сохранения, а какую можно отбросить. Гейт учится в процессе обучения и запоминает, какие паттерны в истории токенов важны для будущих предсказаний.

После сворачивания работает lightning indexer: модуль на базе FP4 (4-bit floating point) с ReLU-scored multi-head dot product, который выбирает top-k сжатых блоков на каждый query. Идея наследует sparse-выборку из DeepSeek Sparse Attention в V3.2, но работает над блоками, которые уже в 4 раза короче исходной последовательности. Пространство поиска индексера сокращается пропорционально — а значит и стоимость выбора релевантных блоков. FP4 выбран потому что достаточно precision для ReLU-scoring (нужны только положительные значения), но хватает range для выбора top-k из сжатых блоков.

Heavily Compressed Attention (HCA) сжимает KV записи в 128 раз и отказывается от sparse-выборки полностью. Каждый query attends плотно ко всем сжатым блокам — сжатая последовательность достаточно короткая, чтобы dense attention был вычислительно дёшево. HCA экономит на indexer overhead: нет FP4 quantization, нет ReLU scoring, нет top-k selection. Взамен — 128x compression ratio, который делает dense attention над сжатым потоком быстрее, чем sparse attention над несжатым.

Чередование слоёв в 61-слойном стеке V4-Pro: слои 0–1 работают на HCA (лёгкое, широкое сжатие для начальных уровней абстракции), слои 2–60 чередуют CSA и HCA, MTP-блок (Multi-Token Prediction) на выходе использует только sliding-window attention для самого recent context. Разные слои несут разные паттерны attention — low-level слои обрабатывают локальные паттерны (syntax, morphology), high-level слои работают с глобальной структурой (semantics, reasoning chains). Принуждение одного механизма ко всем слоям тратит ёмкость впустую.

Хранение: FP8 (8-bit floating point) для большинства KV entries, BF16 только для RoPE-измерений (позиционное кодирование). RoPE критичен для позиционной информации — потеря precision там напрямую влияет на способность модели понимать относительные позиции токенов. Lightning indexer внутри CSA тоже работает на FP4. Эти choices compound с коэффициентами сжатия и дают итоговые 2% размера cache относительно стандартного подхода.

Рассуждения между вызовами инструментов

Архитектурная эффективность — необходимое условие для агентных сценариев, но не достаточное. V3.2 сохранял цепочку рассуждений (reasoning trace) между раундами вызовов инструментов, но сбрасывал её при каждом новом сообщении пользователя. Для одиночного запроса это не проблема — пользователь спрашивает, агент отвечает, контекст очищается. Для мультитурновых сценариев, где пользователь отправляет follow-up после того, как агент уже совершил цепочку из десяти вызовов, модель теряла накопленный контекст рассуждений и реконструировала состояние с нуля.

V4 сохраняет содержание рассуждений между границами пользовательских сообщений, когда в разговоре присутствуют вызовы инструментов. Модель удерживает полную историю reasoning на всех раундах, включая пользовательские turn'ы. Это позволяет выстроить когерентную, кумулятивную цепочку мысли над длинными горизонтальными агентными задачами — агент «помнит», почему он выбрал тот или иной путь, и может откатиться от ошибочных решений без полной реконструкции. Представьте агента, который обсуждает баг в коде: он прочитал файл, написал тест, тест упал, он прочитал стектрейс, поправил код, тест прошёл — всё это одна логическая цепочка. V3.2 сбрасывал её после каждого ответа пользователя. V4 сохраняет.

Для разговорного использования без инструментов поведение V3.2 сохранено: рассуждения сбрасываются на каждом turn, чтобы контекст оставался компактным. Это важно для обычных пользователей, которые не запускают агентов — им не нужно платить за накопление длинных reasoning chains, если они не используются.

Схема вызова инструментов и DSec sandbox

Vocabulary модели включает dedicated tokens для инструментов — это не просто текстовая интерпретация ("Now calling tool: search"), а отдельные token ID в decoder. Это упрощает парсинг, снижает ошибки при определении границ tool call и позволяет модели «видеть» границы инструментов на уровне токенизации. Раньше парсинг tool call требовал regex или LLM-переоткрытия — теперь это вопрос одного токена.

DSec (DeepSeek Execution environment for Containers) — sandbox для RL-траекторий с агентными workflow. Предназначен для post-training: модель запускает инструменты, результаты возвращаются в sandbox, RL-агент получает reward signal на основе успешности траектории. Всё это работает поверх механизмов сжатия — длинные траектории укладываются в память GPU без характерных OOM, которые блокировали RL на агентных задачах раньше. До V4 обучение агентов на задачах длиной в 500+ шагов было практически невозможно — reward signal приходил слишком редко, а memory pressure делал batch size равным 1.

Benchmark-результаты конкурентные, но не SOTA — и это честная позиция авторов. Инновация не в том, чтобы быть лучшим на бенчмарках, а в том, чтобы сделать длинный контекст дешёвым для практических агентных сценариев. SOTA на бенчмарках при этом обычно означает переобучение на тестовые данные или adversarial overfitting — DeepSeek выбирает инженерную применимость.

Практические следствия

Два checkpoint'а доступны на HuggingFace: DeepSeek-V4-Pro (1.6T total parameters, 49B active, BF16) и DeepSeek-V4-Flash (284B total, 13B active, FP8). Обе модели — Mixture-of-Experts архитектура с ёмкостью в 1M токенов контекста.

Для разработчика агентов выбор простой: если задача требует 50K+ токенов контекста — кодовая модель с большой базой, мультидокументный анализ, длинные цепочки инструментов — DeepSeek-V4 даёт принципиально другой tradeoff между памятью и качеством, чем любой предыдущий открытый MoE. Не ёмкость контекста, а стоимость каждого токена на глубине — вот что меняется. При 13B active parameters Flash-версия укладывается в потребительские GPU (2x 4090 или аналоги) и при этом даёт те же свойства длинного контекста.

Что это значит для индустрии

До V4 длинный контекст в LLM был компромиссом: либо короткий контекст и быстрый инференс, либо миллион токенов ценой невозможной памяти. HuggingFace-пост называет это «the KV cache problem for agents» — типичная проблема, которую все признают, но не решают на уровне архитектуры.

Предыдущие подходы решали проблему через иерархическую память (retrieval из внешних баз), разбиение задачи на короткие сессии (с потерей когерентности), approximate attention (sparse, linear, kernel methods), или offloading в CPU/NVMe память (с задержкой на transfer). Все работают в определённых сценариях, но добавляют complexity и ограничивают то, что модель может рассуждать о within the full context.

V4 меняет экономику: теперь память для KV cache при 1M токенов сопоставима с памятью для 20K токенов в стандартной архитектуре. Это делает реализуемыми workflow, которые раньше требовали костылей — например, агент, который анализирует 10K-строчную кодовую базу без иерархического retrieval, или модель, которая ведёт длинный диалог с накоплением контекста без explicit memory management.

RL на агентных задачах с длинными траекториями тоже становится возможным. DSec — это ответ на вопрос, который давно висел в воздухе: как обучать агентов на задачах, где reward приходит через 500+ шагов? Ранние RL-подходы к агентам (Voyager, AutoGPT) были ограничены именно этим — приходилось искусственно ограничивать длину траекторий или делать reward sparse до невозможности. V4 + DSec дают инфраструктуру для dense reward over long horizons.

FAQ

Чем V4 отличается от V3.2 на уровне архитектуры? V3.2 использовал стандартный attention с sparse-выборкой. V4 вводит два механизма сжатия (CSA 4x и HCA 128x), чередующихся по слоям, и переходит на FP8-хранение KV entries. Это даёт 10x экономию на FLOPs и 50x экономию на KV cache при 1M контексте. Lightning indexer на FP4 внутри CSA заменяет дорогую sparse-выборку на дешёвую.

Почему MoE-архитектура важна для агентов? Mixture-of-Experts позволяет иметь огромную общую ёмкость модели (1.6T параметров) при небольшом количестве активных параметров на каждый токен (49B для Pro). Агент получает доступ к «широким знаниям» без пропорционального роста стоимости инференса. Каждый токен активирует только часть экспертов — отсюда 49B active при 1.6T total.

Что такое DSec и зачем он нужен? DSec — sandbox для исполнения агентных траекторий и получения reward-сигнала для RL. Позволяет запускать модель в режиме агента с инструментами, собирать успешные и неуспешные траектории, и дообучать на них. Без DSec длинные агентные траектории не помещаются в память GPU для post-training — проблема, которая блокировала масштабное RL на агентных задачах.

Можно ли использовать V4 для задач без агентов? Да. Модели конкурентны на стандартных бенчмарках и подходят для обычного inference. Но основная инновация V4 — в том, что она делает возможными сценарии, которые раньше упирались в memory constraints: очень длинные документы, код-базы с большим контекстом, мультидокументная аналитика.

Как соотносятся Pro и Flash версии? V4-Pro (1.6T total, 49B active, BF16) — максимальное качество при умеренной стоимости. V4-Flash (284B total, 13B active, FP8) — компромисс в пользу скорости и памяти, укладывается в consumer GPU. Обе версии используют одинаковую архитектуру сжатия — разница только в размере и precision.

Почему чередование CSA и HCA важно? Разные слои в трансформере несут разные функции: low-level слои обрабатывают локальные паттерны (syntax, morphology), mid-level — семантические связи, high-level — глобальные рассуждения. Один механизм attention для всех слоёв либо переплачивает за локальные операции (dense attention everywhere), либо теряет информацию на глобальных (sparse attention everywhere). Чередование позволяет каждому слою использовать оптимальный для его задачи механизм.

Главный вывод: миллион токенов контекста перестаёт быть маркетинговой цифрой. DeepSeek-V4 делает длинный контекст инженерной реальностью — при 1M токенов KV cache занимает 2% от стандартного решения, а рассуждения модели переживают границы между вызовами инструментов.