量化掉多少精度：TeleOCR从bf16到INT4/GGUF的显存-精度账本实测

【免费下载链接】TeleOCR项目地址: https://ai.gitcode.com/XingChen-AGI/TeleOCR

1.2B 参数的 TeleOCR 在 OmniDocBench v1.6 上拿到 96.87 的综合分，表格 TEDS 97.05、公式 CDM 96.36 双双登顶，压过了参数量高出两个数量级的通用大模型。但榜单之外，真正的落地问题从来只有一个：用多低的精度，换多小的显存，代价是丢掉多少精度？社区里流传着"INT4 后仅需 1GB 显存""GGUF 压缩到 1.5GB""单卡 8G 可跑"等说法，数字之间却缺乏一本可对账的明细。本文直接从仓库源码出发，把 TeleOCR 从 bf16 到 INT4/GGUF 的显存账单逐项摊开，再回答一个更尖锐的问题：表格与公式这两类 TeleOCR 最强的任务，在量化之后究竟会"掉血"多少。

先把账本摊开：一份权重，三种精度

先确认原始账单。仓库中的model.safetensors是一个 Git LFS 指针文件，其头部明确记录：

size 2830223488

即2.83GB（约 2.64GiB），这正是 bf16 权重全量的大小，与社区实测"2.8GB"完全吻合。config.json中"dtype": "bfloat16"，而 README.md 的加载代码也明确以torch_dtype=torch.bfloat16载入：

model = AutoModel.from_pretrained( "StarDoc-AI/TeleOCR", trust_remote_code=True, torch_dtype=torch.bfloat16, ).cuda().eval()

这就是三档精度账本的基线。按字节数折算，INT4 的理论权重体积约为 bf16 的 1/4，即0.71GB；而社区情报给出了两组实测数字：一组是 "INT4 量化后仅需 1GB 显存"，另一组是 "4bit 量化后显存占用 <2GB"，二者差异来自是否计入 KV cache 与激活；GGUF 路线的实测则把2.8GB 压到 1.5GB（Q4 级别量化），并借助 llama.cpp 实现无 CUDA 依赖的 CPU 推理。

注意一个容易踩的坑：量化省的是权重，省不掉 KV cache 与激活。这一点决定了上面那张表只能回答"模型装得下吗"，回答不了"单页文档跑得完吗"。

显存账单里被忽略的大头：KV cache 与图像 token

TeleOCR 不是纯文本模型，它的显存大头一半藏在视觉侧。先看语言侧：config.json给出 decoder 为 28 层、hidden_size: 1024、num_key_value_heads: 8、head_dim: 128（GQA 结构，modeling_naviocr.py中的repeat_kv即为此实现）。按 bf16 计算，每生成一个 token、每层 KV 占用：

28 层 × 8 KV头 × 128 dim × 2(K+V) × 2 字节 ≈ 112KB / token

而 README.md 中infer()函数的max_new_tokens=4096意味着，单次输出上限 4096 token 时，仅文本侧的峰值 KV cache 就接近450MB——这还没算图像。

视觉侧的账更夸张。preprocessor_config.json中min_pixels: 3136、max_pixels: 12845056，即 TeleOCR 采用动态分辨率：分辨率越高，视觉 token 越多。以 README 中 layout 示例为例，图片被resize((1036, 1036))后再送入模型；结合patch_size: 14与spatial_merge_size: 2（config.json 中vision_config），约 1036×1036 像素的图像会切出约 5400 个 patch，经 PatchMerger 2×2 合并后产生1300+ 个 LLM 侧图像 token——这些 token 同样吃 KV cache 与激活。一张高分辨率合同扫描件（接近max_pixels上限）对应的图像 token 可达上万，KV cache 轻松突破 1GB。

所以一本完整的显存账本应当是：

峰值显存 = 权重 + KV cache（文本 + 图像） + 激活（attention 中间矩阵） + 框架开销

量化只压缩第一项。这也解释了社区实测为何出现"1GB"与"<2GB"两种 INT4 口径：单图、短输出的轻任务可以压到 1GB 出头，长文档、高分辨率图的任务即便权重只有 0.7GB，也会被 KV cache 顶到 2GB 以上。选精度之前，先算清楚你的文档长什么样。

精度回退实测：表格与公式为何先"掉血"

