DeepSeek V4.1 Flash: как модель читает длинный текст и экономит память

Большой документ редко удаётся разобрать одним вопросом к ИИ. Нужно найти нужное условие, сопоставить несколько разделов, уточнить ответ. Для вас это один разговор. Для модели — работа с большим объёмом текста, к которому приходится обращаться снова и снова, пока она составляет ответ. Чем длиннее материал, тем труднее быстро находить в нём нужные сведения.

Обычно модель сохраняет промежуточные результаты обработки текста, чтобы использовать их дальше. Благодаря этому не нужно заново вычислять весь документ ради каждого следующего токена ответа. Но сохранение результатов тоже требует ресурсов. Они занимают память, а поиск и передача данных требуют времени. При работе с большим документом или накопившейся историей запросов обслуживание этих данных может стать основной нагрузкой: процессор должен не только выполнять новые вычисления, но и получать результаты предыдущих.

DeepSeek V4.1 Flash меняет способ работы с этими записями. В техническом отчёте DeepSeek компания описывает, как модель разделяет чтение текста и написание ответа, сокращает число отдельных копий данных и восстанавливает часть записей по мере необходимости. Экономия начинается ещё до появления ответа — с того, как модель читает запрос и сохраняет прочитанное.

Работа модели разделена на две фазы. Во время предварительного чтения, или prefill, она обрабатывает запрос, приложенные документы и другую переданную информацию, чтобы подготовить контекст будущего ответа. Текст разбивается на небольшие элементы — токены: это могут быть слова, части слов или знаки. Они проходят через слои модели — последовательные этапы обработки текста. Каждый слой рассчитывает для каждого токена два набора чисел, называемые ключами и значениями. Они сохраняются в KV-кэше. KV-кэш содержит промежуточные числовые данные, которые модель затем использует при вычислении ответа.

Затем начинается написание ответа, или decode: ответ появляется последовательно, по одному слову или токену. Для выбора следующего наиболее вероятного элемента нужно учитывать предшествующий текст. Сохранённые ключи и значения позволяют обращаться к уже обработанной информации без повторного расчёта всей беседы с самого начала. Модель тратит вычисления на чтение один раз, а затем пользуется его результатом при написании ответа.

Кэш сохраняет именно результаты вычислений над текстом. Когда модель продолжает ответ, она использует уже рассчитанные данные предыдущих токенов, а новый расчёт выполняет для очередного элемента. Это сокращает повторную обработку. При коротком запросе сохранённых данных сравнительно мало, и они помещаются в доступной быстрой памяти. Поэтому затраты на их хранение и передачу обычно не становятся главным ограничением.

Ситуация меняется, когда от системы ждут длительной самостоятельной работы. Агенты — системы, которые сами выполняют последовательность действий, — должны работать часами или днями, учитывать множество документов либо большую кодовую базу и продолжать работу с накопленной информацией. Объём промежуточных данных растёт вместе с обработанным текстом. Сохранение результатов по-прежнему позволяет избежать повторных вычислений, однако сам кэш становится большим. Для каждого нового токена требуется обращаться к подходящим данным из этого объёма. Возникают две связанные нагрузки: хранение результатов и работа с ними во время продолжения ответа.

Графический процессор, или GPU, выполняет вычисления модели и получает необходимые данные из памяти. Рядом с ним находится HBM — быстрая память с высокой пропускной способностью. Она позволяет передавать данные процессору с небольшими задержками. Но её объём ограничен, а сама память дорогая. В ней должны размещаться не только промежуточные записи о прочитанном тексте, поэтому рост KV-кэша увеличивает требования к ресурсам системы. Чем больше данных требуется для очередного вычисления, тем существеннее становится скорость доступа к ним.

Когда KV-кэш не помещается в доступной быстрой памяти, часть данных можно хранить за пределами GPU, например на твердотельных накопителях SSD. Там доступно больше места, однако получение данных занимает больше времени. Система выигрывает в доступном объёме хранения, но тратит дополнительное время на загрузку сохранённых результатов. Поэтому большой накопитель сам по себе не решает задачу быстрого продолжения ответа: данные ещё нужно доставить туда, где модель выполняет вычисления.

Если кэш хранится на SSD, для генерации следующего токена данные нужно получить с накопителя, провести через материнскую плату в быструю память и затем подать процессору. Пока большой кэш перемещается, вычислительный блок может простаивать. Поэтому проблема состоит не только в количестве математических операций. Нужно одновременно уменьшить объём данных, к которым обращается модель, и затраты на их доставку. Перестройка слоёв сокращает повторную обработку, совместное использование кэша уменьшает число отдельных наборов данных, а отказ от некоторых сохранений снижает обращения к накопителю. Каждое изменение сокращает определённую работу системы: вычисление, хранение или передачу результатов.

