企业官网建设流程全解析

6卡 serve qwen 失败，我太熟了。不管是 6 张 4090 跑量化大模型，还是 6 张专业卡想上全精度，第一波操作看着都挺像：CUDA_VISIBLE_DEVICES=0,1,2,3,4,5 python -m vllm.entrypoints.openai.api_server --model ...，然后回车，屏幕滚动几秒，接着要么直接抛 CUDA OOM，要么 NCCL 通信炸了，要么卡在 loading weights 死活不动。这篇文章就把我踩过的坑、花了一整晚排查的日志、试了 n 个版本的依赖组合全部摊开讲，从框架选型到 NCCL 调参，从显存计算到模型文件检查，按真实排查顺序写完，保证你下次遇到同样问题能半小时定位。

1. 六卡环境下的 serve 方案选型，为什么这里最容易翻车

1.1 六张卡是个“不上不下”的尴尬配置

先泼一盆冷水：6 卡在多卡推理里属于特别容易出问题的数量。原因很简单——Tensor Parallelism（张量并行，简称 TP）的切分逻辑通常要求 GPU 数量是 2 的幂次，比如 2、4、8。vLLM 自己也支持 TP=6，SGLang 也支持，但支持归支持，性能与稳定性远不如 4 卡或 8 卡那种规整的切分。

为什么 TP 偏向 2 的幂次？因为 transformer 里的多头注意力（MHA）和 MLP 层在切分时，按 head 数、hidden size 做等分最自然。qwen 系列的 head 数基本都是 8 的倍数，4 卡可以从容地把 32 个头切成每个卡 8 个头，但 6 卡就是 32/6=5.33，有些框架虽然能硬切，但会输出奇怪的 warning，甚至个别版本直接放弃治疗——报ValueError: num_heads must be divisible by tensor_parallel_size。所以第一件事：先确认你要跑的 qwen 版本能不能被 6 整除的 head 数支持。

6 卡更麻烦的一点在于硬件拓扑。很多人的 6 卡是 4 卡 + 2 卡混插，或 3 张双卡主板拼出来的，这时候不同 GPU 之间可能走不同的 PCIe switch，甚至有一张卡走芯片组、其他卡走 CPU 直连。一旦 NCCL 在初始化时发现 P2P 访问不可用，就会回退到 PCIe 拷贝，流量一大直接卡死。我自己就遇到过 6 卡里 4 张有 NVLink、2 张纯 PCIe 的诡异组合，serve 起来之后响应极不稳定，偶发 60 秒超时。

还有一个非常隐蔽的坑：nvidia-smi里看到的 GPU 编号，和 CUDA 实际枚举的编号不一定一致。你写--tensor-parallel-size 6，vLLM 会按 CUDA 顺序拿卡，但你的物理卡可能是 0 和 5 之间有信息差，实际分配的通信拓扑乱成一团。后面小节我专门讲怎么查这种问题。

所以选型阶段就要想清楚：6 卡到底要不要做 TP？如果你的模型是 qwen2.5-7B 或 qwen2.5-14B，单卡就能放下权重，这时候更好的方案是用 6 个独立实例做数据并行（DP），或者干脆只选 2 张显存最大的卡组 TP=2，其余卡跑别的任务。6 卡 serve qwen 失败，很多时候是因为把本该单卡/双卡能跑的事情强行 TP=6，反而把问题复杂化。

1.2 主流 serve 框架的多卡支持差异

我实际在 6 卡环境上用过 vLLM、SGLang、TGI、Ollama 这几套，它们的多卡策略差别很大，挑框架本身就是排查的一半工作。

vLLM 支持--tensor-parallel-size和--pipeline-parallel-size，6 卡可以 TP=6，也可以 TP=3 + PP=2（流水线并行）。但 vLLM 对模型切分的要求比较死，注意力头数不好切时直接拒绝。SGLang 后来居上，对 qwen 系支持很激进，--tp 6直接可用，而且自带 RadixAttention，多轮对话场景复用 KV Cache，吞吐比 vLLM 高不少，但它在纯 6 卡拓扑下对 NCCL 的敏感度也很高，我实测经常看到它把卡间通信量打满。

