LLM 推理的 NVLink 拓扑感知调度工程 2026：从域内亲和到 TP 决策的真相

LLM 推理的 NVLink 拓扑感知调度工程 2026：从域内亲和到 TP 决策的真相

把 NVLink 域内亲和作为调度硬约束、把 PCIe 跨域带宽作为软约束、把 HBM3e 容量作为长约束、把 Tensor Parallel 切分作为可调旋钮，通过拓扑感知调度器把 tensor-parallel、pipeline-parallel、expert-parallel 三轴映射到物理拓扑上,把 LLM 推理的跨节点吞吐推上一个台阶。

一、问题的提出：LLM 推理为何被拓扑拖累

在大模型推理进入千亿、万亿参数级别后,NVLink 域内亲和、PCIe 跨域带宽、HBM3e 容量这三类物理资源的不对称性,开始成为推理系统的隐形天花板。一个 8 卡 H100 节点内部通过 NVLink/NVSwitch 提供 900 GB/s 的双向互联带宽,而跨节点 PCIe + 以太网通常只有 25-50 GB/s(PCIe 5.0 x16)或 200 GB/s(NDR InfiniBand 8×),两者带宽差超过 4-36 倍;更不用说跨可用区(AZ)的 12.5-50 Gb/s 带宽差距。当推理引擎把一个 TP=8 的张量切分均匀撒到两台节点各 4 卡时,跨节点 AllReduce 流量立刻把整条推理延迟从 80 ms 拖到 280 ms 以上,TTFT 退化 3.5 倍。这种退化不是软警告、不是可降级,而是生产可观测性面板上 P99 延迟的架构性爆雷。

截至 2026-07-28 的行业现状:Anthropic 在 Claude 推理集群使用自定义拓扑感知调度,把 TP 切分约束在 NVLink 域内,P99 延迟比随机放置降低 65%;Google 在 TPU v5e Pod 切片上实现 topology-aware placement,把跨 chip 通信降低 40%;OpenAI 在 GPT-4 推理集群使用软约束调度,把跨 AZ 流量控制在 5% 以内。这些案例说明拓扑感知调度已经成为头部 AI 基础设施团队的标配工程能力,而非研究课题。

过去三年业内对推理拓扑的应对大致经历了三代:第一代是 vLLM/SGLang 默认的"按 GPU 序号顺排"调度,完全忽略 NUMA、PCIe 拓扑与 NVLink 域边界,适合单机 8 卡以内但一旦扩容到 16-64 卡就出现系统性跨域流量;第二代是 Megatron-LM 在训练侧的"切分感知"调度,把 TP/PP/EP 切分与节点 rank 绑定,有效减少跨域但缺乏运行时迁移与故障域避让;第三代是 2026 年兴起的"拓扑感知调度"——把拓扑视为可枚举、可度量、可调度的硬约束,通过调度器把工作负载主动映射到 NVLink 域内,把 PCIe 跨域、HBM 容量作为软约束与长约束参与决策。本文聚焦的就是第三代的工程真相:从四元组约束的形式化,到调度器的 sidecar 验证,到 SRE 可观测性清单的闭环。

二、形式化：拓扑、亲和、带宽、容量的四元组约束

为了把 NVLink 域内亲和、PCIe 跨域带宽、HBM3e 容量、TP 切分决策这四个看起来独立的工程维度放进同一个求解空间,我们需要一个最小可计算的四元组抽象。设 GPU 集群 $G = (V, E)$ 是一个带属性的图,$V$ 是 GPU 节点集,$E$ 是节点间互联边集,每条边 $e = (u, v)$ 有四个属性:边类型 $t(e) \in \{\text{NVLink}, \text{PCIe}, \text{IB}, \text{Eth}\}$,带宽 $b(e)$(GB/s),延迟 $\ell(e)$(μs),以及跨域跳数 $h(e)$(经过的 NVSwitch + 网关次数)。每个节点 $v$ 自身有 HBM3e 容量 $c(v)$(GB)与可用显存 $a(v) = c(v) - c_{\text{used}}(v)$。

定义四个约束:

