LLM 推理的异构硬件调度工程 2026：从 GPU SKU 拓扑感知到 TPU Pod 切片的统一调度真相

摘要：当 LLM 推理服务从单卡 A100 部署演化到 8 卡 H100、再扩展到 H100+H200+GH200+L40S 混合集群，乃至与 TPU v5e/v5p Pod 切片并存时，"调度"二字从简单的 round-robin 跃升为涉及显存带宽域、NVLink 拓扑亲和、PCIe 通道瓶颈、HBM 容量规划、Pod 切片边界、占位成本与跨域通信拓扑的复合决策问题。本文从工程实证角度系统拆解 LLM 推理异构硬件调度的七个核心子系统——GPU SKU 选型决策、NVLink/NVSwitch 拓扑感知、PCIe 通道瓶颈识别、HBM 容量规划、TPU Pod 切片边界、占位成本优化、跨域统一调度器——并给出每一步可落地的工程实现细节、经验参数、陷阱与生产监控指标。

一、问题的提出：为什么"同构调度"在 2026 年已经破产

过去三年，LLM 推理服务的硬件清单相对单一：要么是 8×A100-80GB 的同构节点，要么是 8×H100-80GB 的同构节点。调度器只需关心 batch size 与显存占用即可，单卡 80GB HBM 的容量边界让"放不下就拆分"成为合理默认。但进入 2026 年后，三股力量同时让"同构调度"破产：

第一，GPU SKU 碎片化。同一集群内并存 H100-80GB（5.2TB/s 显存带宽）、H200-141GB（4.8TB/s 带宽但容量大 76%）、GH200-480GB（Grace CPU+Hopper GPU 统一地址空间）、L40S-48GB（推理专用但带宽仅 0.86TB/s）、甚至 A100-40GB 与 A100-80GB 的代际混合。一台 vLLM 0.7.x 默认假设 "H100 80GB"，当遇到 L40S 时 batch size 会被严重错估。

第二，TPU Pod 切片进入推理主流。Anthropic、Gemini、xAI 等头部厂商 2025 年起已大量采用 TPU v5e/v5p 推理（成本约为 H100 的 30-40%），TPU 的 MXU 脉动阵列、Pod 切片拓扑（2x2x1 / 4x4x1 / 8x8x1）、HBM 通道布局与 GPU 完全不同；调度器需要同时处理两套硬件抽象。

第三，能耗与占位成本压力。H100 满载功耗 700W、GH200 1000W、L40S 350W——按 0.08 美元/度电、24/7 满载计算，一台 8 卡 H100 节点年电费约 $4,900。占位（idling 但被预留）的卡数每增加 10$5 万。如何让"已被预留的卡"尽可能被填充是调度器的新 KPI。

本文的核心论断是：异构硬件调度不是简单的"挑便宜的卡分配"问题，而是一道同时满足显存容量、显存带宽、NVLink 拓扑亲和、PCIe 通道带宽、TPU Pod 切片边界、能耗预算、占位填充率七个约束的多目标优化。任何只优化单一维度（如成本）的调度器，都会在生产中遭遇预想不到的尾延迟尖峰。

二、形式化：异构调度问题的七元约束

设集群有 $N$ 个物理节点，第 $i$ 个节点的硬件画像为元组：

$H_i = (S_i^{sku}, S_i^{mem}, S_i^{bw}, S_i^{nvlink}, S_i^{pcie}, S_i^{tpu\_pod}, S_i^{power})$

其中 $S_i^{sku} \in \{H100-80G, H200-141G, GH200-480G, L40S-48G, A100-40G, A100-80G, TPUv5e, TPUv5p, ...\}$，$S_i^{mem}$ 为 HBM/显存容量（GB），$S_i^{bw}$ 为显存带宽（TB/s），$S_i^{nvlink}$ 为 NVLink 拓扑邻接矩阵（节点内 8 卡通常构成 4+4 NVSwitch 全互连或 8 卡全互连两种形态），$S_i^{pcie}$ 为 PCIe 通道数与代际（Gen4 x16 = 32GB/s、Gen5 x16 = 64GB/s），$S_i^{tpu\_pod}$ 为 TPU Pod 切片坐标（如 (4,4,1)），$S_i^{power}$ 为单卡 TDP。

