最近几个月笔者一直在学习和关注 AI 原生领域，对 Istio 的关注度有所下降，不过昨天看到 Istio 1.28 发布 ，让我对其重新燃起了兴趣。
随着企业大规模部署 LLM 在线推理服务（vLLM、TGI、SGLang、llama.cpp 等），网络层的需求从“传统微服务治理”迈向“高吞吐、强一致性、高可观测的 AI 推理数据平面”。 Istio 1.28 正式发布后，我们首次看到 Service Mesh 开始为大模型推理提供“原生能力支持”。
这一点对 AI Infra 架构师来说意义很大： → Service Mesh 不再只是微服务治理，而是 LLM 推理平台的基础设施之一。
Service Mesh 正在成为 AI 推理基础设施的关键一环。Istio 1.28 的原生 LLM 支持，标志着微服务网络层正式迈入 AI 时代。
文章导读
本文将系统解析 Istio 1.28 对大语言模型（LLM, Large Language Model）推理基础设施的关键影响，涵盖 InferencePool、Ambient Multicluster、nftables、Dual-stack 及可观测性与安全增强等方面。
主要内容包括：
- InferencePool v1：Service Mesh 首次原生拥抱 AI 推理
- Ambient Multicluster：跨 GPU 网络的 L7 治理能力
- nftables 支持：面向高并发推理的现代网络能力
- Dual-stack：IPv6 时代的大模型集群
- 可观测性与安全增强
- 一张图看懂：Istio 在 LLM 推理集群中的位置
InferencePool v1：Service Mesh 正式进入 AI 推理时代
Istio 1.28 最值得关注的更新是 Gateway API Inference Extension → InferencePool v1 正式稳定。对于 LLM 推理基础设施来说，这是一次“质变”而不是“量变”。
推理流量在企业实际部署中面临诸多挑战：
- 多模型版本灰度路由（如 v1/v2）
- 异构 GPU 集群负载均衡（A100、H20、Mi300）
- 多副本推理池生命周期管理
- 推理节点不稳定（OOM、H2 连接断裂）自动摘除
- 远端 GPU 集群（独立 VPC）网络治理困难
这些问题原本需要在业务侧、推理平台、Ingress、Gateway、Operator 等多处分散实现，导致架构复杂且运维成本高。
InferencePool 的引入，让 GPU 推理节点成为服务网格的一级资源。Istio 1.28 带来的能力包括：
- 模型推理端点统一抽象（Endpoint Pool）
- 智能负载均衡（版本、健康、延迟）
- 跨多集群 / 多 GPU 资源池的智能调度
- 自动 failover（掉卡、OOM 自动摘除）
- 与 Gateway API 原生集成（稳定 API）
InferencePool 对 LLM 推理的意义，相当于 DestinationRule 对微服务的意义，只是规模更大、策略更复杂。
下面这张流程图展示了 InferencePool 的技术机制：
这让 Istio 成为 LLM 推理平台的统一入口，无论底层是 vLLM、TGI、SGLang、llama.cpp 还是专有 GPU Inference Engine。对于 AI Infra 团队来说，这是非常关键的演进。
Ambient Multicluster：跨 GPU 网络的 L7 推理治理
LLM 推理集群通常分布在不同的网络环境中，例如：
- GPU 专区（高带宽、独立子网/VPC）
- CPU + RAG + VectorDB 在另一个网络
- 多数据中心的推理池
Istio 1.28 的 Ambient Multicluster 带来了两个关键能力：
- 推理池可以部署在任何网络
- 应用侧不需要 Sidecar 也能享受完整 L7 策略
- GPU 集群可以独立部署，不影响主网
此外，L7 Outlier Detection 也可跨网络生效：
- 某个 GPU Pod 推理延迟升高（显存碎片化、请求排队过深）会自动摘除
- TGI/vLLM 产生错误（OOM、H2Error）会自动 failover
- 异地推理副本延迟过大会自动降权
对于 LLM 在线推理系统来说，这种自愈性至关重要。
Ambient Multicluster 对 AI Infra 的意义在于：
- 高延迟敏感
- 副本状态不稳定（大模型容易 OOM、连接断）
- GPU 资源昂贵，需要细粒度调度
- 多机推理越来越普遍（Mixture-of-Experts、Tensor Parallelism）
Ambient Multicluster 带来了网络层自治能力。
nftables 支持：面向高并发 LLM 推理的现代网络框架
LLM 推理的典型负载包括：
- 长连接（HTTP/2、gRPC）
- 大流量（prompt/data 输出 token）
- 高频短调用（embedding）
iptables 在高并发场景下容易出现：
- 大规模规则性能下降
- 规则难维护
- Conntrack 插件在大模型流量下有瓶颈
Istio 1.28 在 Ambient 模式下正式支持 nftables 原生模式。这带来了更快的规则匹配、更好的并发性能，更适合大模型长连接场景。对于大规模推理集群来说，这是非常明显的性能收益。
Dual-stack Beta：IPv6 时代的大模型推理网络
许多算力中心（如国产 GPU 集群、AI 机房）已开始部署 IPv6 网络。
大模型推理对 IP 地址的需求远超传统微服务：
- GPU 节点地址空间巨大
- 多机训练与推理节点密度高
- 长连接数量巨大（每用户一个 token 流）
Istio 1.28 将 Dual-stack 升级到 Beta，带来：
- IPv4/IPv6 同时支持
- 流量治理逻辑全量适配
- 适用于大型数据中心的 LLM 推理平台
这是一种基础设施级别的进化。
可观测性与安全增强：对 AI 推理平台的价值
B3 + W3C Trace 双协议适用于如下场景：
- LLM → RAG → VectorDB → Cache → User 的完整调用链。
特别适合构建：
- 全链路 token-level 调用追踪
- Prompt-based Latency Profiling
- 模型版本对比分析
BackendTLSPolicy v1 用于：
- 调用外部大模型（Gemini、OpenAI、AWS Bedrock）
- 配置更严格的 TLS
JWT 自定义 claim 支持适合企业内部：
- 基于模型版本 / 模型能力的权限管控
- “谁可以访问哪个模型”的精细访问控制
一张图看懂：Istio 在 LLM 推理基础设施中的位置
下图展示了 Istio 在 LLM 推理基础设施中的整体架构关系：
这体现了一个新的事实：在 AI 时代，Istio 不仅治理微服务，也成为治理 LLM 推理服务的统一数据平面。
总结
Istio 1.28 的发布，标志着 Service Mesh 正在从微服务时代的网络层升级为 AI 推理时代的算力网络层。InferencePool v1 的推出极大增强了 AI 推理基础设施，Ambient Multicluster 简化了 GPU 专用网络管理，nftables 与 dual-stack 等能力则提升了平台的可扩展性。
如果你正在构建企业级 LLM 推理平台、多集群 GPU 调度系统、高可用 RAG 平台或边云协同的模型服务，Istio 1.28 是必须关注的重要版本。