【事件概述】 蚂蚁 inclusionAI 团队为 ArmorOCR 发布官方 GGUF 量化权重，让这款针对旋转、镜像、微小、低对比度、艺术字等对抗视觉文字的 OCR 模型，可以通过 llama.cpp 在本地运行。新仓库同时提供 Q8_0 与 Q4_K_M 两档主模型及视觉投影器权重，其中 Hugging Face 标注 Q4_K_M 约 5.03 GB、Q8_0 约 8.71 GB。 【模型与开发者】 模型：ArmorOCR-GGUF 开发者：inclusionAI / 蚂蚁研究团队 官方发布日期：2026 年 9 月 1 日 基础模型：Qwen3-VL-8B-Instruct 任务：带区域定位的对抗 OCR、文字识别与视觉问答 量化格式：GGUF，提供 Q8_0 和 Q4_K_M 许可：Apache License 2.0，同时受基础模型许可与可接受使用政策约束 日期核对说明：ArmorOCR 基础模型、论文和推理代码在 8 月已经公开；本轮新闻点不是基础模型首次发布，而是官方 GitHub 发布记录与 Hugging Face 仓库在 2026-09-01 新增 GGUF 量化权重。本文按量化版本的事件日期发布，避免把旧模型包装成新模型。 【关键能力与改动】 1. 官方 GGUF 转换：团队同时量化主模型和视觉投影器，并提供 `serve_gguf.sh`，可由 llama.cpp 启动 OpenAI 兼容接口，降低从 Safetensors 自行转换时出现模板、投影器或量化参数不匹配的风险。 2. 两档体积：Q4_K_M 约 5.03 GB，偏向节省存储与运行内存；Q8_0 约 8.71 GB，保留更多数值精度。文件体积不等于完整运行内存，图片编码、上下文、缓存和后端仍会额外占用资源。 3. 面向困难视觉文字：ArmorOCR 把对抗 OCR 定义为带区域依据的视觉感知任务，目标不只是输出字符，还要定位相关文字区域。官方 AdvSpot 分类覆盖空间变换、字形变化、成像退化、上下文融合和视觉编码五大类、十三个细分类型。 4. 单次原图推理：基础模型卡说明，ArmorOCR 直接处理原始图片，不依赖推理阶段的旋转、放大等额外视觉变换，也不需要调用外部工具辅助识别。 5. 两阶段训练思路：模型先通过 On-Policy Self-Distillation，从经过变换的特权观察中迁移对抗文字感知能力，再用带定位、识别、完整 spotting 和 VQA 奖励的 GRPO 细化区域感知。此次 GGUF 发布没有重新训练基础模型，主要改变部署格式。 6. 多种本地入口：官方模型页给出 llama.cpp 的 macOS、Linux、Windows 与预编译二进制用法，也可通过 Ollama、LM Studio 等兼容 GGUF 的环境接入。真正的多模态推理仍需加载匹配的 `mmproj` 视觉投影器。 【官方量化评测怎么看】 官方在 AdvSpot 上给出的平均区域问答准确率为：原始 ArmorOCR 55.7、Q8_0 56.9、Q4_K_M 54.2；平均 IoU 分别为 63.3、58.6、57.2。结果说明两档量化在该表中的识别准确率接近原模型，但区域定位 IoU 都有下降，Q8_0 的下降也不能被略过。 Q8_0 平均准确率略高于原模型不等于量化让模型普遍变强。官方注明原模型结果来自论文中的 PPU 评测，而两个 GGUF 版本在单张 A100 上通过 llama-server 评测；样本量、运行栈和量化噪声都会造成波动。应把这些数字视为发布方在同一数据上的参考，不是跨环境的严格性能结论。 【适用对象】 适合需要离线处理截图、海报、短视频帧、扫描件和复杂排版图片的开发者，尤其适合想测试旋转文字、镜像文字、微小字、手写字、低对比度文字、图案覆盖或 AIGC 融合文字的团队。Q4_K_M 更适合先做低成本可运行性验证，Q8_0 则适合在资源允许时优先评估识别与定位稳定性。 【实际影响】 普通 OCR 往往在规整文档上表现较好，但面对艺术字、反射镜像、背景纹理和故意扰动时容易看错或找错位置。ArmorOCR 的价值是把“读出内容”和“指出文字在哪”放到同一套视觉语言模型中；GGUF 版本则让这种研究模型更容易进入本地桌面应用和现有 llama.cpp 服务。 本地量化还方便团队把敏感图片留在内网测试，并用 OpenAI 兼容接口接入现有程序。但“本地运行”只描述推理位置，日志、前端、插件或上游工作流仍可能外传图片；部署者需要自行审计整个链路。 【部署要点】 官方推荐构建带 CUDA 支持的 llama.cpp，然后用对应量化档位启动 `llama-server` 并加载视觉投影器。请求以图片 data URL 和 OCR 提示组成，示例把推理放在 ` `，最终识别文本放在 ` `。Windows 用户也可先通过 WinGet 安装 llama.cpp，但模型是否能在 CPU 或特定显卡上达到可用速度，仍需实测。 若通过 Hugging Face 的便捷命令拉取 Q4_K_M，应确认客户端实际选择了官方 inclusionAI 仓库和同档位的 `mmproj`。量化主模型与视觉投影器混用不同来源、不同提交或不同精度，可能造成加载错误或识别异常。 【限制与使用提醒】 第一，这次是部署格式更新，不是新的基础模型能力发布。ArmorOCR 仍建立在 Qwen3-VL-8B-Instruct 之上，训练方法和核心 OCR 能力来自此前版本，不能把 GGUF 的日期当成论文或原始权重首次发布日期。 第二，5.03 GB 与 8.71 GB 是 Hugging Face 展示的量化文件规模，不是最低内存或显存承诺。运行还需要视觉投影器、KV 缓存、图片张量、上下文和 llama.cpp 后端；官方没有给出各类 CPU、GPU 和内存配置的统一速度表。 第三，Q4_K_M 在官方表中的平均准确率与平均 IoU 均低于原始模型，Q8_0 的平均 IoU 也下降。对票据金额、合同条款、身份证件、医疗和财务材料等高风险文本，必须保留原图复核和人工确认，不能只依赖一次模型输出。 第四，AdvSpot 数据集本身包含 390 张带区域标注的图片，但仓库仍标注数据即将开放。当前外部团队无法完整复现所有官方评测，应等待数据发布并对自有真实图片进行盲测。 第五，模型可能生成看似合理但图片中不存在的文字，区域框也可能偏移。应用端应校验输出格式、设置最大图片大小和超时、保留置信度或多模型复核，并禁止模型自动执行由图片文字触发的支付、登录或系统命令。 第六，GGUF 与 llama.cpp 的多模态支持仍在演进。升级运行时、聊天模板或视觉投影器后应固定版本回归测试；不要仅凭服务端返回 200 就认定 OCR 内容正确。 【官方来源】 官方 GGUF 模型页：https://huggingface.co/inclusionAI/ArmorOCR-GGUF 官方基础模型页：https://huggingface.co/inclusionAI/ArmorOCR 官方项目仓库：https://github.com/ant-research/ArmorOCR