为何Gemini API的PDF缓存延迟无法匹配原始文本输入？

延迟差异的核心原因 #

1. 缓存未提前完成OCR解析：通过File API上传PDF并创建缓存时，Gemini并不会立即对PDF执行OCR和文本提取，缓存仅存储原始PDF的文件引用。当你第N次调用缓存时，API才会触发PDF加载、OCR识别、文本解析的完整流程，这部分额外操作直接导致了20秒的延迟；而直接传入OCR文本时，文本已经是预处理完成的，API只需处理生成逻辑，所以延迟仅2秒。
2. 文档处理与纯文本生成的资源差异：PDF的OCR和解析需要调用专门的文档处理服务，该服务的资源调度优先级、处理效率和纯文本生成的资源池不同，进一步放大了延迟差异。

可行优化方案 #

• 提前离线OCR预处理：在上传到Gemini之前，用本地工具（如PyTesseract、pdfplumber）对PDF完成OCR文本提取，将提取后的文本存入Gemini缓存。后续调用时直接使用文本缓存，延迟会和直接传OCR文本的情况一致。
• 预触发缓存的文档解析：创建缓存后，立即发起一次轻量调用（比如传入"文档是否已成功加载？"这类简单prompt），触发API完成PDF的OCR和文本解析。后续正式调用时，缓存已经存储了解析后的文本，延迟会大幅降低。
• 拆分大文档处理：如果PDF页数较多，拆分页面分别做OCR提取，再将文本拼接后存入缓存，减少单次文档处理的负载，进一步降低延迟。

内容的提问来源于stack exchange，提问作者joshlevy89