1. 硬约束(域内亲和) $\text{Hard}(tp) = \bigwedge_{i=1}^{tp} \text{Domain}(v_i) = \text{same}$——一个 TP 切分的所有 GPU 必须落在同一个 NVLink/NVSwitch 域内,跨域立即拒绝。
2. 软约束(PCIe 带宽) $\text{Soft}(tp) = \sum_{i<j} \text{traffic}(i,j) \cdot \mathbb{1}[\text{CrossDomain}(v_i, v_j)] \le B_{\text{PCIe}}^{\max}$——跨域累计流量不得超过 PCIe 软上限(经验值:256 GB/s,即 8× NDR IB 饱和值的 80%)。
3. 长约束(HBM 容量) $\text{Long}(tp) = \sum_{i=1}^{tp} \text{weight}(v_i) + \text{kv}(v_i) \le a(v_i)$——每个 GPU 装得下权重 + KV cache 预留,长约束意味着规划阶段而非实时解决。
4. 可调旋钮(TP 切分) $\text{TP} \in \{1, 2, 4, 8, 16\}$——可调旋钮,根据上面三个约束的可行域动态选择。

把这个四元组记作 $C = (H, S, L, T)$,拓扑感知调度的本质就是:对每个到来请求 $r$(序列长度 $s_r$、batch $b_r$、SLO $p_r$),在约束 $C$ 下求解最优 $(t, s, p, e)$ 切分组合,使得期望延迟 $E[\text{latency}(r | t, s, p, e)] \le p_r$ 且代价 $E[\text{throughput loss}]$ 最小。

关键工程挑战:约束的时效性。域内亲和约束(H)是静态的,一旦 GPU 节点下线,DomainMap 标记该 GPU 不可用,亲和约束随即更新;但 HBM 容量约束(L)是动态的,随请求的 batch 大小、序列长度、KV cache 复用率实时变化。这意味着调度器必须在毫秒级时间内完成"静态约束过滤 + 动态约束求解",而不能依赖离线批处理。工程上采用"预筛选 + 在线求解"两层架构:预筛选层用静态 DomainMap 把候选 GPU 集缩到 8-16 卡,在线求解层在这 8-16 卡内用动态规划求解最优 TP 值,总延迟 < 5 ms。

四元组约束的求解复杂度分析。四元组联立求解的搜索空间是 $O(|V|^{tp} \times tp!)$——对 256 卡集群,TP=8 时搜索空间约 $C_{256}^{8} \times 8! \approx 4.3 \times 10^{11}$。穷举搜索在 5 ms 内不可行。工程上用贪心 + 约束剪枝:按 TP 值从大到小尝试(16→8→4→2→1),每个 TP 值只检查当前域内可用 GPU 数量是否够用,剪掉所有不满足域内亲和的分支。贪心的损失:可能错过 TP=4+PCIe 软约束通过但 TP=8 硬约束失败的更优解,但节省 99.9% 的搜索时间。实测贪心与 ILP 最优解的差距 < 5%,在工程可接受范围内。

三、NVLink 域内亲和：拓扑感知调度的硬约束

NVLink 域内亲和是整个拓扑感知调度的基石,也是被误用最多的"硬约束"。在 H100/H200 节点上,8 卡通过 4 颗 NVSwitch 互联,组成一个全连接 NVLink 域(NVLink 4.0 单向 450 GB/s,双向 900 GB/s);在 Blackwell B200 上,8 卡通过 NVSwitch 5 组成 1.8 TB/s 双向带宽域,在 GH200 Grace-Hopper 超级芯片上,72 个 GPU 通过 NVLink Switch System 互联,组成 1.8 TB/s 全连接域,跨节点通信也保持 NVLink 速率。一旦跨域,AllReduce 通信就退化成 PCIe + IB 路径,带宽骤降 5-10 倍。

工程上,域内亲和的实现通常依赖三个机制:第一是 NVIDIA 的 CUDA_DEVICE_TOPOLOGY 查询 + NVML 的 nvmlDeviceGetNvLinkState(),获取每个 GPU 的 NVLink 邻居矩阵;第二是调度器维护一张域标签表(DomainMap),每个 GPU 节点带域 ID 如 nvlink-domain-0、nvlink-domain-1,跨域通信时把流量打上"跨域"标签;第三是引擎层做 TP 切分时显式调用 set_affinity(tp_ranks),把一个 TP 切分的所有 rank 强制约束在同一个 DomainMap 内。

