我们花了一个月的时间痴迷于网关延迟
我花了一个月的时间来测量 LLM 网关的开销。我将代理延迟追踪到了微秒级别。我分别在每秒 500、1000 和 5000 次请求的负载下进行了压力测试。
然后一位同事问：“网关占总请求时间的百分比是多少？”
我运行了查询。答案是 0.3%。
以下是目前 LLM API 调用在延迟方面的成本：
• GPT-4o: 850ms TTFT | 总计 2-8s • Claude Sonnet 4: 900ms TTFT | 总计 3-15s • Claude Fable 5: 147s TTFT | 总计 155s • GPT-4.1: 1,100ms TTFT | 总计 3-12s • Gemini 2.5 Flash: 500ms TTFT | 总计 1-5s
现在来看看网关增加了多少：
• 直接 API 调用: 0ms • Python 代理: 8-40ms • Go/Rust 代理: 1-11ms
争论的焦点在于，对于一个耗时 3,000ms 到 155,000ms 的调用，你到底是增加了 8ms 还是 1ms。这就像是在为从卫星下载文件的过程争论是否需要一根更快的 USB 线一样。
一些基准测试声称“延迟快了 50 倍”。这些测试通常在资源有限的小型机器上运行。在生产环境中，你会进行水平扩展。当你使用多个实例时，延迟会降低。
实际的 LLM 调用耗时是网关的 50 到 1000 倍。你的延迟来自于模型，而不是代理。
以下是真正对我们产生显著影响的因素：
- 模型选择：在简单任务中从 GPT-4o 切换到 Gemini 2.5 Flash，使延迟降低了 60%。
- 基于延迟的路由：将请求路由到最快的可用模型，使我们的 P99 延迟降低了 40%。
- 缓存：这在我们的工作流中减少了 30% 的冗余调用。
- Prompt 长度：将 system prompts 从 2000 个 tokens 缩减到 800 个 tokens，使响应速度提升了 35%。
- 故障转移：在服务中断期间自动切换到其他提供商，以保持服务运行。
如果你选择 LLM 网关，请转而关注以下这些方面：
- 提供商覆盖范围：它是否支持你需要的模型？
- 路由与故障转移：它能否处理服务中断？
- 成本追踪：你能看到哪些用户消耗了大量 tokens 吗？
- 生态系统：当出现问题时，是否有社区提供帮助？
- 可扩展性：能否轻松添加自定义逻辑？
微秒级的网关开销只是一个营销噱头。它不是生产环境中的问题。我宁愿使用一个增加 40ms 延迟但能追踪成本的网关，也不愿使用一个只增加 1ms 延迟却让我对成本一无所知的网关。
你在 LLM 基础设施方面最大的痛点是什么？
可选学习社区：https://t.me/GyaanSetuAi