1. 没有 GPU 也能修引擎崩溃问题背景与整体思路1.1 一个反直觉的排查场景很多人一听到“给推理引擎修 bug”第一反应就是没卡怎么复现没卡怎么调试我一开始也是这么想的。手上这台开发机没有独立显卡只有一块集成显卡连 CUDA 都跑不起来更别说加载一个几十 GB 的大模型权重了。但问题偏偏就出在一个部署了 vLLM 的线上环境里——服务跑着跑着EngineCore 进程直接挂掉日志里只剩下一堆看不出所以然的堆栈前端请求全部超时。这种场景其实很典型真正出问题的机器在远端有卡、有负载、有真实流量而你手边只有一台没有 GPU 的笔记本。你不可能把线上流量原样搬过来也不可能靠“再跑一遍看看”来复现。这时候唯一能依靠的就是把崩溃这件事从“运行时现象”降维成“代码逻辑问题”用纯 CPU 的方式去逼近它。我这次要处理的就是这样一个问题vLLM 的 EngineCore 在特定调度条件下会崩溃。关键词里提到的 EngineCore、调度器正是这次排查的两个核心抓手。整篇文章我会把从拿到日志到定位根因、再到写出修复补丁的完整过程拆开讲重点不是“我修了个什么 bug”而是“在没有 GPU 的情况下我是怎么把这个问题一步步逼到墙角的”。1.2 为什么调度器是这类崩溃的高发区先给不熟悉 vLLM 架构的朋友补一下背景。vLLM 的推理服务大致分成几层最上面是 API Server负责接收请求中间是 EngineCore负责调度和批处理最底下是 Worker真正在 GPU 上跑模型。EngineCore 里最核心的组件就是调度器Scheduler它决定每一轮迭代哪些请求进 batch、哪些请求被抢占、哪些请求被换出。调度器之所以容易出问题是因为它同时要处理好几件互相牵制的事显存预算、序列长度、抢占策略、请求优先级。任何一个状态没对齐就可能出现“调度器认为某个请求还在但实际它的状态已经被释放”这种不一致。而这类不一致在 GPU 上往往表现为崩溃在 CPU 上却可能只是逻辑错误——这恰恰给了我们无卡排查的机会。我这次的思路很明确不去复现 GPU 上的崩溃现场而是把调度器的状态机单独拎出来用 CPU 跑单元测试构造出会导致状态不一致的输入序列。只要能在纯 CPU 环境下让调度器逻辑暴露出问题就等于间接定位了 GPU 上的崩溃根因。1.3 整体排查路线图我把整个过程分成四步后面每个章节会展开讲读日志、缩小范围从崩溃堆栈里找到可疑的模块和函数确认问题出在调度阶段而不是模型计算阶段。搭 CPU 复现环境不装 GPU 依赖只装 vLLM 的纯 Python 部分用假的模型和假的 KV Cache 跑调度逻辑。构造触发用例根据日志里的请求模式反推出可能触发崩溃的调度序列写成可重复执行的测试。定位根因、写补丁、验证找到状态不一致的具体位置改代码再用同一套 CPU 测试验证修复有效。这条路线的核心价值在于它不依赖任何特定硬件任何一台能跑 Python 的机器都能复现。对于经常要处理远端推理服务问题的同学来说这套方法可以反复套用。2. 从日志到代码核心细节解析与实操要点2.1 崩溃日志里到底该看什么拿到一份 EngineCore 崩溃日志很多人第一眼会被几十行堆栈吓到然后开始从头往下读。我的习惯是反过来先看最后抛出的异常类型再看异常发生前最后几个被调用的业务函数最后才回头看完整堆栈。这次日志里最关键的信息有三条第一异常类型是AssertionError不是段错误也不是 OOM说明这是代码里主动断言的逻辑被违反了第二断言发生在调度相关的代码路径上第三崩溃前最后一次成功的调度迭代里出现了“请求被抢占后又立刻被重新调度”的模式。这三条信息合起来基本可以判断问题不在模型计算而在调度器的状态管理。因为如果是显存或计算问题异常类型通常是 CUDA 相关的错误而AssertionError加上调度路径几乎可以锁定是逻辑 bug。提示读日志时优先关注异常类型和最后一个业务函数调用而不是堆栈的行数。堆栈越长越说明问题可能被层层包装真正的根因往往在中间某一层。2.2 为什么可以脱离 GPU 复现调度问题这里要解释一个关键判断调度器本质上是一段纯逻辑代码它不直接操作 GPU。调度器做的事情是根据当前显存预算和请求状态决定这一轮哪些请求能进 batch。它调用的是抽象的 KV Cache 管理器接口而不是直接调 CUDA。这意味着只要我们能提供一个“假的” KV Cache 管理器让它按照我们设定的规则返回显存占用和释放结果就能在 CPU 上完整跑通调度逻辑。模型本身不需要真的加载因为调度阶段根本不涉及前向计算。我实际的做法是找到 vLLM 里调度器依赖的 KV Cache 抽象接口写一个 mock 实现把 block 的分配和释放都记录成日志。这样每次调度迭代我都能看到“调度器认为的 block 状态”和“mock 实际记录的 block 状态”是否一致。不一致的地方就是 bug 的藏身之处。2.3 搭建最小 CPU 复现环境的关键步骤搭环境这一步坑其实不少。我踩过的几个典型问题不要装完整 vLLM完整安装会拉一堆 CUDA 相关依赖在没有 GPU 的机器上要么装不上要么装上了 import 就报错。正确做法是只装纯 Python 依赖或者直接从源码里把调度相关模块单独拎出来。注意 torch 版本即使不跑 GPU调度代码里也可能 import torch。装 CPU 版 torch 即可不要装带 CUDA 的版本否则 import 时会尝试加载 CUDA 库。隔离虚拟环境这一点非常重要。因为安装 vLLM 相关依赖时很容易把已经装好的 torch 版本覆盖掉。用独立的 venv 或 conda 环境避免污染主环境。具体步骤大致是这样# 创建独立环境 python -m venv vllm_cpu_debug source vllm_cpu_debug/bin/activate # 安装 CPU 版 torch pip install torch --index-url https://download.pytorch.org/whl/cpu # 只安装调度模块需要的轻量依赖 pip install numpy pytest然后把 vLLM 源码里调度器相关的几个文件复制到工作目录手动处理一下 import 路径。这一步不需要装整个包只要保证调度器能 import 成功、能实例化就行。注意不同版本的 vLLM 调度器接口差异较大复制源码前先确认你线上环境用的是哪个版本避免用错接口导致复现结果对不上。2.4 构造触发用例的核心思路有了环境下一步是构造能触发崩溃的输入。这里不能瞎试要根据日志里的请求模式反推。我总结了一个“三要素法”请求到达顺序日志里崩溃前请求是批量到达还是逐个到达这决定了调度器每轮看到的队列长度。序列长度分布有没有特别长的请求和特别短的请求混在一起长请求容易触发抢占。抢占发生时机抢占是在显存快满时发生还是在显存充足时也发生这能区分是预算计算错误还是状态管理错误。我这次的用例就是围绕“长请求触发抢占、抢占后短请求立刻补位”这个模式构造的。写成一个 pytest 测试每次运行都能稳定复现断言失败。到这一步问题已经从“线上偶发崩溃”变成了“本地必现的逻辑错误”排查难度直接降了一个数量级。3. 实操过程从复现到定位根因的完整实现3.1 用 mock KV Cache 记录状态变化复现环境搭好后第一件事是写 mock。我的 mock 设计很简单维护一个 block 集合分配时加入释放时移除每次操作都打印当前集合状态。关键是要让 mock 的行为和真实 KV Cache 的语义一致——比如释放一个已经被释放的 block真实实现可能会报错mock 也要报错。class MockKVCache: def __init__(self, num_blocks): self.free_blocks set(range(num_blocks)) self.allocated {} def allocate(self, seq_id, num_blocks): if len(self.free_blocks) num_blocks: return False blocks [self.free_blocks.pop() for _ in range(num_blocks)] self.allocated[seq_id] blocks return True def free(self, seq_id): if seq_id not in self.allocated: raise RuntimeError(fdouble free: {seq_id}) for b in self.allocated.pop(seq_id): self.free_blocks.add(b)这个 mock 里最关键的是free方法里的双重释放检查。真实环境里双重释放往往不会立刻报错而是导致后续分配拿到脏 block最终在 GPU 上表现为崩溃。mock 把它变成显式异常问题就暴露出来了。3.2 复现脚本的编写与运行有了 mock接下来写复现脚本。脚本的核心是模拟调度器的多轮迭代每轮传入不同的请求状态观察 mock 是否抛出异常。def test_scheduler_preemption(): cache MockKVCache(num_blocks10) scheduler Scheduler(cache) # 第一轮一个长请求占满大部分 block scheduler.add_request(seq_id1, num_blocks8) scheduler.step() # 第二轮新请求进来触发抢占 scheduler.add_request(seq_id2, num_blocks5) scheduler.step() # 第三轮被抢占的请求重新调度 scheduler.step()运行这个测试果然在第三轮step时抛出了double free异常。这说明调度器在抢占和重新调度的过程中对同一个请求的 block 释放了两次。问题定位到了。3.3 根因分析状态机里的一个遗漏分支顺着异常往上追我找到了调度器里处理抢占的那段代码。逻辑大致是当显存不足时选择一个 victim 请求释放它的 block把它标记为preempted。然后在下一轮preempted的请求会被重新加入等待队列。问题出在当一个请求被抢占后如果它同时还在另一个数据结构里被引用重新调度时就会走两条释放路径。一条是抢占时的释放另一条是重新调度失败时的清理释放。两条路径都调用了free导致双重释放。这个 bug 在 GPU 上之所以表现为崩溃而不是显式异常是因为真实的 KV Cache 释放是异步的双重释放不会立刻报错而是破坏了 block 的引用计数最终在某个后续分配时触发 CUDA 错误。这也解释了为什么线上日志里看不到直接的“double free”只有一堆间接的崩溃堆栈。3.4 补丁编写与 CPU 验证定位到根因后补丁其实很简单在释放 block 前加一个状态检查确保同一个请求不会被释放两次。def free_request(self, seq_id): if seq_id not in self.allocated: return # 已经释放过直接返回 for b in self.allocated.pop(seq_id): self.free_blocks.add(b)改完后重新跑复现脚本测试通过。为了确认没有引入新问题我又补了几个边界用例连续抢占、抢占后立即取消、多个请求同时抢占。全部通过后才把补丁提交到远端环境做真实验证。提示CPU 复现通过不代表 GPU 上一定没问题但它是必要条件。如果 CPU 上都跑不过GPU 上必然有问题。所以先用 CPU 测试做快速迭代再用 GPU 做最终确认效率最高。4. 常见问题与排查技巧实录4.1 无卡排查常见问题速查表问题现象可能原因排查方向import vLLM 就报 CUDA 错误装了带 CUDA 的 torch换 CPU 版 torch隔离环境调度器实例化失败依赖的配置对象缺失手动构造最小配置或从源码里找默认值复现脚本跑不出异常用例构造不对对照日志里的请求模式调整到达顺序和长度分布修复后 CPU 通过但线上仍崩还有其他触发路径扩大用例覆盖补充边界场景安装依赖覆盖了已有 torch环境未隔离用 venv 或 conda 独立环境4.2 几个容易踩的坑第一个坑是盲目相信日志里的行号。线上环境的代码可能和本地版本不一致行号对不上是常事。正确做法是根据函数名和调用关系去定位而不是死磕行号。第二个坑是试图在 CPU 上跑完整模型。完全没必要调度问题不涉及前向计算跑模型只会浪费时间还可能引入新变量。把范围缩小到调度器本身效率高得多。第三个坑是忽略 mock 的语义准确性。mock 太宽松问题复现不出来mock 太严格又会引入假阳性。我的经验是mock 的行为要尽量贴近真实实现的契约尤其是错误处理部分。4.3 一个提升效率的小技巧如果你经常要处理这类远端推理服务的问题建议在本地维护一套“调度器单元测试集”。每次遇到新的调度相关 bug就把触发用例加进去。时间长了这套测试集就成了你的回归防线很多问题在提交前就能被拦住。我自己这套测试集现在有二十多个用例覆盖了抢占、取消、超长序列、并发到达等场景。这次修的这个 bug其实就是被其中一个用例的变体触发的。没有这套积累光靠临时构造用例排查时间至少要翻倍。5. 从这次排查延伸出的几点经验5.1 硬件不是排查逻辑问题的门槛这次经历最大的收获是让我重新认识了“复现”这件事。很多人把复现等同于“原样重跑”但实际上复现的本质是让问题在可控环境下稳定出现。只要能把问题从硬件依赖中剥离出来没有 GPU 一样能修引擎 bug。调度器、状态机、资源管理器这类组件本质上都是纯逻辑代码。它们的 bug 大多源于状态不一致而状态不一致完全可以用 mock 和单元测试来捕捉。GPU 只是让这些 bug 的表现形式变得更“吓人”而已。5.2 日志分析要抓主要矛盾一份崩溃日志里90% 的信息是噪音。真正有用的往往就那两三条异常类型、最后一个业务函数、崩溃前的关键状态变化。抓住这三条就能把排查范围缩小到一两个模块。剩下的时间应该花在构造复现用例上而不是反复读堆栈。5.3 补丁要小验证要狠定位到根因后补丁能小则小。这次我只加了一个状态检查没有重构任何逻辑。小补丁的好处是引入新风险的概率低review 起来也快。但验证要狠CPU 用例要覆盖各种边界GPU 上还要跑一轮真实流量确认。两者都过了才算真正修好。最后分享一个我自己的习惯每次修完一个 bug我都会在代码注释里写清楚“这个检查是为了防止什么场景”。这样下次有人改到这段代码时能立刻明白为什么不能删。很多 bug 的复发就是因为后来的人不知道当初为什么这么写。