这是本文最需要谨慎对待的部分：仓库内并未提供量化前后的基准对比数据，因此下面的结论以源码机理分析为主，辅以社区实测口径，供读者在自建数据集上 A/B 验证。

TeleOCR 在表格与公式任务上的精度优势，恰恰建立在一套对数值高度敏感的结构化输出协议上。表格走的是 OTSL 中间格式——README.md 中定义了仅 6 个特殊 token：

OTSL_TOKENS = [OTSL_NL, OTSL_FCEL, OTSL_ECEL, OTSL_LCEL, OTSL_UCEL, OTSL_XCEL]

<fcel>/<ecel>标记单元格边界，<lcel>/<xcel>标记跨行跨列（对应 HTML 的rowspan/colspan），再由convert_otsl_to_html()做确定性转换。这套协议的好处是让模型"先说结构、再填内容"，避免直接生成 HTML 的结构错误；坏处是结构 token 序列是一串高度有序的离散符号，任何一位 token 的 logit 被量化扰动，都可能造成单元格错位、跨度丢失，最终以 TEDS 的形式反映为整表失分。公式任务同理：LaTeX 输出本质上是\frac、\sum、^{、_{这类符号的长序列，一处下标与上标混淆，CDM 分数就会整体下滑。

更关键的是生成策略放大了这种敏感性。查看 generation_config.json：

"do_sample": true, "temperature": 0.1, "top_k": 1, "top_p": 0.001,

而 README 的infer()直接do_sample=False走贪心解码。也就是说，TeleOCR 的官方推理路径是近确定性的单条路径：没有随机性来"稀释"单点错误，结构 token 一旦被量化引入的噪声推偏，错误会直接进入输出，而不是被多次采样平滑掉。

社区实测给出的口径是：INT4/GGUF 下模型可正常运行，表格与公式的"肉眼可用度"尚可，但结构化精度存在回退风险，且没有公开的量化前后 benchmark 兜底。我的建议是分两类看待：

• 文本、版面、阅读顺序：对量化相对宽容，INT4 可用性较高；
• 表格（OTSL 结构）与公式（LaTeX）：属于高敏感任务，若业务以结构化入库、TEDS/CDM 指标考核，建议保留 bf16 或使用更高比特的量化档（如 GGUF Q6/Q8），并在自建样本上先跑一轮 A/B。

仓库提供了现成的测试素材——assets/table.png（表格样例）、assets/formula.png（公式样例）——配合 README 中 OTSL 转 HTML 的完整后处理链路，量化前后各跑一遍、对比 TEDS/CDM 是成本最低的验证姿势。

不同硬件档位怎么选：一张决策表

把上面的账本汇总，按硬件档位给出选择矩阵：

值得单独说明的是第三条路：GGUF + llama.cpp 的社区贡献已被项目方写入 README.md 的 Community Contributions，属于官方认可的部署生态。它的代价除了精度回退，还有吞吐——CPU 上跑 VLM 视觉编码的 latency 明显高于 GPU，适合离线批处理而非在线低延迟服务。而 vLLM + INT4 组合则适合服务化场景，且社区情报显示 TeleOCR 同时兼容 LoRA 微调，INT4 基座 + 领域 LoRA 是"省显存 + 提精度"的折中方案。

结论：先算权重账，再算结构账

回到标题的问题：量化到底掉多少精度？源码给出的答案是——取决于你让模型输出什么。权重账可以精确算清（2.83GB → 0.71GB → 1.5GB），KV cache 账可以按公式推（112KB/token，图像 token 另计），但"精度账"没有普适答案：文本与版面在 INT4 下代价轻微，表格与公式这两项 TeleOCR 的看家本领，却恰好落在对量化最敏感的结构化序列上，且贪心解码让错误无法被随机性稀释。

工程上最稳妥的姿势是"双档部署"：面向结构化入库的关键链路跑 bf16（或高比特 GGUF），面向容量受限的边缘与 CPU 场景上 INT4/GGUF，并借助仓库自带的 OTSL 后处理链路做一次量化前后的 TEDS/CDM 实测，用你自己的文档把最后一笔账算平。毕竟 1.2B 模型选量化的意义，不是"能不能跑"，而是"跑出来的表格和公式，还值不值得信"。

【免费下载链接】TeleOCR项目地址: https://ai.gitcode.com/XingChen-AGI/TeleOCR