每个推理请求 $r$ 的需求画像为：

$R_r = (n_{tokens}^{in}, n_{tokens}^{out}, s_{model}, c_{slo}, c_{preemptible})$

其中 $n_{tokens}^{in/out}$ 是输入/输出 token 数，$s_{model}$ 是模型规格（如 llama3-70B-fp16 占 140GB 权重），$c_{slo}$ 是 P99 延迟约束（如 200ms TTFT），$c_{preemptible}$ 表示是否可抢占。

调度的目标是找一个分配函数 $\phi: R \to H \times \text{slot}$，使得：

1. 显存容量约束：$\sum_{r \in \text{slot}} (W_{s_{model}} + KV_{r}^{peak}) \le S_i^{mem}$，其中 $KV_{r}^{peak}$ 是请求生命周期内的 KV cache 峰值。
2. 带宽约束：每个 slot 的聚合 token/s 不得超过 $S_i^{bw} \times \eta$，其中 $\eta$ 是实际可达到的带宽利用率（一般 0.6-0.85）。
3. 拓扑亲和约束：当 $s_{model}$ 需要 tensor parallel (TP) 时，TP 组必须落在同一 NVLink 域内（同一节点的 8 卡），否则走 PCIe 或 IB 会损失 60%+ 带宽。
4. PCIe 带宽约束：CPU↔GPU 的权重加载、采样器回传必须走 PCIe，每秒不超过 $S_i^{pcie}$ 的 70%（余量给 OS、监控、心跳）。
5. TPU 切片完整性约束：TPU 模型必须落在合法的 Pod 切片内（如 llama2-70B 至少需 4x4x1 = 16 核），不能跨非连续切片。
6. 能耗预算约束：节点总功率不超过机柜 PDU 限额（典型 12-24kW），且 PUE 不超过数据中心承诺值。
7. 占位填充约束：已被预留的卡（reserved）填充率 ≥ 85%（KPI）。

这个七元约束没有解析最优解——它是一个 NP-hard 装箱问题的实例加上连续时间维度的扩展。工程上的做法是把它拆成三个阶段：预过滤（feasibility pruning）→ 评分（multi-objective scoring）→ 增量再平衡（online rebalancing）。

三、GPU SKU 选型决策：不是"选最快的卡"

第一个工程陷阱是"选最快的卡"。H200 显存容量比 H100 大 76%，但带宽反而低 8%（4.8 vs 5.2 TB/s）；GH200 容量 480GB 是 H100 的 6 倍但带宽不变；L40S 容量 48GB 仅是 H100 的 60%、带宽只有 16%。选卡不是"选最快"，而是"选最匹配请求画像"。

3.1 请求画像到卡型的映射规则

经验规则（基于 vLLM 0.7.x、TGI 2.3、SGLang 0.4 三套引擎在 2025 下半年的实测）：

关键洞察：长输出请求（output > input）受显存带宽瓶颈支配，需要高带宽卡（H100、H200）；长输入请求（input >> output）受 KV cache 容量瓶颈支配，需要大显存卡（GH200、H200）；短请求（< 1k token）受占位成本支配，需要便宜卡（L40S、A100-40G）。

3.2 SKU 画像采样器

调度器需要每个节点的实时 SKU 画像。一种轻量做法是节点启动时向调度器注册：

@dataclass
class NodeProfile:
    hostname: str
    sku: str                    # "H100-80GB" / "GH200-480GB" / ...
    mem_gb: int
    mem_bw_tbps: float
    nvlink_topology: str        # "fully-connected-8" / "4+4-nvswitch" / "none"
    pcie_gen: int               # 4 or 5
    pcie_lanes: int             # 16 typical
    numa_topology: List[int]    # NUMA 节点列表
    tpu_pod_slice: Optional[Tuple[int,int,int]]  # None 表示不是 TPU
    power_w: int                # 单卡 TDP
    reserved: bool              # 是否被某租户预留
    current_fill: float         # 0.0-1.0 当前填充率

