INT4 量化后 1GB 显存跑文档解析：TeleOCR 把私有化部署门槛打到了什么水平
【免费下载链接】TeleOCR项目地址: https://ai.gitcode.com/XingChen-AGI/TeleOCR
文档解析长期以来是 AI 落地中最"贵"的环节之一：要同时搞定版面分析、OCR 识别、表格结构还原与公式 LaTeX 化，此前要么依赖数百亿参数的通用多模态大模型，要么拼装由检测、矫正、识别、结构化多段模型串联的复杂流水线——前者显存成本高到私有化难以承受，后者链路长、维护成本高。TeleOCR 用约 1.2B 参数把这两条路同时走通了：它在 OmniDocBench v1.6 等多个公开基准上以极小参数量登顶，同时社区实测在 INT4 量化后仅需约 1GB 显存即可运行。本文结合仓库源码与社区实测数据，拆解这个"1GB 显存"的数字到底怎么算出来的、精度代价有多大，以及它对单卡 8G 显存的中小企业私有化部署意味着什么。
先看事实：1.2B 参数凭什么登顶
在谈量化之前，必须先确认被量化的对象本身够不够强。TeleOCR 在 README.md 公布的基准成绩相当硬核：
- OmniDocBench v1.6：Overall 96.87，Table TEDS 97.05，Table TEDS-S 98.52，均列全部模型第一；对比之下，235B 的 Qwen3-VL 只有 89.78，GPT-5.2 只有 86.52——也就是说，1.2B 参数在文档解析专项上压过了数十倍体量的通用模型；
- Wild_OmniDocBench（手机实拍、形变文档场景）：Overall 88.53 登顶，表格 TEDS 89.05、TEDS-S 92.14 均为最优；
- PureDocBench：干净、数字降质、真实降质三组场景全部拿下最高 Overall；
- ICDAR2026 Sci-ImageMiner：加权分 41.81，位列榜首。
这个成绩的底气来自架构选择。仓库中的 config.json 清晰展示了其"轻"的结构：文本侧 28 层、hidden_size 仅 1024、intermediate_size 3072，且采用 GQA（num_key_value_heads=8，仅为 16 个注意力头的半数），配合tie_word_embeddings: true的输入输出权重共享；视觉侧是 32 层 ViT，hidden_size 1280，在 modeling_naviocr.py 中可以看到标准的 PatchEmbed、PatchMerger 与窗口注意力实现。参数量约 1.2B 但结构非常规整，这正是量化友好的前提。
INT4 量化的账：1GB 显存是怎么算出来的
先算一笔粗账：1.2B 参数在 bf16 下权重占用约 2.4GB，加上 KV Cache 与激活，README.md 官方 Quick Start 直接以torch_dtype=torch.bfloat16加载，社区实测整体约 3GB 显存即可单卡运行。
INT4 量化的逻辑则更极端：1.2B 参数 × 4bit ≈ 0.6GB 权重，加上动态分辨率图像产生的视觉 token 序列与 KV Cache，整体被压进 1GB 级别显存。社区多篇实测文章（如《INT4 量化后仅需 1GB 显存》《4bit 量化显存优化 <2GB》）交叉印证了这一量级。更值得关注的是 GGUF 路径：社区将约 2.8GB 的 bf16 权重转为 GGUF 格式后压缩至约 1.5GB，并借助 llama.cpp 实现了无 CUDA 依赖的纯 CPU 推理，同时有社区成员在昇腾 910B NPU 上完成了 bf16 原生部署——这意味着显存不再是硬约束，甚至内存/国产算力都能兜底。
量化收益能如此显著，与模型生成侧的"确定性设计"直接相关。generation_config.json 中 temperature=0.1、top_k=1、top_p=0.001，实际等价于贪心解码；README.md 的推理代码也显式使用do_sample=False。文档解析的输出是高度结构化的（文本块、OTSL 表格标记、LaTeX 公式、带 bbox 的版面 JSON），确定性解码天然降低了对权重精度的敏感度，这是它比自由对话模型更适合激进量化的结构性原因。
精度损失：哪些数字要谨慎对待
需要明确一个边界：所有公开的 SOTA 分数均来自 bf16 原生权重，INT4 量化后的榜单成绩目前没有官方数字。社区文章的表述是"4bit 量化后显存大幅下降、精度在业务样本上表现可用"，这属于实测经验而非基准结论。严谨的工程态度应当是：
- 量化后先在自有三类样本（文本页、复杂表格、公式页）上复测，重点观察 Table TEDS 与公式 CDM 这类结构指标，而不是只看字符错误率；
- 社区实战文章普遍提示"Layout-Aware 量化"比无差别 W8A8/INT4 更稳，即对版面与坐标回归相关层保留更高精度；
- 配合预处理约束（保证输入分辨率、禁止二值化、长文档分块策略）可以显著缩小量化带来的退化幅度。
仓库图片本身就演示了模型要处理的多类输入：表格识别示例、公式识别示例、科学图表表格提取。这些正是私有化场景中最难量化评估、也最见真章的内容。
单卡 8G 跑私有化：从"能跑"到"跑得好"
8G 显存的消费级卡（RTX 4060、3060 等）是这个模型最典型的部署目标。三种形态分别对应不同需求：
- bf16 原生（约 3GB）：精度最高，README.md 的 Quick Start 六行代码即可跑通，配合 vLLM 可做并发推理服务，适合对输出质量要求最严的正式生产链路；
- INT4 量化（约 1GB）：一张 8G 卡可以同时驻留模型与大量缓存，甚至给视觉 token 的长文档留出余量，适合多租户或批量解析服务；
- GGUF + llama.cpp：彻底脱离 GPU，落到 CPU/边缘设备，是预算最受限场景的兜底方案。
动态分辨率机制（preprocessor_config.json 中 min_pixels=3136、max_pixels=12845056）保证了量化后依然能吃下高分辨率文档页，而 OTSL 表格中间格式（README.md 中的convert_otsl_to_html及 6 个专用 token）让合并单元格、rowspan/colspan 这类最容易出错的表格结构可以被确定性重建，量化对这一环节的冲击也因此可控。
对中小企业而言：私有化文档解析的性价比拐点
此前文档解析私有化的矛盾是：大模型效果好但显存门槛高（几十 GB 起步），小模型跑得动但结构还原不可用。TeleOCR 把"顶尖解析质量"和"1GB 显存"同时落到 Apache-2.0 协议之下，意味着中小企业一台普通 8G 显卡工作站即可自建知识库解析服务——财务凭证、合同扫描件、法律文书、政务材料的版面理解与结构化入库（RAG 前置环节），不再需要按页调用云端 API，数据全程留在内网。
社区落地案例中反复出现的三个关键词是：RAG 流水线集成、财务/法律/政务场景的 JSON 级结构化输出、以及国产算力（昇腾 910B）与 CPU 推理的降级路径。这些共同指向一个结论：文档解析的私有化门槛，已经从"要一台 A100 或接入专有云服务"下降到"一台 8G 显存的主机"，而量化是这条下降曲线最后的临门一脚。
当然，INT4 并不是免费的午餐。1GB 显存的代价是精度需要用业务数据实测背书，结构类指标（表格、公式）比纯文本更值得重点复测。但对于大多数"要跑得起来、数据不出内网、输出可验证"的文档解析需求而言，TeleOCR 给出的这条从 bf16 到 INT4 再到 CPU 的降级阶梯，已经把选择权完整地交还给了使用者——这在半年前还难以想象。
【免费下载链接】TeleOCR项目地址: https://ai.gitcode.com/XingChen-AGI/TeleOCR
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