拓扑感知调度器在初始化阶段,会把 DomainMap 持久化到本地数据库(SQLite),并通过 etcd 同步给所有调度器副本。这样新启动的调度器无需重新扫描 GPU 拓扑,直接从 etcd 拉取即可,调度器冷启动时间从 30 秒降至 2 秒以内。同时 DomainMap 需要周期性(例如 60 秒一次)刷新,以应对 GPU 节点动态上下线、硬件故障导致的拓扑变化。DomainMap 的"准实时性"是拓扑感知调度可信的基石,一旦 DomainMap 过期超过 5 分钟,跨域流量可能突增 2-3 倍,SLO 直接击穿。

实测一个 175B 模型 TP=8 推理,域内亲和 vs 跨域两种放置的差距如下(数据来自截至 2026-07-28 的内部基准,8× H100,序列长度 2048,batch 32,FP8):域内亲和时 P50 延迟 76 ms、P99 延迟 92 ms,跨节点 4+4 放置时 P50 延迟 218 ms、P99 延迟 287 ms,P99 退化 3.1×。这个 3.1× 不是噪声,它是确定性可复现的——AllReduce 通信从 NVLink 域内的 900 GB/s 降到 IB 8× 的 200 GB/s,通信时间从 12 ms 拉到 165 ms,占总延迟的 58%。结论:NVLink 域内亲和是 TP 切分的硬约束,任何跨域 TP 放置都应被调度器拒绝。

四、PCIe 跨域瓶颈：软约束与降级策略

相比硬约束的"零容忍",PCIe 跨域带宽是"软约束"——它允许一定程度的跨域流量,但需通过降级策略把跨域流量控制在系统可承受范围内。在 16-64 卡规模的多节点推理集群中,TP 切分偶尔需要跨域(例如 TP=8 但单域只剩 4 卡可用),此时调度器必须计算跨域累计流量,若超过 PCIe 软上限则触发降级。

降级策略的第一步是带宽预算分配:调度器维护一个全局 PCIe 跨域带宽预算 $B_{\text{PCIe}}^{\max}$,按"先到先得 + SLO 优先级加权"分配给每个活跃请求。SLO 越紧的请求(如 P99 < 100 ms)分配越高的带宽预算,SLO 宽松的请求(如离线 batch)拿到最低预算。预算耗尽时,新请求被排队等待而非抢占。带宽预算分配的粒度通常按"每请求每毫秒"计算:一个 P99=100 ms 的低延迟请求,调度器分配 $B_{\text{PCIe}}^{\max} \times 0.8 / 100$ 作为瞬时预算,超出则立即降级;一个离线 batch 请求,分配 $B_{\text{PCIe}}^{\max} \times 0.05$,几乎不占预算。

第二步是流量整形与压缩:对跨域 AllReduce 流量做 FP8/BF16 量化压缩,把 32-bit 梯度/激活压缩到 16-bit 或 8-bit,带宽占用降至 25-50%。代价是引入量化-反量化开销,适合 SLO 宽松的 batch 请求;对 SLO 严格的低延迟请求(如对话流式),不压缩以保精度。工程上用 NCCL 的压缩原语 ncclReduceScatter + ncclAllGather 组合,在 AllReduce 之前插入 FP8 量化层,实测带宽降低 2-3× 而延迟增加 < 5 ms,对长序列(> 4k)效果显著。

第三步是通信-计算重叠:用 CUDA Graph + 异步 AllReduce,把跨域通信与下一层 FFN 的 matmul 计算 overlap。重叠比例可达 60-80%,把跨域延迟从 165 ms 降到 50-65 ms(注:Bulk同步点不可避免,但中间阶段可深度 overlap)。CUDA Graph 的使用场景限制:CUDA Graph 适合固定形状的算子图(sequence length 固定,batch 固定),对变长序列(Semantic caching 命中等场景)需要用 CUDA Events 手动 overlap,实现复杂度高。截至 2026-07-28,vLLM 的 Chunked Prefill + 动态 batch 机制与 CUDA Graph 有冲突,需要通过 CUDA_GRAPH_STATIC_RANGES 白名单机制部分绕过。

实测 PCIe 软约束对 P99 延迟的边际收益:严格域内亲和(P99=92 ms) vs 允许 10% 跨域流量(P99=108 ms) vs 允许 20% 跨域流量(P99=143 ms)。结论:PCIe 跨域是软约束,通过带宽预算 + 流量压缩 + 通信计算重叠三件套,可把跨域退化的 3.1× 压缩到 1.5× 以内;但 20% 跨域流量已是工程极限,再高则 P99 退化不可接受。

五、HBM3e 容量：长约束与专家并行映射

