零数据留存 LLM 网关:企业为什么需要会遗忘的转发器

只要你在应用和 LLM 上游之间塞了任何一层路由,你就给客户数据多开了一个落地的房间。这一层可能是你自己撸的反向代理、可能是开源 router、也可能是托管的 AI 网关。但从 GDPR、SOC 2、HIPAA 或者你自己事故响应预案的角度看,问的都是同一个问题:这个中间盒会不会留住穿过它的东西?

大多数会留。它们把 prompt 留在请求日志里方便调试。它们把 completion 留在缓存里降低上游成本。它们把两者都灌进数据仓库做面板。它们在异常时把请求体快照进 error tracker。这些操作单看每一项都是无邪的工程便利,合在一起,从合规视角看,就是同一件事:一个厂商现在持有了你客户输入的副本。

零留存网关是反过来的设计。中间盒把字节往上游推、把字节往回带,然后忘掉。一次请求结束后能活下来的只有一行计费读数。本文讲清楚这种设计具体要求什么、为什么留存在生产环境里很危险、以及在把真实流量切过去之前怎么验证厂商的承诺。

"零留存"应该指的是什么

这个词已经被磨平了。营销页上写着"我们不留存你的数据",底层系统其实把 prompt 写进 30 天的日志桶,还把那叫"运营需要"。一个有用的定义得更尖锐。

作为技术承诺,零留存应当指:请求体和响应体永远不会写入任何持久化介质。它们只在上游调用的生命周期里活在进程内存中,响应一结束就被释放。具体来讲,一个零留存网关:

• 永远不把请求体或响应体写入日志文件,无论日志级别是 debug 还是 trace
• 永远不把请求体或响应体写入数据库、消息队列、对象存储或任何持久化后端
• 永远不缓存 completion 后回放给后续用户,即便是同一个账户内部
• 永远不把请求或响应内容转发给任何第三方分析、可观测性或内容审核服务
• 永远不把请求或响应内容快照进 error tracker、APM 产品或审计链
• 不在任何面向用户的控制台里提供"最近请求"视图

如果一个厂商的留存说明对以上任何一条沉默,把这种沉默直接当成"是"。工程团队不会羞于宣传客户在意的功能的"缺席"。

同样要明确,零留存不等于"不训练"政策。不训练政策的意思是:我们不会把你的数据喂进我们的模型训练。零留存的意思是:我们根本不存你的数据。前者更弱:它仍然允许存储、人工审阅、内部分析、和泄露风险。后者直接把数据从威胁面里拿掉,消除整一类风险。

留存在生产里为什么危险

"我们记录 prompt 是为了调试"听起来人畜无害,直到你和隐私律师坐下来过一遍合规。这种留存离开你管控边界的那一刻起,至少在四条路上都会变成负债。

1. 监管暴露(GDPR、SOC 2、HIPAA、CCPA)

大多数企业隐私框架围绕一个原则:数据最小化——只收集和保留你需要的,只在你需要的时间里。当一个第三方网关存了 prompt,这些 prompt 现在就交给了你客户可能没有同意过的子处理者处理。在 GDPR 第 28 条下,你需要和这个子处理者签 DPA,并能可辩护地说明它持有什么。在 SOC 2 下,网关进入你的隐私和保密性边界,审计师会问 prompt 数据是怎么保护、留存和销毁的。在 HIPAA 下,只要 prompt 可能含 PHI,网关就是 business associate,需要签 BAA。当答案是"网关从一开始就不存请求体",上面每一条都会变得简单得多。

2. 你客户数据的连带责任

如果你的应用接受用户输入并把任何片段塞进了一次 LLM 调用,你的网关就是你用户内容的托管方。网关侧的一次泄露就是你客户数据的一次泄露——尽管丢数据的存储层不是你写的。出去通知用户的人会是你,不是网关厂商。把网关的留存面缩小,是降低自身爆炸半径最便宜的一种办法。

