跨国深谈← 返回←LLM 网关生产化实战：Twilio 首席工程师的取舍与踩坑

LLM 网关生产化实战：Twilio 首席工程师的取舍与踩坑

关联

人物 Kanish Manuja

公司 Twilio

概念 LLM 网关 · 回退 · 断路器 · 延迟 · 护栏 · 提示词注入 · 推理模型 · fail open · 负载卸载 · 集中式治理

这一集聊的是一个每个用大模型的公司都绕不开的东西：LLM 网关——架在你的应用和各家模型供应商之间的中间件，负责路由、认证、回退、速率限制和各种治理。你在产品里见过的那句「出了点问题，请重试」，背后就是这套系统在撑着。主讲人是 Twilio 的首席工程师 Kanesh Manuja,他把团队在生产环境里踩过的坑和学到的教训全部摊开来讲。

他给出的核心框架是：网关的心脏处是四样东西的博弈——可用性、延迟、护栏、成本。一旦发生降级，你不可能四样全要，必须想清楚自己的用例要什么。整场演讲就是围绕这四样，逐个讲怎么取舍、怎么做。

可用性：别照搬普通 API 的高可用套路

只有一个模型供应商，他们的上限就是你的上限，他们的宕机就是你的宕机。传统软件工程应对不可靠依赖的办法——指数退避重试、加抖动、断路器(失败次数够了就跳闸、停止调用)——对 LLM 都不够用，因为 LLM 调用又慢又贵：重试一次就飞快吃掉你的延迟预算，盲目重试只会成倍推高成本和尾延迟；而且当你明明有另一家完全正常的供应商可以路由过去时，触发断路器毫无意义。

更好的做法是按请求回退：先试供应商 A,失败了按顺序再试 B。如果你对延迟有极高的执念，可以并行向两家同时发请求——但那会让成本直接翻倍。断路器思想仍可借用：主供应商持续失败就把它移出请求路径、放进冷却期，几分钟后试着放回来。

失败计数存放的位置也有讲究：放实例内存里实现简单，但每次改部署规模，配置和预期都跟着变；做全集群共享才能获得快速故障转移。

几个团队反复栽跟头的地方：

• 回退不透明。行业虽然在向 OpenAI API 兼容格式收敛，但工具调用 schema、token 上限、停止原因等仍有细微差异。网关需要一层归一化层来保证跨供应商回退真正可用，并且要把回退路径好好测试。
• 流式输出锁死你的选择。一旦开始向客户端流式返回内容，就不能中途换供应商，已发出去的定死了——那句「出了点问题」不是偷懒，是设计使然的权衡。
• 备用供应商的容量反而要更高。团队往往把主供应商配置、测试得很到位，备用供应商却得不到同等重视。但它是你最后一道防线，它挂了你的应用就挂了。

延迟：静默的杀手，要按模型按路由监控

可用性故障是明摆着的——会失败、会告警、会传呼你；高延迟却是悄无声息的，需要比可用性调优更多的关注。

两个具体动作：

• 别测网关级聚合延迟。网关往往跑混合负载：嵌入请求不到一秒、分类请求不到一秒、聊天请求三秒、推理请求耗时很长。混在一起算聚合数字「是个谎言」；正确做法是按模型、按路由追踪 P99。
• 按模型类别、按路由设超时。他强调「再怎么强调都不为过」：没有超时是静默故障的头号根因——网关以为请求在被正常服务，实际上并没有。

一句值得记住的话：推理模型的「正常」，相当于聊天模型的「故障」——推理模型高度非确定，同一个提示词可能耗时 2 秒到 60 秒不等，他们见过 P99 无缘无故飙到 60 秒。没有魔法解法，但至少可以按路由固定推理级别；对路由器模型(替你选模型的那种)，要在不确定的系统里尽量让请求具有确定性。还可以对冲长尾：主请求消耗到延迟预算的 P90 时就再发一个请求，能有效压住 P99 长尾。

护栏：它自己也是个会宕机的服务

护栏负责防提示词注入攻击、PII 过滤、毒性过滤，防止 LLM 对客户爆粗口。但它就像另一个服务，也可能宕机、也可能不可靠，于是你必须选：fail open(护栏挂了仍放行请求)还是 fail close(护栏挂了就拦截请求)。这本质是可用性与安全的权衡，没有通用答案——比如毒性过滤器挂了，你可能仍愿意放行；默认选择应该是「你能忍受的最坏情况」。

具体改善手段：

