Optical Context Compression: DeepSeek-OCR & DeepSeek-OCR2

Введение

Размер контекстного окна — одна из ключевых характеристик LLM. От него зависит качество понимания больших документов, работа с кодом и многошаговый ризонинг.

Чем больше контекстное окно, тем больше производится вычислений и выше потребление памяти. Поэтому вопрос сжатия контекстного окна LLM — актуальная тема для исследования.

В статье рассмотрим подход к решению этой задачи в плоскости компьютерного зрения и расскажем о современных методах оптического сжатия контекста на примере Deepseek-OCR и Deepseek-OCR2.

Начинаем 🙂

DeepSeek-OCR

21 октября 2025 года вышла статья про DeepSeek-OCR — первую VLM (Vision Language Model), OCR-решение от команды Deepseek. В этот же день появился пост от Andrej Karpathy о том, как ему понравилась идея оптического сжатия текста для LLM.

В частности, он предполагает — если рендерить текст перед его подачей на вход LLM, можно получить следующие преимущества:

• более плотное сжатие информации (см. статью) ⇒ более короткие окна контекста и более высокая эффективность;
• более универсальный формат входных данных ⇒ не только текст, но и, например, жирный шрифт, цветной текст, произвольные изображения;
• можно использовать двунаправленное внимание по умолчанию, а не авторегрессию, что значительно эффективнее;
• возможность убрать токенизатор (на входе). Я уже не раз говорил, насколько он мне не нравится. Токенизаторы — это уродливый, обособленный этап, не являющийся частью основного обучения модели. Они тащат за собой всю сложность Unicode, байтовых кодировок, исторический багаж, а также риски безопасности и джейлбрейков. В результате два символа, которые визуально выглядят одинаково, внутри сети оказываются совершенно разными токенами. Улыбающийся эмодзи превращается в странный токен, а не в улыбающуюся рожицу. От токенизатора нужно отказаться.

Итак, один из самых известных в мире CV-инженеров и популяризатор ИИ говорит — возможно, скоро весь текст будет рендериться в картинки прежде, чем подаваться на вход LLM. Это позволит существенно повысить эффективность языковых моделей. Случится или нет — покажет время, но разобраться в том, как это работает, мы можем уже сейчас 🙂

DeepSeek-OCR — VLM-модель, которая состоит из визуального энкодера DeepEncoder и LLM-декодера, DeepSeek3B-MoE-A570M. Авторы ставили перед собой задачу по изучению подходов к сжатию контекста, а именно — использованию визуальной модальности как способа сжатия текстовой информации. Задача OCR выбрана потому, что она представляет идеальную тестовую среду для оценки качества отображения изображения в текст с понятными метриками. Разработчики заявляют, что при 10-кратном сжатии текста (то есть число текстовых токенов в 10 раз превышает число визуальных токенов) им удалось достичь точности распознавания текста в 97%.

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

Чтобы понять, чем отличается предложенная архитектура DeepEncoder, рассмотрим примеры типовых визуальных энкодеров, которые используются в VLM.

Типовые визуальные энкодеры

DeepSeek-VL

В DeepSeek-VL был предложен двухголовый энкодер. Простой ViT ограничен низким входным разрешением (224х224), что негативно сказывается на задаче OCR, поэтому разработчики добавили параллельную голову на входе в виде визуального энкодера ViTDet. Он обогащает итоговый выходной вектор признаками более мелких объектов за счёт высокого разрешения изображения на входе (1024х1024).

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

DeepSeek-VL-2 / InterVL

Подход, предложенный в InterVL и DeepSeek-VL-2 моделях, заключался в разбиении входного изображения на фрагменты (тайлы), которые обрабатывались параллельно.

Недостаток подхода — невысокое разрешение тайла (512х512), с которым может работать энкодер. Это приводит к сильной фрагментации входного изображения высокого разрешения и, следовательно, избыточному числу токенов на входе LLM-декодера.

Qwen2-VL

Третий подход был предложен в модели Qwen2-VL — Naive Dynamic Resolution, который позволяет изображение любого разрешения преобразовывать в последовательность визуальных токенов переменной длины.

Недостаток здесь — возможное переполнение GPU памяти в случае высокого разрешения изображения.

Архитектура DeepSeek-OCR

Теперь давайте изучим архитектуру DeepSeek-OCR, которая состоит из традиционных для VLM частей — визуального энкодера и LLM-декодера.

Подробно рассмотрим энкодер — DeepEncoder, где были основные нововведения, но затронем и декодер DeepSeek-3B.

