① 他说过的话

9 条

网关的核心处，是四样东西之间的博弈：可用性、延迟、你的护栏，以及成本。
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]

指向原始笔记的链接

② 出现在这些集

1 集

• 《LLM 网关生产化实战：Twilio 首席工程师的取舍与踩坑》 — 作为嘉宾

③ 他谈到的

点进去有真内容 —— 本页主要出口

Twilio · LLM 网关 · 回退 · 断路器 · 延迟 · 护栏 · 提示词注入 · 推理模型 · fail open · 负载卸载

④ 也在聊「智能体」的人