TGI（Text Generation Inference）是老牌的 Hugging Face 方案，--num-shard 6也能跑，但现在更新频率不如 vLLM/SGLang，新版本 qwen 的 chat template 支持偶尔滞后。Ollama 的OLLAMA_NUM_GPU只能控制“加载到 GPU 的层数”，6 卡不能用它做真正的张量并行，它更适合单卡或双卡场景。

选型建议很简单：追求稳定和可复现，用 vLLM；追求极端吞吐、且愿意接受调试成本，用 SGLang；只是想本地快速验证，Ollama 加载 GGUF 文件就行，但别指望它在 6 卡上有好表现。

2. 翻车现场：先学会读懂 serve 失败里的“隐藏信息”

2.1 启动期、加载期、推理期，失败原因完全不同

多卡 serve 失败的日志信息量极大，但大多数人只看最后 20 行，这是最大的误区。我建议把失败分为三个时间段：启动期、权重加载期、推理运行期。

启动期崩溃，通常出现在框架初始化 CUDA context 和 NCCL 通信组的时候，典型报错是CUDA error: invalid device ordinal、NCCL_ERR_UNPROCESSED、torch.distributed相关的 timeout。这类错误指向环境配置问题：卡没被正确识别、CUDA_VISIBLE_DEVICES 顺序写错、NCCL 初始化握手失败。

权重加载期崩溃，典型表现是加载到 50% 左右直接 OOM，或者报KeyError: 'model.embed_tokens.weight'、FileNotFoundError: model.safetensors。这指向两类问题：显存装不下、模型文件不完整。

推理运行期崩溃，最典型的是第一个请求进来后显存爆掉，或者批量请求时出现随机超时、NCCL 通信重置。这个问题通常和 KV Cache 预留大小、并发数设置、跨卡通信带宽有关。

所以不要上来就重装 CUDA，先看日志出现在哪个阶段。把报错日志往后翻到 200 行之前，找到第一次出现的红色 ERROR 或 CUDA error，那才是根因。后面跟的一大串 traceback 往往只是连锁反应。

2.2 显存计算：模型多大、卡多大、KV Cache 还要吃掉多少

“6卡 qwen”最常见的失败原因是显存不够。这里要算清楚三笔账：模型权重显存、KV Cache 显存、运行时开销。

模型权重显存计算公式是：参数量 × 每个参数字节数。以 BF16 精度为例，每个权重占 2 字节，qwen2.5-72B-Instruct 那么权重硬盘大小约 144GB（72 × 2），6 卡如果是 4090 24GB，总显存正好 144GB——听起来刚好能放下？错。因为你还要给 KV Cache、激活值、CUDA context 留空间。所以 72B BF16 在 6×24GB 上，只要启动就已逼近极限，第一个请求进来直接 OOM。现实点方案是量化到 INT4，比如 AWQ/GPTQ 4bit，权重降到大约 40GB，这时候 6 卡跑就没有太大压力。

KV Cache 的计算很多人忽视，它占用的显存远超想象。公式大致是：KV Cache 显存 = 2（K 和 V 两组）× 层数 × 每层 KV 维度 × 序列长度 × 最大并发数 × 2 字节（BF16）。以 qwen2.5-7B 为例，28 层，每个 token 的 KV 约 0.1MB 左右，如果你设置--max-model-len 32768且同时处理 8 个并发请求，KV Cache 可能吃掉几十 GB。这也是为什么明明模型才 15GB，8 卡 24GB 还是 OOM 的原因。

实操中我一般按“安全显存占比 85%”来反推参数：可用显存 = 单卡显存 × 卡数 × 0.85，先减掉权重大小，剩下的再除以（KV 单位占用 × 期望并发数），最后得到合理 max-model-len。计算过程可以写成一个 Python 小脚本，下面给个参考。

