OpenRouter 零数据留存(ZDR)实践:97 款新模型,流量占比近半
ZDR 远不止“不存数据”这么简单,提示、响应、缓存的区分很多人没搞清楚。OpenRouter 的三层执行算是把自由度给足了,做合规服务的人可以仔细看看。
OpenRouter 的零数据留存(ZDR)保证用户提示词和模型响应不被存储,元数据一般安全。自 1 月以来新增 97 款支持 ZDR 的模型,月度 token 量增长 4.3 倍,约占全部路由流量一半。ZDR 在三个层面执行:账户级(整个供应商开启)、护栏级(按 API Key 或组织成员限定)、单次请求级(传参数仅路由至 ZDR 端点)。企业用户可灵活选择控制粒度,避免锁定单一供应商。
当零意味着零
Afzal Jasani · 2026年6月24日

- OpenRouter 如何处理 ZDR
过去一周,“零数据留存”(Zero Data Retention,ZDR)被提及了大约 15 次。第一次是当我和妻子在找电视节目看的时候。她建议我们看新剧《公鸡》。但我们已经看完了前三集!这才叫真正的零数据留存。
接下来的 14 次同样令人兴奋,因为我意识到每个人对零数据留存及其实际含义的看法都不太一样。这让我回想起以前人们要求“实时”数据,当我问他们实时是什么意思时,他们回答说“哦,每 15 分钟一次就很好”。呵,这哪算什么实时。
ZDR 通常意味着保证你的数据在处理后不会被存储。其中的细微差别在于“数据”包含哪些内容。这种对“数据”定义的混淆正是造成隐私和安全风险的原因。
例如,你有提示词和响应。提示词是你发送给大语言模型的内容。根据提供商和套餐的不同,你发送的内容可能会被存储、访问或用于训练未来的模型。因此,企业担心它们实际的提示词是合理的,因为提示词中可能包含专有信息。
举个例子,假设工程团队中的某个人向大语言模型提示词:“调试我们产品中的这个认证问题”。在没有 ZDR 的情况下,这条提示词可能会被存储,在某些情况下还会被用作训练数据,从而超出你的控制范围暴露你内部系统的细节。虽然你的认证问题可能得到了解决,但这风险实在不值得冒。在医疗和金融服务等高度监管的行业中,这种风险会进一步放大。
在响应方面,模型的输出同样敏感。继续上一个例子,大语言模型可能回复说:“除了你的认证问题,我还发现了这些其他漏洞”。如果该响应被保留,那么你的未修复漏洞记录就会存在于第三方日志中,一旦发生泄露或配置错误,这些漏洞就可能被暴露。

然后再加上缓存技术——随着大家都在追求模型 token 优化,缓存已成为重中之重。部分服务商会自动处理对提示词的隐式缓存。具体做法是:将提示词中重复出现的部分存入内存缓存,从而避免重复处理,这能带来显著的成本节省。不过,缓存并不被视为数据留存,因为没有任何内容存入长期存储。你也可以设置显式缓存,但这需要你标记出哪些内容块需要缓存。
因此,“数据”本质上就是提示词和响应。元数据(时间戳、模型版本、延迟、吞吐量、成本等)算是一个例外,但通常认为存储这些数据是安全的,因为它们不包含敏感内容。

在 OpenRouter,我们每天都处理关于零数据留存(ZDR)的问题。事实上,自今年年初以来,我们提供的支持 ZDR 的模型阵容已经变得更加强大。在许多场景下,ZDR 正从“锦上添花”演变为“刚性需求”。

自 1 月以来,我们新增了 97 个支持 ZDR 的模型。虽然可用性很重要,但我们也观察到,ZDR 模型在整个平台上的模型 token 用量始终保持稳定。
可用性说明我们拥有充足的供给,而用量则证明用户正在有意义地使用这些模型。这通常转化为实际的生产工作流。我服务过许多 AI 原生公司,它们既能在前沿模型上使用 ZDR 模型,也能在开放权重模型上使用。这种灵活性如今已成为硬性要求。

自 1 月以来,我们支持 ZDR 的模型月度模型 token 用量增长了 4.3 倍。ZDR 不应以牺牲模型选择为代价。其他服务商无法支持我们所能支持的众多模型,因此如果没有 OpenRouter,你可能会被锁定在单一供应商上,而无法拥有我们默认提供的可选择性。
不过这一切都说得通。我上一篇文章强调了模型可选择性以及企业为何需要它。你不可能从一家供应商那里得到所有你需要的东西,而标准化于一家供应商可能意味着自取灭亡。

在 OpenRouter 路由的全部流量中,大约一半已经是 ZDR。在我们的企业级业务中,我们看到许多组织希望深入了解如何实际执行和启用这一点。
OpenRouter 如何处理 ZDR
那么,OpenRouter 是如何处理 ZDR 的呢?我们在三个层面实施,你可以根据自身需求选择控制程度。
账户层面。在整个账户中,为某个完整提供商(Anthropic、OpenAI、Google 或非前沿模型)开启 ZDR。只需设置一次,后续所有请求都会继承该设置。
防护栏层面。按每个 API 密钥或每个组织成员限定实施范围。这样,生产环境密钥可以要求 ZDR,而沙盒密钥则不要求。团队借此既能执行严格策略,又不妨碍实验探索。
单次请求层面。在单个调用中传入 `"provider": {"zdr": true}`。OpenRouter 随后仅将该请求路由至符合 ZDR 条件的端点,跳过任何无法满足该策略的模型或提供商,并继续尝试列表中下一个符合条件的选项。

请记住,“数据”所涵盖的三项内容:提示词、响应以及中间的元数据。无论你实际关注的是其中哪一项,都可以根据团队的工作方式,在相应的层面实施管控。
这正是受监管团队一直向我们要求的灵活性。围绕 ZDR 的混淆是真实存在的,而且大多数提出该需求的人并不清楚自己指的是提示词、响应、缓存,还是这三者全部。供应商们也并未急于澄清。下次再遇到这种情况,你就知道该具体要求什么了。
现在你可以在账户隐私设置中开启 ZDR,或者通过 `"provider": {"zdr": true}` 在单次请求中强制执行。完整配置请参见零数据留存文档。