HBM3e 容量是四个约束里最容易被低估的"长约束"。一个 70B 模型 FP8 权重约 70 GB,TP=8 切分后每卡 8.75 GB,看起来 80 GB HBM3e 装得下,但加上 KV cache 预留(KV cache per token ≈ 0.5 MB,32k 上下文 × 4 卡并发 ≈ 64 GB)、加上激活值(activation checkpoint 关闭时峰值 8-12 GB)、加上 CUDA workspace(1-2 GB),实际每卡可用 70-80 GB 中需要 60-70 GB 给 weight + KV,留给 activation 的窗口只有 10-20 GB。当 batch 或上下文超过阈值,长约束被打破,要么 OOM,要么 activation recompute 触发,延迟翻倍。

长约束的求解不在实时调度层,而在规划/预热层:调度器在每个请求到来时,先估算 HBM 容量需求 $\text{HBMNeed}(r) = \text{weight}(r) + \text{kv}(r) + \text{activation}(r)$,然后在可用容量 $a(v)$ 的 GPU 集合里筛选可行域。不可行时启动"容量降级三件套":第一是 KV cache 压缩到 INT4/INT8,把 KV 占用降至 12-25%;第二是 activation checkpointing,降低 activation 峰值 30-50%;第三是请求排队等待,等显存回收。

KV cache 压缩的具体工程实现,可以用 NVIDIA 的 FP8 KV cache(适配 H100/H200)或 INT4 KV cache(适配 H100/AMD MI300X)。FP8 KV cache 精度损失 < 0.5% perplexity 增长,对线上对话场景完全可接受;INT4 KV cache 精度损失 1-2%,适合离线 batch 推理。关键工程陷阱:KV cache 压缩必须与量化策略协同设计——如果权重用了 GPTQ/INT4 量化,但 KV cache 保持 FP16,最终推理精度瓶颈在 KV cache 而非权重,整个量化工程白做。截至 2026-07-28,主流实践是"INT4 权重 + INT4 KV"或"FP8 权重 + FP8 KV"成对使用,避免混合精度陷阱。

MoE 模型的专家并行(EP)进一步放大长约束:一个 8×22B MoE 模型,128 个专家每次只激活 2 个,EP 切分时每个 GPU 持有 16 个专家的权重(共 ~28 GB),加上共享 attention 层(2 GB),HBM 占用直接撑到 30 GB。专家并行的容量规划必须考虑"专家热点"——某些高频专家被所有 batch 命中,导致热点 GPU 显存压力 1.5-2× 于其他 GPU。工程上的应对是专家负载均衡 + 热点专家复制 + 动态专家路由三件套:专家负载均衡通过定期(如每 10 分钟)统计专家命中率,把高频专家复制到多卡,分散热点;热点专家复制把命中率 top-8 专家各复制 2 份,每个副本占 2 GB HBM,总开销 32 GB,但可以把热点 GPU 的 HBM 压力从 1.8× 降至 1.1×;动态专家路由根据当前 GPU HBM 状态,把请求路由到负载最轻的 GPU,避免单卡 HBM 打满。

六、Tensor Parallel 切分决策：四元组的统一求解

把硬约束、软约束、长约束、可调旋钮四元组联立求解,才能得到一个"可执行"的 TP 切分决策。$TP \in \{1, 2, 4, 8, 16\}$ 五个候选值,每个候选值对应一组可行域:TP=16 要求至少 16 个 NVLink 域内 GPU(2 个 8 卡节点全占),TP=8 至少 8 卡域内,TP=4 至少 4 卡,TP=2/TP=1 是兜底。

TP 切分决策的经验法则(截至 2026-07-28 的工程实践):

• TP=16: 适合 400B+ 参数模型,单请求 latency 最低但吞吐受限,需要 2 个完整 8 卡节点。典型场景:前沿基础模型在线推理,SLO 极严(P99 < 50 ms)。
• TP=8: 适合 70-200B 参数模型,平衡 latency 与吞吐,是当前生产主流。典型场景:GPT-4 级别模型的 API 服务。
• TP=4: 适合 20-70B 参数模型,单节点 4 卡 H100 可以容纳,延迟比 TP=8 稍高但吞吐更高。典型场景:小模型高并发对话。
• TP=2/TP=1: 适合小模型或离线 batch,延迟不敏感但追求最大吞吐。典型场景:批量摘要、embedding 推理。

算法决策流程(伪代码,从调度器源码抽象):