import torch num_gpus = 6 gpu_mem_per_card = 24 # GB，以4090为例 usable_ratio = 0.85 weights_gb = 144 # qwen2.5-72B BF16，量化后按实际改 kv_cache_per_token_per_request = 0.1 # MB，7B约0.1MB，14B约0.2MB，可实测 total_avail = num_gpus * gpu_mem_per_card * usable_ratio print(f"总可用显存: {total_avail:.1f}GB") left = total_avail - weights_gb max_concurrency = 8 per_token_gb = kv_cache_per_token_per_request / 1024 max_len = left / (per_token_gb * max_concurrency) print(f"建议 max-model-len 约: {int(max_len)} tokens")

这个脚本不算精确实测值，但能帮你快速判断方向：到底是“权重就放不下”还是“并发参数设计不合理”。我有一次 6 卡跑 qwen 失败，把 max-model-len 从 32768 降到 8192，立刻稳定，一次搞定。

2.3 版本矩阵：CUDA、PyTorch、vLLM 之间必须对上号

6 卡环境对版本兼容的要求比单卡苛刻得多。单卡上哪怕 CUDA 版本有点歪，顶多报个 warning，多卡时 NCCL、分布式初始化对 CUDA runtime 版本高度敏感，driver 和 runtime 不一致经常导致莫名的卡死或通信失败。

我踩过一个典型坑：显卡驱动版本（用nvidia-smi看的右上角 CUDA Version）是 12.4，但装了 PyTorch 的 CUDA 12.1 版本，vLLM 编译时用的是 12.1 的头文件，跑起来就报CUDA error: no kernel image is available for execution on the device，或者干脆在 NCCL 初始化时段错误。这不是玄学，是 driver 支持的 CUDA 版本和 runtime 库版本差了一级。

我的建议是三步确认：

1. nvidia-smi看驱动支持的 CUDA 版本，比如 12.4；
2. python -c "import torch; print(torch.version.cuda)"看 PyTorch 对应的 CUDA 版本，必须 ≤ driver 支持版本；
3. vllm --version看你装的 vLLM 版本，去官方文档或 GitHub README 里确认它对应的 torch 版本。

如果是新版 vLLM（比如 0.6.x 以上），很多对 qwen2.5 的架构支持补全了，但也对 Python 版本有要求，太老的 Python 3.8 装不上最新依赖。我实测最稳的组合是 Python 3.10 + PyTorch 2.4 + CUDA 12.4 + vLLM 0.6.3.post1，跑 qwen2.5 系没有任何问题。如果你用的是 SGLang，建议直接用官方 Docker 镜像，或者按官方 requirements 从头装，别拿 conda 乱混。

依赖版本冲突最恶心的一个报错是AttributeError: module 'torch' has no attribute 'compile'，这通常是你装的 torch 版本太老，但 vLLM 在不断调用新版 API。遇到这种问题，别搜半天，直接升级 torch 到匹配版本更省时间。

2.4 模型文件本身可能是最大的坑

很多人忽略这一点：serve 启动不了或启动后行为异常，模型权重文件没下全才是根因。

qwen 大模型在 Hugging Face 和 ModelScope 上的文件是分片存储的，比如 qwen2.5-72B 的 safetensors 有十几个分片，每个 5GB 左右。使用某些下载工具时，断点续传会留下大小不完整的文件，读取时也不报错，但加载到某个分片直接KeyError，或者报file not found / unexpected end-of-file。解决办法很简单：下完后对比 SHA256 或看配置文件里的safetensorsindex 文件内容，确认每个分片都在。

国内环境我更推荐直接用 ModelScope 下载，因为它的节点在国内，速度快且稳定。安装 ModelScope 后一行命令就能拉下模型：

pip install modelscope modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir ./qwen2.5-7b-instruct

