# OpenRouter 零数据留存（ZDR）实践：97 款新模型，流量占比近半

- 来源：OpenRouter：Announcements（RSS）
- 发布时间：2026-06-25 00:00
- AIHOT 分数：68
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmqsi8c9303azslfuexk0h241
- 原文链接：https://openrouter.ai/blog/insights/when-zero-means-zero

## 精选理由

ZDR 远不止“不存数据”这么简单，提示、响应、缓存的区分很多人没搞清楚。OpenRouter 的三层执行算是把自由度给足了，做合规服务的人可以仔细看看。

## AI 摘要

OpenRouter 的零数据留存（ZDR）保证用户提示词和模型响应不被存储，元数据一般安全。自 1 月以来新增 97 款支持 ZDR 的模型，月度 token 量增长 4.3 倍，约占全部路由流量一半。ZDR 在三个层面执行：账户级（整个供应商开启）、护栏级（按 API Key 或组织成员限定）、单次请求级（传参数仅路由至 ZDR 端点）。企业用户可灵活选择控制粒度，避免锁定单一供应商。

## 正文

OpenRouter 如何处理 ZDR

过去一周，“零数据保留”（ZDR）这个词大约被提到了 15 次。第一次是我和妻子在找电视节目看的时候。她建议我们看新剧《公鸡》。但我们已经看过前三集了！这才叫真正的零数据保留。

接下来的 14 次同样令人兴奋，因为我意识到每个人对零数据保留及其实际含义的看法都不尽相同。这让我回想起以前人们要求“实时”数据的时候，当我问他们实时具体指什么，他们会回答“哦，每 15 分钟更新一次就很好了”。没错，这算不上真正的实时。

ZDR 通常意味着保证你的数据在处理后不会被存储。其中的细微差别在于“数据”具体包含什么。对“数据”定义的混淆正是产生隐私和安全风险的原因。

例如，你会有提示词和回复。提示词是你发送给大语言模型的内容。根据提供商和套餐的不同，你发送的内容可能会被存储、访问或用于训练未来的模型。因此，公司担心其实际提示词是合理的，因为这些提示词可能包含专有信息。

例如，假设工程团队的某个人向大语言模型发送了提示词：“调试我们产品中的这个身份验证问题”。如果没有 ZDR，这个提示词可能会被存储，在某些情况下还会被用作训练数据，从而在你无法控制的情况下暴露你内部系统的细节。虽然你的身份验证问题可能得到解决，但这并不值得冒这个风险。在医疗和金融服务等高度监管的行业中，这种风险会进一步放大。

在回复方面，模型的输出同样可能很敏感。延续上一个例子，大语言模型可能会回复：“除了你的身份验证问题，我还发现了这些其他漏洞”。如果该回复被保留，那么你未修补的弱点记录就会留在第三方的日志中，一旦发生泄露或配置错误，这些信息就可能被曝光。

接下来是缓存技术，随着大家都在追求 token 优化，这已成为首要关注点。一些提供商会自动对提示词进行隐式缓存。这意味着提示词中重复出现的部分会被保存在内存缓存中，无需重新处理，从而显著节省成本。不过，缓存并不被视为数据留存，因为没有任何内容被存储到长期记忆中。你也可以设置显式缓存，但这需要你标记出哪些内容块需要缓存。

因此，“数据”实际上指的就是提示词和响应。元数据（时间戳、模型版本、延迟、吞吐量、成本等）是一个例外，但由于它不包含敏感内容，通常被认为是安全的存储对象。

在 OpenRouter，我们每天都在处理与 ZDR 相关的问题。事实上，自今年年初以来，我们提供的支持 ZDR 的模型阵容已经变得更加强大。在许多情况下，ZDR 正从“锦上添花”演变为“必不可少”。

自一月份以来，我们又新增了 97 个支持 ZDR 的模型。虽然可用性很重要，但我们也观察到，所有 ZDR 模型的 token 用量都保持稳定。

可用性证明了我们有供应能力，而用量则证明我们的用户正在以有意义的方式使用它。这通常意味着它已融入实际的生产工作流程。我支持许多 AI 原生公司，它们能够将 ZDR 模型同时用于前沿模型和开放权重模型。这种灵活性现在已成为硬性要求。

自一月份以来，我们支持 ZDR 的模型的月度 token 用量增长了 4.3 倍。ZDR 不应该让你牺牲模型选择权。其他提供商无法像我们一样支持如此众多的模型，因此如果没有 OpenRouter，你可能会被锁定在单一供应商上，无法获得我们默认提供的可选性。

不过，这一切都说得通。我上一篇文章强调了模型可选性以及企业为何需要它。你无法从单一提供商那里获得所需的一切，而标准化于一家供应商可能意味着死路一条。

在我们路由的所有流量中，大约有一半已经是 ZDR 的。在我们的企业客户中，我们看到许多组织希望深入了解如何实际执行和启用这一功能。

OpenRouter 如何处理 ZDR

那么 OpenRouter 是如何处理 ZDR 的呢？我们在三个层级上强制执行，你可以自行选择想要的控制程度。

账户层级。为整个账户下的某个提供商（Anthropic、OpenAI、Google，或非前沿模型）开启 ZDR。只需设置一次，所有请求都会继承该设置。

护栏层级。按每个 API 密钥或每个组织成员来限定执行范围，这样生产环境的密钥可以要求 ZDR，而沙盒密钥则不需要。团队通过这种方式既能保持严格策略，又不会阻碍实验探索。

单次请求层级。在单次调用中传入 `"provider": {"zdr": true}`。OpenRouter 随后只会将该请求路由到符合 ZDR 条件的端点，跳过任何无法满足该策略的模型或提供商，并顺延至列表中的下一个合格选项。

请记住，“数据”可能指代三样东西：提示词、回复，以及两者之间的元数据。无论你实际关心的是哪一项，都可以在适合你团队工作方式的层级上强制执行。

这就是受监管的团队一直向我们要求的灵活性。围绕 ZDR 的困惑确实存在，大多数提出此要求的人并不清楚他们指的是提示词、回复、缓存，还是三者全部。而供应商们也并不急于澄清。下次再遇到这个问题时，你就知道该具体要求什么了。

你现在就可以在账户隐私设置中开启 ZDR，或者通过 `"provider": {"zdr": true}` 在每次请求时强制执行。完整设置请参阅零数据保留文档。