我前段时间帮人调一个 RTX 5070 Laptop 跑 vLLM 的问题启动日志里直接甩出来一行cuda capability sm_120 is not compatible。这不是 vLLM 第一次在新 GPU 上吃瘪也不会是最后一次。底层原因很直接vLLM 过去几年为了压榨性能把大量逻辑深度绑在了 CUDA 的旧抽象上。现在为了接住新 GPU社区又在拆掉旧抽象转头再造一套可移植层。听起来像是绕圈子拆了又造为什么不直接在老代码上打补丁这篇文章我想把这件事讲透旧抽象到底哪里不够用了为什么不能靠写分支硬扛以及再造可移植层这个决定背后真正的取舍逻辑。最后我也会分享一些适配新 GPU 时的实操经验和踩坑记录给正在折腾 vLLM 部署、或者想参与推理引擎开发的人一点参考。1. 拆掉旧抽象三个被新 GPU 推翻的老规矩vLLM 早期的抽象其实非常简单一切都围绕NVIDIA 的 CUDA GPU来设计。这个抽象在 A100/H100 时代非常成功因为它精准匹配了当时的两个现实——硬件形态单一模型结构相对确定。但到了新 GPU 集中出现的阶段这套抽象背后的三个隐含假设同时被推翻了。1.1 第一条规矩CUDA 是唯一需要认真对待的设备早期 vLLM 的代码里设备相关逻辑经常直接以torch.cuda为锚点编写包括显存分配、流管理、图捕获、kernel 启动。那时候这么写没错因为 vLLM 的目标就是在英伟达数据中心卡上跑出极限吞吐其他平台都是后话。但是当社区开始支持 AMD ROCm、Intel XPU、CPU、甚至更多加速卡时问题就暴露了你把设备能力和设备实现混在了同一层。一个上层逻辑只是想知道这块卡能不能跑 FP8结果下层要把 CUDA、ROCm、OpenVINO、XPU 各写一遍。这不是多做几份代码的问题而是每新增一个平台所有调用点都要过一遍它是不是 CUDA的判断代码开始出现大量平台泄漏。打个比方旧抽象像一栋只有一种插座标准的楼。所有电器都按同一个插头设计没问题。但后来你需要接入不同标准的供电设备时不可能给每个房间都塞一个转接头你得重新设计配电箱。1.2 第二条规矩SM 架构差异靠多编译一次就能抹平CUDA 生态一直有个向下兼容的幻觉只要你编译时把 PTX 包含进去旧二进制总能在新 GPU 上跑起来。对很多应用来说这个幻觉是真的——能跑但性能未必达标。对 vLLM 这类追求每一点性能的推理引擎来说能跑从来不是目标关键是能不能用上新的硬件特性。就拿sm_120 is not compatible那条报错来说RTX 5070 Laptop 对应的是 Blackwell 时代的 compute capability 12.0。如果 vLLM 里的.so只针对 sm_90 编译过并且没有预留 PTX forward-compatibility 路径那么老镜像在新卡上会直接拒绝加载。更麻烦的是就算你强行编译通过旧 kernel 的调度方式、内存访问模式也没法自动适配新架构的 TMA、异步拷贝这些特性。也就是说编译通过和性能可用之间的空隙被新 GPU 拉得越来越大再靠多编译一个 sm_120 目标已经解决不了问题了。这就像你给一个旧发动机装到新车上点火是能点火但变速箱逻辑、供油曲线全不匹配跑不出设计的马力。1.3 第三条规矩显存管理与 kernel 选择可以绑在一个包里vLLM 最核心的竞争力在于 PagedAttention、Continuous Batching 这套显存调度机制。旧抽象里KV cache 的页表分配、显存池管理、kernel 实现是深度耦合的——同一套代码同时完成显存怎么分和注意力怎么算。在 CUDA 生态内这个设计非常高效因为显存分配和 kernel 选择都依赖同一套驱动行为。但换成其他加速卡后这套耦合就变成了枷锁。不同设备的显存分配 API 不同虚拟地址空间管理方式不同甚至 kernel 的启动方式都不同。如果把显存管理和注意力实现硬绑在一起那么适配一块新卡时你等于要把整条链路重写一遍。真正合理的做法是把这两件事拆开显存管理负责提供内存布局能力注意力 kernel 通过统一接口去消费这种布局。这也就是为什么后来的重构里内存抽象和 attention backend 被强行切开——不是没事找事而是新硬件逼出来的。2. 拆完之后为什么不直接写分支而要再造一层很多人看到拆掉旧抽象的第一反应是那好办以后遇到新 GPU 就加一个 if/else判断is_new_gpu然后走另一条路径不就行了这个思路短期看起来省事长期却会把项目拖入泥潭。2.1 ifdef 式适配的诱惑与代价最容易想到的粗暴方案是在关键路径上写一堆条件判断if gpu_type blackwell: use_kernel_a(); else: use_kernel_b()。开始只有两张卡时分支数量很少代码还能看。但一旦 GPU 阵营多起来组合爆炸就来了——GPU 型号 × 模型结构 × 量化策略 × 图捕获能力四者相乘之后测试矩阵直接失控。我在一些开源项目里见过这种分支式适配的晚期形态一个文件里十几个is_sm90、is_sm120、is_rocm的标记改一个分支会影响到另一个分支修复一个 bug 又带出两个新 bug。更糟的是性能优化很难跨分支复用。你在 Blackwell 上针对 TMA 做了一版优化的 kernelAmpere 用不上ROCm 也用不上等于每次优化都只能服务一小撮用户。社区的力量就这样被分散掉了。所以直接写分支不是快是假快。它把决策成本从设计阶段转移到了每一个后续修改里而且越到后期成本越高。2.2 可移植层不是再包一层而是配电箱再造可移植层听起来像是给本已复杂的系统再套一个容器。但从电气工程的角度来类比就很容易理解你家的墙壁插座电压标准不统一时你不会买一堆转接头到处插而是会在入户处装一个配电箱先把进来的电识别清楚再按电器类型分配到正确的电路里。可移植层就是这个配电箱。它的核心职责不是供电——也就是说它不负责具体的矩阵乘法、注意力计算而是负责三件外围的事能力探测、实现路由、接口约定。上层模型只跟能力接口打交道下层各后端各自注册自己的 kernel 实现。新 GPU 到来时只需要新增一个能力包和一批 kernel 实现不需要把模型执行流程图推倒重来。这个设计思路在图形学里有一个成熟原型叫 RHIRendering Hardware Interface。游戏引擎面对 NVIDIA、AMD、Intel 的显卡不会为每张卡写一套完整渲染链路而是定义一份统一的硬件抽象接口各厂商驱动去实现它。vLLM 现在做的可移植层本质上就是推理引擎的 RHI。2.3 统一接口给社区协作带来的实际收益除了工程结构上的好处统一接口还有一个容易被低估的价值它让社区贡献变成可拼接的。没有统一接口时一个开发者想给某张卡写一个更好的 attention kernel他得先搞懂整套执行器代码再把内核嵌到一堆条件分支里。而有了明确的后端注册机制之后他只需要实现一个接口、注册一个名字其他人通过配置就能选用。上游的新模型、新量化策略也可以直接复用到所有后端而不是每个后端各自适配一遍。我自己参与维护类似项目时有个很直观的感受接口定义清楚的项目贡献者混乱程度会显著降低因为每个人都知道自己该往哪个抽屉里放东西。可移植层解决的不只是技术问题也是协作问题。3. 再造可移植层时真正要搬运的是能力边界既然要再造一层那问题就变成了这一层到底应该抽象什么答案并不是把所有 GPU 变成同一个 GPU而是把一个 GPU 的能力描述和实现方式拆开让上层只跟能力描述打交道。3.1 五个必须从 GPU 型号里抽离出来的边界我梳理了五个在适配新 GPU 时最容易出问题的边界这些也正是可移植层最需要花力气的地方抽象边界为什么要抽象如果没抽象会怎样内存分配与显存池不同设备的显存分配 API、地址空间规则差异很大KV cache 调度代码会散落在每个后端里改一个内存策略要动全链路注意力后端同一语义的注意力在不同 GPU 上有不同的最优 kernel新模型进来时需要为每张 GPU 各配一套注意力实现图捕获与图执行CUDA Graph 在非 NVIDIA 平台上的语义完全不同依赖图捕获的加速逻辑无法跨平台复用平台间性能差距被拉大集合通信NCCL、RCCL 和其他通信库的接口和性能特征不一致多卡扩展逻辑只能写死某一家的通信库跨厂商组集群几乎没有可能量化与混合精度策略FP8、INT4 等特性在不同 SM 上的支持和性能差异巨大模型量化策略会从底层泄露到上层推理配置变得不可移植这张表里最容易忽略的是第五项。很多人觉得量化是模型侧的事跟硬件抽象没关系。但实际上supports_fp8这个布尔值在不同 GPU 上含义完全不同有的卡 FP8 是主力精度有的卡只是勉强支持。如果可移植层不把这层差异封住上层就会默认所有 GPU 都具备同样的量化能力于是出现这张卡跑量化模型特别慢但没人知道为什么的尴尬局面。3.2 一个极简的能力探测接口长什么样可移植层落地的第一步往往是定义一个能力探测接口。下面是一个概念示意不是 vLLM 的真实代码但思路是相通的# 概念示例能力探测与后端选择 dataclass class DeviceCapabilities: family: str # cuda / rocm / xpu / cpu compute_cap: tuple # (9, 0) 对应 sm_90(12, 0) 对应 sm_120 has_tma: bool supports_fp8: bool graph_capture: bool def detect_capabilities(device_id: int) - DeviceCapabilities: props get_device_properties(device_id) return DeviceCapabilities( familydetect_family(device_id), compute_cap(props.major, props.minor), has_tmaprops.major 9, supports_fp8props.major 9, graph_captureis_graph_capture_supported(device_id), ) def select_attention_backend(caps: DeviceCapabilities, model_config): if caps.has_tma and model_config.attn_type mla: return tma_mla_kernel if caps.compute_cap (9, 0): return flash_attn_3 return generic_attention这段代码看起来很朴素但它背后有一个关键原则用能力判断而不是用型号判断。compute_cap (9, 0)这种表达比写一长串if device_name in [RTX 5090, RTX 5070, ...]要可靠得多。因为型号列表永远会过时能力判断却是一个永远有效的自检方式。3.3 接口允许后端加速不让通用性拖慢特殊路径有人会担心可移植层会不会把性能拉到通用最差的水准这是一个合理的忧虑。实际上好的可移植层设计恰恰相反——它定义的是最小公倍数接口同时允许每个后端在接口内超车。什么意思就是说接口只约定一个语义比如计算这份 KV cache 的注意力不约定实现方式。NVIDIA 后端可以注册一个用 TMA FlashAttention-3 内核的实现AMD 后端可以注册一个基于 ROCm 的实现CPU 后端甚至可以注册一个完全不同的数据布局实现。上层按能力检测结果选择路由而不是要求所有后端都跑同一条代码。这样设计之后可移植层反而会让特殊路径的优化更容易落地。因为每次优化都被封装在独立的后端包里不会干扰其他平台也不会被其他平台的兼容性要求拖后腿。4. 在真实 GPU 上走通适配链路从自检到验收说完了设计层面的内容接下来聊聊实际操作。如果你是做 vLLM 部署的不写 kernel但面对新 GPU 时依然会踩到可移植层相关的坑。我按自己习惯的流程整理了一套适配检查链路。4.1 先跑能力自检再碰任何模型拿到新卡之后的第一件事不是急着部署一个 7B 模型而是先跑一个非常小的能力自检脚本。这一步能提前暴露 80% 的环境问题。python - EOF import torch print(cuda available:, torch.cuda.is_available()) if torch.cuda.is_available(): print(device name:, torch.cuda.get_device_name(0)) print(compute capability:, torch.cuda.get_device_capability(0)) props torch.cuda.get_device_properties(0) print(total memory: {:.2f} GB.format(props.total_memory / 1024**3)) EOF在 RTX 50 系列sm_120上老版本 PyTorch 很可能在这一步就报错或者打印出异常的 capability。看到(12, 0)之后你就知道当前环境里的 CUDA runtime 和算子库够不够新。同时还要用nvidia-smi确认驱动版本和最高支持的 CUDA 版本。这一步特别重要因为容器里的 PyTorch 使用的是容器内自带的 CUDA runtime但最终调用的是宿主机的驱动接口。如果两者版本落差太大你能看到的现象就是明明是同一个镜像在别人的卡上正常在我这里报CUDA driver version is insufficient。4.2 镜像和版本的选择driver、CUDA runtime、算子库的三层匹配很多人部署 vLLM 时喜欢直接拉最新镜像这并不总是对的。拿一个真实例子来说用老镜像vllm/vllm-openai:v0.27.1去加载一个很新的 embedding 模型失败一点也不意外。因为老镜像里的算子库、模型映射逻辑、甚至 HTTP API 细节都停留在当时的版本它没理由认识后来的模型格式。反过来太新的镜像也可能要求太新的驱动。比如某个镜像内置了针对 Blackwell 的 kernel 补丁但它要求 host 驱动至少是某个版本否则即使镜像再新也跑不起来。我现在的选择逻辑是三层匹配先看宿主机驱动允许的最高 CUDA 版本再选一个包含对应算子库的 vLLM 镜像最后确认镜像版本覆盖了你需要的模型架构。不要盲目追新也不要死守旧版本。4.3 冒烟测试应该从最小模型开始很多人一上来就在新 GPU 上跑一个巨大的模型出了问题根本分不清是模型加载失败、kernel 不支持、显存不足还是 API 调用错误。正确的做法是先跑一个很小的模型打通整条链路。比如你可以先用一个几百 MB 的 embedding 模型或者最小的生成模型通过 vLLM 的 OpenAI 兼容接口发起一次请求确认四件事模型能加载、kernel 能选对、显存能分配、请求能返回。这条链路通了再上大模型问题就能局限在模型太大还是kernel 性能不够上。这一步我每次适配新卡都会做成本很低但省下的排查时间非常多。4.4 性能验收吞吐、TTFT、显存水位一个都不能少功能通了只是第一步适配还远没有结束。我见过不少人新卡部署成功后只看一个 tokens/s觉得性能不错就完事了。实际上有三个指标需要同时看指标关注点常见问题P50/P99 TTFT首 token 延迟用户感知的快不快吞吐很高但 TTFT 很高说明 kernel 启动或显存预分配阶段有瓶颈稳态吞吐tokens/s系统整体处理能力新 GPU 上吞吐高但波动大说明调度器没有吃满设备特性显存水位与 KV cache 池使用率资源利用是否健康显存剩余很多但 KV cache 池碎片化严重说明显存策略没接上可移植层这三个指标最好是配套测试。只测吞吐不测 TTFT你会漏掉新卡虽然算得快但每次请求冷启动很慢的问题只看 TTFT 不看吞吐你会漏掉大并发下的资源争抢。适配新 GPU 时任何一条链路不对最后都会暴露在这三个指标的组合上。5. 我在适配新 GPU 时踩过的坑以及补救思路最后分享几个我在实际适配过程中遇到的坑。这些坑不一定都写在文档里但大概率会在你折腾新 GPU 时冒出来。5.1 CUDA Graph 捕获失败先想预热而不是换卡vLLM 会通过 CUDA Graph 把一段模型执行流程捕获成图减少 kernel 启动开销。在新 GPU 上Graph 捕获失败的频率更高而且报错信息常常令人摸不着头脑直接抛一段 CUDA illegal memory access。我的经验是遇到这类问题先不要怀疑显卡坏了。绝大多数情况是因为某些首次调用的操作比如分配缓存、初始化 cuBLAS workspace不允许出现在图捕获路径里。解决办法是先把 eager 模式的第一次迭代跑完让所有需要初始化的东西都完成再尝试 Graph 捕获。很多所谓新卡不兼容的问题本质上只是新卡对执行顺序更敏感。5.2 FP8 和量化 kernel跨硬件最容易翻车的区域FP8 在不同 GPU 上的支持情况差异非常大。有的卡 FP8 是核心卖点专门优化过累加器和内存布局有的卡只是支持这种格式跑起来比 FP16 还慢。如果你在适配新 GPU 时发现量化模型性能异常先别调 kernel先确认可移植层是否真的把算子路由到了正确的实现上。一个很典型的低级错误是模型被量化成了 FP8但当前后端并没有支持 FP8 的高性能 kernel于是一路跌进通用 fallback性能自然惨不忍睹。正确的检查方式是看日志里的 kernel 选择记录确认每个注意力层用的是哪个实现而不是只看有没有报错。5.3 显存容量不等于带宽抽象层也要感知硬件体质最后说一个容易被忽视的点显存大不代表带宽高带宽高也不代表显存策略好用。我在适配一台显卡时明明显存比上一代多了一半但吞吐只提升了 20%。后来才发现瓶颈根本不在显存容量而在显存带宽和 kernel 的数据搬运模式上。可移植层在做显存池设计时也需要对这种硬件体质敏感。不能只看还剩多少显存还要知道这块卡适合什么样的数据布局、多大的页表粒度、甚至是不是对连续访存有偏好。如果你在做部署侧可以把这个问题简化为一个经验原则同一份 KV cache 配置在不同 GPU 上表现差异很大不要照搬别人的参数一定自己跑一遍显存水位曲线。说起来我这几年做 GPU 相关适配最大的体会是与其记住一堆 GPU 型号不如建立一套能力自检的流程。每次拿到新硬件先把能力边界摸清楚再谈优化。这样不管下一代 GPU 叫什么名字你都能用同一套方法快速找到正确答案。可移植层的设计思路也是这个样子——把型号忘掉把能力记住。你如果正在自己部署 vLLM遇到新卡报错时不妨也先问一句我的环境里driver、镜像、kernel 这三层分别处在一个什么版本大概率问题就出在这三层之间的断层上。