如果你在 Hugging Face 下载，也可以用huggingface-cli带--resume-download参数续传。对 qwen 的 GGUF 版本（像热搜里提到 qwen2.5-7b-instruct-gguf），要注意：GGUF 是给 llama.cpp/Ollama 用的量化格式，不能直接拿去 vLLM 里加载，vLLM 对 GGUF 的支持很晚才加入，且只支持部分量化类型。同一份模型，用 vLLM 就下载 safetensors 版本，用 Ollama 就下载 GGUF 版本，别混。

3. 实操排查：从启动命令到 NCCL 通信的完整套路

3.1 三步定位法：查卡、查拓扑、逐卡测试

遇到 6 卡 serve 失败，我会按下面的顺序排查，基本 20 分钟内能找到方向：

第一步，用nvidia-smi确认 6 张卡都在、驱动正常、当前没有其他进程占显存。重点关注 Power 和 Volatile GPU-Util，如果某张卡 Utilization 异常高，说明之前有残留进程没清干净。

nvidia-smi

看到 6 张卡后，第二步查看卡间拓扑。这是 6 卡环境最容易出问题但最少人查的一步。

nvidia-smi topo -m

输出会显示每张卡之间的连接方式，可能看到NV#（NVLink）、PIX（同一个 PCIe switch）、PHB（PCIe Host Bridge）、SYS（走系统总线）。如果出现SYS，说明这两张卡要经过 CPU 甚至芯片组互相通信，NCCL 的 P2P 在这条路径上可能非常慢或者直接失败。看到 SYS 连接时，就该考虑调整 CUDA_VISIBLE_DEVICES，尽量把通信频繁的卡放在同一个 switch 里，或者干脆降低 TP 并行度。

第三步，逐卡做一个最小化测试，确认每张卡都能正常张量计算和通信。先用 torch 检查单卡：

import torch for i in range(torch.cuda.device_count()): print(i, torch.cuda.get_device_name(i)) a = torch.randn(1000, 1000, device=f"cuda:{i}") print(a.sum())

然后测试分布式通信：

import torch.distributed as dist import os os.environ["MASTER_ADDR"] = "127.0.0.1" os.environ["MASTER_PORT"] = "29500" os.environ["WORLD_SIZE"] = "6" os.environ["RANK"] = "0" dist.init_process_group(backend="nccl") t = torch.tensor([1.0]).cuda() dist.all_reduce(t) print(t)

这个测试如果报 NCCL 超时或段错误，那问题基本锁定在多卡通信层，而不是模型层。先证明 6 张卡拉起来能互通，再谈 serve 模型，这是我从无数次失败中总结的第一原则。

3.2 vLLM 启动命令的正确打开方式

假设你已经排查了基础环境，现在给出一个稳健的 vLLM 启动模板。以 qwen2.5-14B-Instruct 在 6×24GB 环境为例：

CUDA_VISIBLE_DEVICES=0,1,2,3,4,5 \ python -m vllm.entrypoints.openai.api_server \ --model /path/to/qwen2.5-14b-instruct \ --tensor-parallel-size 6 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 32 \ --port 8000

注意几个关键参数的选择逻辑：

--tensor-parallel-size 6让 vLLM 用满 6 卡作为张量并行。如果 head 数无法整除，换成 TP=3 + PP=2 也可以，但 PP（流水线并行）会引入额外的调度开销，吞吐略降。

--max-model-len 8192很重要。按前面的显存计算，14B 在 6 卡上其实很宽裕（权重约 28GB，总显存 144GB×0.85=122.4GB），但如果你把 max-model-len 拉到 32768，且并发较高，KV Cache 还是可能吃几十 GB。保守先设 8192，等服务起来再逐步往上调。

--gpu-memory-utilization 0.85告诉 vLLM 每张卡最多用 85% 显存，给 CUDA context 和其他进程留 15% 余量。这个值我实测不要超过 0.92，尤其是多卡环境，过高的利用率会让 NCCL 通信缓冲区分配失败。

