昨天，DeepSeek 发布了一个新模型 DeepSeek-OCR。
这是一个专门为 OCR（文字识别）微调的 6.6GB 模型，主要贡献在于首次量化 “视觉 - 文本 token 压缩比”，验证 10× 近无损压缩、20× 仍保有 60% 精度的可行性；提出 DeepEncoder，解决现有编码器 “高分辨率 - 低内存 - 少 token” 不可兼得的问题；开发 DeepSeek-OCR，在实用场景达 SOTA 且 token 消耗最少，兼具科研价值与产业落地能力。
开源地址及论文全文：https://github.com/deepseek-ai/DeepSeek-OCR
这篇论文引发了不少人关注，其中 Karpathy 就直言：“我很喜欢这篇新的 DeepSeek-OCR 论文。”
它是一个不错的 OCR 模型（可能比 dots 稍微差一点），数据收集等方面也都做得不错，但这些其实都不是最让我感兴趣的部分。
我更在意的，是一个更根本的问题——对大语言模型（LLM）来说，像素是否比文本更好的输入形式？也就是说，文本 token 会不会其实是一种“浪费而糟糕”的输入方式？
或许，从逻辑上讲，所有输入都应该是图像。
即使原始内容是纯文本，也可以先渲染成图像再输入。为什么这么做有意义？
信息压缩更高效（论文中也提到了）：图像输入能在更短的上下文窗口中包含更多信息，推理效率更高。
信息流更丰富：不仅能表示文字，还能自然包含加粗、颜色、格式、甚至任意插图等视觉要素。
输入可以天然地使用双向注意力（bidirectional attention），而不是像语言模型那样必须自回归（autoregressive）地逐步处理，这在结构表达上更强大。
最关键的一点：可以彻底摆脱 tokenizer（输入端）！我早就对 tokenizer 深恶痛绝。它既丑陋又割裂，让整个模型不再是端到端的流程；它继承了 Unicode、字节编码等一大堆历史包袱，还引入了安全和越狱风险（比如续字节攻击）；它让两个看起来一模一样的字符在内部被编码成完全不同的 token；它让一个笑脸表情符号在模型眼里变成一个怪异的 token，而不是一个真实的“笑脸”——模型也因此失去了像素级迁移学习所带来的自然语义。
Tokenizer 必须被淘汰。
OCR 只是视觉 → 文本任务中的一个典型代表。实际上，许多文本 → 文本任务完全可以被重构为视觉 → 文本任务，但反过来却行不通。所以，也许未来用户的输入都是图像，而模型的输出（即助手的回应）仍然是文本。当然，要让模型生成像素级的输出仍然不太现实——或者说，暂时我们也没那么需要。
现在我得努力克制自己，不去立刻搞一个“只接受图像输入的 nanochat”实验项目……
Pleiasfr 联合创始人 Alexander Doria 更是直言：“DeepSeek-OCR 是一个里程碑式的工程成就，代表了轻量高效 OCR 模型的最佳范例。这不是终点，但可能是未来所有 OCR 系统的起点。”
他解释道，人们早就猜测，VLM/OCR 模型其实可以小得多。在多模态视觉语言模型（VLM）出现之前，业界领先的 Google Cloud OCR 模型规模其实也不过一亿参数左右。最近，一些参数相对较小的开源模型已经能与闭源产品正面竞争，其中最令人惊讶的是 dots.ocr ——在其内部和公开的多个基准测试中，它的 17 亿参数模型在准确率上普遍超过了 OpenAI、Anthropic，甚至在某些任务上优于 Gemini，而成本仅为后者的一小部分。
这背后的原因在于：OCR 本质上是一种“模式识别”任务，不需要太多推理或长程记忆，因此模型架构可以相对轻量。这也解释了为什么 DeepSeek-OCR 采用了仅 12 层的精简架构。
他认为，DeepSeek-OCR 在两个方面进一步创新：
它进入了一个新兴的“小型专家混合（Mixture of Experts）”范式——虽然模型总规模较大，但每次推理时只有 5 亿个参数被激活，这让它能在一批次中处理大量数据； 它采用了激进的编码策略（aggressive encoding），并结合了语义池化（semantic pooling）。DeepSeek-OCR 的编码器在输入阶段就做了大量“信号压缩”的工作，把低层视觉信号聚合成更高层的语义单元，再加上一些性能优化手段，这显著提升了处理速度。
不过，Alexander 并不认为这个模型会在 OCR 领域带来颠覆性的飞跃。“它的训练流水线包含了大量合成和仿真数据（尤其是图表类的渲染数据），但从官方样例来看，数据的多样性仍有限。”
但他表示，DeepSeek-OCR 的意义在于成为一个真正“基础型”的 OCR 模型：它几乎已经提前找到了推理效率与模型性能的最佳平衡点，奠定了工程基础，但若要在大规模真实业务中应用，还需要针对特定领域进行数据标注和定制化流程设计。
DeepSeek-OCR 的发布也吸引了大量开发者尝试，目前官方只提供了基于 PyTorch + CUDA 的权重文件。
资深开发者 Simon Willison 表示自己花了大概 40 分钟就把这个模型成功跑在了 NVIDIA Spark 上，靠的是让 Claude Code 用“暴力破解”的方式一步步解决兼容问题。
“这个小实验其实把我最近在研究的一堆概念串在了一起：我为问题设计了一个 智能体循环（agentic loop），给 Claude 完整的 Docker 沙箱权限，用并行智能体的思路去做，同时复用了上周我在 Spark 上的环境配置笔记。”Simon 说道。
Simon 清楚，要在 Spark 这种 ARM 平台上跑 PyTorch CUDA 模型，过程一定会非常折腾。于是他干脆把整个流程外包给 Claude Code，看它能不能搞定。
结论是，它真的搞定了。只用了 4 次提示（1 次长指令 + 3 次短补充），Claude Code 完整地让 DeepSeek-OCR 在 NVIDIA Spark 上跑起来，实现了对一张图片的 OCR 识别，并留下了详尽的笔记。
Simon 从 Mac 用 SSH 连上 Spark，在那边启动了一个 Docker 容器：
docker run -it --gpus=all \-v /usr/local/cuda:/usr/local/cuda:ro \nvcr.io/nvidia/cuda:13.0.1-devel-ubuntu24.04 \bash
接着安装 npm，再通过 npm 安装 Claude Code：
apt-get updateDEBIAN_FRONTEND=noninteractive TZ=Etc/UTC apt-get install -y npmnpm install -g @anthropic-ai/claude-code
启动 Claude Code，并告诉它可以在 sandbox 里以 root 身份运行：
IS_SANDBOX=1 claude --dangerously-skip-permissions之后会弹出一个 URL，点击登录 Anthropic 账号就行。
Simon 先让 Claude 在当前目录下新建一个文件夹：
Create a folder deepseek-ocr and do everything else in that folder然后 Simon 给了它 DeepSeek-OCR 的 GitHub 链接和 Hugging Face 模型地址，并说明要在 NVIDIA ARM 设备的 Docker 容器 里运行，还给它一张要做 OCR 的图片。
Simon 还特意要求它把所有过程写进一个 notes.md 文件里，只能“追加”新内容，这样最后能看到完整笔记。
Claude 运行了 13 分钟，期间探索了各种平台兼容问题，最后崩溃报错：
CUDA error: no kernel image is available for execution on the deviceThe NVIDIA GB10 GPU has compute capability sm_121, which is too new for PyTorch 2.5.1
也就是说，这个 GPU 太新，PyTorch 2.5.1 还不支持。
Simon 提醒它：
“能不能试下别的 PyTorch 版本？看看有没有支持 ARM CUDA 的 wheel 包？”
它就去爬取了 PyTorch 官网的下载目录，找到了 ARM 版本的 CUDA wheel：
curl -s https://download.pytorch.org/whl/torch/ | grep -o 'torch-[0-9.]*.*aarch64.whl' | sort -V | tail -20Claude 找到突破口后兴奋地回应：
“太好了！PyTorch 2.9.0 有 CUDA 13.0 的 ARM64 wheel！这正是我们需要的！”
安装完成后，Claude 报告说：
“PyTorch 2.9.0 可以识别 GB10 GPU，虽然会提示‘最高只支持 CUDA 12.0’，但现在只是警告，不是报错。让我们试着跑一下推理吧。”
于是它继续执行，并成功让模型加载、运行了 OCR。
Claude 发出指令：
<|grounding|>OCR this image.模型成功识别出文本与定位框，生成了检测结果。
不过输出文件 result.mmd 全是空白。
Simon 提示它：“结果是空的，试着让输出更完整。”
Claude 重新查看 DeepSeek-OCR 的 README，发现不同提示词的模式：
<|grounding|>Convert the document to markdown.（适合文档） <|grounding|>OCR this image.（通用模式） Free OCR.（不带布局）
它推测 “grounding” 模式偏重框检测，文本输出可能被忽略，于是重新试了多个 prompt，并生成了一个 PROMPTS_GUIDE.md，总结不同模式下的表现。示例如下：
最后，它把所有结果、脚本、笔记都打包成 zip 文件，Simon 解压后放到了 GitHub 仓库中。
从第一次提示（15:31:07 UTC）到 Claude 最后一条消息（16:10:03），不到 40 分钟。Simon 称只参与了不到 10 分钟，其余时间它自己在跑。
Simon 表示，“作为一个曾多次折腾 PyTorch 环境失败的人，这次我觉得是大胜利。以后我一定会更频繁地用这种方式。Claude 的笔记写得极其详细，我还没完全看完，可能也有错误，但关键是：它确实把模型跑通了，还留下了完整复现步骤。”
最后，Simon 总结了几个成功要点：
给了它充分的环境与目标。Docker 容器、明确的模型地址、清晰的任务定义。 沙箱模式让它完全自主执行，不用每步都点确认。 关键时刻用经验引导。当它卡住时，因为知道 ARM64 CUDA 版本肯定存在，只需提示它去找。
Simon 实践后表示，DeepSeek-OCR 本身的效果也不错，只要花点时间调整提示和运行方式，表现就非常出色。
参考链接：
https://x.com/Dorialexander/status/1980289147609776232
https://simonwillison.net/2025/Oct/20/deepseek-ocr-claude-code/
10 月 23-25 日 QCon 上海站开幕倒计时 3 天，3 天沉浸式学习，100+ 工程实战案例，直面一线的挑战与解法。大会将聚焦 AgenticAI、具身智能、强化学习框架、端侧大模型实践、多智能体协作等热门话题，以及 AI 时代下的软件研发、可观测、开源等技术实践。一票难求，立即扫码预占席位！
今日荐文
你也「在看」吗？👇