Обычная языковая модель на основе трансформера обрабатывает текст во множестве последовательных слоёв. Входные данные проходят через них, получается следующий вероятный элемент ответа, он добавляется к тексту, и цикл повторяется. При этом каждый слой создаёт собственный KV-кэш, который нужно где-то хранить.

В новой архитектуре слои разделены на две части: блок чтения, который называется causal encoder, и блок написания ответа — decoder. При предварительном чтении основную обработку исходного материала выполняет первая часть. Глобальные ключи и значения для второй получают преобразованием результата последнего слоя блока чтения. Поэтому второй части не нужно повторять полную обработку всего запроса, чтобы подготовить эти данные. Затем при написании ответа работают обе части модели. Такое распределение сокращает вычисления при чтении.

У такого решения есть риск: если половина слоёв пропускает самостоятельное чтение исходного материала, качество понимания может ухудшиться. Поэтому блок написания ответа всё же обрабатывает часть текста самостоятельно.

Глобальный контекст охватывает весь запрос, все переданные сведения и приложения. Локальный контекст относится к предложению, которое модель пишет сейчас, и к тексту, непосредственно важному для очередного токена. Глобальные данные блок написания ответа получает из результатов блока чтения, а с ближайшим окружением работает самостоятельно. Для этого используется внимание в скользящем окне, или sliding window attention: особенно подробно рассматриваются самые последние токены. Получается сочетание уже подготовленного общего представления с непосредственной обработкой недавнего текста. Здесь необходимо сохранить достаточно информации для хорошего ответа, хотя вычислений и собственных записей у второй половины стало меньше.

При таком разделении примерно половине модели больше не нужно создавать собственный огромный набор глобальных записей. В техническом объяснении такой отказ от повторного чтения оценивается как сокращение вычислений на этом этапе примерно вдвое. При этом вопрос памяти остаётся: даже после уменьшения количества работающих над чтением слоёв глобальные и локальные записи могут быть слишком велики. Значит, нужно уменьшить ещё и объём самих записей.

Сравнение поколений по объёму глобального KV-кэша на один токен показывает: почти 390 тысяч байт у DeepSeek V1, около 3500 байт у V4 Flash и 890 байт у V4.1 Flash. Это уменьшение примерно в 437 раз относительно V1 и почти в четыре раза относительно предыдущей Flash-модели. Как сохранить полезную информацию при таком сокращении? Один из механизмов — Compressed Sparse Attention 2, или CSA2: слои делятся сохранёнными записями и средствами поиска по ним. Эти числа относятся к промежуточным данным глобального кэша, а не ко всей памяти, необходимой для работы модели.

В обычной схеме каждый слой рассчитывает и сохраняет собственные ключи и значения для обработанных токенов. Даже если все слои работают с одним исходным текстом, результаты их вычислений хранятся отдельно. При большом контексте совокупный объём таких наборов становится значительным. CSA2 меняет порядок создания и использования кэша: одни слои подготавливают данные, а другие используют уже подготовленные наборы. Предусмотрены три режима — Full, Reindex и Reuse. Они различаются тем, создаёт ли слой новый кэш и выполняет ли собственную работу по выбору данных для внимания. Во всех трёх режимах слой сохраняет собственные локальные записи: совместное использование относится к глобальному кэшу.

В режиме Full слой выполняет всю подготовку: создаёт новый глобальный KV-кэш и строит индекс для выбора подходящих записей. Индексатор определяет, какие позиции в сохранённых данных нужны для текущего вычисления. Это позволяет направить внимание на отобранные части контекста, вместо того чтобы одинаково обрабатывать весь доступный объём. Подготовленные кэш и результаты индексации могут использовать следующие слои. Именно слой Full создаёт исходный набор, который затем доступен для совместного использования.

В режиме Reindex новый набор глобальных ключей и значений не создаётся. Слой использует кэш, подготовленный слоем Full, но самостоятельно выполняет индексацию: выбирает подходящие позиции для своего вычисления. Поэтому совместное хранение данных не требует одинакового выбора на каждом этапе обработки. Один набор ключей и значений может обслуживать несколько слоёв, а работа по определению нужных позиций выполняется для них отдельно.

Различие между кэшем и индексом здесь существенно. Кэш содержит промежуточные данные о токенах, а индекс используется для выбора записей, к которым обращается внимание. При Reindex меняется выбор, но сами сохранённые ключи и значения остаются прежними. Таким образом, модель сокращает повторное создание и хранение данных, сохраняя возможность заново определить, какие из них нужны конкретному слою. Экономия относится к общему набору записей; собственная индексация всё ещё требует вычислений.