--max-num-seqs 32控制并发序列数。并发数越高，KV Cache 占用越大，吞吐也越高，但要跟 max-model-len 配合。如果并发高且长序列多，很容易触发out of memory，此时调低这个参数比调低 max-model-len 更能保住吞吐。

启动后观察日志，如果出现Starting vLLM server...并且最后输出Uvicorn running on http://0.0.0.0:8000，说明服务已经起来了。此时先用 curl 做个最小请求验证：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "/path/to/qwen2.5-14b-instruct", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 50 }'

这个最小请求能回来，再压测；回不来，从日志和错误码继续排查。

3.3 NCCL 通信失败：环境变量调整和拓扑限制

NCCL 是 6 卡 serve 失败里绕不开的话题。典型的报错有：

• NCCL Error: 2 (unhandled host error)一般指线程或 socket 连接问题；
• NCCL error in process...CUDA error: device not found指某个 rank 拿到的 GPU 编号无效；
• NCCL: Timeout多半是跨节点或跨 switch 通信延迟太高；
• 更隐蔽的是不报错，但每次推理请求后等待几秒，显存和 GPU 利用率都很低，这种情况经常是 NCCL 从 P2P 回退到了 PCIe 传输，带宽断崖式下跌。

对于 6 卡环境，先检查卡间拓扑（上一步的nvidia-smi topo -m）。如果发现有些卡之间是SYS，NCCL 默认的 P2P 通信可能不可用，需要环境变量强制降级：

export NCCL_P2P_LEVEL=LOC export NCCL_P2P_DISABLE=1

NCCL_P2P_LEVEL=LOC表示只在本地节点启用 P2P。NCCL_P2P_DISABLE=1是完全禁用 P2P，走共享内存或 PCIe DMA。禁用 P2P 后通信带宽会下降，但稳定性大幅提升。如果你看到CUDA error: peer access is not supported，直接禁用 P2P 就是最有效的解法。

另一个常用变量是NCCL_IB_DISABLE=1，在无 InfiniBand 的纯 PCIe 机器上必须设置，否则 NCCL 会尝试初始化 IB 从而超时。还有NCCL_SOCKET_IFNAME，多网卡机器上不指定会导致跨节点通信选错网卡，虽然单机 6 卡影响不大，但偶尔也会踩坑。

export NCCL_P2P_DISABLE=1 export NCCL_IB_DISABLE=1 export NCCL_SOCKET_IFNAME=eth0

还有一个细节经常被人忽视：CUDA_VISIBLE_DEVICES的排列顺序会影响 NCCL 的 rank 分配，也就影响通信路径。比如你物理卡 0 和 5 之间是 SYS 路径，而 CUDA_VISIBLE_DEVICES=0,5,1,2,3,4，TP 的前两个 rank 正好卡在最差的通信路径上，性能慢得离谱。这时调整可见卡顺序让通信关系好的卡相邻，能明显改善。这个细节属于经验值，必须实测对比才能发现。

3.4 换框架救场：SGLang 和 TGI 的备选方案

如果 vLLM 在 6 卡上因为 head 数切分或拓扑限制反复失败，我的转法是立刻换 SGLang。SGLang 对 qwen 家族的兼容性真的可以，而且它对 TP 的支持不像 vLLM 那样对 head 整除这么敏感。启动命令类似：

CUDA_VISIBLE_DEVICES=0,1,2,3,4,5 \ python -m sglang.launch_server \ --model-path /path/to/qwen2.5-14b-instruct \ --tp 6 \ --mem-fraction-static 0.85 \ --max-total-tokens 16384 \ --port 8000

注意 SGLang 的--max-total-tokens是总 token 上限，不同于 vLLM 的--max-model-len，它代表所有请求加起来最多能占多少 token 的 KV cache。这个参数设太大会在并发高时报显存不足，设太小则长度受限。我一般先按显存余量的 70% 估算，再根据实际压测回落。