调度器在 nvidia-smi -q -d MEMORY,UTILIZATION,POWER,PCI 的基础上，再读 /sys/class/drm/card*/device/numa_node、nvidia-smi topo -m、ibstat（如果是 IB 网卡）等，构造完整画像。画像刷新频率 30 秒一次即可——硬件拓扑变化以小时计，无需秒级刷新。

四、NVLink 拓扑感知：TP 组不能跨域

Tensor Parallel (TP) 需要 GPU 之间高速互传激活与梯度（推理时主要是激活）。NVLink 提供 600-900 GB/s 的卡间带宽（H100 NVLink 4.0 单向 450GB/s，双向 900GB/s），而 PCIe Gen5 x16 仅 64GB/s——跨 NVLink 域走 PCIe 或 IB 的 TP 组性能会下降 60-80%。

4.1 NVLink 拓扑分类

实际生产中常见三种 NVLink 拓扑：

• fully-connected-8：8 卡全互连（DGX H100 基线），任意两卡走 NVSwitch 单跳；
• 4+4-nvswitch：8 卡分两组，组内全互连，组间通过 PCIe 或 IB（HGX H100 基线）；
• none：纯 PCIe 拓扑（如 L40S、A100 PCIe 版），TP 性能严重受限。

调度器收到一个 tp=8 的请求时，必须先查 nvidia-smi topo -m 确认目标节点有 fully-connected-8 拓扑，否则拒绝在该节点 TP=8 部署（或自动降级为 TP=4 + PP=2）。

4.2 拓扑查询的实现

# 查询节点 8 卡的拓扑
nvidia-smi topo -m
# 输出示例（DGX H100）:
#         GPU0  GPU1  GPU2  GPU3  GPU4  GPU5  GPU6  GPU7  CPU Affinity
# GPU0     X    NV12  NV12  NV12  NV12  NV12  NV12  NV12  0-23,48-71
# GPU1    NV12   X    NV12  NV12  NV12  NV12  NV12  NV12  0-23,48-71
# ...
# GPU4    NV12  NV12  NV12  NV12   X    NV12  NV12  NV12  24-47,72-95
# GPU5    NV12  NV12  NV12  NV12  NV12   X    NV12  NV12  24-47,72-95
# GPU6    NV12  NV12  NV12  NV12  NV12  NV12   X    NV12  24-47,72-71
# GPU7    NV12  NV12  NV12  NV12  NV12  NV12  NV12   X    24-47,72-95
#
# Legend: NV12 = NVLink 12 links (Hopper 全互连)
#         SYS = PCIe (NUMA 跨域, 极慢)
#         PHB = PCIe Host Bridge

调度器缓存这张矩阵到 Redis（key=topo:{hostname}，TTL=1h），分配 TP 请求时用 BFS 找出最大的连通子图：8 卡全互连时最大连通子图大小 = 8，4+4 拓扑时 = 4。

4.3 拓扑感知的调度伪代码

def assign_tp_group(req: Request, candidates: List[Node]) -> Optional[Node]:
    required_tp = req.tp_size  # 1, 2, 4, 8 ...
    for node in candidates:
        # 找到最大的 NVLink 连通子图
        max_island = node.nvlink_max_island  # cached
        if max_island >= required_tp:
            # 进一步检查是否独占（避免与已有 TP 组抢卡）
            free_islands = node.free_nvlink_islands(required_tp)
            if free_islands:
                return node, free_islands[0]
    return None  # 无可用节点, 走排队或降级

五、PCIe 通道瓶颈识别

NVLink 处理的是"卡间"通信，但还有三类通信走 PCIe：CPU↔GPU 的权重加载、CPU↔GPU 的样本传输（用于 CPU sampler）、GPU↔NIC 的 RDMA 卸载。当 PCIe 通道被这三类流量挤满时，GPU 推理的"启动延迟"会从 50ms 涨到 200ms+。

5.1 PCIe 带宽分配经验值

单卡 PCIe Gen5 x16 = 64 GB/s 双工。经验分配：