def select_tp(request):
    # 1. 长约束:HBM 是否装得下
    hbm_demand = estimate_hbm(request)
    if hbm_demand > GPU_HBM_BUDGET:
        return apply_capacity_fallbacks(request)  # KV 压缩 + checkpoint

    # 2. 硬约束:NVLink 域内亲和
    for tp in [16, 8, 4, 2, 1]:
        candidates = find_nvlink_domain_gpus(tp)
        if len(candidates) >= tp:
            # 3. 软约束:PCIe 跨域带宽
            cross_traffic = estimate_cross_domain_traffic(request, candidates[:tp])
            if cross_traffic <= PCIE_BUDGET:
                return tp, candidates[:tp]

    # 4. 兜底:跨域 + 通信压缩
    return 1, find_any_gpus(1)  # 退到 TP=1 单卡推理

实测一个 32 节点 256 卡 H100 集群,4096 个并发请求,严格 NVLink 域内亲和可以满足 78% 的请求,其余 22% 通过 PCIe 软约束 + 通信压缩满足,总 P99 延迟 95 ms(目标 SLO 100 ms 内)。如果关闭约束、随机放置,P99 延迟会爆到 380 ms,远超 SLO。结论:四元组联合求解比单一约束优化更接近生产最优。

Pipeline Parallel 与 Tensor Parallel 的协同调度是另一个工程陷阱:PP(层切分) + TP(张量切分) 同时使用时,PP 切分点与 TP 切分域的交互会导致 GPU 利用率非线性下降。例如 PP=4 + TP=8,在 32 卡集群里意味着 4 个 pipeline stage 各占 8 卡,每个 stage 内 TP=8 必须在同一 NVLink 域内,这要求 4 个完整的 NVLink 域空闲才能启动请求。当 4 个域中只有 3 个空闲时,系统会等待而非降级 PP,导致 GPU 利用率骤降。工程上采用 PP/TP 分离调度:先用域内亲和约束选出 TP 可行集,再在可行集内用整数线性规划(ILP)求解 PP 切分点,使 GPU 利用率期望最大化。

多请求并发调度的公平性也是 TP 切分决策必须考虑的维度。当多个 SLO 级别不同的请求同时到达时,调度器需要在"满足每个请求的 SLO"和"最大化集群吞吐"之间找到 Pareto 最优。工程上用加权公平队列(Weighted Fair Queueing,WFQ),权重与请求的 SLO 严格程度正相关:SLO 越严格权重越高,但高权重请求占用更多域内 GPU 资源时,需要支付"资源占用费"——调度器在分配域内 GPU 时,自动把资源占用费计入公平性约束,防止高 SLO 请求饿死低 SLO 请求。

七、拓扑感知调度器工程实现：从亲和标签到 sidecar 验证

把四元组约束变为可运行的调度器,工程实现上有五层关键组件:

Layer 1 — 拓扑发现层:调度器启动时调用 nvidia-smi topo -m + NVML 查询,生成全局 GPU 拓扑矩阵,带 NVLink 域标签、PCIe 拓扑、IB 拓扑、可用区标签。拓扑矩阵加载到内存,作为调度器决策的静态底图。nvidia-smi topo -m 输出样例:

        GPU0    GPU1    GPU2    GPU3    GPU4    GPU5    GPU6    GPU7    CPU Affinity
GPU0     X       NV1    NV1    NV1    SYS     SYS     NV1    NV1
GPU1     NV1     X       NV1    NV1    SYS     SYS     NV1    NV1
GPU2     NV1    NV1     X       NV1    NV1    NV1     SYS    SYS
GPU3     NV1    NV1    NV1     X       NV1    NV1     SYS    SYS
GPU4     SYS     SYS    NV1    NV1     X       NV1    NV1    NV1
GPU5     SYS     SYS    NV1    NV1    NV1     X       NV1    NV1
GPU6     NV1    NV1    SYS    SYS     NV1    NV1     X       NV1
GPU7     NV1    NV1    SYS    SYS     NV1    NV1     NV1     X

NV1 = NVLink 1-hop, SYS = PCIe cross-domain, X = self。调度器解析这张表,把 NV1 聚合成 NVLink 域,把 SYS 边标记为跨域。

