Spotify 希望让 AI 像电子邮件一样直观，并成为员工日常工作中不可缺少的工具。要实现这个目标，难点不只是接入一个大模型，而是让大量团队能够稳定、安全、可观测地使用不同模型。Spotify Engineering 介绍的方向，是通过 Kong AI Gateway 为生成式 AI 流量建立统一入口。
由于公开摘要没有披露 Spotify 的完整拓扑、插件配置和容量数据，下面不会推断其内部实现细节，而是分析 AI Gateway 在这类大规模场景中承担的职责，并给出一套可以改造的 Kong 配置模板。
为什么模型调用需要独立网关
团队刚开始使用大模型时，通常会让应用直接调用模型供应商：
Application -> Model Provider API
这种方式适合原型，但随着使用规模扩大，问题会快速出现：
- 每个应用都要保存供应商密钥，凭证泄露面持续扩大。
- 重试、超时和限流策略散落在不同代码库中。
- 团队难以回答“哪个应用调用了哪个模型、花费多少、失败率多高”。
- 切换模型供应商时，业务代码和请求格式可能一起变化。
- 敏感提示词、响应内容和审计日志缺少统一治理位置。
引入 AI Gateway 后，调用路径变成：
Application -> AI Gateway -> Model Provider
这多了一跳网络请求，却换来了集中的策略执行点。对 Spotify 这种希望把 AI 推广到日常工作的组织而言，网关的价值不只是转发流量，而是降低每个团队重复建设认证、治理和可观测性的成本。
AI Gateway 应该控制哪些事情
传统 API 网关处理认证、路由、限流和日志。面对生成式 AI，请求仍然是 HTTP，但计量与风险模型发生了变化。
身份与凭证隔离
应用只持有访问内部网关的凭证，模型供应商密钥由网关集中管理。这样可以独立撤销某个应用的权限，也可以轮换供应商密钥，而不必修改所有调用方。
生产环境不应把密钥直接写进声明式 YAML。更稳妥的做法是从 Vault、云密钥管理服务或 Kubernetes Secret 注入，并限制谁能够读取 Kong 的管理接口。
限流与预算边界
普通 API 常按请求数限流，但两次大模型请求的成本可能相差几十倍。除了每分钟请求数，还应关注：
- 输入和输出 token 数量；
- 模型单价与团队预算；
- 并发请求数；
- 响应时间和超时比例；
- 重试造成的额外调用。
如果当前网关只能按请求限流，可以先建立粗粒度保护，再从日志中汇总 token 用量。不要把“每分钟 100 次请求”误认为“成本已经受控”。
可观测性与审计
网关层适合记录调用方、模型、状态码、延迟、token 用量和供应商请求 ID。不过，提示词和模型响应可能包含源码、客户数据或个人信息，不应默认写入普通访问日志。
建议把指标与内容分开处理：指标进入监控系统，正文只在明确授权的调试或审计流程中采集，并设置脱敏、加密和保留期限。
可以这样实践：用 Kong 建立统一模型入口
下面是一个通用实验模板，不代表 Spotify 的内部配置。示例假设所使用的 Kong Gateway 版本提供 ai-proxy 插件；插件可用性、字段名称和授权方式可能随 Kong 版本及许可证变化，运行前应对照对应版本文档确认。
新建 kong.yml，把 YOUR_OPENAI_API_KEY 替换为测试密钥。生产环境应改用密钥管理系统注入：
_format_version: "3.0"
_transform: true
services:
- name: llm-gateway
url: https://api.openai.com
routes:
- name: internal-chat
paths:
- /ai/chat
strip_path: true
plugins:
- name: ai-proxy
service: llm-gateway
config:
route_type: llm/v1/chat
auth:
header_name: Authorization
header_value: Bearer YOUR_OPENAI_API_KEY
model:
provider: openai
name: gpt-4o-mini
options:
max_tokens: 512
temperature: 0.2
- name: rate-limiting
service: llm-gateway
config:
minute: 60
policy: local
可以使用 DB-less 模式启动 Kong。下面命令假设当前目录包含 kong.yml，并且所选镜像包含 AI Gateway 所需插件：
docker run --rm --name kong-ai-gateway \
-e KONG_DATABASE=off \
-e KONG_DECLARATIVE_CONFIG=/kong/declarative/kong.yml \
-e KONG_PROXY_ACCESS_LOG=/dev/stdout \
-e KONG_ADMIN_ACCESS_LOG=/dev/stdout \
-e KONG_PROXY_ERROR_LOG=/dev/stderr \
-e KONG_ADMIN_ERROR_LOG=/dev/stderr \
-p 8000:8000 \
-p 8001:8001 \
-v "$PWD/kong.yml:/kong/declarative/kong.yml:ro" \
kong/kong-gateway:latest
随后发送一个兼容聊天接口的请求：
curl --fail-with-body http://localhost:8000/ai/chat \
-H 'Content-Type: application/json' \
-d '{
"messages": [
{"role": "system", "content": "Answer briefly and include one concrete action."},
{"role": "user", "content": "How should we review an AI service before production?"}
]
}'
在企业环境中，还应给路由添加内部身份认证，例如 OIDC、JWT 或 mTLS，并将限流维度绑定到消费者、团队或工作负载身份。policy: local 只适合单节点实验；多节点部署需要选择能够在实例之间协调计数的策略，否则每个节点都会拥有独立额度。
从试点走向规模化
统一入口不意味着一次性接管所有 AI 流量。更稳妥的采用路径是先选择一两个非关键内部应用，验证网关增加的延迟、流式响应支持、超时行为和供应商错误映射，再扩大覆盖范围。
上线前可以检查以下项目：
- 应用无法读取模型供应商的原始密钥。
- 每个请求都能关联到团队、应用和环境。
- 限流覆盖请求数、并发量，并尽可能覆盖 token 或预算。
- 日志默认不保存完整提示词与响应。
- 流式输出经过代理后仍能及时传递，且连接超时配置合理。
- 对供应商的
429、5xx和超时设置了有上限的重试，避免重试风暴。 - 预先定义模型不可用时的降级策略，而不是盲目切换到行为不同的模型。
- 网关自身具备高可用部署、容量监控和故障演练。
Spotify 的目标说明了真正的规模化并不是“接入更多模型”，而是把 AI 变成可重复使用的组织能力。AI Gateway 可以提供关键的控制面，但它不会自动解决数据合规、提示词质量、模型评估和成本归属问题。把这些责任与网关策略、应用测试和组织流程结合起来，统一入口才会从网络组件变成可靠的 AI 基础设施。