TGI 是一个更保守的选择，更新慢但胜在稳定。启动时用--num-shard 6分布在 6 卡上，它对 NCCL 的封装比 vLLM 更简单，但 qwen 新版本的支持可能滞后，比如 qwen2.5 的 chat template 如果没更新，生成的回答风格会跑偏。这个方案适合“不能再折腾了，必须立刻出活”的时刻。

其实换框架的核心逻辑不是“哪个好”，而是“哪个在当前环境里能跑”。我做过的判断顺序是：vLLM 优先，因为它文档最全；vLLM 有不能绕过的切分硬伤时，SGLang；SGLang 还不稳时，TGI；TGI 都救不了，就回到单卡 + GGUF 量化，把 6 卡用 DP 实例拆分出去。

4. 常见错误代码速查表与实战复盘

4.1 错误代码与解决方向速查表

下面这张表是我在 6 卡环境下实际收集的高频报错，可以直接用来对照你的日志。

这张表不能解决所有问题，但它能帮你快速归类。我把它的使用思路说清楚：先定位报错属于哪一行，对应到表格里的“高频阶段”，再从“解决方向”那一列挑优先级最高的动作去做。80% 的情况，解决方向里的第一条就是有效的。

4.2 实战案例一：6 张 4090 跑 qwen2.5-72B-AWQ，一启动就 OOM

这个案例来自一次线上服务配置。环境是 6×4090 24GB，模型 qwen2.5-72B-Instruct-AWQ（4bit 量化，权重大约 40GB）。按说 144GB 显存跑 40GB 权重绰绰有余，但启动后第一个请求就 OOM。

排查过程是这样的：先看启动日志，发现 vLLM 在初始化 KV cache pool 时打印了GPU KV cache size: 90.39GB——问题找到了。我设了--max-model-len 32768 --max-num-seqs 64，vLLM 按照 64 并发 × 32768 长度把 KV cache 预分配了 90GB，加上权重 40GB，剩余的 CUDA context 和其他开销已经超过 144GB。

解决动作：

--max-model-len 16384 \ --max-num-seqs 32 \ --gpu-memory-utilization 0.9

把 KV cache 预分配降到约 45GB，总占用控制在 100GB 以内，服务稳定跑了一下午。这里有个经验：vLLM 的 KV cache 是在启动时就一次性预分配的，不是按需增长，所以参数必须按照峰值场景预留，而不是平均场景。多卡环境下尤其严重，单卡 OOM 还可以靠系统 swap 兜底，多卡 OOM 直接让整个集群的通信组down掉。

如果想准确估算 KV cache 大小，可以在启动时加--verbose标志，日志里会打印每层的 KV cache 分配明细。不要依赖直觉猜，数字永远比感觉可靠。

4.3 实战案例二：6 卡 PCIe 混插，NCCL 初始化一直卡死

另一个更头疼的场景：台式机扩展坞混插 4 张 3090 + 2 张 4090，都走 PCIe，且没有 NVLink。启动 vLLM 时卡在 NCCL 初始化，每分钟滚一条NCCL: Timeout，最终失败。

这个问题的核心在拓扑。nvidia-smi topo -m输出显示卡 0-1 之间是PIX，卡 2-3 之间是PIX，但 4、5 两张卡与前面四张卡之间全部是PHB+SYS。NCCL 初始化时会对所有卡两两建连，一遇到跨 SYS 的连接就开始疯狂等待。

我当时的处理思路是：既然 6 张卡没法组成一个高效的 TP 组，那就拆成两个 TP=3 的实例，避免跨 SYS 通信。于是启动两个 vLLM 服务，分别在 0-2 和 3-5 之间做 TP=3，对外用 nginx 做负载均衡。实际效果非常好，单个实例的吞吐略低于理想值，但服务整体可用性和稳定性直接远超 6 卡硬 TP。