В режиме Reuse слой использует и готовый кэш слоя Full, и уже выполненную индексацию — из слоя Full либо Reindex. Он не создаёт новый набор глобальных ключей и значений и не повторяет работу по выбору записей. Поэтому дополнительные затраты на хранение собственного кэша и индекса почти исчезают. Сам слой продолжает выполнять обработку, но обращается к подготовленным ранее данным. Отсутствие нового кэша относится к промежуточному хранению, а не к отсутствию вычислений вообще.

Три режима вместе позволяют отказаться от предположения, что каждому слою обязательно нужен собственный комплект записей и указателей к ним. Часть слоёв делает всё, часть сохраняет самостоятельность только в организации поиска, а часть использует оба готовых результата. Снижение общего объёма получается за счёт устранения повторяющихся наборов, поскольку дальнейшие слои получают доступ к информации, подготовленной раньше. Именно так сокращается количество записей: полезный материал и средства его поиска могут служить сразу нескольким участкам модели.

Следующий механизм заранее отбирает подходящие записи для дальнейшей работы. Он называется иерархическим разреженным индексатором, или hierarchical sparse indexer. Первый слой блока написания ответа просматривает глобальные записи и формирует набор кандидатов, то есть короткий список наиболее подходящих сведений. В приведённом примере из миллиона токенов отбирается около 16 тысяч. Последующие индексаторы ищут глобальные записи внутри этого набора. При этом локальное внимание продолжает работать с недавними токенами. Поэтому пространство поиска резко сужается в начале написания ответа.

Условие успеха здесь особенно жёсткое: если важная деталь не попала в список, система может её упустить или начать выдумывать ответ. Согласно описанию команды, модель обучили достаточно точно составлять такие списки, чтобы последующие слои практически не замечали отсутствия остальных данных. Программа сокращает работу оборудования, но риск потери нужной информации сохраняется.

Оптимизация порождает и дополнительную проблему: внимание в скользящем окне сохраняет промежуточные данные только для недавних токенов. По описанию разработчиков, при разговоре из нескольких обменов репликами сохранение такого локального контекста каждого хода на SSD стало серьёзной нагрузкой на хранилище. Пользователь пишет, модель отвечает, пользователь продолжает; чтобы затем восстановить ход беседы, соответствующие данные постоянно записываются. Кэширование обычно означает сохранение данных там, откуда их можно быстро получить, но когда сохранённого слишком много и оно вынесено далеко от процессора, получение данных замедляется. Для этого конкретного затруднения предлагается SWA-bounded replay: повторная обработка короткого недавнего фрагмента текста вместо постоянного хранения локальных промежуточных записей.

Локальные промежуточные записи не сохраняют надолго на SSD. Текст беседы и глобальный кэш остаются. Если нужных локальных записей уже нет, модель заново обрабатывает ближайший фрагмент — последние 128 токенов — и восстанавливает их на GPU. Это приближённое восстановление: полученные данные не полностью совпадают с результатом обработки всей истории. В техническом отчёте разработчики оценивают влияние на качество как незначительное в проверенных условиях.

Возникает вопрос: ранее архитектура старалась избавляться от повторных вычислений, а теперь сознательно возвращает их. Возникают два риска: ухудшение работы с контекстом и дополнительная задержка из-за нового расчёта. Ответ основан на различии между повторением небольшого расчёта и повторным чтением всего контекста. Ограниченный ближайший фрагмент можно восстановить, сохранив общий контекст в другой части схемы. Поэтому отказ от длительного хранения относится именно к локальным записям скользящего окна. Ближайший контекст по-прежнему нужен для следующего слова. Меняется способ его получения: вместо загрузки сохранённых вычислений модель вновь обрабатывает короткий конец беседы.

Для сравнения предлагаются два пути. Первый — перенести локальные данные с GPU через материнскую плату на накопитель, позднее отыскать их и доставить обратно к процессору. Второй — воспользоваться вычислительной мощностью GPU и пересчитать короткий фрагмент. В таком сравнении небольшая порция вычислений на GPU обходится быстрее, чем запись данных на SSD и их последующая загрузка. Речь идёт о коротком фрагменте из 128 токенов, а не о повторном чтении всей истории. Следовательно, сохранение таких локальных записей расходовало медленный ресурс, хотя их можно быстро восстановить. Удаление этого этапа должно одновременно ускорить работу и освободить место на накопителях.

К этому моменту схема объединяет несколько изменений: локальное окно внимания, разделение чтения и написания, предварительный отбор общего материала и использование готовых записей некоторыми слоями. Ограниченный повторный расчёт дополняет их, уменьшая стоимость хранения локального состояния.

Single-Pass mHC сокращает перемещение данных уже внутри GPU. Одни операции создают промежуточные значения, которые нужны следующим. При раздельном выполнении операций результат приходится сначала записать в память графического процессора, затем вновь загрузить.