DeepEncoder используется для извлечения визуальных признаков, имеет 380 млн. параметров и состоит двух базовых слоёв:

• SAM-трансформер ViTDet от модели Segment Anything;
• CLIP-энкодер.

Трансформер ViTDet от SAM отвечает за получение визуальных признаков из входного изображения. Если на вход ViTDet поступает изображение 1024х1024 — на выходе энкодера получается 64×64=4096 токенов размерностью 768. Они проходят через два дополнительных свёрточных слоя, сжимающих визуальные признаки в 16 раз и уменьшающих число токенов до 256.

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

Следующий блок в DeepEncoder — CLIP, но без входного слоя эмбеддинга патчей (patch embedding), поскольку эта операция уже выполнена слоем ViTDet + Conv. CLIP позволяет преобразовать визуальные признаки в пространство, понятное языковой модели декодера. На этом этапе уже применяется глобальное внимание ко всем токенам изображения.

В процессе обучения DeepEncoder’а используется подход с переменным разрешением входного изображения. Входная картинка подаётся либо в нативных разрешениях от 512х512 до 1280х1280, либо в режиме динамического разрешения, аналогично InterVL2 (изображение масштабируется с сохранением пропорций и разбивается на патчи с учётом ограничения по максимальному числу токенов). Подход позволил DeepSeek-OCR стать устойчивой к динамическому разрешению входного изображения.

В декодере DeepSeek-3B-MoE при инференсе модель активизирует в общей сложности порядка 8 экспертов, что составляет 570 млн. параметров. Это оптимальный выбор для OCR-задач, поскольку она достаточно компактна при инференсе, но при этом общее число параметров в 3 млрд. более, чем достаточно для решения задач OCR.

Обучение проводится в 2 этапа. Сначала учится DeepEncoder. На первом этапе энкодер извлекает визуальные признаки и сжимает их. На втором этапе в энкодере остаются размороженными только веса CLIP, которые учатся совместно с декодером DeepSeek-3B-MoE.

Датасет обучения состоит из документов — их 30 млн. Из них 25 млн. на английском и китайском, а остальные 5 — на других языках. Всего около 100 языков. Также есть датасеты для обучения визуальной части модели (DeepEncoder) для таких задач, как описание картинки, детекция объектов и граундинг детекция. Но поскольку DeepSeek-OCR — не общая VLM модель, а с уклоном в OCR, то чисто визуальных данных было 20% от всего размера обучающей выборки. Ещё 10% выборки — чисто текстовые данные, чтобы модель не потеряла свои LLM-способности. И, соответственно, оставшиеся 70% — данные для OCR.

В таблице 1 приведено сравнение DeepSeek-OCR c различной длиной контекста и других End-to-End OCR-моделей на бенчмарке OmniDocBench. Все метрики в таблице — Edit distance. Это метрика, измеряющая минимальное количество элементарных операций для преобразования одной строки в другую. К элементарным операциям могут относиться: вставка, удаление или замена символа. Чем их меньше, тем лучше.

Под числом токенов понимается число входных визуальных токенов на страницу А4 разрешения 200 dpi. Например, достаточно всего 100 (640х640 пикселей) токенов контекста, чтобы обогнать по качеству GOT-OCR2.0 c 256 входными токенами.

400 входных токенов (1280х1280 пикселей) хватает для достижения качества SOTA-моделей. А 800 токенов — чтобы побить качество MinerU2.0, которой для сопоставимого результата требуется 7000 токенов контекста.

Таким образом, DeepsSeek-OCR — не только качественное практическое решение задачи OCR, но и подтверждение эффективности подхода, основанного на оптическом сжатии контекста.

Deepseek-OCR-2

В конце января 2026 года появляется DeepSeek-OCR-2 — развитие архитектуры первой версии.

Во второй версии разработчики отказались от CLIP в энкодерной части в пользу LLM-подобной архитектуры (Qwen2-0.5B). Сжатие входного изображение в 16 раз сохранилось, но вместо его жёсткого патчевания слева направо и сверху вниз применяется подход Causal flow queries — интеллектуальное упорядочивания токенов (модель сама выучивает порядок токенов и может его прогнозировать).

Таким образом, в новой архитектуре реализован причинно-следственный ризонинг изображения — порядок обработки визуальных токенов обоснован семантикой изображения, а не задан жёстко. Это позволяет адаптироваться под сложную семантику документа и подготовить входную последовательность для LLM-модели.

Помимо отказа от CLIP в DeepEncoder v2 разработчики добавили обучаемые токены (learnable query), которые отвечают за порядок чтения. Теперь модель читает документ не в строго определённом порядке слева направо и сверху вниз, а более гибко, как это делает человек, в зависимости от реального расположения сущностей на документе.