• 权重加载（冷启动）：< 5 GB/s 持续 < 10s，可容忍独占
• CPU sampler（beam search 等需要 CPU 端采样）：< 2 GB/s 持续
• GPU↔NIC RDMA（如 NCCL 跨节点）：< 10 GB/s（直连 RDMA 时不走 PCIe 太多）
• OS/监控/心跳：< 0.5 GB/s
• 可用余量：≥ 80%

当监控发现 pcie_bw_util > 70% 持续 1 分钟以上，调度器应自动减少该节点上的"冷启动任务"（如新模型加载、batch 切换）。

5.2 PCIe 拓扑对 NUMA 的影响

CPU↔GPU 的 PCIe 通道绑定到特定 NUMA 节点。DGX H100 的拓扑是：CPU0-23 绑定 GPU0-3，CPU24-47 绑定 GPU4-7。调度器应保证：CPU sampler 进程跑在与目标 GPU 同 NUMA 的核上。

实现上用 numactl --cpunodebind=0 --membind=0 python sampler.py 或 Python 端 os.sched_setaffinity(0, {0,1,2,...,23})。

5.3 GPU Direct RDMA 与 PCIe 的带宽接力

跨节点通信（如 TP=8 跨两台 4 卡机）走 IB 或 RoCE 网卡时，现代实现（GPU Direct RDMA）让 NIC 直接 DMA 读写 GPU 显存，完全绕过 host memory——这避免了 PCIe 通道成为瓶颈。但有三类操作必须走 PCIe：(1) 模型权重从 CPU 内存加载到 GPU（冷启动必经）；(2) 监控数据从 GPU 上传到 Prometheus exporter（每小时一次，可忽略）；(3) token 采样结果回传到 host（beam search 等 CPU 端 sampler，每 token 一次）。第三类是高并发下的隐性瓶颈：当 batch=64、TTFT 预算 200ms 时，每 token 回传 64 个 token id（int32 各 4 字节）= 256B，64 路并发 × 4 字节 = 256B/次，频率 ~ 50ms/次 = 5KB/s——看起来很小，但若走 CPU sampler 而非 GPU sampler，额外开销在 host↔GPU 同步原语（cudaMemcpyAsync 同步、cudaStreamSynchronize 等待）上，每个 request 累计 5-15ms，这是 200ms 预算的 2.5-7.5%——量级已经能影响 P99。经验：beam search 或 top-p > 0.9 时，优先用 GPU sampler（vLLM 0.6+ 默认即 GPU sampler）；只有必须用 CPU sampler（如定制 logit processor）时才接受这部分开销。

六、HBM 容量规划

HBM 容量是 LLM 推理的硬约束：模型权重 + KV cache + 激活 + CUDA 工作区都必须放进去。

6.1 权重占用公式

$W_{model} = n_{params} \times s_{dtype}$

其中 $s_{dtype}$ 是每参数字节数：FP32=4, FP16/BF16=2, INT8=1, INT4=0.5, FP8=1（E4M3/E5M2）。

常见模型的权重占用（FP16）：

• llama3-8B：16 GB
• llama3-70B：140 GB
• llama3-405B：810 GB（需 TP=8 + 量化才能推理）
• mixtral-8x7B：90 GB（MoE）

FP8 量化权重（如 FP8 E4M3）让 70B 模型从 140GB 降到 70GB，刚好塞进 H100-80GB，这是 2025 年 H100 上跑 70B 模型的主流形态。

6.2 KV cache 容量公式

KV cache 大小与 batch size、序列长度、模型层数、头数、维度强相关：

$KV_{total} = 2 \times n_{layers} \times n_{kv\_heads} \times d_{head} \times seq\_len \times batch \times s_{dtype}$

举例：llama3-70B（80 层、8 KV 头、128 头维），batch=8，seq_len=4096，FP16：

$KV = 2 \times 80 \times 8 \times 128 \times 4096 \times 8 \times 2 = 10.7 \text{ GB}$

这个数字会随 seq_len 线性增长——128k 上下文 + batch=8 时，KV cache 占用会冲到 335GB，必须用 GH200 或 PagedAttention 切分。

6.3 容量监控与触发再平衡