При долгой обработке такие шаги повторяются миллиарды раз. Отдельное перемещение быстро, но накопленная задержка может стать существенной и ограничить скорость всей обработки. Single-Pass mHC объединяет несколько связанных операций, чтобы между ними меньше записывать промежуточные результаты в память и вновь загружать их. Вместо цепочки отдельных шагов некоторые действия выполняются совместно. Заявленный эффект — сокращение внутреннего обмена с памятью и более быстрая работа GPU.

Engram — отдельный модуль памяти. При генерации его данные можно заранее получать из обычной оперативной памяти сервера, вне дорогой памяти GPU. В объяснении архитектуры модулю отводится запоминание устойчивых сведений, например дат и столиц, чтобы отделить часть хранения от активных вычислений. Однако это обученные числовые представления, а не обычная база фактов, из которой гарантированно извлекается точная дата или цитата. CSA2 сокращает и повторно использует данные текущего контекста, а Engram добавляет отдельную память модели.

Следующий вспомогательный компонент называется DSpark. Последовательное написание ответа по одному токену само по себе ограничивает скорость. DSpark позволяет готовить несколько токенов за один шаг, ускоряя написание ответа. В отличие от изменений кэша, этот механизм работает с самим темпом выдачи текста: вместо продвижения по одному элементу система готовит сразу несколько. Подготовленные элементы служат черновиком, который основная модель проверяет перед принятием.

Общая эффективность объясняется сочетанием изменений, а не одним изолированным приёмом. Одни механизмы сокращают объём записей, другие — повторную обработку, третьи — перемещение данных, ещё один ускоряет выдачу текста.

На рисунке 2 технического отчёта по вертикали показаны FLOPs, число операций с плавающей точкой, то есть объём вычислительной работы для очередного токена ответа, по горизонтали — размер контекстного окна, то есть количество информации, с которой модель может работать одновременно. При росте окна примерно с 4000 до миллиона токенов кривая написания ответа у V4.1 Flash остаётся почти горизонтальной. Миллион токенов приблизительно сопоставляется с 700 тысячами слов либо кодовой базой среднего размера. В этом сравнении нагрузка на очередной токен меняется относительно мало при переходе от короткого документа к тысячам страниц.

Для прошлых поколений показан рост нагрузки с контекстом. График показывает вычислительную работу в условиях этого сравнения. FLOPs не измеряют расход энергии, цену запроса или время ответа.

В приведённых результатах тестов V4.1 Flash сопоставляется с ведущими моделями. Для DeepSWE 1.1 указано 74,2 — примерно на уровне 74 у GPT-6 Astra и выше результатов других открытых моделей в этом сравнении. Результат CyberGym оценивается как один из лучших. Для AutomationBench заявлено преимущество даже перед GPT-6 Astra Max.

В таблице LiveBench модель представлена как первая среди открытых, а в VALS Index — как занимающая первое место. Последний индекс объясняется как измерение выполнения задач интеллектуального труда. Речь идёт о заявленных результатах и местах в приведённых таблицах. Для этих сравнений CyberGym, AutomationBench, LiveBench и VALS Index подробные условия тестирования и численные оценки не приведены.

Качество сопоставляется со стоимостью выполнения задач. Для моделей на втором и третьем местах в приведённой таблице заявлена стоимость более чем в 20 раз выше; отдельный график стоимости задачи также трактуется как преимущество DeepSeek относительно GPT-6 Astra и других закрытых моделей. Это относительные сравнения по приведённым таблицам, без тарифов или конкретной денежной суммы за задачу.

При обращении к модели из программы через API заявлена скорость свыше 200 токенов в секунду, приблизительно вчетверо выше GPT-6. Задержка до первого ответа характеризуется как самая низкая в отрасли, но её численное значение не сообщается. Скорость выдачи текста и ожидание его начала — разные показатели: модель может быстро писать уже начатый ответ, но долго готовиться к нему. Для этих сравнений подробные условия измерения не приведены.

Веса V4.1 Flash доступны открыто: модель можно скачать для локального запуска. DeepSeek публикует её вместе с техническим отчётом, в котором описаны архитектура и результаты испытаний.

Для компании открытые веса дают возможность развернуть модель в собственной инфраструктуре и работать с внутренними документами. Юридической фирме такой помощник может пригодиться для поиска условий в договорах и сопоставления их версий. Производственной компании — для поиска по инструкциям и технической документации, службе поддержки — для подготовки ответов по внутренней базе знаний. В юридической работе выводы модели всё равно проверяет специалист: длинное контекстное окно не исключает пропущенных деталей.

Если хотите развернуть ИИ в своём контуре, мы поможем подобрать модель и оборудование, настроить локальную работу и подключить ваши документы. Начать можно с одной конкретной задачи — например, поиска по архиву договоров. Расскажите, с какими материалами работают ваши сотрудники и какую часть работы вы хотите упростить.