Building a reliable, multi-region LLM gateway

据现场外部录音整理，未与本人录音对照。讲者是 Optiver 的 AI Engineer，英文演讲，无问答环节；幻灯片上的监控图和 trace 截图只能从口述还原。

一句话

LLM 网关看着只是转发请求，但 LLM 请求有状态（流式、缓存、thinking 链），协议翻译、简单负载均衡、跨区域共享库都会出问题。Optiver 靠同会话粘性、功能取交集、备份常态分流、鉴权本地化、全链路 tracing 一路补，最后放弃协议翻译，自建精简网关。

他说网关已经像水电一样成了基础设施，一出问题所有人都知道，用户比监控还快。流中途卡住、缓存被破坏、thinking block 被静默丢掉，这些问题最后多半归到协议翻译上。

“HTTP 200, which is the standard HTTP code for successful requests, does not always mean successful here.” ——HTTP 200 在这里不一定代表成功。

规模：每天约 300 万次 LLM 请求，四个数据中心，22 个模型承担 95% 的请求，上游协议有 Anthropic Messages、OpenAI 兼容、Gemini 等。上游错误率约 0.4%，没说统计口径；他的意思是基数大时错误就多，单个用户碰到一次体验就坏了。
起点是一个开源 LLM 网关，免写代码就能支持多 provider 和协议互译，服务内部几千名用户。名字没说。
早上 Slack 里有人抱怨，下面的 +1 从 10、20、30 涨到 100。用户分不清是网关、上游还是工具调用坏了。
缓存命中通常只付约十分之一的价格，翻译出错导致缓存失效后，成本很快翻倍甚至三倍。没给具体金额。
静默失败：Anthropic 的 thinking block 以加密签名形式返回，某些情况下在响应里被静默丢掉。当次用户看不出，下一轮因为思维链断了，上游要重新生成，延迟和成本都上升。是一位用户的 agent 发现了异常，最后定位为从 OpenAI 兼容 harness 调 Anthropic 模型时的协议翻译 bug。他们因此告诉用户别用 OpenAI 兼容 harness 调 Anthropic 模型，反之亦然。

每个重要模型至少接两家 provider 互相 failover，但因为 LLM 请求有状态，不能简单负载均衡。

“you cannot simply load balance between them. Because the nature of LLM request is stateful.” ——不能简单负载均衡，因为 LLM 请求有状态。

“You can have two sessions calling two different models, but never one session across the two models.” ——两个会话可以走两家，一个会话绝不能跨两家。

两家之间随便分流，即使是同一个模型，缓存也很容易坏。
Anthropic 一方 API 有藏在 beta flag 后的功能，比如他说能大量节省 MCP 工具 token 的 tool search，但 AWS Bedrock 当时未必支持。同一个模型 ID 后面挂两家时要对用户隐藏差异，哪家不支持的功能就关掉。省多少 token 没给数字。
他引了一句老话"backup always breaks when you need it"，所以平时固定分 10% 的流量或会话给备份 provider，拿到它的真实指标，不用等主路坏了才知道备份行不行。10% 怎么定的没说。

需求是权限集中管理、一套凭证全球通用，不让用户按地区管四个 API key。最初所有区域共用一个 Postgres，又因为合规要记录全部提示词和返回，就在开源网关里打开开关把提示词日志存进 Postgres。

“Our main database is four terabytes large. This is the gateway database.” ——网关主库 4TB。

他说指标看网关整体健康，日志管合规，缺的是 tracing。所以在所有 harness、网关和 MCP 工具上做了分布式 tracing。

“But the actual inference time is 17 seconds” ——实际推理只有 17 秒。

“we learned that protocol translation is not something that we want because it breaks things.” ——协议翻译会弄坏东西，所以不想要。