硬件环境
- CPU: i7-9700K
- 内存: DDR4 32G 2666
- 主板: MSI Z390 ACE
- 亮机卡: GTX 1060 6G（这卡有问题，有时候点不亮，被我拆了随手换了一张垃圾亮机卡不记得是啥了，好像是 GT 710？）
- 计算卡: Tesla V100-SXM2-32GB × 2 (NVLink 互联)
- 扩展卡: PLX8749 免拆分 PCIe 卡（MSI 的 Z390，哪怕是这么高的定位竟然还不支持拆分，还要我买拆分卡，差评！）
软件环境
- 系统: Ubuntu 24.04 Desktop（考虑到别的一些需求，选择了 Desktop）
- 驱动: 570 驱动（对应可以支持到 CUDA 12.8，至于 580 貌似不太兼容）
- 工具: GPU Burn 烤机 nvtop 监测GPU dcgmi dmon -e 449,1011,1012 监测NVLink流量
- 容器: Docker，NVIDIA Container Toolkit
- 面板: 1Panel（1Panel 重度依赖了属于是）
首先你要知道
抛开vLLM不谈，使用Llama.cpp跑Qwen3-Next-80B-A3B-Thinking-Q4_K_XL，以我这个配置峰值可以到65token/s。
问题
- V100不支持 Flash-Attention
- V100计算能力,也就是SM为7.0 不支持AWQ，不支持FP8，BF16，FP4，甚至INT4都不支持，不支持稀疏加速，不支持各种乱七八糟的东西
- V100这也不支持那也不支持，烦的要死。
- 我讨厌V100的每一点，包括价格，我只是没得选，每一个买V100的人都是迫不得已。冯的电子垃圾还能卖好几千。
- So Nvidia fuxk you！
实战
- vLLM: v0.15.0（我先用的 0.14.1，也是可以的，但是他在我折腾的当天更新了 0.15.0 然后我第二天晚上才发现）
- 模型: jart25/Qwen3-Next-80B-A3B-Thinking-Int4-GPTQ
- 有 bug 的 GPTQ 内核，有待优化
- 使用的 TRITON_ATTN
- 单请求 11 token/s，GPU 占用率不高
- 在 VLLM 开始监听之后发个请求，这个请求会需要很久，大概 240 秒开外（报了四行 60 秒的日志）属于正常现象。
我严重怀疑他这个根本不是张量并行。我怀疑他其实是流水线并行，两块显卡的负载曲线差距有点大。
CLI 参数
这样好看一点
/root/other/Qwen3-Next-80B-A3B-Thinking-Int4-GPTQ \
--chat-template /root/other/Qwen3-Next-80B-A3B-Thinking-Int4-GPTQ/chat_template.jinja \
--tensor-parallel-size 2 \ #张量并行
--dtype=half \ #强制指定使用fp16，试图规避torch.compile在进行图编译优化时的计算能力检查，失败
--enforce-eager \ #禁用图优化
--max-num-seqs 5 \ #限制并发为5
--max-model-len 128000 \ #限制上下文上限为128k
--served-model-name qwen3-next \ #设置模型id
--tool-call-parser hermes \ #设置工具回调，默认都是hermes风格，少数模型需要看vllm文档
--enable-auto-tool-choice \ #打开自动工具选择，一般要打开这个才能用工具
--reasoning-parser deepseek_r1 \ #思考格式模板，一般都用deepseek_r1，少数模型需要看vllm文档
--gpu-memory-utilization 0.85 #限制显存占用到85%，理论上限制到99%都行，但我实测会超过85%，甚至默认(90%)会报OOM整理到一行
/root/other/Qwen3-Next-80B-A3B-Thinking-Int4-GPTQ --chat-template /root/other/Qwen3-Next-80B-A3B-Thinking-Int4-GPTQ/chat_template.jinja --tensor-parallel-size 2 --dtype=half --enforce-eager --max-num-seqs 5 --max-model-len 128000 --served-model-name qwen3-next --tool-call-parser hermes --enable-auto-tool-choice --reasoning-parser deepseek_r1 --gpu-memory-utilization 0.85--enforce-eager 会禁用CUDA图优化，于是会出现严重的CPU瓶颈，拖慢显卡（应该是这个原因）
环境变量
不是很重要的环境变量
VLLM_WORKER_MULTIPROC_METHOD=spawn
PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
VLLM_USE_TRITON_FLASH_ATTN=0此外，我还试了很多乱七八糟的cli参数，一个有用的都没。
实际硬件占用
CPU，两个TP所在的核都占满了，明显喂不饱GPU啊，TP核心看起来是单核战神，只不过有俩罢了。
RAM，内存消耗太少了忽略不计。（几个g？反正不是什么值得留意的东西）
GPU，占用大概在30%以下，两个gpu负载很奇怪，交替负载的感觉，都很低，偶尔占满某一张显卡也不是解码阶段。
显存，几乎就是吃满了。（是的，限制了--gpu-memory-utilization 0.85它也会吃满，我不明白）
总而言之
至此，已经折腾三四天了，最高也就11.7 toekn/s，这个速度，只能说不一定追的上人的阅读速度，何况思考模型。
Llama.cpp的下限真的太高了，比vLLM的下限高出不知道多少。
我猜大多数V100踩坑教程戛然而止就是因为这个，为什么要折腾vLLM呢？要跟各种量化方案打交道，然后上来就是各种报错，紧接着就是跑不动，巨慢无比，终于调的差不多了还会稳定的假死，最后还要处理工具回调，工具自动选择，思考模板。
Llama.cpp相比起来真是开箱即用，何况我这种低并发情景，孰优孰劣，显而易见。
（本文章只基于你要用v100这款昂贵电子垃圾的情况，vLLM仍然是吞吐量最大的推理框架）
（我不推荐任何人购买v100，这破玩意一看就没前途！）