调度器每 30 秒拉一次 nvidia-smi --query-gpu=memory.used,memory.free --format=csv，构造 mem_util 指标。当 mem_util > 0.85 持续 1 分钟，触发"复制到空闲卡"的再平衡操作；当 mem_util < 0.30 持续 5 分钟（典型低峰期），触发"合并到少数卡"以释放节点进入休眠。

6.4 PagedAttention 与 KV cache 分页的工程真相

vLLM 在 0.4+ 引入的 PagedAttention 把 KV cache 切成固定大小的"页"（典型 16 token / 页），类比操作系统的虚拟内存分页。这一设计让显存利用率从连续分配的 ~60% 提升到 ~92%，但带来三个工程代价：(a) block table 的元数据开销——每个请求额外占用约 0.5MB 元数据（block table、引用计数），10k 并发时累计 5GB；(b) 拷贝与换出的粒度变为页级而非请求级，单次换出 16 token 的延迟 ~50μs，但换出 1k token 需要 64 次页 IO，累计 3.2ms——必须 batch 起来；(c) prefix sharing 的实现变得复杂，公共前缀的 block 必须支持"多请求引用同一 block"，引用计数是必须的。生产中推荐配置：block_size=16（默认值已平衡）、gpu_memory_utilization=0.92（不要追求 0.95+，留给 CUDA 工作区）、enable_prefix_caching=True（命中率 < 30% 时反而是负优化，需根据 A/B 测试开关）。Prefix caching 的命中率与命中质量分离——很多团队只看"命中率"但忽略了"命中的前缀是不是真有共享价值"。一个反例是聊天系统，用户 A 的第 1 条消息被用户 B 的第 1 条消息完全复用的概率极低（前缀太短），开启 prefix caching 反而引入元数据开销而无收益。正确做法是按"前缀长度 ≥ 256 token 才计入命中率"过滤，避免短前缀的"假命中"骗了监控。

6.5 长上下文（128k+）的容量工程

当请求 seq_len 达到 128k 时，KV cache 单请求占用 335GB（前述计算），单卡 H100-80GB 装不下。工程上的三种应对：(1) TP=8 跨 8 卡，每卡分摊 42GB，可行但 PCIe 跨域开销大；(2) Sequence Parallel (SP) 把序列维度切分到 4 卡，KV 切到 4 张卡，每卡 84GB，H100 刚好装下——SGLang 与 vLLM 0.7+ 都支持；(3) 滑动窗口 attention（如 Mistral）让 KV 不需要全量存储。经验阈值：seq_len ≤ 32k 用单卡 TP=1，32k-128k 用 SP=4，> 128k 必须考虑模型本身的滑动窗口或 long-context 训练。Llama-3-405B 在 128k 上下文上即使 SP=8 + TP=8 = 64 卡 H100 也只能勉强装下 KV（每卡 32GB / 80GB），所以长上下文 405B 推理至今仍是工程难题。

七、TPU Pod 切片边界

TPU 的硬件抽象与 GPU 完全不同：GPU 是单卡独立 + 卡间 NVLink，TPU 是芯片互联成 Pod 切片（2D 网格或 3D 网格），模型必须完整放在一个切片内。

7.1 TPU 切片的常见形态

• TPU v5e：1 chip = 1 core；常见切片 1x1, 2x2, 4x4, 8x8, 16x16；
• TPU v5p：1 chip = 2 cores（4 MXU）；常见切片 2x2x1, 4x4x1, 8x8x1, 16x16x1；
• 切片坐标：(x, y, z) 三维，每维 1-N 核。

7.2 调度约束

TPU 切片的关键约束：模型大小必须能被切片大小整除。llama-70B 在 TPU v5e 上需约 16 核（4x4 切片）；在 TPU v5p 上需 8 核（2x2x1）。调度器收到 TPU 请求时，先查 tpu_topology 找到合法的最小切片，再分配。

def assign_tpu(req: Request, tpu_pods: List[TPUPod]) -> Optional[TPUSlice]:
    min_slices = compute_min_slices(req.model_size, tpu_pods[0].chip_type)
    for pod in tpu_pods:
        free_slices = pod.find_free_slices(min_slices)
        if free_slices:
            return free_slices[0]
    return None