另外一个纯环境层面的解法是把 UEFI/BIOS 里打开“Above 4G Decoding”和“Resizable BAR”，同时在驱动层确认 PCIe Gen4 链路速率。混插场景下很多 PCIe switch 没跑在最高速率，通信带宽减半，NCCL 握手时间翻倍。这些不是软件能完全修复的，但升级 BIOS 设置确实能减少超时概率。

4.4 排查时容易忽略的环境细节与避坑清单

• 进程残留是 6 卡场景的最大隐形杀手。上一次 serve 进程没杀干净，新进程启动时 CUDA 可以拿到卡，但显存早就被占满；旧进程持有的 NCCL 通信组也会和新进程冲突。遇到 OOM 前先执行nvidia-smi看Processes表，用kill -9 PID清掉残留进程。

• 统一容器环境比 bare-metal 更可控。裸机装的 conda 环境通常存在大量历史版本污染，vLLM 的 C++ extension 一旦和某个旧 CUDA 库冲突，报错极模糊。我后来直接用 NVIDIA PyTorch 官方镜像，一次性解决依赖问题：

docker run --rm --gpus all --ipc=host \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/qwen2.5-14b-instruct \ --tensor-parallel-size 6 \ --max-model-len 8192

容器方案另一个好处是隔离，六个 worker 的 NCCL 通信组不容易互相干扰。

• IP 地址和网卡选择也影响 NCCL。单机 6 卡看起来不涉及网络，但 NCCL 初始化时仍会绑定 socket 网卡。如果你的机器有 docker0、eth0、ens 多个网卡，NCCL 可能选错默认网卡导致握手超时。统一设置NCCL_SOCKET_IFNAME能规避大部分不确定性。

• Hugging Face 与 ModelScope 的文件最好按 index.json 校验后再启动。qwen 系列模型通常有model.safetensors.index.json，里面列了所有分片文件名的映射关系，加载前先对照目录确认文件完整。这个检查成本极低，能避免 99% 的加载期KeyError。

• vLLM 新版对 qwen2.5 的模板支持有变化。老版本可能在 serve 时输出Warning: chat template is not set，导致回答没有系统提示词、格式混乱。如果你在跑 qwen2.5 系，升到 v0.6.3 之后的版本基本能自动适配。

5. 几条越早明白越省事的体感经验

说到这，我最后分享几条个人主义色彩比较重的经验，不一定写在官方文档里，但都是被 6 卡环境毒打过之后换来的教训。

第一，先小后大是排查铁律。6 卡 serve 任何大模型之前，先用 qwen2.5-0.5B 或 1.5B 跑一遍 TP=6，验证通信和框架是否正常。小模型启动只要 10 秒，任何维度的问题都能快速暴露；大模型启动动不动加载几分钟，排障时间成本太高。我绝大多数 6 卡问题，都是先拿小模型复现后定位的。

第二，日志保存是第一生产力。不管用nohup还是tmux还是docker logs，一定要把完整启动日志留底。多卡问题往往不是一次就能修复的，你改一个参数后需要和前一轮日志对比，找出变化点和残留报错。没有日志的排障就是瞎猫碰死耗子。

第三，参数的优先级高于重装。遇到 serve 失败时，按“版本匹配 → 通信拓扑 → 显存计算 → 模型文件 → 并发参数”的顺序逐一检查，80% 的问题不需要重装任何东西。重装 CUDA、重装驱动是最后的选项，因为它会把环境搅得更混，反而丢失排查线索。

6 卡 serve qwen 是一个“看起来简单、实则坑多”的事。只要把框架选型、显存预留、NCCL 拓扑、模型文件这四关都走一遍，绝大多数失败都能被定性和解决。如果你按这篇文章的步骤排查完还是不行，把你日志里第一次出现的 ERROR 贴给任何一个论坛，回复速度都会快得多——因为你现在问的是一个已经被正确归类的问题了。