企业级 LLM 网关的路由瓶颈与分布式架构实现
TuBrief 편집팀
2026년 9월 8일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
在企业环境中，当多个团队同时调用生成式 AI 模型时，集中式代理架构由于数千个 Token 的输入输出以及漫长的会话，很容易引发线程耗尽。为了消除 15 到 40 毫秒的跨 VPC 网络延迟以及租户间的邻近干扰（Noisy Neighbor）问题，必须在物理上隔离运行时流量路径与中央策略控制平面。
单一的中央网关在大规模流量环境中会成为瓶颈的根源。引入双层拓扑结构，将流量传输隔离到域别数据平面，并将控制平面保留在中央。
在 Kubernetes 环境中，声明式地应用 Envoy AI Gateway 1.0 规范。在各个业务域的命名空间中创建 Gateway 资源以终止 HTTPS 流量，并联动 BackendSecurityPolicy 以从中央安全密钥库（Vault）同步 API 认证密钥。定义 AIServiceBackend 和 AIGatewayRoute 资源，以读取请求体中的模型参数并分流路由。
即使中央策略服务器或企业网络骨干网发生故障，各个域也能通过最近同步的缓存策略，无中断地处理推理流量。将控制器的消息大小设置扩展到 25MB 以上并稳定轮询周期，以抑制因频繁重载而导致的 CPU 尖峰。
如果将整体周转时间作为单一指标收集，大模型和大模型、小模型的推理时间就会混杂在一起，从而掩盖性能退化。当 P99 指标出现跳跃时，为了区分是外部供应商的 GPU 预填充队列过载还是网关内部的锁等待时间，必须在中间件层分阶段独立计量。
直接编写中间件以在网关管道中收集 Prometheus 直方图（Histogram）指标。通过 ASGI 中间件捕获客户端进入时间，并将租户 ID 和路由域标头存储在状态值中。将内部中间件排队延迟时间记录到 Histogram 对象中，以收集 0.001 秒到 2.5 秒之间的桶（Bucket）。在管道化上游客户端流的过程中检测接收到第一个 Token 字节的时间点，并将供应商纯 TTFT 延迟作为独立的直方图进行观测。
根据 Uber 基础设施治理案例，当将此类内部中间件排队 P99 延迟与后端供应商各自的纯 TTFT 延迟并排配置在 Grafana 仪表盘上时，客户咨询摘要生成管道的响应处理时间缩短了 6 秒。
绝大多数 LLM 推理服务器在立即刷新 200 OK 状态码后，会暂停传输负载数秒，直至加载完 KV 缓存。为了避免用户看到停滞不前的画面，必须运行实时检测首个 Token 字节接收延迟并将其回退切换至备用模型的运行时引擎。
结合异步事件循环和流控制逻辑来实现运行时回退路由。定义包含第一供应商和第二供应商的端点及认证标头的配置字典，并将超时阈值设为 2.0 秒。使用异步迭代器调用第一供应商流，并利用 asyncio.wait_for 函数验证第一个 Token 是否在指定的阈值内到达。发生超时后，立即取消第一流以回收套接字和资源，并在向下游客户端传递 0 字节 Token 的无损状态下，立即将流量切换至第二供应商的流。
根据自适应对冲（Adaptive Hedging）基准测试数据，当运营在发生延迟时触发备份请求的传输层时，P99 尾部延迟从 64.3 毫秒降至 17.0 毫秒，呈现出 73.6% 的延迟缩短效果。在第一供应商发生部分故障的情况下，也能完美防御用户体感停机时间。