7.3 GPU/TPU 统一调度接口

工程上的优雅做法是抽象出统一的"计算单元"接口：

class ComputeUnit(Protocol):
    def capacity(self) -> int: ...           # 容量评分
    def bandwidth(self) -> float: ...         # 带宽评分
    def topology_score(self, req: Request) -> float: ...  # 拓扑适配分
    def power(self) -> int: ...              # 功耗
    def cost_per_hour(self) -> Decimal: ...  # 时成本

GPU 和 TPU 都实现这个 Protocol，调度器对两者一视同仁。这是 2026 年异构推理调度的工业共识。

7.4 XLA 与 GPU kernel 的语义鸿沟

TPU 用 XLA 编译器，GPU 用 Triton/CUDA。同一份 PyTorch/JAX 代码在两者上跑出不同的内存布局与算子融合策略，导致 (a) 同一模型的权重在 TPU 上序列化后不能在 GPU 上直接加载——必须经过一次 host-side 的 layout 转换（XLA HLO → MHLO → ONNX → TensorRT，典型 30-60s 一次性的初始化时间）；(b) 同一请求的 P99 延迟在两者上差异可达 30%（TPU 在 batch 大、序列短时占优，GPU 在 batch 小、序列长时占优）；(c) KV cache 的 block 格式不同（TPU 用 tiled layout，GPU 用 row-major），无法直接共享。工程上的折中：建立模型仓库（model registry），每个模型预编译两个 artifact（model.tpu.xla + model.gpu.triton），调度器按目标硬件分发。这一双 artifact 模式是 Anthropic 2025 公开的工程经验，是 GPU/TPU 异构部署的隐性基础设施成本——首次接入 TPU 时通常需要 1-2 周的工程投入，之后就稳了。"快速试一下 TPU"是个伪命题——单是算子兼容性验证就需要完整测试套件跑过一遍。

八、占位成本优化：让"被预留"的卡被填满

GPU/TPU 集群的一个普遍痛点是：客户 A 预留了 100 张 H100 跑推理，但峰值只用 60 张，剩下 40 张闲在那里、但其他客户不能用。这 40 张卡的机会成本就是占位浪费。

8.1 三种占位模式

• 硬预留（hard reservation）：客户独占，其他客户完全不能跑（高浪费但确定性强）；
• 弹性预留（soft reservation）：客户优先用 100 张，闲时其他客户可填，但闲时客户请求需 < 100ms 迁回（GPU 显存迁移）；
• 竞价预留（spot reservation）：其他客户可填，但需在 5-30s 内让出（强制 eviction）。

8.2 占位填充的工程实现

调度器维护一个 reservation_fill_rate 指标：

class Reservation:
    customer: str
    total_reserved: int          # 100
    current_active: int          # 60
    soft_pool: List[int]         # [40, 41, ..., 99] 可被填的卡
    fill_policy: str             # "soft" / "hard" / "spot"
    
    @property
    def fill_rate(self) -> float:
        return 1.0 - (len(self.soft_pool) - self.soft_filled) / self.total_reserved

当 fill_rate < 0.85 时，调度器把 soft_pool 中的卡标为"可竞价"，接受其他客户的请求（带可抢占标记）。一旦预留客户的高峰回来，按 LIFO 抢占。

8.3 占位成本的可观测性

每张卡的 cost_per_hour_idle = 时租 × 1（不省电，空载与满载功耗差仅 20%）。100 张 H100 闲 1 小时 = $32（按$0.32/h 算）。一年下来，10% 浪费率 = $28k。这就是为什么占位填充率进调度器 KPI。

九、跨域统一调度器：从单集群到多集群

当一个企业有多个 GPU 集群（不同区域、不同代际、不同供应商）时，调度器需要"跨域"。跨域调度的核心挑战是延迟：同区域内 0.5ms RTT，跨区域（如 us-west-1 到 us-east-1）80ms RTT，跨云（AWS 到 GCP）100ms+ RTT。

9.1 跨域策略