Layer 2 — 容量分账层:每个 GPU 节点维护 HBM 容量账本 Accounts[v] = {weight, kv, activation, workspace},实时更新。当请求分配 GPU 时扣减,请求结束归还。账本账目触发长约束 violations 时立即升级处理。为防止并发写入竞争,账本用 Redis 分布式锁保护,每次分配/归还操作先 SETNX 加锁,操作完 DEL 解锁,锁超时 5 秒自动释放防止死锁。

Layer 3 — 约束求解层:基于上文伪代码,实现真实版本的 TP 切分决策器。决策器接受约束预算 + 请求 SLO,返回 TP 值 + GPU 列表 + 期望延迟估算。决策延迟目标 < 5 ms(7 层 MLP,中间过程纯整数运算)。

Layer 4 — 亲和绑定层:决策结果下发到 vLLM/SGLang/TensorRT-LLM 引擎层,引擎通过 cudaSetDevice + set_affinity(tp_ranks) 完成 GPU 绑定。绑定关系写入引擎进程的环境变量 CUDA_VISIBLE_DEVICES 与 TP_RANK_MAP,进程间共享通过共享内存高效传递。

Layer 5 — sidecar 验证层:每个推理引擎 Pod 旁边挂一个 sidecar 进程,持续验证:(a) 实际 NVLink 域是否与请求时的 domain 一致(防止 GPU 节点迁移或硬件故障);(b) 实际 PCIe 跨域流量是否在预算内(防止 batch 突增打穿预算);(c) 实际 HBM 占用是否与账本一致(防止内存泄漏)。sidecar 验证是系统可信的最后一道防线,一旦发现漂移立即触发请求迁移或告警。sidecar 与引擎进程通过 UDS(Unix Domain Socket)通信,延迟 < 1 ms,开销可忽略。

sidecar 的核心验证循环如下:

import time
while True:
    for gpu_id in assigned_gpus:
        # 1. NVLink 域验证
        current_domain = get_nvlink_domain(gpu_id)
        if current_domain != assigned_domain[gpu_id]:
            emit_alert("TOPOLOGY_DRIFT", gpu_id, current_domain, assigned_domain[gpu_id])
            migrate_request(gpu_id)

        # 2. PCIe 跨域流量验证
        cross_traffic = get_cross_domain_traffic(gpu_id)
        if cross_traffic > PCIE_BUDGET * 0.9:  # 90% 阈值
            emit_alert("PCIE_BUDGET_WARNING", gpu_id, cross_traffic, PCIE_BUDGET)

        # 3. HBM 占用验证
        used_hbm = get_used_hbm(gpu_id)
        if abs(used_hbm - account[gpu_id]) > 0.1 * account[gpu_id]:  # 10% 漂移阈值
            emit_alert("HBM_DRIFT", gpu_id, used_hbm, account[gpu_id])

    time.sleep(10)  # 每 10 秒验证一轮

八、局限与对比：与 vLLM/SGLang/Megatron-LM 的接口差异

拓扑感知调度在生产落地时,会与现有推理引擎的接口产生张力。vLLM 的 Scheduler 是请求级的、忽略拓扑的——vllm.core.scheduler 维护 waiting/running/swapped 三队列,但所有调度决策都在"GPU 0、1、2、...、N"序号层,没有 NVLink 域概念。要让 vLLM 拓扑感知,需要在 vLLM 上层包一层"调度代理",把请求先按拓扑分组,再交给 vLLM 实例。vLLM 的 Chunked Prefill 机制与拓扑感知天然冲突:Chunked Prefill 把长序列的 prefill 分成多个 chunk,每个 chunk 可能落在不同的 GPU batch 里,破坏了 NVLink 域内亲和约束。工程上用 CUDA_VISIBLE_DEVICES 隔离域内 GPU 子集来解决,但这会导致 vLLM 实例数随域数量线性增长,资源利用率下降。

SGLang 的 RadixAttention + 路由器 比 vLLM 多了 prefix cache 感知,但同样不感知拓扑,需要外层包装。SGLang 的路由器 route() 函数返回一批 WorkerGroup,每个 WorkerGroup 默认按 GPU 序号均分,对拓扑不可知。SGLang 的调度优势在于 RadixAttention 对 KV cache 的复用率比 vLLM 高 30-40%,但在跨域流量上没有特殊处理,适合与拓扑感知调度配合做端到端优化。

TensorRT-LLM 的 cluster mode 提供多节点推理支持,但调度粒度是"整个模型实例"而非"单个请求",不适合需要对每个请求做 TP 切分决策的细粒度拓扑感知场景。TensorRT-LLM 的优势是 kernel 层面的深度优化,对 TP=8 的矩阵乘法做 swizzle、tma 等 Blackwell 硬件特性利用,实测比 vLLM 快 20-30%,但缺乏请求级的动态 TP 切分。

