量化掉多少精度TeleOCR从bf16到INT4/GGUF的显存-精度账本实测【免费下载链接】TeleOCR项目地址: https://ai.gitcode.com/XingChen-AGI/TeleOCR1.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_dtypetorch.bfloat16载入model AutoModel.from_pretrained( StarDoc-AI/TeleOCR, trust_remote_codeTrue, torch_dtypetorch.bfloat16, ).cuda().eval()这就是三档精度账本的基线。按字节数折算INT4 的理论权重体积约为 bf16 的 1/4即0.71GB而社区情报给出了两组实测数字一组是 INT4 量化后仅需 1GB 显存另一组是 4bit 量化后显存占用 2GB二者差异来自是否计入 KV cache 与激活GGUF 路线的实测则把2.8GB 压到 1.5GBQ4 级别量化并借助 llama.cpp 实现无 CUDA 依赖的 CPU 推理。精度档位权重体积整机显存参考社区实测典型载体bf16 全量2.83GB3GB 起步单卡 3GB 可部署transformers / vLLMINT4bitsandbytes 4bit≈0.71GB1GB ~ 2GBtransformers vLLMGGUFQ4 级别≈1.5GBCPU 内存即可无需 CUDAllama.cpp注意一个容易踩的坑量化省的是权重省不掉 KV cache 与激活。这一点决定了上面那张表只能回答模型装得下吗回答不了单页文档跑得完吗。显存账单里被忽略的大头KV cache 与图像 tokenTeleOCR 不是纯文本模型它的显存大头一半藏在视觉侧。先看语言侧config.json给出 decoder 为 28 层、hidden_size: 1024、num_key_value_heads: 8、head_dim: 128GQA 结构modeling_naviocr.py中的repeat_kv即为此实现。按 bf16 计算每生成一个 token、每层 KV 占用28 层 × 8 KV头 × 128 dim × 2(KV) × 2 字节 ≈ 112KB / token而 README.md 中infer()函数的max_new_tokens4096意味着单次输出上限 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: 2config.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 个特殊 tokenOTSL_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.jsondo_sample: true, temperature: 0.1, top_k: 1, top_p: 0.001,而 README 的infer()直接do_sampleFalse走贪心解码。也就是说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 是成本最低的验证姿势。不同硬件档位怎么选一张决策表把上面的账本汇总按硬件档位给出选择矩阵硬件档位推荐精度依据8GB 以上消费级显卡bf16 全量权重 2.83GBKV cache 预算充足保留 96.87 级精度README.md 的 Quick Start 即此路径4GB ~ 6GB 显卡笔记本、入门卡INT4bitsandbytes 4bit vLLM权重压到 1GB为 KV cache 与长文档留出余量社区实测 1GB~2GB 显存可跑无独显 / CPU / 边缘设备GGUF llama.cpp2.8GB → 1.5GB纯 CPU 推理无 CUDA 依赖国产算力昇腾 910Bbf16 原生社区已落地原生 bf16 部署路径无需量化即可跑满精度值得单独说明的是第三条路GGUF llama.cpp 的社区贡献已被项目方写入 README.md 的 Community Contributions属于官方认可的部署生态。它的代价除了精度回退还有吞吐——CPU 上跑 VLM 视觉编码的 latency 明显高于 GPU适合离线批处理而非在线低延迟服务。而 vLLM INT4 组合则适合服务化场景且社区情报显示 TeleOCR 同时兼容 LoRA 微调INT4 基座 领域 LoRA 是省显存 提精度的折中方案。结论先算权重账再算结构账回到标题的问题量化到底掉多少精度源码给出的答案是——取决于你让模型输出什么。权重账可以精确算清2.83GB → 0.71GB → 1.5GBKV cache 账可以按公式推112KB/token图像 token 另计但精度账没有普适答案文本与版面在 INT4 下代价轻微表格与公式这两项 TeleOCR 的看家本领却恰好落在对量化最敏感的结构化序列上且贪心解码让错误无法被随机性稀释。工程上最稳妥的姿势是双档部署面向结构化入库的关键链路跑 bf16或高比特 GGUF面向容量受限的边缘与 CPU 场景上 INT4/GGUF并借助仓库自带的 OTSL 后处理链路做一次量化前后的 TEDS/CDM 实测用你自己的文档把最后一笔账算平。毕竟 1.2B 模型选量化的意义不是能不能跑而是跑出来的表格和公式还值不值得信。【免费下载链接】TeleOCR项目地址: https://ai.gitcode.com/XingChen-AGI/TeleOCR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考