• 亲和性优先：请求 80% 概率路由到同区域/同集群；
• 成本感知次选：同区域满载时，路由到次区域（延迟+20ms 但成本-30%）；
• 容灾兜底：次区域也满载时，路由到任意可用区，TTFT 预算放宽到 P99=500ms。

9.2 跨域请求的 token 续传

跨域调度最大的坑是"请求已经在 GPU-A 上生成到第 50 个 token，现在要迁到 GPU-B"。续传不是免费的——要么冻结 GPU-A 的 KV cache，序列化传到 GPU-B（200-500ms 延迟）；要么丢弃 GPU-B 的部分输出，从头生成（成本更高）。

工程上的做法是永远不跨域续传——只在新请求边界（消息分隔、工具调用返回）做跨域切换。单条消息生命周期内必须留在一个节点。

9.3 跨域成本感知路由的数学表达

设集群 A 在 us-west-1，集群 B 在 us-east-1，集群 C 在 eu-west-1。客户请求从 us-west-2 进来，调度器需决策路由到 A、B 还是 C。完整的成本函数应同时考虑：

$\text{Cost}_{route} = \alpha \cdot \text{RTT}_{route} + \beta \cdot \text{PricePerToken}_{route} + \gamma \cdot \text{PowerPUE}_{route} - \delta \cdot \text{Affinity}_{route}$

其中 $\alpha, \beta, \gamma, \delta$ 是可调权重（典型配置：$\alpha=0.4, \beta=0.3, \gamma=0.1, \delta=0.2$）。亲和性权重 $\delta$ 的物理含义：如果用户近 7 天 95% 请求都打到 A，则 Affinity(A)=1.0，Affinity(B)=0.1——这避免了"今天便宜路由到 C，明天便宜路由到 B，后天又路由回 A"的抖动。经验值：P99 路由切换间隔 < 5 分钟会引发用户感知到的延迟波动，应设置最短切换间隔 30 分钟的阻尼（damping）。SRE 排查"为什么延迟抖了"时，第一查的就是路由切换频率——根因通常是权重配置里 $\delta$ 设小了或没有阻尼。这条经验是 2025 年多个生产事故的共同根因，值得记入 runbook。

十、生产监控与告警指标

异构调度器的可观测性必须覆盖七个维度：

1. per-SKU 容量利用率：h100_mem_util, h200_mem_util, l40s_mem_util（分流监控）；
2. NVLink 跨域流量：nvlink_bw_util_grouped_by_island（识别 4+4 拓扑被穿透）；
3. PCIe 通道压力：pcie_bw_util_per_node（识别冷启动风暴）；
4. HBM 余量：hbm_free_gb_per_gpu（触发再平衡的输入）；
5. TPU 切片完整度：tpu_slice_fragmentation_ratio（碎片率，理想 < 0.1）；
6. 占位填充率：reservation_fill_rate（每客户、每集群、整体三个维度）；
7. 跨域延迟：cross_region_p99_rtt（识别跨域调度异常）。

告警阈值：

• pcie_bw_util > 0.7 持续 1 分钟 → 警告（冷启动可能拥塞）；
• nvlink_cross_island_traffic > 100 MB/s → 严重（TP 跨域部署，违反拓扑约束）；
• tpu_slice_fragmentation > 0.3 → 警告（碎片化，需重新分片）；
• reservation_fill_rate < 0.7 → 警告（占位浪费超 30%）。

十一、给 SRE 的可观测性清单

如果你是新接手这个系统的 SRE，下面七项是 Day-1 必须配置的：

1. prometheus + grafana 采集每张卡的 nvidia-smi 全字段（30s 一次）；
2. nvidia-smi topo -m 在节点启动时采集一次，存到 topo:{hostname} Redis 键；
3. DCGM exporter 暴露 DCGM_FI_DEV_GPU_UTIL, DCGM_FI_DEV_FB_USED, DCGM_FI_DEV_FB_FREE, DCGM_FI_DEV_POWER_USAGE；
4. NVLink 流量监控 用 nvlink_errors + nvlink_bandwidth（部分驱动支持）；
5. PCIe 流量 用 lspci -vvv + perf stat -e uncore_imc（Intel）/ perf stat -e amd_l3（AMD）；
6. TPU 监控 用 gcloud compute tpus describe + Cloud Monitoring exporter；
7. 占位填充率 dashboard 单独一个 tab，按 customer、cluster、整体三层钻取。