Страница может состоять из нескольких блоков текста, различной ориентации. В таком случае простое чтение слева направо и сверху вниз приведёт к потере контекста. Это не оригинальная идея авторов. Например, у PaddleOCR-VL для определения порядка чтения используется предварительная сегментация документа, позволяющая выделить отдельные сущности (блоки текста, таблицы, картинки), и далее с помощью отдельной модели или дополнительной головы прогнозируется порядок их чтения. DeepSeek же предлагает отказаться от дополнительной модели и выучивать порядок чтения с помощью специальных токенов.

Токенайзер в DeepEncoder V2 остался тот же, ViTDet (80 млн. параметров), а также два свёрточных слоя, уменьшающие число токенов в 16 раз. Единственное отличие — число каналов последнего свёрточного слоя уменьшили с 1024 до 896 для выравнивания размерности с последующим пайплайном.

Декодер здесь используется такой же, как и в первой версии, — DeepSeek-3B-MOE.

DeepSeek-OCR2 обучался на тех же данных, что и DeepSeek-OCR, но теперь в 3 этапа:

• DeepEncoder V2 извлекает визуальные признаки и переупорядочивает токены;
• на этапе Query Enhancement: DeepEncoderV2 обучается совместно с декодером DeepSeek-3B-MOE, а в энкодере веса токенизатора (ViTDet + conv) замораживаются;
• все веса DeepEncoderV2 замораживаются, обучается только декодер.

Сравнение результатов DeepSeek-OCR2, DeepSeek-OCR и Gemini-3-Pro представлено в таблице выше.

Стоит отметить: контекст, поступающий на вход LLM-декодера, был ограничен в диапазоне от 256 до 1120 токенов. Максимальное число токенов контекста — 1120 — выбрано не случайно. Именно такой контекст у Gemini-3-pro.

И тут DeepSeek-OCR 2 показал меньшее значение Edit Distance (0.1) против 0.115 у Gemini на бенчмарке OmniDocBench v1.5 в задаче парсинга документов. То есть DeepsSeek смог при сохранившемся высоком уровне сжатия входной информации обогнать значительно большую в размере модель.

Заключение

Кроме DeepSeek-OCR и DeepSeek-OCR-V2, сжатие контекста изучается и в других статьях. Например, в Glyph рассматривается концептуально другой подход к сжатию контекста: без преследования практической цели, например, решения задачи OCR. Работа вышла одновременно с первой версией DeepSeek-OCR, в октябре 2025 года, и подтверждает стремление разработчиков уменьшить входной контекст LLM с помощью оптического сжатия и VLM.

Главное отличие подхода Glyph — внимание уделяется способу рендеринга изображения, а не архитектуре энкодера. При высокой степени сжатия входного контекста, то есть при довольно низком разрешении рендера (72 dpi — компрессия в 4-7 раз), Glyph существенно проигрывает по точности популярным открытым моделям на 8 млрд. параметров в поиске информации в длинном контексте из бенчмарка LongBench. Если снижать уровень компрессии — можно добиться сопоставимого уровня точности, но при этом уровень сжатия будет небольшим, в 1.2-2.8 раза. Glyph больше интересен как подход к решению задачи сжатия входного контекста, нежели потенциальное SOTA-решение.

На основе рассмотренных статей, посвященных оптическому сжатию контекста, можно сделать вывод — есть оптимистичные результаты, но есть и ряд недостатков. А именно:

• при определённом разрешении изображения точность может упасть критически: например, при сжатии в 20 раз точность DeepSeek-OCR падает до 60%, и часто это зависит от плотности текста, то есть при одном и том же разрешении в зависимости от плотности текста можно получить совершенно разные значения точности;
• такие модели хуже справляются с разреженными данными (редко встречаемые, слабая семантическая связь с соседним текстом), например, ИНН, ОГРН, по сравнению с обычными LLM;
• VLM модели в целом хуже обобщают информацию, не обладают гибкостью рассуждений, как LLM.

Специфика архитектуры (DeepSeek-OCR), сложность подбора конфигурации рендеринга (Glyph) и более общие недостатки, перечисленные выше, пока препятствуют появлению SOTA-решений на базе оптического сжатия контекста, но красота идеи и оптимистичные результаты на бенчмарках дают надежду, что это направление будет развиваться! Ведь оно по смыслу гораздо ближе к природе человеского восприятия текста 😊

Полезные ссылки

• DeepSeek-OCR
• Deepseek-OCR-2
• Glyph