Mini UFlash：为 Unlimited-OCR 探索 Windows 本地投机解码

[ZhiYiTree]

Mini UFlash：为 Unlimited-OCR 探索 Windows 本地投机解码

一个面向 8GB 级 Windows 设备、受 DFlash / 混元 OCR 思路启发的 Unlimited-OCR 投机解码参考实现。

Research Preview。 链路可运行、可测量、失败可复现；但尚未达到「完整输出下稳定高倍加速」。

仓库：https://github.com/ZhiYiTree/mini-uflash-ocr-windows
更细的自我评估：HONEST_STATUS.md · 测法：../train/GOLD_BASELINE.md

---

从哪里来

Mini UFlash 起源于一个很直接的问题：

混元 OCR 可以通过 DFlash 类草稿模型减少逐 token 解码；
类似思路能否迁移到 Unlimited-OCR，并在 Windows 本地设备上跑通？

经过训练与工程适配，项目已经串起：

草稿模型训练 → 本地推理 → 固定页 A/B 墙钟 → 失败记录。

需要先说清楚：

• 它已经可以运行和测量；
• 它还没有证明「无损、完整输出、稳定显著快于官方」；
• 当前更亮眼的墙钟数字，很大一部分来自长度策略（soft/hard 截断），而不是纯高接受率投机。

---

当前实现

模块	说明
Windows 原生本地网页	Gradio，图片 / PDF 逐页
官方 Unlimited-OCR 后端	稳定质量基线
R5 草稿权重	Release 提供；域续训生产点
Stable DFlash	前缀验证 → KV crop → 失败 resync
运行分档	fast / balanced / lossless（UI 可切换）
A/B 基准	官方路径 vs 投机路径，固定 manifest
成本拆分	draft / verify / resync / pure B1
8GB 训练脚手架	teacher 抽取、TV / Markov / pos0 等
在线 conf	统计 + 温度校准（verify_len 调度）

推理流程（示意）

Unlimited-OCR 当前状态
        ↓
Mini UFlash 预测候选 draft tokens（+ conf）
        ↓
Target 按序验证候选前缀
        ↓
接受正确前缀，crop KV Cache
        ↓
接受差 / 退化 / 周期：resync 或回退 B1

相对「盲写 commit」的实验路径，这里强调：只有 target 认过的前缀才进状态。

---

当前结果（诚实版）

测试环境：Windows 原生 · 约 8GB 级 笔记本 GPU · 固定金标准页（5 scored + warmup）。

墙钟口径：官方 stable 耗时 / 加速路径耗时（>1 表示加速更快）。

模式	相对官方速度（约）	输出特征
Official Unlimited-OCR	1.00×	官方基线
lossless（无 soft 截断）	~0.95×	更完整，暂未实现加速
balanced	~1.5×	软帽放宽；完整度好于 fast
fast / sys_v2	~1.7–1.9×	soft/hard 截断换墙钟

在线观测（同批实验量级）：

指标	约值
live τ（mean accepted draft）	1.1～1.4
pure B1 成本占比	经常 >70%
lossless 长度比（accel/stable）	约 1.8

这些数字只说明当前工程状态，不能外推到所有文档类型与硬件。
完整表与跑次目录见 train/GOLD_BASELINE.md。

---

必须说明的限制

1. Fast 的「快」与截断绑定

Fast 的明显加速，很大程度来自 soft / hard 长度策略（低 τ 提前停写、硬顶 token）。

• 更快，但可能更早结束输出；
• 长文、表格、复杂版式上，用户容易感到截断偏狠；
• 这是产品取舍，不是「无损投机已经成功」的证据。

2. 关掉截断之后

关闭 soft 后，lossless 约 0.95× 官方速度。

也就是说：现有权重还不能支持「完整输出 + 稳定快于官方」。

3. 当前主要瓶颈

• 在线 τ 偏低，B1 回退吃掉大部分成本；
• 训练轨迹与 free-run 推理分布错位；
• free-run hard mining 尚未完成有效验证；
• 金标准页数少；相对官方文本的质量评估不够系统；
• R6 沿同一数据轨迹继续训练 未超过 R5——失败会保留在仓库里，说明「同分布加 step」不会自动抬 live accept。

4. 叙事边界

容易说满	更准确
「1.8× 无损加速」	「可截断策略下约 1.7–1.9×；无损约 0.95×」
「训练大幅拉高墙钟」	「R5 后墙钟跃迁主要来自调度；R6 训练失败」
「已对齐混元 DFlash」	「受其启发的迁移探索；硬件与 τ 条件不同」

---

为什么现在开源

项目已经到了适合公开协作的阶段：

• 基础链路可运行；
• 性能可测量；
• 失败可复现；
• 瓶颈逐渐明确；
• 下一步仍有大量未验证假设。

希望把 代码、权重获取方式、基准方法、失败记录 一起摊开，方便一起判断：

1. 速度究竟来自哪里（τ vs 截断 vs 调度）？
2. 截断牺牲了多少输出质量？
3. 怎样提升真实在线 τ？
4. 怎样减少 B1 回退？
5. 训练 / 推理分布错位如何对齐？
6. 怎样建立更公平的 OCR 加速基准？

---

Help Wanted

1. 在线轨迹与 Hard Mining

从真实推理轨迹中找：

• 高 conf 却很快失败的 anchor；
• 常触发 B1 的上下文；
• 难例文档类型；
• 训练集未覆盖的 token 模式。

目标：验证 hard mining 能否抬 live τ，而不只是 offline 指标。

2. OCR 质量评估

速度数据目前比质量数据完整。需要补充：

• 相对官方文本的字符 / 结构差异；
• 长度与完整性；表格 / 公式 / 多栏；
• 长尾丢失；soft/hard 具体砍掉了什么。

3. Windows 性能复现

欢迎在不同设备上跑统一 manifest，尤其：

• 6 / 8 / 12 / 16 GB 显存
• RTX 20 / 30 / 40 / 50
• 不同 PyTorch / CUDA；SDPA vs eager

报告请尽量包含：GPU、显存、Python/PyTorch/CUDA、文档类型、官方耗时、加速耗时、输出长度、τ、B1 占比、档位与是否 soft。

4. 投机解码与 Cache

• 降 verify / resync 成本；
• 少做无必要 cache 复制；
• crop 后状态一致性；
• 完整输出约束下如何少 B1。

5. 工程与文档

安装、网页、错误提示、教程、基准脚本、实验记录整理——都很欢迎。

---

如何参与

1. setup_full.ps1 + Release 权重，跑自己的文档；
2. 在 Issue 提交环境 / 速度 / 质量（模板见上）；
3. 大改动前先开 Discussion / Issue；
4. Fork + PR；
5. 失败实验只要可复现，同样欢迎。

请不要只写「比官方快」或「比官方慢」。
有价值的报告至少有：环境、输入、模式、双方耗时与输出长度、τ / B1、质量差异、复现步骤。

---

当前定位

Mini UFlash 是一套可在 8GB 级 Windows 上运行的 Unlimited-OCR 投机解码参考实现，覆盖训练脚手架、推理、测量与失败记录。
它尚未对齐「混元式无损高倍加速」。

• 它已经证明：这条迁移路线可以被实现。
• 它还没有证明：这条路线已经被解决。

如果你关心 OCR、投机解码、草稿模型、Windows 推理或评估协议——欢迎一起推。

成功的实验会留下。失败的实验也会留下。

希望这个仓库最终是一套可被复现、质疑和继续推进的公开实现，而不只是只展示最好数字的 Demo。