Kubernetes Topology Manager：NUMA 感知调度，大模型推理的显存性能倍增器

Kubernetes Topology ManagerNUMA 感知调度大模型推理的显存性能倍增器一、跨 NUMA 访问的隐形惩罚两张 A100 的性能落差在配置 GPU 节点的工程师眼中两张 A100 看起来完全相同——同样的显存、同样的算力。但如果它们分别挂在 CPU 的不同 NUMA node 上性能差距可达 20%~30%。根源在 PCIe 拓扑。现代 GPU 通过 PCIe 交换机连接 CPU。跨 NUMA node 访问意味着 GPU 的 DMA 数据需要跨越 CPU 的 UPI/Infinity Fabric 互联——带宽从直连的 64GB/s 骤降到约 20GB/s。对于大模型推理每次 token 生成都涉及 CPU-GPU 间的数据搬运输入 token embedding、KV Cache 管理、采样结果回传。这些跨 NUMA 的传输会累积可观的延迟。某 70B 模型推理服务的压测数据显示同一节点两张 A100NUMA 本地 GPU 吞吐 1,240 tokens/s跨 NUMA GPU 吞吐仅 910 tokens/s——下降 26.6%。这不是 GPU 的问题是数据搬运路径的问题。Kubernetes 默认调度器不考虑 NUMA 拓扑。它只知道节点上有2 张 GPU然后随机分配。如果 Pod 恰好被调度到 NUMA 对齐的 GPU 上性能正常如果不对齐用户只能接受隐性性能损失。这种不确定性正是基础设施需要消除的问题。二、Topology Manager 的 Hint Provider 机制Kubernetes Topology Manager 的核心工作方式是通过 Hint Provider 收集各资源管理器的拓扑约束再综合决策。flowchart TD A[Pod 创建请求] -- B[Topology Manager] B -- C[CPU Manager Hint Provider] B -- D[Device Plugin Hint Provider] B -- E[Memory Manager Hint Provider] C -- F{收集所有 Hint} D -- F E -- F F -- G[Topology Policy 决策] G --|single-numa-node| H[要求所有资源在单一 NUMA node] G --|restricted| I[偏向单一 NUMA node允许回退] G --|best-effort| J[尽可能紧凑不强制] G --|none| K[忽略拓扑约束] H -- L{校验} I -- L J -- M[资源分配生效] K -- M L --|通过| M L --|失败| N[Pod 调度失败]Topology Manager 定义了四种对齐策略single-numa-node最严格。要求 Pod 所有资源CPU、内存、GPU必须位于同一个 NUMA node。如果节点两个 NUMA node 各有一张空闲 GPU但 Pod 申请 2 张 GPU——调度失败。适合追求极致性能的单卡推理任务。restricted偏向对齐但在资源不足时允许跨 NUMA 分配。这是生产环境最常用的策略——兼顾性能与资源利用率。best-effort尽可能将资源收缩在同一 NUMA node但不保证。适合开发测试环境。none关闭拓扑感知。Kubernetes 默认行为。实际配置需要在 kubelet 启动参数中指定--topology-manager-policyrestricted同时启用 CPU Manager 的 static 策略和 Memory Manager。CPU Manager static 策略确保推理 Pod 使用独占 CPU避免与其他进程争抢核缓存。Memory Manager 则为大页内存提供 NUMA 感知分配——大模型的 KV Cache 通常使用 hugepage 分配对齐 NUMA node 意味着更少的 TLB miss。三、Device Plugin 与 NUMA 节点亲和性配置GPU Pod 的 NUMA 亲和性主要通过 Device Plugin 配合 node-feature-discovery 实现。以下是一个完整的生产配置示例。步骤 1标记 GPU 的 NUMA 归属# 通过 NFD 自动标记 GPU 节点的 NUMA 拓扑 # nfd-worker 配置片段 apiVersion: nfd.k8s-sigs.io/v1alpha1 kind: NodeFeatureRule metadata: name: gpu-numa-topology spec: rules: - name: nvidia-gpu-numa labels: # 标记每张 GPU 对应的 NUMA node nvidia.com/gpu-0-numa: 0 nvidia.com/gpu-1-numa: 0 nvidia.com/gpu-2-numa: 1 nvidia.com/gpu-3-numa: 1 matchFeatures: - feature: pci.device matchExpressions: vendor: { op: In, value: [10de] }步骤 2Pod 声明 NUMA 亲和apiVersion: v1 kind: Pod metadata: name: llm-inference-70b spec: # Topology Manager 将在调度时自动填充拓扑约束 containers: - name: vllm image: vllm/vllm-openai:latest resources: requests: nvidia.com/gpu: 2 # 申请 2 张 GPU memory: 128Gi # 显存 主存总量 cpu: 16 # 独占 16 核 limits: nvidia.com/gpu: 2 memory: 128Gi cpu: 16 env: # 显式指定 CUDA_VISIBLE_DEVICES确保设备可见性 - name: CUDA_VISIBLE_DEVICES value: 0,1 # 启用 NUMA 绑定模式 - name: NCCL_SOCKET_IFNAME value: eth0 volumeMounts: # 挂载 NUMA 拓扑信息供应用读取 - name: sys mountPath: /sys readOnly: true volumes: - name: sys hostPath: path: /sys步骤 3验证 NUMA 对齐Pod 运行后可以通过以下命令确认 NUMA 绑定# 进入容器查看设备与 NUMA node 的映射关系 cat /sys/bus/pci/devices/0000:3b:00.0/numa_node # GPU 0 cat /sys/bus/pci/devices/0000:86:00.0/numa_node # GPU 1 # 如果两张 GPU 返回相同的 NUMA node 编号说明对齐成功如果返回不同的 NUMA node 编号如 GPU 0 返回 0、GPU 1 返回 1说明 Topology Manager 未生效需要排查 kubelet 配置。四、调度惩罚与碎片化Topology Manager 的成本调度成功率下降。single-numa-node 策略下假设节点有 8 张 GPU 均匀分布在 2 个 NUMA node 上。任何申请 GPU 数量超过单一 NUMA node 可用数量的 Pod比如 NUMA 0 仅剩 1 张空闲Pod 申请 2 张都会调度失败。这导致资源利用率最高只能达到约 75%存在单 NUMA node 不可用的情况。节点碎片化加剧。Restricted 策略允许跨 NUMA 分配但倾向于对齐。当节点资源进入半满状态时Topology Manager 会优先选择对齐的、资源充裕的 NUMA node。导致的一种典型场景是NUMA 0 满载、NUMA 1 半空——随后到来的小 Pod申请 1 张 GPU全部堆到 NUMA 0 的 waitlist 上NUMA 1 的 GPU 反而闲置。与 GPU 共享技术的冲突。NVIDIA MIG 将物理 GPU 切分为多个 GPU Instance。单张物理卡在 PCIe 总线上只有一个 NUMA node 归属MIG 切分后的 CICompute Instance共享这个归属。这意味着多个租户的 MIG 实例被强行约束在同一个 NUMA node 的 PCIe 带宽上竞争。禁用场景GPU 节点仅配置单 CPU 或单 NUMA node 的环境Topology Manager 无任何价值频繁动态扩缩的短生命周期 Pod调度开销 收益使用 GPU 算力不多但频繁 CPU-GPU 数据搬运的场景不突出时如批处理离线推理。五、总结Topology Manager 解决的是隐性瓶颈——不为肉眼所见却在持续侵蚀 GPU 吞吐。通过 NUMA 感知调度可以让大模型推理服务避免跨 NUMA 数据搬运的 20%~30% 性能惩罚。落地建议在 GPU 节点上启用restricted策略作为起点搭配 NFD 自动标记 GPU NUMA 拓扑。注意监控两个核心指标调度成功率不应低于 95%和各 GPU 的实际吞吐。如果发现节点碎片化严重需要引入 Descheduler 定期重整——这是下一个话题。