开源5天Star破万之后百度Unlimited-OCR的爆火路径复盘【免费下载链接】Unlimited-OCR项目地址: https://ai.gitcode.com/paddlepaddle/Unlimited-OCR2026年6月22日百度在 GitHub 与 Hugging Face 上同时放出baidu/Unlimited-OCRREADME 第一行标语就是Welcome the Era of One-shot Long-horizon Parsing——一次读入一整本书的长程文档解析。6月23日论文挂上 arXiv2606.2305024日 Hugging Face Space 的在线 Demo 上线大约5天后仓库 Star 破万被东方财富、36Kr、智源社区、InfoQ、新浪财经等媒体集中报道标题统一指向同一个钩子「开源5天Star破万」与「核心作者 YY 疑似来自 DeepSeek」。这篇文章不打算复读新闻稿而是直接拆仓库源码这次爆火的技术底牌是什么、长文档解析这个场景为什么恰好踩中当下需求、以及热度回落后项目实际进入了什么阶段。一、爆火路径复盘一周内铺满五个传播节点把 README 里的 Release 时间线与社区情报叠在一起传播曲线其实非常清晰6月22日GitHub Hugging Face 双端开源模型卡带 MIT 协议和transformers推理代码README.md。6月23日论文上线 arXiv标题Unlimited OCR Works作者列表中出现了只有两个字母的署名 YY。6月24日Hugging Face 社区知名开发者 AKAKhaliq官方认领并搭建了 Space Demo——开源模型能第一时间被 AK 做 Demo本身就是被 Hugging Face 社区接住的信号。6月28日vLLM 社区vllm-project 与社区贡献者 Tianyu Guo官宣支持 vLLM 推理README 收录了vllm/vllm-openai:unlimited-ocr官方 Docker 镜像。约6月27日前后Star 破万媒体集中引爆。真正让事件出圈的其实是两条并行叙事线。第一条是技术线它被明确定位为把 DeepSeek-OCR 再推进一步README 中直接写明aiming to push Deepseek-OCR one step further小模型、长文档、一次读完一本书是可感知的卖点第二条是人事线36Kr 与智源社区的报道都在标题里点出核心作者 YY 疑来自 DeepSeek / 前 DeepSeek 研究员新浪、搜狐等后续跟进稿件延续了这个话题。作者身份的悬念叠加对 DeepSeek-OCR 的对标关系让一个 3B 参数的 OCR 模型获得了远超其体量的讨论度——这也是过去两个月 CSDN 上 Unlimited-OCR 部署类文章6月底至7月初密集出现持续有流量的原因。值得注意的是传播并非纯营销驱动CSDN 上 7月4日的《百度Unlimited-OCR部署指南》、6月30日的《Unlimited-OCR是什么部署与使用指南》等实操文章说明热度里有一大部分是真的有人在本地跑。二、场景为什么踩中需求长文档解析的三个痛点与源码里的答案长文档 OCR 一直是端到端多模态模型最难啃的场景痛点非常具体KV cache 随输出 token 线性膨胀生成越长推理越慢、显存越吃紧——这正是媒体标题里告别 AI 越生成越慢的来源。仓库源码里能直接看到对这三个痛点的针对性设计。2.1 环形滑窗注意力KV cache 恒定的秘密config.json中声明了sliding_window_size: 128。但注意这不是标准的滑动窗口注意力——标准滑窗会连 prefill 阶段的 KV 一起截断对 OCR 是致命的因为图像 token 全部在 prefill 段里丢掉任何一部分都会直接损坏识别。实际实现是modeling_deepseekv2.py里的SlidingWindowLlamaAttention.forward()推理时infer()会先把config.sliding_window置空防止DynamicCache截断 prefill token把原窗口值存到config._ring_window里供注意力层读取见 modeling_unlimitedocr.py 第 991-1016 行。attention 内部逻辑分三段Prefill 段完整保留全注意力一个 token 都不丢预热段decode 输出累积到prefill_len W之前正常追加稳态段之后每生成一个新 token就原地覆写prefill 之后的环形槽位slot prefill_len ring_posring_pos (ring_pos 1) % W再对整个 cache 做注意力。效果是无论输出 1 万还是 10 万 tokenKV cache 占用恒定在prefill_len W。配合max_position_embeddings: 32768的上下文多页模式下每页 1024×1024 图像只映射约 256 个图像 token源码中num_queries ceil((1024/16)/4) 1616×16132K 上下文理论上可容纳上百页——Unlimited 的名字由此而来。2.2 双视图视觉编码全局定版面局部保细节UnlimitedOCRModel.__init__modeling_unlimitedocr.py 第 433-443 行同时实例化了两个视觉骨干self.sam_model build_sam_vit_b()SAM ViT-B12 层、宽度 768负责局部细节self.vision_model build_clip_l()CLIP-L24 层、宽度 1024负责全局语义两者由 deepencoder.py 中的build_sam_vit_b()/build_clip_l()构建特征在 2048 维拼接后经MlpProjector投到 1280 维语言空间。前向过程第 479-583 行是典型的全局局部双视图单页大图先走dynamic_preprocess()按长宽比切成若干 640 分辨率的局部 crop全局 1024 概览图与局部 crop 分别过视觉塔用可学习的image_newline、view_seperator向量拼接再按images_seq_mask填回语言序列的image占位符位置。对应到推理 API 就是两种模式gundamimage_size640, crop_modeTrue单页高清精读和baseimage_size1024多页/PDF 连贯解析。2.3 反循环采样长生成不复读长程解码还有一个隐藏杀手模型进入 n-gram 死循环。仓库的做法是SlidingWindowNoRepeatNgramProcessormodeling_unlimitedocr.py 第 353-382 行只在滑动窗口内查重把会复现ngram_size元组的 token 打分置-inf避免全序列扫描的开销。默认参数no_repeat_ngram_size35, ngram_window128直接写死在 generation_config.json 里SGLang 部署时则通过custom_logit_processorDeepseekOCRNoRepeatNGramLogitProcessor在服务端复现同样逻辑。2.4 3B MoE单卡可跑的大模型model.safetensors.index.json显示权重总量 6,672,212,480 字节约 6.2GBbf16 下约 3.3B 参数。语言侧是 DeepSeek-V2 风格的 MoEconfig.json12 层、64 路由专家 2 共享专家、每 token 激活 6 个路由专家、moe_intermediate_size896按此计算每 token 激活约 5.7 亿参数——这就是社区文章里3B 总参、仅激活 570M说法的来源。配合词表 129,280含大量 LaTeX/版式 markup token和 1024×1024 输入单张消费级/入门数据中心 GPU 即可跑多页 PDF这直接决定了它能在 C 端开发者社区快速铺量。三、从爆火到落地生态化才是下半场Star 增速放缓是所有爆款的常态判断项目真实水位要看基础设施的沉淀速度。Unlimited-OCR 在开源 30 天内完成了四件事6月28日vLLM 官方镜像vllm/vllm-openai:unlimited-ocr可用7月初百度智能云上线免部署 APIREADME 标注 7月3日头条系情报里百度智能云开启 Unlimited-OCR 限免即对应此节点7月21日ms-swift 社区完成训练框架适配补齐了微调能力。仓库里那个本地 wheel 值得单独说一句wheel/sglang-0.0.0.dev11416g92e8bb79e-py3-none-any.whl 是百度直接发布的定制版 SGLang。README 给出的启动命令要求--page-size 1 --attention-backend fa3 --enable-custom-logit-processor --disable-overlap-schedule——page-size 1说明 KV cache 分页机制被改造过以配合自定义环形管理这套内核级改动对应kernels包表明团队对推理吞吐是真有工程投入而不只是丢一份权重出来。从百度 OCR 产品线的角度看这次开源也不是孤立事件PaddleOCR 本体在 GitHub 已积累 70k Star2025年10月的 PaddleOCR-VL0.9B曾开源16小时登顶 Hugging Face Trending 第一2026年3月千帆 Qianfan-OCR4B 端到端跟进。Unlimited-OCR 卡位的是其中最痛的一块——长文档端到端解析目标用户是知识库、Agent、文档数字化这类一本一本地喂的场景。那么爆火之后进入什么阶段从源码现状看瓶颈与机会同样清晰transformers 路径下的DeepseekV2Attention是 eager 手写的环形注意力实现prefill 用全矩阵 softmax工程化提速Flash 化的 ring 实现、多请求并发下的显存调度仍有空间而 vLLM/SGLang 双引擎 云 API 的路线恰好把这些工程压力分散到了生态里。对使用者当前的合理姿势是单页精读走gundam模式本地 transformers 推理批量长文档走 SGLang/vLLM 服务端 OpenAI 兼容 API对开发者ms-swift 适配意味着领域微调古籍、票据、医疗报告已经具备条件。5天破万 Star 验证的从来不是一个模型的分数而是长文档解析这个需求终于有了足够轻、足够快、足够开放的开源答案。接下来 6-12 个月值得跟踪的指标也很明确vLLM 与 SGLang 上游合入进度、OmniDocBench 等基准上第三方复现成绩、以及基于它的知识库/Agent 落地案例数量。【免费下载链接】Unlimited-OCR项目地址: https://ai.gitcode.com/paddlepaddle/Unlimited-OCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考