从你的 API key 到模型厂商之间，中间还夹着哪些子处理方？
本文拆解从客户端到模型厂商之间的一次典型 API 聚合调用链路，逐层分析各子处理方对提示词内容和元数据的可见性，帮助开发者理解数据在传输、路由、计费、审计等环节中的暴露边界。
当你通过聚合站调用大模型时，你的提示词并不会直接飞进模型厂商的服务器。中间至少经过三层：聚合站的前置网关、路由与计费系统、以及模型厂商的 API 入口。每一层能看到的原始数据不同，隐私边界也不同。
第一层：你的客户端到聚合站入口
这一层你完全可控。你发出的 HTTPS 请求首先到达聚合站的反向代理或负载均衡器。
- 能看到什么：完整的请求体，包括提示词、模型名、参数、你的 API key。
- 看不到什么：如果启用了 TLS，链路上的网络设备只能看到加密流量，无法直接读取内容。
- 谁在处理：通常是 Nginx、Cloudflare 或自研网关。它们可能记录访问日志（IP、时间戳、状态码、请求大小），但未必记录完整请求体。
第二层：聚合站的鉴权与路由
请求进入聚合站内部后，首先进行鉴权：校验你的 API key、检查余额、确认模型权限。然后根据模型名决定转发给哪家厂商。
- 鉴权系统：能看到你的 key、请求的模型、时间戳。通常只记录元数据，不持久化提示词内容。
- 路由模块：需要读取请求体中的 model 字段，但可能不解析 messages 内容。部分实现会做内容长度校验或敏感词过滤，此时会短暂接触提示词。
- 计费系统：根据 token 用量扣费。token 计数需要读取提示词文本，但通常只保留计数结果，不保留原文。
关键点：聚合站内部服务对提示词的可见性取决于具体实现。设计良好的系统会遵循最小权限原则，只有计费模块临时读取，路由和鉴权只看元数据。
第三层：模型厂商的 API 入口
聚合站用自己（或贡献者）的厂商 key 将请求转发给模型厂商。此时提示词内容对厂商完全可见。
- 厂商网关：接收请求，进行鉴权、限流、内容审核。能读取完整提示词。
- 模型推理服务：实际执行推理，必然接触提示词和生成结果。
- 厂商的日志与审计：根据厂商政策，可能记录提示词用于滥用检测或服务改进。这部分不受聚合站控制。
哪些环节只看到元数据？
- CDN 和负载均衡：只看 IP、TLS 握手信息、请求大小，看不到加密内容。
- 聚合站的鉴权服务：只看 API key、模型名、时间戳。
- 计费服务：需要 token 计数，可能读取提示词但只存储计数。
- 监控与告警：通常只看延迟、错误率、状态码。
哪些环节能看到提示词内容？
- 聚合站的请求解析中间件：如果做参数校验、格式转换，会读取完整请求体。
- 内容审核模块：如果聚合站提供敏感词过滤，会扫描提示词。
- 模型厂商的 API 网关：接收完整请求。
- 模型推理服务：处理提示词并生成回复。
如何判断一个聚合站是否值得信任？
- 看隐私政策：是否明确说明日志保留策略、是否用于训练、是否与第三方共享。
- 看架构设计：是否支持端到端加密（目前较少）、是否提供不记录日志的选项。
- 看透明度：是否公开子处理方名单，是否说明数据流向。
- 看你的威胁模型：如果提示词包含敏感信息，考虑本地脱敏或使用自托管方案。
小结
一次聚合调用至少经过客户端、聚合站入口、鉴权路由、计费、厂商网关、推理服务六个环节。其中鉴权、路由、CDN 主要接触元数据；计费可能临时读取提示词；厂商网关和推理服务必然接触完整内容。理解这条链路，有助于你评估数据暴露风险，并选择与自身隐私要求匹配的服务。