GLM-OCR：几张图片是一份文档，还是几份资料？输入列表会改变结果

三张扫描图放进一个列表，可能是报告的前三页，也可能是三份互不相关的通知。对GLM-OCR SDK，这个区别必须由应用先表达：图片列表会被作为同一份文档的多页，而不是三项独立任务。

官方README的Python与服务说明都明确了这个约定。它看似只是输入格式，却影响输出应该怎样保存、如何命名、以后又怎样引用来源。不能只确认三张图都传成功，就认为文档边界已经正确。

先把“同一份”说明白

如果输入是某份公开报告的连续扫描页，将图片按页序放进列表，符合这个入口的语义。若是三份不同活动通知，则应分别调用，每次对应一份文档。批量处理与多页处理各有位置，不必为了少一次调用就把所有材料混在一起。

这也影响整理结果。报告应保留页序与整体文档身份；独立通知则各有标题、来源与后续状态。识别出来的文字再准确，若被归到错误文件，接进知识库以后仍会产生不属于同一材料的引用关系。

GLM-OCR的完整管线先用PP-DocLayoutV3分析版面，再并行识别区域，最后形成JSON与Markdown。README将页面加载、模型调用、布局检测和结果格式化列为可组合模块。

对文档应用，版面JSON适合继续做区域展示或定位，Markdown便于阅读和文本处理。result.save()把结果保存下来，应用则应把原始文件、页面顺序与输出一同管理。只保留一段模型回答，后面难以判断它来自哪一页、哪份材料。

模型卡还划出另一层边界：SDK面向文档解析，按JSON字段做信息抽取应直接调用模型并使用对应提示。看到模型支持信息提取，不能就把任意字段要求放进页面解析命令，期待它自动变成一套台账系统。

一种方式是智谱MaaS。SDK将文件交给云端服务，直接接收Markdown和布局结果，本机不运行识别模型；采用前需配置API密钥并核对服务条件。网页账号、调用额度与开源代码许可不是同一件事。

另一种是自托管服务加客户端：GPU机器部署完整管线，其他设备通过HTTP提交文档。这里省下的是客户端算力，服务器仍要准备模型、布局组件和推理服务，不能概括为整套系统无需GPU。

代码仓库采用Apache-2.0，GLM-OCR权重采用MIT，管线中的PP-DocLayoutV3另按Apache-2.0。实际使用还需对应的模型与依赖版本；本文依据官方说明解读，没有运行模型或测量中文识别准确率。

它适合给已有文档应用补上清楚的输入边界与结构化产物：先决定哪些页属于同一份资料，再让布局和识别接续。这样得到的内容，才容易在后面的检索、编辑与引用里继续保持来源关系。