3. Prompt 内容本身就是攻击面

被留存的 prompt 就是可以被外泄的 prompt。多数 LLM 应用把私有 system prompt、检索上下文、用户输入塞在同一个请求体里。如果网关存了这些请求体,一次凭据泄露、一个 SSRF bug、或者厂商内部一次安全事件,就会变成所有曾经穿过这一层的 system prompt 和检索片段全数泄出。Prompt 没法像 API key 那样"轮换",一旦语料出去了,就出去了。

4. 竞争和 IP 流失

你的 prompt 编码了你的业务逻辑。评估器 prompt 的措辞、tool calling 协议的形状、你磨了几个月的 few-shot 示例、你注入检索结果的顺序——这些就是壁垒,也是被留存日志可以轻松抄走的东西。一个持有你请求体的网关,就是一个持有你 IP 的网关。把它当成把训练数据交给第三方一样去对待。

零留存网关的架构形态

零留存是一种架构属性,不是一条政策条款。政策会变,架构留下。一个正确搭建的转发器,形状大致是这样:

      client                  gateway                upstream LLM
        |                        |                         |
        |  POST /v1/messages     |                         |
        |  (request body)        |                         |
        |--------------------->  |                         |
        |                        |  open upstream conn     |
        |                        |  stream body through    |
        |                        |-----------------------> |
        |                        |                         |
        |                        |  <-- response chunks    |
        |                        |  pass-through to client |
        |  <------- chunks ----  |                         |
        |                        |                         |
        |                        |  on stream end:         |
        |                        |  parse usage headers    |
        |                        |  write 1 billing row    |
        |                        |  drop body buffer       |
        v                        v                         v
                            [ memory only ]          [ provider keeps
                            [ no disk, no DB ]         per its own ToS ]

这种设计有几个关键属性:

• 请求体永远不会被收拢到一个单独缓冲区里以供检视。网关是按 chunk 流式过的,请求生命周期里不存在一个"完整 prompt 在堆上等着被写到某处"的瞬间。
• 计费数据来自响应头和 usage 事件,不来自 body 解析。Anthropic、OpenAI、Google、xAI 都在结构化元数据里暴露 token 计数。一个正确的网关会在流结束时抽出这些计数,写一行只含模型名、input tokens、output tokens、时间戳和已认证 user_id 的记录。这一行没有一个字段碰到 prompt 内容。
• 请求中途没有任何改写。网关不重写 prompt、不偷换便宜模型、不注入 system 指令、不缓冲响应来"美化"输出。客户端发出去的每一个字节都到达上游;上游返回的每一个字节都到达客户端。这就是"透明转发"在实践中的样子。
• 内存压力替换存储压力。请求体只活在和连接绑定的缓冲区里。连接关闭时,运行时回收它们。没有刷盘路径,因为根本没有磁盘路径。

哪些字段会被留下,为什么

"请求体零留存"不等于"什么都不留存"。网关至少要留够元数据来计费、做限流、给你看用量。诚实的回答是,以下运营元数据会被保留:

注意这张表里没有的:prompt、completion、system 消息、工具定义、tool call 参数、检索文档、附件,或者任何文本内容。这些都不计费需要,零留存网关不会去收它不需要的东西。

孤立看,token 计数就是整数,无法反推出 prompt 文本。多数监管者和审计师把 token 计数这种聚合计费指标视为运营遥测,而不是个人数据。和 user_id 的组合可能落入你自己的隐私政策,但真正承担监管重量的部分——prompt 本身——已经不在了。

作为客户怎么核实网关的留存承诺

营销话术廉价。在把生产流量打过任何一个网关之前,跑一遍核实清单。下面这些步骤都不需要厂商配合,它们能告诉你的比一张光鲜合规页多得多。

逐字读服务条款