十二、未来三年的趋势

第一，FP4/FP6 量化进入主流。2025 年底 Blackwell B200 已原生支持 FP4（E2M1），单 GB 显存可装 2 倍参数，让 70B 模型在单卡 40GB HBM 上就能跑——这会彻底改写 SKU 选型规则。

第二，TPU/GPU 统一调度抽象成熟。Anthropic 2026 年公开的调度器论文显示，他们用类似上文 ComputeUnit Protocol 的抽象统一管理 TPU v5p 和 H100，调度延迟 < 50μs，跨硬件 P99 差异 < 8%。

第三，能效作为一阶 KPI。欧盟 2027 年起对数据中心 PUE 强制要求 < 1.3，意味着"低功耗 SKU 优先"将从工程偏好上升为合规约束。L40S（350W）、TPU v5e（200W/核）这类"慢但省"的硬件会被重新评估。综合来看，异构调度的终极形态是"硬件无关的算力抽象层"——上层业务只看到"我需要 1000 token/s 的吞吐 + P99 200ms 延迟"，下层调度器自行决定哪几张卡、哪种拓扑、哪套编译器来满足这个 SLO；这种抽象让硬件迭代（如 Blackwell B200 上市）不再触发业务层改造，只需在调度器里加一条新的 ComputeUnit 实现即可。这一愿景在 2026 年仍未完全实现，但方向已经清晰——Anthropic、xAI、Google DeepMind 都在朝这个方向收敛。

参考文献

1. Korthikanti, V. A., et al. Reducing activation recomputation in large transformer models. Proceedings of MLSys 2023.
2. Pope, R., et al. Efficiently scaling transformer inference. Proceedings of MLSys 2023.
3. NVIDIA. H100 Tensor Core GPU Architecture Whitepaper. 2022.
4. NVIDIA. H200 Tensor Core GPU Architecture Brief. 2024.
5. NVIDIA. GH200 Grace Hopper Superchip Architecture Whitepaper. 2023.
6. NVIDIA. L40S GPU Product Brief. 2023.
7. Jouppi, N., et al. TPU v4: An optically reconfigurable supercomputer for machine learning. Proceedings of ISCA 2023.
8. Google Cloud. TPU v5e and v5p system architecture. 2024.
9. Kwon, W., et al. Efficient memory management for large language model serving with PagedAttention. Proceedings of SOSP 2023.
10. Zheng, L., et al. SGLang: Efficient execution of structured language model programs. 2024.
11. vLLM Team. vLLM: A high-throughput and memory-efficient inference engine for LLMs. 2023.
12. Anthropic. Building effective agents. 2024.
13. Patel, P., et al. Splitwise: Efficient generative LLM inference using phase splitting. Proceedings of ISCA 2024.
14. Yu, C., et al. Tiered memory management for LLM serving. 2025.
15. Anthropic. Constructing a CPU sampler for LLM inference. 2024.
16. Google Cloud. Cloud TPU slicing best practices. 2024.
17. NVIDIA. Multi-Instance GPU (MIG) user guide. 2024.
18. Mosaix.AI. Heterogeneous GPU scheduling for LLM inference. 2025.
19. Liu, Y., et al. Cross-cluster LLM inference with affinity-aware routing. Proceedings of EuroSys 2025.
20. OpenTelemetry. Semantic conventions for generative AI. 2025.
21. Wei, J., et al. Simple synthetic data reduces sycophancy in large language models. 2024.（参考对照，未直接引用）
22. Anthropic. The economics of LLM inference at scale. 2025.
23. Sharma, P., et al. TPU vs GPU inference: A cost-performance analysis. 2024.
24. Dean, J., et al. The evolution of Google's TPU pod architecture. Communications of the ACM, 2024.

一句话摘要：异构 LLM 推理调度的本质是"七元约束 + 三阶段决策"——预过滤可行性、评分多目标、增量再平衡；任何只优化单一维度的调度器都将在生产中遭遇 P99 尖峰。