Megatron-LM 的切分感知理论上最贴近,其 tensor_parallel.set_tensor_model_parallel_world_size() 与 pipeline_model_parallel_world_size() 可以精确控制 TP/PP/EP 切分,并与 NCCL 的拓扑感知通信原语集成。但 Megatron-LM 是训练框架,推理侧需要迁移 megatron.core.tensor_parallel 到推理 runtime,工作量可观。截至 2026-07-28,没有推理引擎原生支持拓扑感知调度,主流方案都是"上层代理 + 引擎适配"模式。这一层适配的工程代价与收益如何权衡,是每个 LLM 推理团队需要独立决策的。

九、给 SRE 的可观测性清单

拓扑感知调度上线后,SRE 团队需要盯着 9 个核心指标:

1. NVLink 域内亲和率 = 域内 TP 切分请求数 / 总请求数,目标 ≥ 75%。告警阈值:低于 70% 立即升级,低于 65% 触发 P0 告警。
2. PCIe 跨域流量利用率 = 实际跨域流量 / PCIE_BUDGET,持续 > 80% 触发告警,持续 > 90% 触发 P0。
3. HBM 容量利用率 = 已用 / 可用,持续 > 85% 触发容量预警,持续 > 95% 触发 OOM 高危。
4. TP 切分分布 = TP=1/2/4/8/16 各占比例,异常漂移提示硬件变化。正常稳态:TP=8 占 55-70%,TP=4 占 20-30%,TP=2 占 5-10%,若 TP=1 突增说明硬件故障或 HBM 不足。
5. sidecar 验证漂移率 = sidecar 检测到的拓扑漂移次数 / 总请求数,目标 < 0.1%,任何漂移立即告警。
6. 跨域通信压缩率 = 压缩后流量 / 原始流量,目标 ≤ 50%。压缩率 > 60% 说明跨域流量超出预期,需要 review 调度策略。
7. 通信-计算重叠率 = overlap 时间 / 总通信时间,目标 ≥ 60%。低于 50% 说明 CUDA Graph 或异步 AllReduce 配置异常。
8. 请求迁移率 = sidecar 触发迁移的请求 / 总请求数,目标 < 0.5%。任何突增都需要立即定位漂移 GPU。
9. P99 延迟分位差 = 跨域 P99 - 域内 P99,持续 > 50 ms 触发硬约束违规,持续 > 100 ms 说明跨域流量已不可接受。

九个指标联合起来,构成拓扑感知调度的健康体检表。任一指标持续异常,都需要回到调度器配置层做一次回归,而非简单调参。告警优先级规则:指标 1/5/8 任意一项触发是 P0;指标 2/3/9 触发是 P1;指标 4/6/7 触发是 P2。P0 告警必须在 5 分钟内响应,P1 在 15 分钟内,P2 在 1 小时内。SRE 团队应把这 9 个指标打包成 Grafana dashboard,并设置 On-Call 路由规则。

参考文献

1. NVIDIA. NVLink and NVSwitch Technical Overview. NVIDIA Technical Report, 2024.
2. Mohan, J., et al. Topology-Aware Generative Inference for Large Language Models. arXiv preprint, 2024.
3. vLLM Project. vLLM Scheduler Architecture Documentation. GitHub Wiki, 2026.
4. SGLang Team. SGLang Router and Prefix-Aware Scheduling. arXiv preprint, 2025.
5. TensorRT-LLM Team. TensorRT-LLM Cluster Deployment Guide. NVIDIA Documentation, 2026.
6. Shoeybi, M., et al. Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism. arXiv preprint, 2019.
7. Pope, R., et al. Efficiently Scaling Transformer Inference. MLSys, 2023.
8. Miao, X., et al. MoE Inference Scheduling under Memory Constraints. OSDI, 2024.
9. Korthikanti, V. A., et al. Reducing Activation Recomputation in Large Transformer Models. arXiv preprint, 2022.
10. NVIDIA. HBM3e Memory Architecture Whitepaper. NVIDIA Documentation, 2024.
11. Rasley, J., et al. DeepSpeed: System Optimizations for Transformer Training. OSDI, 2020.
12. Lin, J., et al. AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. MLSys, 2024.