在 ToS 里搜:retain、store、log、cache、archive、analytics、improve、training。注意留存窗口。"我们留存请求数据 30 天"不是零留存。"我们在提供服务必要的时间内留存请求数据"也不是零留存,这是一张空头支票。你想看到的措辞更接近于"请求体和响应体不会被写入任何持久化存储"。

要数据流图

任何认真做这件事的厂商都能给你一张图,标出从入口到出口字节的走向。看分叉:每一个从主转发路径上岔出去的箭头,都是一个可能藏留存的位置。一张干净的零留存图只有两条路径——请求和响应——加上一条专门给计费元数据的支线。

跑一次反向验证

发一个带唯一可搜字符串的请求,比如 ZRTEST-7c4a9b2f-please-do-not-store-this。然后在厂商所有暴露面里搜这串:控制台、账户导出接口、客服会话、错误追踪集成、示例 webhook。如果它在上游厂商日志之外的任何地方出现,这家就是在留存请求体。

抓取链路

同一个请求跑两次:一次直接打上游,一次走网关。把网关的出向 IP 加白(或者在你出口流量上做一次受控镜像),你可以字节级地确认网关转出去的 body 和你发的一致。任何偏差——注入了 system prompt、改写了与内容相关的请求头、压缩了响应导致 payload 变化——都说明这不是一个透明转发器。

看 SOC 2 / 渗透测试摘要

对一家正经厂商,要 SOC 2 Type II 报告或近期第三方渗透测试摘要。看 system description 里的在范围组件。如果描述里列了接触请求体的日志聚合系统、分析仓库、消息队列,那就是你的留存面。如果没有,这是一个强信号。

提防"安全例外"措辞

有些厂商会写:除"滥用预防所必需"之外不留存。这往往意味着一部分流量被镜像到了一个独立的审核系统。这可以接受,前提是审核管线本身也是零留存的、且只在内存里跑。问清楚:审核副本去了哪里、活多久?

BUZZ 在这张图里

BUZZ AI Gateway 就是按上面那个架构搭的。一把 API key 同时打通 Claude、GPT、Gemini、Grok。请求体和响应体是流式过去的——不写日志、不进数据库、不做跨用户回放、不转发给任何第三方分析或审核管线。一次请求结束后能活下来的只有那一行计费记录:模型名、token 计数、时间戳、user_id、状态、延迟。

接入只需改一行。把 Anthropic SDK 指向 https://buzzai.cc,或者把 OpenAI SDK 指向 https://buzzai.cc/v1。线协议和上游厂商完全一致,因为 BUZZ 不去改它。

# Anthropic SDK
from anthropic import Anthropic
client = Anthropic(
    base_url="https://buzzai.cc",
    api_key="sk-buzz-..."
)

# OpenAI SDK
from openai import OpenAI
client = OpenAI(
    base_url="https://buzzai.cc/v1",
    api_key="sk-buzz-..."
)

所有支持模型的价格都在 buzzai.cc/api/pricing 列出,实时模型目录和能力描述在 buzzai.cc/models。两个端点都公开且机器可读,你可以直接接进自己的分发逻辑,不用去爬营销页。

常见问题

结语

对软件来说,留存是默认行为——存储很便宜,工程师也喜欢有日志可看。但对一个夹在企业应用和模型上游之间的 LLM 网关,这个默认是错的选择。每一条被留下来的 prompt,都是未来的一次安全通报、未来的一次审计发现、未来某个对手抄走你壁垒的一次机会。这种留存的代价不会出现在月账单上,而是在事情出问题那天才浮现。

零留存网关把默认翻了过来。字节穿过、计数器统计 token、请求体消失,活下来的只有一张收据。如果你在评估一个 AI 网关,而厂商对"我的 prompt 在哪里"的回答不是"它们不在,而且这是证明这件事的架构图",继续找。

需要一个把 Claude、GPT、Gemini、Grok 收在一把 key 后面的透明零留存转发器,看 BUZZ AI Gateway、公开的价格端点、以及模型目录。