大模型IPv6网络适配部署实战：从协议兼容到流量治理的完整方案

为什么大模型部署必须直面IPv6适配问题

生成式大模型应用的Token流量正呈爆发式增长，单次推理请求的上下文窗口动辄128K Token，流式响应场景下长连接持续时间远超传统Web请求。中央网信办联合四地网信办启动的人工智能大模型IPv6能力提升专项行动，明确要求生成式大模型应用全面支持IPv6。这不是一个可选项，而是所有大模型服务提供方必须面对的基础设施升级任务。

IPv4地址枯竭已是既定事实，国内主要云厂商的新增实例已默认分配IPv6地址。大模型推理服务如果只监听IPv4，将直接损失一部分只能通过IPv6访问的用户终端。更关键的是，CDN回源、API网关、服务网格等中间层正在加速IPv6-only部署，双栈不彻底会导致链路中出现协议转换瓶颈，增加延迟和故障点。

大模型推理服务的IPv6网络架构设计

一个典型的大模型在线推理服务，从用户请求到模型推理返回，链路通常如下：

User Terminal
  → CDN (IPv4/IPv6 双栈)
    → API Gateway (双栈监听)
      → Load Balancer (双栈)
        → Inference Service (Pod 双栈 IP)
          → Model Storage (对象存储)
          → KV Cache (Redis 集群)

IPv6适配的核心要求是：链路中每一层都要支持IPv6，且尽量做到原生IPv6而非协议转换。NAT64/DNS64方案虽然能让IPv6-only客户端访问IPv4-only后端，但引入的地址转换和DNS合成开销对低延迟的推理场景不可接受。

关键配置点：

• CDN层：确认回源地址同时配置AAAA记录，回源协议设置为跟随客户端
• API网关：开启双栈监听，IPv6入口的X-Forwarded-For字段需正确解析IPv6地址
• 负载均衡：Kubernetes Service使用ipFamilies字段指定IPv4+IPv6双栈
• 推理服务Pod：配置双栈IP，确保健康检查端口同时监听两个协议

Kubernetes双栈集群的实操配置

Kubernetes从1.23版本起IPv4/IPv6双栈进入稳定阶段。集群初始化时需要指定双栈CIDR：

# kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
networking:
  podSubnet: "10.244.0.0/16,fd00::/108"
  serviceSubnet: "10.96.0.0/12,fd00:1::/112"
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
  kubeletExtraArgs:
    node-ip: "192.168.1.10,fd00:2::10"

集群就绪后，验证节点双栈IP分配：

kubectl get nodes -o wide
# 确认INTERNAL-IP列同时显示IPv4和IPv6地址

kubectl get pods -n kube-system -o wide
# CoreDNS Pod需同时绑定两个协议的地址

大模型推理服务的Service配置：

apiVersion: v1
kind: Service
metadata:
  name: llm-inference
spec:
  ipFamilies: [IPv4, IPv6]
  ipFamilyPolicy: RequireDualStack
  selector:
    app: llm-inference
  ports:
  - port: 8000
    targetPort: 8000
    name: http-inference

模型服务框架的IPv6监听配置

vLLM作为当前主流的大模型推理框架，默认绑定0.0.0.0只监听IPv4。要同时监听IPv6，需要修改启动参数：

# vLLM双栈监听启动命令
python -m vllm.entrypoints.openai.api_server \
  --model /models/qwen2.5-72b \
  --host :: \
  --port 8000 \
  --tensor-parallel-size 4

# :: 表示同时监听IPv4和IPv6所有接口

Triton Inference Server的配置类似，在grpc端点中指定绑定地址：

# config.pbtxt
name: "qwen2.5-72b"
backend: "vllm"

instance_group [
  {
    count: 1
    kind: KIND_MODEL
  }
]

grpc:
{
  address: "::"
  port: 8001
}

注意：部分模型服务框架在IPv6环境下，健康检查URL使用[::1]回环地址，如果upstream监控只配置了127.0.0.1，会导致健康检查失败。确保readiness/liveness probe同时覆盖两个协议。

IPv6环境下的大模型流量治理

大模型推理的流量特征与传统微服务不同：长连接、高并发、请求体大。IPv6环境下的流量治理需要额外关注几个问题。

连接数限制：IPv6地址空间巨大，客户端IP分散度远高于IPv4+NAT场景。如果按IP做连接限流，阈值需要重新评估。建议在API网关层按Token桶做速率限制而非按IP连接数：

# Envoy限流配置片段
rate_limits:
- actions:
  - remote_ip:
      ipv6_prefix_length: 64
  - request_headers:
      header_name: "x-api-key"
  limit:
    requests_per_unit: 100
    unit: MINUTE

这里对IPv6地址取/64前缀聚合，相当于IPv4下一个C段，避免IPv6海量地址空间导致限流形同虚设。

DNS解析策略：大模型服务域名需同时配置A和AAAA记录。客户端优先使用哪个协议取决于系统DNS解析策略。Linux上glibc的getaddrinfo()默认按RFC6724排序，优先选择IPv6。可以通过/etc/gai.conf调整：

# 优先IPv4（兼容性更好时使用）
precedence ::ffff:0:0/96  40
precedence ::1/128       50
precedence 2002::/16     30

# 或保持IPv6优先（推荐在纯IPv6环境）
# 保持默认配置即可

IPv6-only环境的兼容性排查

在大模型推理链路中，最容易出问题的环节是外部依赖的IPv6支持。以下是需要逐一排查的关键项：

• 模型权重存储：S3兼容对象存储的Endpoint是否支持IPv6访问？MinIO默认不监听IPv6，需要在启动参数中添加–address [::]:9000
• Redis KV缓存：Redis从6.0起支持IPv6绑定，bind配置需要包含::1或::。检查Redis Sentinel/Cluster的公告IP是否包含IPv6地址
• 监控体系：Prometheus的scrape配置中target地址需使用IPv6格式，如http://[fd00::10]:8000/metrics
• 日志收集：Fluentd/Filebeat的输出端点是否支持IPv6？Elasticsearch的publish_host需配置IPv6地址

排查工具推荐：

# 测试IPv6连通性
curl -6 https://api-inference.example.com/v1/models

# 检查DNS AAAA记录
dig AAAA api-inference.example.com

# 查看当前Pod双栈IP
kubectl get pod llm-inference-xxx -o jsonpath='{.status.podIPs}'

IPv6适配的渐进式迁移路径

对于存量大模型服务，建议按以下阶段推进IPv6适配：

阶段一：双栈就绪。所有新增节点分配双栈IP，Service开启双栈支持，但不对外暴露IPv6入口。此阶段验证内部链路的双栈可达性。

阶段二：IPv6灰度。在CDN层为指定区域（如雄安新区等IPv6先行区域）的用户开放IPv6入口，监控请求延迟、错误率、Token吞吐量是否有劣化。

阶段三：全量双栈。DNS全量添加AAAA记录，IPv4和IPv6同时提供服务。按客户端协议类型分别统计SLA，确保IPv6链路质量不低于IPv4。

阶段四：IPv6优先。当IPv6链路的流量占比和稳定性达到阈值后，调整DNS解析策略优先返回AAAA记录，逐步将流量向IPv6倾斜。

每个阶段的回滚方案必须提前准备：AAAA记录可随时删除，CDN回源可强制指定IPv4。关键是在灰度期间积累足够的IPv6链路监控数据，确认问题收敛后再扩大范围。