先别急着把它当“又一个 OCR 模型”。DeepSeek-OCR 说的是另一个方向：拿视觉做压缩，把长文本“挤”成少量视觉 token，再让解码器还原回文本。意思是：同样的信息，用图像的方式传给模型，比原始文字更省 token。听起来有点离谱，但数据挺硬。
要点先摆出来：
- • 在 Fox 基准里，文本:视觉 token ≈ 10× 时，解码精度约 96–97%；20× 时还能有 ~60%
- • 在 OmniDocBench 上，它用 100 个视觉 token（640×640）就能超过用 256 token 的 GOT-OCR2.0；用 <800 token（Gundam 模式）能压过平均每页 6000+ token 的 MinerU2.0
- • 工程侧做了两件大事：一个新编码器 DeepEncoder（窗口注意力 + 全局注意力之间塞了 16× 卷积压缩），再配一个 3B MoE 解码器（推理激活约 5.7e8 参数）
如果你想初步了解原理，我建议先抓三条线：
- 为什么“用图”比“用字”更省 token？
- 10× 和 20× 的压缩意味着什么、边界在哪？
- 工程落地要怎么切：分辨率模式、token 预算、文档类型差异。
一、为什么“图像通道”能做上下文压缩？
因为文本 token 是按字符/词切的，很细；而图像把版面、排版、文字形状都打包到二维栅格里，视觉编码器一次性“看大片”。对 LLM 来说，文字上下文越长，注意力开销（近似二次）越狠；但视觉 token 数可以相对可控。你可以把它想成：把一串很长的字符串，先“拍成一张图”（或几张），再丢给视觉 encoder，输出少得多的视觉 token，让语言模型去“解码”。只要解码器够会，还原度就高
听上去很像“偷鸡”。但结果是：在 10× 压缩里，OCR 精度能到 96–97%。这不是“完美复原”，可对很多场景足够能打
二、DeepEncoder 怎么省激活、还不丢关键细节？
结构是“三明治”：
- • 前半段：窗口注意力（像 SAM-base 那套）先把局部细节吃进去，激活可控；
- • 中间：2 层卷积把 token 做 16× 下采样（通道升到 1024），把 token 数量直接砍；
- • 后半段：CLIP-large 式的全局注意力吃压缩后的 token，做语义聚合.
逻辑很朴素：该细看时细看（窗口注意力），该全局时全局（dense attention），中间一定要“瘦身”。否则大分辨率下，全局注意力会把显存打爆。参数量级也克制：DeepEncoder ~380M；解码端是 3B MoE，但推理只激活少量专家，算力账能算过来.
三、10× 精度 96–97% 的含义，别误读
- • 10× 压缩 ≠ 100% 无损。编辑距离和格式对齐会吃分，论文里也承认“实际更高”（格式误差掺在评测里）
- • 超过 10× 精度掉得快，20× 左右 ≈ 60%。为什么？一是文档布局复杂度上来；二是低分辨率（512/640）会让小字发糊。这两个因素共同作用
- • 因此真正做产品，要按“文档类别”和“文字量级”定 token 预算。Slides、书籍页可用 64–100 token 跑得还行；报纸类动辄 4–5k 文本 token，必须上 Gundam（局部切块 + 全局视角）模式
给个实操心法：
- • 估文本 token 量级（例如 1k、3k、5k）。
- • 先用 Small（100 token）探底；编辑距离高就升到 Base（256，有效 ~182）；再不行上 Large（400，有效 ~285）；最后才用 Gundam（n×100+256）
- • 记住“10× 以内基本安全”，超过 10× 风险快速上升
四、分辨率/模式怎么选？别一上来就 Gundam
模式表大概是：
- • Tiny：512→64 token（直接 resize）
- • Small：640→100 token（直接 resize）
- • Base：1024→256 token（padding，保持纵横比）
- • Large：1280→400 token（padding）
- • Gundam：n×640 的局部视图 + 1024 全局视图，token = n×100 + 256（n 控制在 2–9)
经验：
- • 小文档（<=1k 文本 token），先 Small，实在不稳再 Base
- • 公式/表格多的 PDF，别怕 Base/ Large，多花点 token 能稳住结构还原
- • 报纸、密集杂志：直接 Gundam，别绕弯子
五、它不仅 OCR：图表/化学式/几何“深解析”有啥用？
- • 图表：图像→HTML 表格。比起直接读轴刻度+柱线，这种结构化输出后续更好喂给数据管道
- • 化学式：图→SMILES，这对化学/药物文献抓取是致命效率提升
- • 几何：平面几何图→字典化线段/端点坐标，这玩意儿对教辅、题库清洗很香（但还很难）
“一个 OCR 模型”，硬是把下游解析做成了“二次模型调用”的统一入口（官方叫 deep parsing）。你可以把它当一个 PDF 抽取总线：能抠文本，也能抠图表结构、识别化学式、给自然图配密集 caption
六、工程账：吞吐、并行、训练小抄
- • 生产侧吞吐：单卡 A100-40G，日 20 万页级生成；20 节点×8卡可到 3300 万页/天（内部实测）
- • 训练并行：4 路 PP（SAM+压缩器 冻结/PP0；CLIP 训练/PP1；MoE 12 层分到 PP2/PP3），DP≈40，AdamW，cosine/step 学习率调度，序列长 8192
- • 数据配比：70% OCR（含传统 + 2.0 解析）、20% 通用视觉、10% 纯文本。高分辨率激活靠“中间 16× 下采样”扛住
这些细节对落地很关键：你要么把它当现成模型用，要么借它的“中间下采样 + 双注意力编码器”思路去改你自己的 VLM 编码器。
七、它会改变长上下文的玩法吗？
我现在的判断：会，但有边界。
- • 会：因为“历史对话→渲染成图→逐轮缩图”这件事，天然模拟“记忆衰减”。新信息高分辨率，旧信息模糊、token 更少——这跟人脑记忆曲线很像
- • 边界：一旦你超过 10×，可靠性掉得快；信息不可逆损（尤其格式和微小符号）是代价。想要“几乎无损”的超长上下文，可能得“多级存储”：最近 N 轮保文本，N~M 轮走 Base/Large 图像，最远历史走 Gundam，必要时再检索召回
换句话说，“光学压缩”更像是把长上下文搬到“视觉缓存层”。当你不需要字字还原，只要“提神提醒 + 关键结构”时，它的性价比就特别高。
八、我的一个小担忧和一个乐观点
- • 担忧：过度追求压缩比。看数字会上头，但 20× 的 60% 意味着你要在业务上容错。信息丢失的代价，得提前设计回退策略（比如命中关键页就回源用文本通道重跑）。
- • 乐观：把“编码器层面的 token 预算”当成一等公民来设计系统。这比单纯加长上下文更工程化。动态分辨率 + 有效 token 统计（padding 后有效 token）这一套，对成本控制特别有用
最后一句话版总结：
- • 想要“便宜的长上下文”，优先把历史塞进视觉通道，10× 内基本稳；
- • 文档类型分档管理 token，别一把梭；
- • 结构化需求强（表/式/几何），就别抠 token，选 Base/Large/Gundam；
- • 把 deep parsing 当总线用，价值远超 OCR 本身
论文原文[1]
引用链接
[1] 论文原文: https://arxiv.org/html/2510.18234v1