OpenRouter 正式发布响应缓存(Response Caching)功能。启用后,相同 API 请求命中缓存将直接返回结果,耗时降至 80 到 300 毫秒,且不消耗 token 与计费。该功能已由开源社区开发者 Teknium 确认集成至 Hermes Agent 中。

OpenRouter 响应缓存功能界面与原理说明截图

OpenRouter 响应缓存的工作原理与性能表现

响应缓存位于模型提供商前端。当用户发送带有缓存标志的请求时,系统会将请求体、模型标识、API 密钥及流模式哈希为唯一的缓存键。若此前存在相同请求且未过期,系统直接从边缘节点返回结果,不经过模型提供商,不产生 token 消耗。

缓存查找平均耗时 4 毫秒。完整流或非流响应均能在 80 到 300 毫秒内返回,主体耗时集中在序列化与网络传输。作为对比,同一请求在无缓存状态下,Gemini 2.5 Flash 模型响应约需 1.3 秒,Kimi K2.6 需 4.6 秒,GPT-5.5 需 9.1 秒。OpenRouter 官方博客指出,命中缓存的调用不扣减任何请求或完成 token。Hermes Agent 项目更新确认已合并该缓存逻辑。

核心适用场景与提示词缓存的区别

该功能主要覆盖三大高频场景。首先是智能体重试,当工作流中途失败时,从初始步骤重试,已缓存的中间步骤可即时返回,仅对新增工作付费。其次是自动化测试套件,大语言模型驱动的重跑测试在填充缓存后实现完全确定性且零成本。最后是重复上下文处理,向同一模型重复发送包含系统提示与用户输入的固定请求时,首次调用后后续调用免单。

需注意的是,响应缓存独立于许多提供商原生的提示词缓存(Prompt Caching)。后者仅通过共用前缀缩短系统提示的计费长度,而响应缓存直接跳过模型调用,返回完整响应。用户可通过 HTTP 响应头 X-OpenRouter-Cache-Status: HITMISS 监控缓存效能,并结合 X-OpenRouter-Cache-AgeX-OpenRouter-Cache-TTL 查看存储时长。

配置方式与 API 端点支持范围

启用方式分为两种。用户可在每次 API 调用时添加 X-OpenRouter-Cache: true 头部,或在全局预设配置中设置 cache_enabled: true。缓存保留时间由 X-OpenRouter-Cache-TTL 控制,范围 1 秒至 24 小时(默认 5 分钟)。若需针对特定请求强制刷新,可发送 X-OpenRouter-Cache-Clear: true 头部。

当前功能处于 Beta 阶段。缓存基于 API 密钥隔离,不同密钥(即使属于同一账户)之间不共享缓存条目。支持端点覆盖 /chat/completions/responses/messages/embeddings。传统 /completions 端点、音频接口、/rerank 及视频生成接口暂不支持。值得注意的是,内部处理的大型多模态文件(如超大尺寸图像或音视频附件)无法纳入缓存计算,标准尺寸的多模态输入仍可正常缓存。

OpenRouter 的响应缓存机制为智能体编排与高频评测任务提供了显著的链路优化方案。在 token 成本持续受到关注的环境下,该功能有望成为构建高容错性大语言模型应用的标准基础设施。具体性能表现与端点扩展节奏仍需观察 Beta 阶段的实际运行数据。

评论