凌晨两点，某头部内容平台的监控大屏上突然拉出一条红色的峰值曲线。
那是基于 Llama-3.1-8B 模型运行的客服推理服务。随着晚间促销活动的预热，流量并未均匀分布，而是出现了明显的长尾效应。部分用户输入了长达 2000 Token 的复杂指令，瞬间占满了节点的 GPU 显存，导致 P99 延迟从 200ms 飙升至 3s 以上，进而引发 CUDA Out of Memory (OOM) 错误。对于 MLOps 工程师而言，这不仅是性能抖动，更是服务可用性的崩塌。
这一场景并非孤例。据 CNCF 在 2026 年 1 月发布的年度调研显示，尽管 82% 的容器用户已在生产环境中使用 Kubernetes，且在部署生成式 AI 模型的企业中，有 66% 会将部分甚至全部推理负载置于 K8s 之上，但网络层和调度层的“盲区”导致了 40% 的不可用事件。
传统的负载均衡器（如 Nginx Ingress）不懂 Token，更不懂模型的显存水位，它们只能机械地进行轮询或随机分发。而在 AI 推理场景中，一个 500 Token 的请求和一个 2000 Token 的请求对 GPU 的压力截然不同。解决这个问题的钥匙，藏在 Service Mesh 里。
给流量装上“透视眼”：基于 Token 的智能路由
要解决上述崩溃，第一步是为 AI 推理服务构建一张专用的网格。我们选择 Istio 作为底层基础设施，因为它提供了比 Linkerd 更细粒度的策略引擎，能够深入 Sidecar 容器内部，读取 Envoy 代理收集到的业务指标。
重构的第一步，是在客户端侧植入轻量级的 Token 计数器。在发送请求前，利用 tiktoken 等库预估 Token 数量，并将其写入自定义请求头 x-token-count。这一步几乎是零开销的，但它赋予了网格“看见”请求体量的能力。
在 Istio 的 VirtualService 中，我们配置了如下规则，实施“动静分离”策略：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: llama-inference
spec:
hosts:
- llama-service
http:
- match:
- headers:
x-token-count:
regex: "^([1-9][0-9]{0,2}|1000)$" # 预估 Token <= 1000
route:
- destination:
host: llama-service
subset: v2-quantized # 路由至量化版，资源预留较低
weight: 100
- route:
- destination:
host: llama-service
subset: v1-raw # 长请求默认路由至原始高配版
weight: 100
通过这种策略，我们将短请求引导至经过 W4A16 量化加速、容器体积压缩至 500MB 以内的轻量版实例（参考《权重大小量化提速：臃肿依赖让Agent体重居高不下怎么瘦身》中的方案），而将长请求直接分流至拥有更高显存预留的原始版集群。这不仅避免了大请求在小实例上的阻塞，也防止了小请求在大实例上的资源浪费。
金丝雀发布：从“玄学”到“可控”
在云原生环境下，模型迭代往往伴随着巨大的风险。以往更新模型权重，一旦新模型出现幻觉或性能倒退，全量流量瞬间崩塌。现在，借助 Service Mesh 的流量治理，我们可以将金丝雀发布变成一场精确的实验。
假设我们要对 Llama-3.1-8B 进行 A/B 测试，将 5% 的流量指向新版本的 Pod。Istio 的 Sidecar 代理不仅转发流量，还实时回传关键指标：首字延迟（TTFT）、每秒输出 Token 数（TPS）以及错误率。
我们设定了一个严格的熔断阈值：如果新版本服务的 P99 延迟超过基线 20%，或者错误率（包括 OOM 和超时）高于 0.1%，Istio 会自动触发故障注入，将该版本流量切断，并回滚至稳定版本。这个 0.1% 的容错率，是基于我们对 Llama-3.1-8B 在 K8s 集群中长时间观测得出的经验值——低于此值，用户几乎无法感知异常；高于此值，用户体验将急剧下降。
此外，为了防止单个长请求堵塞整个队列，我们在 DestinationRule 中为量化版设置了更保守的连接池配置：最大待处理请求数设为 8，每连接最大请求数设为 1。配合 Envoy 的超时动态调整机制——将超时时间设为 token_count * 50ms，上限 30 秒——长请求不会被硬性全局超时切断，从而大幅降低了慢故障导致的连锁反应。
基础设施的韧性，决定了 AI 落地的深度
回望那个凌晨的崩溃，如果当时我们拥有了这套基于 Istio 的专用网格，结果将会完全不同。流量会被平滑地削峰填谷，大请求会被引导至强壮的节点，小请求会被快速响应，而任何异常的苗头都会在 0.1% 的错误率阈值下被自动拦截。
当然，引入 Service Mesh 也会带来额外的资源开销。Sidecar 代理本身需要消耗 CPU 和内存。但在 2026 年的今天，随着 eBPF 技术的成熟，基于 Cilium 等非侵入式网格方案逐渐成为主流。它们直接在内核层处理流量，几乎零损耗，这对于追求极致性能的 AI 推理场景来说，是更优的选择。
AI 推理的本质，是对算力和数据的精细调度。而 Kubernetes 提供了调度的舞台，Service Mesh 则是舞台上的灯光师和音效师，确保每一束光、每一个音符都能在正确的时间、正确的地点响起。对于 MLOps 工程师而言，掌握这套组合拳，意味着你不再是被流量裹挟的被动者，而是掌控全局的导演。
如果你正在为 AI 代理的账单危机发愁，不妨先检查一下你的流量治理是否足够智能。正如《AI Agent的账单危机：自动续费背后的FinOps治理新解法》中所言，细粒度的权限和实时监控，才是控制成本的关键。而这一切，始于你对 Service Mesh 的深刻理解。