1. 从我晓得你在跑大模型到它到底能不能启动第一次看到I know you run LLMs. Will it boot?这个标题我脑子里蹦出来的不是技术问题而是一个特别具体的画面凌晨两点你盯着终端里滚动的日志vLLM 的进程刚起来三秒就 OOM 了或者更气人的是——它压根没报错就是卡在那儿一动不动GPU 利用率 0%风扇都不转。你心里清楚这台机器上跑过 7B、跑过 14B甚至量化过的 32B 也勉强能塞进去但这次换了模型、换了精度、换了 CUDA 版本它就是不给你面子。这个标题问的其实是一个所有搞本地大模型推理的人都会反复撞上的问题在已知这台机器能跑 LLM的前提下怎么判断一个新模型、一套新环境、一个新配置到底能不能顺利 boot 起来注意这里说的 boot 不是操作系统开机而是指从你敲下启动命令到模型权重加载进显存、KV Cache 分配完成、HTTP 服务端口真正开始响应请求的这整个过程。它涵盖了驱动、CUDA、框架、显存、模型格式、并行策略这一整条链路任何一环掉链子你看到的都是起不来。我写这篇东西是想把这条链路上真正会卡人的地方一个个拆开讲清楚。适合谁看如果你已经在用 vLLM、SGLang、llama.cpp、Ollama、LM Studio 这类工具跑模型但经常遇到明明昨天还能跑今天就不行了或者别人能跑我这台就是不行的情况那这篇就是给你准备的。如果你刚配好 CUDA 环境准备上手也能从里面找到不少能直接抄的排查思路。核心关键词就那几个LLMs、vLLM、GPU、CUDA、RTX 4090但我会把它们放在真实的启动流程里讲而不是干巴巴地列参数。先说一个反直觉的结论大多数起不来的问题根本不在模型本身而在启动前的环境自检被你跳过了。很多人拿到一台机器第一反应是直接vllm serve或者ollama run跑不起来才开始查。正确的做法是反过来——先用一套固定的自检流程确认这台机器具备 boot 的资格再去谈具体模型。下面我就按这个思路从硬件和驱动这一层开始往上捋。2. 启动之前先确认这台机器有没有资格跑起来2.1 GPU 可见性nvidia-smi 之外你还要看什么所有人都会敲nvidia-smi但真正会看的人不多。这个命令输出的信息里对能不能 boot LLM最关键的其实不是显卡型号而是三样东西驱动版本、CUDA Version注意这是驱动支持的最高 CUDA 版本不是你装的 CUDA 版本、以及显存总量和当前占用。我见过太多人栽在驱动支持的 CUDA 版本和实际安装的 CUDA 版本这两个概念的混淆上。nvidia-smi右上角那个CUDA Version: 12.4意思是这块驱动最高能带 CUDA 12.4 的运行时不代表你系统里装的就是 12.4。如果你用 conda 或 pip 装了 PyTorch它自带一份 CUDA runtime这时候真正生效的是 PyTorch 编译时链接的那个版本。三者不一致就是各种CUDA error: no kernel image is available的根源。一个我常用的自检顺序是这样的# 1. 驱动和 GPU 是否正常 nvidia-smi # 2. 系统层面的 CUDA 编译器版本 nvcc --version # 3. PyTorch 实际链接的 CUDA 和 cuDNN python -c import torch; print(torch.version.cuda, torch.backends.cudnn.version()) # 4. PyTorch 能不能真正看到 GPU 并做一次运算 python -c import torch; atorch.randn(1000,1000).cuda(); print((aa).sum().item())第四步特别重要。很多人只验证torch.cuda.is_available()返回 True 就放心了但那只能说明驱动层面能看到卡不代表能真正跑 kernel。做一次实际的矩阵乘法才能确认 CUDA runtime、cuDNN、算力架构三者是匹配的。这一步过了才谈得上这台机器有资格 boot LLM。2.2 算力架构与精度支持RTX 4090 的甜蜜与陷阱拿 RTX 4090 举例它是 Ada Lovelace 架构算力 8.9支持 FP8、BF16、FP16、INT8、INT4 这些精度。听起来很美好但坑在于不是所有框架都针对 sm_89 编译好了 kernel。比如某些老版本的 vLLM 或者自己编译的 flash-attention如果编译时的TORCH_CUDA_ARCH_LIST没包含 8.9你启动时就会遇到那个经典的no kernel image is available for execution on the device。这个错误的本质是框架里预编译的 CUDA kernel 只覆盖了它编译时指定的算力架构你的卡不在列表里运行时找不到对应的二进制。解决办法有两个方向——要么装官方已经编译好覆盖 sm_89 的 wheel 包要么自己从源码编译并显式指定架构export TORCH_CUDA_ARCH_LIST8.9 pip install -e . --no-build-isolation我个人的经验是在 4090 上跑 vLLM优先用官方发布的 wheel别轻易自己编译。官方 wheel 对主流架构的覆盖已经很全自己编译除了耗时还容易因为 nvcc 版本、gcc 版本不匹配引入新的问题。只有当你要用某个官方还没支持的模型结构或者自定义 kernel 时才值得动手编译。还有一个容易被忽略的点4090 是消费级卡没有 NVLink多卡之间走 PCIe。这意味着如果你打算用 tensor parallel 跨两张 4090 跑一个大模型卡间通信带宽会成为瓶颈启动阶段可能没问题但推理吞吐会明显低于同价位的专业卡。判断能不能 boot的时候单卡显存够不够是一回事多卡并行效率是另一回事别混为一谈。2.3 显存预算模型权重之外你还得留多少这是能不能 boot最核心的算术题。很多人算显存只算模型权重结果启动到一半 OOM。正确的显存预算至少包含四块组成说明粗略估算模型权重参数量 × 每参数字节数7B FP16 ≈ 14GBKV Cache随并发和上下文长度线性增长取决于 max_model_len 和并发数激活与临时缓冲前向计算中间结果通常 1-3GB框架开销CUDA context、通信缓冲等1-2GB以 7B 模型 FP16 为例权重 14GB加上 KV Cache 和框架开销24GB 的 4090 跑单路推理是够的但如果你想开大 batch 或者长上下文就得靠gpu_memory_utilization这个参数来卡预算。vLLM 里这个参数默认 0.9意思是允许用 90% 的显存。如果你发现启动时 KV Cache 分配失败第一反应应该是调低这个值而不是怀疑模型坏了。提示gpu_memory_utilization调太低会导致 KV Cache 空间不足高并发时请求排队调太高则可能因为碎片和临时缓冲导致 OOM。0.85 到 0.92 之间是我在 4090 上比较常用的区间具体要看模型和上下文长度。3. 环境链路CUDA、驱动、框架三者版本对齐的实战3.1 版本矩阵为什么能跑和跑得稳是两回事CUDA、驱动、PyTorch、vLLM 这四个东西的版本关系是本地部署里最容易出玄学问题的地方。它们不是简单的越新越好而是存在一个兼容矩阵。举个真实的例子CUDA 12.8 刚出来的时候很多人的 vLLM 直接起不来因为当时 vLLM 依赖的 PyTorch 还没发布对应 CUDA 12.8 的版本你强行装就会遇到运行时找不到符号的问题。我一般会按这个顺序确定版本先看 GPU 驱动支持到哪个 CUDA 版本再选一个该范围内、PyTorch 官方有预编译 wheel 的 CUDA 版本最后选一个明确声明支持这个 PyTorch 版本的 vLLM 版本。三步锁定不要跳步。具体到操作查 PyTorch 支持哪些 CUDA 版本直接去它的官方安装页面看命令就行比如cu121、cu124这种后缀就是 CUDA 版本。vLLM 的每个 release note 里也会写明它测试过的 PyTorch 和 CUDA 组合。照着官方测试过的组合装能省掉你 80% 的排查时间这是我踩了无数次坑之后最想强调的一条。3.2 多版本 CUDA 共存别把系统搞脏开发机上经常需要同时维护好几个项目有的要 CUDA 11.8有的要 12.1。这时候最忌讳的就是反复卸载重装系统级 CUDA。正确做法是用 conda 或者容器隔离。用 conda 的话可以给每个环境装独立的cudatoolkitconda create -n vllm-env python3.11 conda activate vllm-env conda install cudatoolkit12.1 -c nvidia pip install vllm注意cudatoolkit装的是运行时库不是完整的 toolkit对跑推理来说通常够用。如果你需要 nvcc 编译那得装cuda-toolkit或者用系统级的。更干净的方式是用容器。把 CUDA、Python、vLLM 全部封在一个镜像里宿主机只需要装好驱动。这样无论你换多少个项目宿主机环境永远干净。判断能不能 boot的时候容器方案的好处是环境完全可复现——今天能跑明天换台机器照样能跑不会因为宿主机上某个库被升级了就崩掉。3.3 WSL2 场景能跑但有几个专属的坑现在不少人是在 Windows 上用 WSL2 跑 LLM。这条路是通的但有几个 WSL2 特有的坑必须知道。第一WSL2 里的 CUDA 版本不能超过 Windows 宿主机驱动支持的上限。你在 WSL 里装 CUDA 12.4但 Windows 驱动只支持到 12.2那就会出问题。所以先在 Windows 侧nvidia-smi确认驱动版本再决定 WSL 里装哪个 CUDA。第二WSL2 的显存是动态分配的默认上限是宿主机的 50% 左右。如果你有 24GB 显存WSL 里可能只能看到 12GB 左右模型自然装不下。解决办法是在 Windows 用户目录下建一个.wslconfig文件[wsl2] memory48GB swap8GB然后wsl --shutdown重启。注意这里的 memory 是系统内存显存的控制在较新版本里可以通过nvidia-smi在 WSL 内直接看到全部但早期版本确实有显存受限的问题具体要看你的 WSL 内核版本。第三WSL2 的文件系统跨盘访问很慢。模型权重如果放在 Windows 的 NTFS 盘上从 WSL 里加载会慢到让你怀疑人生。一定要把模型放在 WSL 自己的 ext4 文件系统里加载速度能差好几倍。这个坑我在第一次用 WSL 跑模型时踩得结结实实一个 14GB 的模型加载了快十分钟换到 ext4 之后不到一分钟。4. 框架启动阶段vLLM 从命令到端口响应的完整链路4.1 启动日志怎么读哪一行才是真正的分水岭vLLM 启动时会打一大堆日志很多人看到刷屏就慌了。其实你只需要盯几个关键节点。启动流程大致是解析参数 → 加载模型配置 → 下载或定位权重 → 初始化分布式环境 → 加载权重到显存 → 分配 KV Cache → 启动 API server。真正决定成败的是加载权重和分配 KV Cache这两步。如果卡在加载权重通常是权重文件损坏、格式不对、或者路径有问题。如果卡在 KV Cache 分配那就是显存不够日志里会有明确的out of memory或者No available memory for the cache blocks。看到后者直接调低gpu_memory_utilization或者减小max_model_len。有一个特别隐蔽的情况日志显示一切正常Uvicorn running on http://0.0.0.0:8000也打出来了但你发请求就是超时。这时候八成是模型还在后台做 CUDA graph 捕获或者 warmup端口虽然监听了但还没准备好处理请求。判断服务真正就绪的标志是日志里出现类似init engine完成、可以接受请求的提示而不是端口监听那一行。我一般会用一个简单的 curl 去探活直到返回正常响应为止。4.2 模型格式与量化GPTQ、AWQ、FP8 各自的启动脾气同一个模型用不同的量化格式启动行为完全不一样。FP16 是最省心的权重直接加载没有额外的反量化开销。GPTQ 和 AWQ 是 4bit 量化显存占用小很多但启动时需要加载量化配置、初始化对应的 kernel某些版本对量化格式的支持还有差异。以 AWQ 为例vLLM 对它的支持相对成熟但你要确保quantizationawq这个参数传对了否则框架会按 FP16 去加载然后因为权重形状对不上直接报错。FP8 是较新的格式对硬件有要求——需要算力 8.9 以上也就是 4090、H100 这类卡才支持。你在老卡上跑 FP8 模型启动阶段就会失败。我的建议是第一次跑某个模型先用 FP16 或 BF16 确认整条链路是通的再换量化版本。这样出问题的时候你能确定是量化引入的而不是环境本身的问题。这个控制变量的思路在排查启动问题时特别管用。4.3 并行策略单卡装不下时的 tensor parallel 启动细节当模型单卡装不下就要上 tensor parallel。vLLM 里用--tensor-parallel-size N指定。启动时它会初始化 NCCL 通信、把权重切分到各卡。这里最常见的启动失败是 NCCL 相关的错误比如NCCL error: unhandled system error或者卡在初始化不动。排查 NCCL 问题我一般按这个顺序先确认所有卡互相可见nvidia-smi topo -m看拓扑再确认 NCCL 版本和 CUDA 匹配然后可以设NCCL_DEBUGINFO看详细日志。如果是 PCIe 拓扑且没有 NVLink有时候需要显式指定网卡或者禁用某些通信路径export NCCL_P2P_DISABLE1 export NCCL_IB_DISABLE1这两个环境变量在消费级多卡场景下经常能救场。原理是禁用 P2P 和 InfiniBand 通信强制走更保守的路径。代价是性能会降但至少能启动起来。先让它 boot再谈优化这是我处理并行启动问题的一贯原则。5. 那些看起来能跑其实跑不动的隐性故障5.1 显存碎片为什么重启一下就好了有一种故障特别气人第一次启动失败 OOM你什么都没改重启一下进程居然起来了。这不是玄学是显存碎片。GPU 显存分配和释放不像内存那么灵活长时间运行或者反复启动失败后会留下无法利用的碎片。这时候即使总空闲显存够也分配不出一块连续的大空间。应对办法有两个。一是启动前确认没有残留进程占着显存nvidia-smi看到有僵尸进程就kill掉。二是如果碎片严重重启机器是最彻底的解法。生产环境里我会在启动脚本里加一段清理逻辑确保每次启动都是干净的显存状态。5.2 上下文长度与 KV Cache 的隐性膨胀max_model_len这个参数设大了KV Cache 会按最坏情况预留显存。比如你设了 32K 上下文但实际请求都只有 2K那预留的显存就白白浪费了。vLLM 用的是 PagedAttention理论上能缓解这个问题但启动时仍然会按配置预留一部分。我的做法是按实际业务需要设max_model_len不要盲目拉满。如果确实需要长上下文可以配合--enable-prefix-caching和合理的--max-num-seqs来控制。这几个参数之间是联动的调一个要想着另一个。5.3 驱动层的物理移除与掉卡热词里有个电脑经常提示 gpu 被物理移除这个在跑 LLM 时是真会遇到的。原因可能是供电不足、PCIe 接触不良、驱动 bug或者散热导致的降频保护。跑大模型时 GPU 长时间满载对供电和散热的要求比打游戏还高。如果你在启动或推理过程中遇到 GPU 突然消失先查供电电源功率够不够、线有没有插紧再查散热温度是不是撞墙了最后才怀疑驱动。软件层面能做的排查有限硬件问题得从硬件入手。这一点很多人会忽略一直在重装驱动其实问题在电源上。6. 一套可复用的能不能 boot自检清单把上面这些串起来我整理了一套自己每次上新模型前都会走一遍的流程。它不保证 100% 成功但能帮你快速定位问题出在哪一层。检查项命令/方法通过标准GPU 可见nvidia-smi列出目标卡无异常驱动-CUDA 匹配对比 nvidia-smi 和 nvcc实际 CUDA ≤ 驱动支持上限PyTorch 可用跑一次矩阵乘法无报错结果正确算力架构覆盖查框架编译架构包含你的卡算力显存预算权重KV缓冲小于可用显存模型格式确认量化参数与框架支持一致并行配置单卡先跑通再上 tensor parallel服务就绪curl 探活返回正常响应这套流程的价值在于分层定位。出问题的时候你能明确知道是硬件层、驱动层、框架层还是模型层的问题而不是笼统地跑不起来。我见过太多人在框架层反复折腾结果问题在驱动层也见过有人在驱动层重装半天其实是模型格式不对。注意这套清单里的每一步都要单独验证通过再进入下一步。跳步是排查效率的最大杀手因为一旦跳步后面出的问题你无法判断是哪一步引入的。最后分享一个我自己的习惯每次成功 boot 一个模型后把当时的环境版本、启动命令、关键参数记下来。下次换模型出问题先拿这份记录对比能瞬间排除掉一大半变量。这个习惯看起来笨但在我处理过的所有起不来的问题里它帮我省下的时间比任何调试技巧都多。毕竟LLM 能不能 boot很多时候不是能力问题是版本对齐和显存算术的问题——把这两件事做扎实剩下的就是耐心读日志了。