• 时间预算：请求永远不该被护栏耗时束缚，决定速率的步骤应该始终是 LLM 本身，给护栏设独立超时。
• 护栏也要回退：二级提供商、二级检查、缓存决策，别只给模型供应商做回退。
• 放置位置三选一：prehook 在输入上跑，最安全但增加串行延迟；并行跑是他最喜欢的方案，但流式输出配合不好——如果产出结构化输出，请不要流式，把护栏并发跑；posthook 最适合输出监控和审计。

网关自身：别为全公司建一个中央网关

最后他反身审视：网关本身就是你加进请求路径的新依赖。几个教训：

• API 密钥按最细粒度隔离——按路由、按使用场景拆分，否则一个嘈杂的租户就是最大的问题来源。
• 确保支持负载卸载，把它纳入操作手册和演练日。遇到重试风暴时你没法简单横向扩容，web 服务器的内部队列必须设成有界，不能接受无界请求；有需要还可以做流量优先级，保证负载之下最重要的用例先被服务。
• 最重要的一条：中央网关是单点故障。如果你在考虑给整个公司建一个中央网关，重新想想——大多数场景下，人们想要的其实不是中央网关，而是**集中式治理**。路径是：把网关去中心化，通过插件和自定义代码把治理(成本追踪、速率限制管理等)集中化。网关可以由单一团队管理，但不要部署成面向全公司的单一部署，哪怕它是分布式的。

演讲结尾他说，今天是他儿子的生日，而他在这里和陌生人谈论熔断——所以你们至少能为他做的一件事，是去为你和你的客户预防一次事故。

本集带走

• 网关的核心是四选一的取舍：可用性、延迟、护栏、成本，发生降级时不可能全保；先想清楚你的用例要什么，再把对应杠杆设计出来给调用方。
• 回退而非重试：LLM 调用又慢又贵，按请求回退到第二供应商比盲目重试划算；备用供应商的容量余量要设得比主供应商更高，并好好测试它的兼容性。
• 按模型按路由监控 P99、按路由设超时：网关级聚合延迟是谎言；没有超时是静默故障的头号根因。
• 推理模型按路由固定推理级别，长尾用对冲压：主请求用掉 P90 延迟预算就再发一个请求。
• 护栏也要高可用设计：想清楚 fail open 还是 fail close、给护栏时间预算和二级回退；结构化输出不要流式，好让护栏并行跑。
• 别建全公司中央网关：流量去中心化，治理集中化——用插件统一成本追踪和速率限制，而不是把所有流量塞进一个单点。

网关的核心处，是四样东西之间的博弈：可用性、延迟、你的护栏，以及成本。
And right at the heart of the gateway is a fight between four things. It’s availability, latency, your guardrails, and costs.
—— Kanish Manuja · [01:08]

如果你只有一个模型供应商，他们的上限就是你的上限，他们的宕机就是你的宕机。
If you have a single model provider, their ceiling is your ceiling. Their outage is your outage.
—— Kanish Manuja · [01:50]

盲目重试只会成倍增加你的成本和你的尾延迟。
So blind retries just multiply your cost and your tail latencies.
—— Kanish Manuja · [02:54]

我认为，你的备用提供商的吞吐量、容量或余量应该设得更高，因为那是你的最后一道防线。
And I would argue that your throughputs or your capacity or your headroom should be even higher for the second provider or the fallback provider because that’s your last line of defense.
—— Kanish Manuja · [06:12]

你应该按模型、按路由追踪你的 P99,而不是一个网关级别的数字。
You should be tracking your P99 per model per route, not a gateway-wide number.
—— Kanish Manuja · [07:27]

推理模型的「正常」，实际上相当于聊天模型的「故障」。
Reasoning models normal is actually a chat models outage.
—— Kanish Manuja · [08:06]

而且我强烈建议，在一个不确定性的系统里，你至少要让请求尽可能具有确定性。
And I would highly recommend that you at least make requests as deterministic as possible with an undeterministic system.
—— Kanish Manuja · [09:12]

你的请求永远不应该被你的护栏耗时所束缚。决定速率的步骤应该始终是 LLM。
Your request should never be bound by your guardrail timing. It should always be the LLM that is the rate determining step.
—— Kanish Manuja · [11:21]

这里有一条前进的路径，你实际上可以把网关去中心化，同时仍然把治理集中化。
And there is a path forward where you can actually decentralize the gateway and still centralize governance.
—— Kanish Manuja · [15:00]