跳到主要内容

vLLM 在 Tesla V100 上能跑到哪个版本？—— 3090 + V100 混合机器的安装复盘

· 阅读需 20 分钟
sumshare
sumshare
coder

这台机器上插着 1 张 RTX 3090（cc 8.6）和 2 张 Tesla V100（cc 7.0）。原以为"装个 vLLM、起个 xinference"是半天的事，实际从 05-02 折腾到 05-05，最后拆成两套互不干扰的 conda 环境才稳下来。

写这篇时我把当时的结论重新核了一遍，其中一条被实测推翻了：无论是当时的记录、还是社区里常见的说法，都是"新版 vLLM 在 V100 上根本起不来"。今天在同一台机器、同一张卡上实测：0.19.1 能起，也能出字——只是 V100 上的默认后端从 xformers 换成了 TRITON_ATTN，比 0.10.0 慢约 25%。所以这篇分两半：这台机器上真实发生了什么，以及"V100 到底支持到哪一版"这个问题的代码级答案。

三条结论先摆出来：

  1. V100 跑不了新版 vLLM，卡点不在编译产物，而在 Python 侧的 attention backend 门槛。 0.19.1 的 _C.abi3.so 里明明编进去了 sm_70，照样被 Python 层的 supports_compute_capability() 挡在候选之外——排查时别去 .so 的架构列表上找。
  2. V100 的可用区间不是"只有 0.10.0"，而是 0.10.0 ~ 0.19.x。 0.10.0 会自动降级到 xformers（最省心，也实测最快）；0.19.x 会自动降级到 TRITON_ATTN（能跑，慢一些）。真正断掉这条路的是 0.20.0 起官方构建删掉了 sm_70，有 PR diff 为证。
  3. 最阴的坑跟 V100 无关：pip install "xinference[all]" 会静默把 transformers 升到 5.x，把刚装好的 vLLM 0.10.0 弄坏——不报冲突、pip check 干净、vllm --version 通过，直到真正推理才炸。

0. 一张表看全​

最终活下来的两套环境（另有 vllmv100、vllm 两个残留环境，是试错产物，已弃用）：

环境面向vLLMtorchattention 后端状态
xinRTX 3090（cc 8.6）0.19.12.10.0+cu126原生（FA2 / flashinfer）✅ 日常在用
xinv100Tesla V100（cc 7.0）0.10.0+cu1262.7.1+cu126xformers 0.0.31（自动回退）✅ 已实测跑通

六个坑，按"最坑"排序：

#现象根因结论类型
FAttributeError: Qwen2Tokenizer has no attribute all_special_tokens_extendedxinference[all] 把 transformers 顶到 5.x，vLLM 0.10.0 只兼容 4.x实测
C新版 vLLM 在 V100 上后端选择失败xformers 后端已被上游移除；FA2 要 cc ≥ 8.0、flashinfer 要 7.5~12.1，V100(7.0) 全被拒读代码 + 实测
Blibtorch_cuda.so: undefined symbol: ncclCommWindowDeregistertorch 由新版 NCCL 编译，环境里 nvidia-nccl-cu12 偏旧；且 cu11/cu12 包混装实测
A手动装的 torch 被顶掉pip install "xinference[all]" 会把 torch 作为依赖重装一遍实测
EvLLM 0.10.0 装完 pip check 一路报缺该版本 wheel 的依赖声明不全实测
Dtorchvision 与 torch 版本对不上torch 2.10.0 需要 torchvision 0.25.0，不是 0.15.x实测

下面逐条展开，重点是 C 和 F——它们分别对应"新版为什么起不来"和"装好了为什么还是坏的"。

1. 机器基线​

GPU 0: NVIDIA GeForce RTX 3090        24576 MiB   cc 8.6
GPU 1: Tesla V100-SXM2-16GB           16384 MiB   cc 7.0
GPU 2: Tesla V100-SXM2-16GB           16384 MiB   cc 7.0

驱动：NVIDIA-SMI 580.159.03（CUDA Version 13.0）
本地 CUDA Toolkit：release 12.9, V12.9.41  (/usr/local/cuda-12.9)
conda：/home/sumshare/anaconda3

系统原先装的是 cuda_12.2.0_535.54.03 的驱动 + CUDA，安装过程中升到了 580.159.03 / CUDA 12.9。

上表是 2026-09-24 用 nvidia-smi / nvcc --version 现场复读的，不是当时的截图。

2. 三天时间线（压缩版）​

时间操作结果
05-02 15:35conda create -n Xinference python=3.10.14建第一个环境
05-02 15:38 起反复 pip install "xinference[all]"torch 被顶掉（问题 A）
05-02 19:29启动 xinference-local报 NCCL 符号错误（问题 B）
05-02 23:53升级 NVIDIA 驱动到 580.159.03 → reboot驱动/内核对齐
05-03 00:02装 cuda_12.9.0_575.51.03nvcc 升到 12.9
05-03 08:52conda create -n xin3090 用环境
05-03 09:13装 torch 2.10.0+cu126（torchvision 试到 0.25.0）问题 D 解决
05-03 09:56conda create -n vllmv100 + pip install vllm==0.10.0V100 试验环境
05-03 13:13回 xin 装 vllm==0.19.1认为在 V100 上不可用 → 见第 4 节
05-03 13:20conda create -n xinv100 + 装 vllm==0.10.0放弃 0.19.1、另起炉灶的那一刻
05-03 15:13 / 15:14pip install "xinference[all]"（最后一轮）埋下问题 F
05-03 15:23conda env remove -n Xinference删掉废弃环境
05-05 22:28xinference-local --host 0.0.0.0 --port 8890用 xin 起服务，稳定
09-24 23:24在 GPU 1（V100） 上跑 xinv100 冒烟测试✅ 通过（详见第 5 节）

时间点取自本机 ~/.zsh_history（带时间戳），不是我事后回忆。

3. 问题 A / B：torch 被反复顶掉，以及 NCCL 符号错误​

问题 A 是贯穿全程的主线：pip install "xinference[all]" 会把 torch 当依赖重新拉一遍。手动装好的 torch 版本白装，环境里开始出现"一半新一半旧"的状态。

问题 B 是它的直接后果之一：

ImportError: /home/sumshare/anaconda3/envs/Xinference/lib/python3.10/site-packages/torch/lib/libtorch_cuda.so:
undefined symbol: ncclCommWindowDeregister

当时的判断是"torch 由新版 NCCL 编译，而环境里的 nvidia-nccl-cu12 偏旧，动态链接时找不到符号"。这条判断今天可以在两个已验证环境里直接对上——用 nm -D --defined-only 数这个符号：

环境nvidia-nccl-cu12libnccl.so.2 里 ncclCommWindowDeregister
xinv1002.26.20 处
xin2.27.52 处（定义）

也就是说这个符号在 2.26.2 里没有、在 2.27.5 里有，与"2.27 引入"的说法对得上（没有逐个小版本核对）。当时的解法是两件事一起做：把 nvidia-* 全部统一到 cu12 一条线（xin/xinv100 现在都是 cu11 包 0 个），并把 nvidia-nccl-cu12 提到 2.27+。

教训：同一个环境里混装 nvidia-*-cu11 和 nvidia-*-cu12，是这类符号错误的温床。装上没问题，import 才炸。

4. 核心问题 C：V100 上到底哪个 attention 后端能接活​

先说清楚证据状态：当时为什么判定 0.19.1 不行，已经无据可查——记录里只留下"13:17 装了、13:20 就另起环境"这个时间差，没有 traceback。所以下面给的是代码层面的解释 + 今天的实机复测，不是当时的报错原文。

4.1 门槛在 Python 侧，不在编译产物​

vLLM 0.19.1（xin）里，每个 attention 后端都声明自己支持的 compute capability，逐字如下（源码位置见括号）：

# vllm/v1/attention/backends/flash_attn.py:179
def supports_compute_capability(cls, capability: DeviceCapability) -> bool:
    return capability >= DeviceCapability(8, 0)          # V100 (7,0) 直接被拒

# vllm/v1/attention/backends/flashinfer.py:393
def supports_compute_capability(cls, capability: DeviceCapability) -> bool:
    return capability >= DeviceCapability(7, 5) and capability <= DeviceCapability(12, 1)

# vllm/v1/attention/backends/triton_attn.py:353
def supports_compute_capability(cls, capability: DeviceCapability) -> bool:
    return True                                            # ← 唯一对 V100 放行的

后端选择器会按这些返回值筛掉不支持的候选（vllm/v1/attention/backend.py:292，invalid_reasons.append("compute capability not supported")）。所以在 V100 上，FA2 和 flashinfer 出局，剩下的候选是 TRITON_ATTN 和 FLEX_ATTENTION——这句话是后面实机验证的关键。

一个容易误判的点：0.19.1 的 _C.abi3.so 里其实编了 sm_70。

$ cuobjdump --list-elf .../xin/.../vllm/_C.abi3.so | grep -oE 'sm_[0-9]+' | sort -u
sm_52 sm_70 sm_75 sm_80 sm_89 sm_90 sm_100 sm_120

（2026-09-24 现场复跑，cuobjdump 用 /usr/local/cuda-12.9/bin/cuobjdump。）

所以卡住的不是"没编译进去"，而是 Python 侧的 backend 门槛。下次排查别再往 .so 的架构列表上找。

4.2 xformers 去哪了：官方原文​

V100 在旧版 vLLM 上能用，靠的是 xformers 这条回退路径。它被移除有明确的官方记录（均于 2026-09-24 用 curl -sS -L 抓 GitHub API，原文留档在 source/vllm-v100-lab/）：

【官方原文】"We will no longer support V100 or older GPUs, following PyTorch (pytorch/pytorch#147607)" —— xformers v0.0.31 release notes（发布于 2025-06-25）

【官方原文】"This PR completely removes the dependency of xformers library and should be only merged after v0.11.1 release." —— vLLM PR #29262 [Core] Deprecate xformers（合并于 2025-11-24）

有一条常见的引用需要更正：网上常把"移除 xformers 后端"记成 PR #22777。查证下来，PR #22777 [V0 Deprecation] Remove V0 xFormers attention backend 是 closed、未合并（2025-09-23 关闭）；真正落地的是 #29262。

本机也能验证到这一步——xin（0.19.1）里已经搜不到 XFORMERS 后端，只剩一句"已移除"的报错：

# vllm/config/multimodal.py:214
raise ValueError(
    "Attention backend 'XFORMERS' has been removed (See PR #29262 for "
    "details). Please select a supported attention backend."
)

而 xinv100（0.10.0）里 vllm/attention/backends/xformers.py 还在，import 的是真的 xformers：

# vllm/attention/backends/xformers.py
from xformers import ops as xops

4.3 0.10.0 为什么开箱即用：两条自动降级​

0.10.0 是 vLLM 还有 V0 引擎的年代，它在 V100 上会自动做两级降级：

# vllm/platforms/cuda.py:343
target_backend = _Backend.FLASH_ATTN
if not cls.has_device_capability(80):
    # Volta and Turing NVIDIA GPUs.
    logger.info("Cannot use FlashAttention-2 backend for Volta and Turing GPUs.")
    target_backend = _Backend.XFORMERS          # ← 自动退回 xformers

另一级是引擎级：V1 引擎不支持 cc 7.0 时直接回退 V0（vllm/engine/arg_utils.py:1685 那段 _raise_or_fallback）。两级的引擎规模差异，用文件行数就能看出来：

环境vLLMvllm/engine/llm_engine.py含义
xinv1000.10.02061 行（真正的 V0 引擎实现）V0 还在，能退
xin0.19.17 行，内容只有 LLMEngine = V1LLMEngine 一句别名V0 已移除，没得退

4.4 实测：0.19.1 在 V100 上其实能跑​

这是写这篇文章时才补的实验。用 xin（vLLM 0.19.1）在 GPU 1（V100） 上加载 Qwen2.5-0.5B-Instruct，dtype=float16、enforce_eager=True、不指定任何后端：

(EngineCore) ERROR 09-24 23:33:00 [fa_utils.py:145] Cannot use FA version 2 is not supported due to
             FA2 is only supported on devices with compute capability >= 8
(EngineCore) INFO  09-24 23:33:00 [cuda.py:334] Using TRITON_ATTN attention backend out of potential
             backends: ['TRITON_ATTN', 'FLEX_ATTENTION'].

模型加载、KV cache 分配（408,560 tokens）、生成全部正常。同一张卡上两套环境的粗测对比（同一模型、fp16、贪心、128 tokens、enforce_eager、gpu_memory_utilization=0.35，单次运行，不是基准测试）：

环境vLLM自动选中的后端128 tokens 用时吞吐
xinv1000.10.0XFormers4.24 s30.2 tok/s
xin0.19.1TRITON_ATTN5.54 s23.1 tok/s

两者的输出逐字相同（同样的贪心 prompt），差别只在速度：0.19.1 + TRITON_ATTN 比 0.10.0 + xformers 慢了约 25%。

那么当时为什么会得出"起不来"的结论？这是我的推断，无法证实：0.19.1 把"FA2 不支持 Volta"这件事记在了 ERROR 级别（上面那条 fa_utils.py:145），而 0.10.0 里同一件事是 INFO：

INFO [cuda.py:346] Cannot use FlashAttention-2 backend for Volta and Turing GPUs.

一条看起来致命的 ERROR 之后其实还在正常加载 —— 加上当时只有三分钟就决定换环境，很可能就是被这行 ERROR 送走的。如果你也遇到了，别只看日志级别，看后面有没有 Using ... attention backend。

4.5 真正的天花板：0.20.0 起官方构建删掉 sm_70​

这一点有官方 diff，不是论坛转述。vLLM PR #39878（[Build] Switch default CUDA to 13.0, update CUDA architecture lists…，2026-04-23 合并） 里，.github/workflows/scripts/build.sh 的改动逐字如下：

-export TORCH_CUDA_ARCH_LIST="7.0 7.5 8.0 8.6 8.9 9.0+PTX"
+export TORCH_CUDA_ARCH_LIST="7.5 8.0 8.6 8.9 9.0 10.0 12.0+PTX"

7.0 被删掉了。也就是说 0.20.0+ 的官方 wheel 不再含 Volta 的 kernel image，这时候连 supports_compute_capability() 那一关都轮不到——是另一类失败（no kernel image is available）。这也和 vLLM 论坛里那则问答对得上：

【官方论坛，非官方口径】"vLLM 0.20.0+ does not officially support V100 (sm_70) GPUs, even with CUDA 12.6 …" —— vLLM Forums — Support for V100 (sm 70) on vllm 0.20（2026-04-30 发帖）

这条要打个折扣看：回答者是论坛的 AI 机器人 RunLLM，不是 vLLM 维护者，口径本身不能当官方结论。它的价值在于给出了线索（构建架构列表），而上面那段 PR diff 才是我用来定论的依据。

小结（V100 可用区间）：

vLLM 版本段V100 (cc 7.0) 情况依据
0.10.0 一档✅ 自动退回 xformers，开箱即用本机实测
0.11 ~ 0.19.x✅ 能跑，走 TRITON_ATTN（慢约 25%），日志里有误导性 ERROR本机实测
0.20.0+❌ 官方构建已删 sm_70官方 PR diff

只有 0.10.0 与 0.19.1 两个版本是我实测的，中间那些版本是按"后端门槛在 0.19.1、xformers 在 0.11.1 之后移除"这两条推断出来的区间，没有逐版验证。

5. 问题 F：装好了、pip check 干净，但环境其实是坏的​

这是这次最有价值的一个坑，也是它让 xinv100 从建好那天起就不可用。

xinv100 建好后，vllm --version 正常，pip check 也干净。但真正加载模型时：

AttributeError: Qwen2Tokenizer has no attribute all_special_tokens_extended.

根因是 transformers 被升到了 5.7.0，而 vLLM 0.10.0 的代码里还在用这个属性。属性确实没了，直接数一下就清楚（2026-09-24 本机 grep）：

transformersall_special_tokens_extended 出现次数
5.7.0（xin）0
4.57.6（xinv100，降级后）5

而升级是 pip 自己干的，两边声明的约束都没有上界（读自本机 dist-info/METADATA）：

vllm 0.10.0+cu126   : Requires-Dist: transformers>=4.53.2
xinference 2.7.0    : Requires-Dist: transformers>=4.53.3; extra == "all"

两个下界 + 无上界 ⇒ pip 拉最新的 5.x ⇒ 刚装好的 vLLM 直接坏掉。而它不报错：不报依赖冲突，pip check 干净，vllm --version 通过 —— 因为 vllm --version 不加载 tokenizer、不建 KV cache，验证不到这类错配。

修复很干净，只动两个包：

pip install "transformers>=4.53.3,<5"
# 实际落地：transformers 5.7.0 → 4.57.6，huggingface_hub 1.13.0 → 0.36.2

教训：vllm --version 通过 ≠ 环境可用。真正的验证必须加载一次模型、跑一次前向。

6. 实机验证记录（2026-09-24）​

冒烟脚本 source/v100_vllm_smoketest.py，跑在 GPU 1（Tesla V100-SXM2-16GB，cc 7.0） 上，模型 Qwen2.5-0.5B-Instruct，关键参数 dtype="float16"（V100 不支持 bfloat16）、enforce_eager=True：

CUDA_VISIBLE_DEVICES=1 anaconda3/envs/xinv100/bin/python source/v100_vllm_smoketest.py

两级降级全部按代码路径自动触发，日志逐字（source/vllm-v100-lab/smoketest-run-2026-09-24.log）：

WARNING [arg_utils.py:1690] Compute Capability < 8.0 is not supported by the V1 Engine. Falling back to V0.
INFO    [llm_engine.py:228] Initializing a V0 LLM engine (v0.10.0) ...
INFO    [cuda.py:346]       Cannot use FlashAttention-2 backend for Volta and Turing GPUs.
INFO    [cuda.py:395]       Using XFormers backend.
INFO    [model_runner.py:1115] Model loading took 0.9277 GiB and 1.685519 seconds
INFO    [worker.py:295]    model weights take 0.93GiB; non_torch_memory takes 0.09GiB;
                           PyTorch activation peak memory takes 1.39GiB; the rest of the memory
                           reserved for KV Cache is 5.48GiB.
INFO    [executor_base.py:118] Maximum concurrency for 2048 tokens per request: 233.73x

prompt='1+1='        -> '2，这说明了什么？____\nA. 1和1相'  (16 tokens)
prompt='中国的首都是'  -> '____\nA. 北京\nB. 上海\nC.'        (16 tokens)

SMOKE TEST PASSED

输出是"接续"风格（直接喂裸 prompt、没套 chat template），但中文连贯、北京 正确，作为冒烟测试足够。

6.1 复跑时撞上的意外：环境里少了两个包​

上面这次是 23:25 的复跑。22:29（本文初稿整理完）到 23:20 之间，xin 和 xinv100 两个 py3.10 环境的 numpy 同时不见了，复跑第一步就死在：

ModuleNotFoundError: No module named 'numpy'

补回来后紧接着又缺 async-timeout（aiohttp 与 xinference 都要）。两个包都按记录里的版本装回去：

pip install numpy==2.2.5 "async-timeout>=4,<5"

时间窗与怀疑对象：~/.local/lib/python3.10/site-packages 里有个包的目录时间戳是 23:10，说明当时有别的进程在往用户级 site-packages 装东西；而这个目录在 xin/xinv100 的 sys.path 里排在环境自己的 site-packages 之前（本机 python -c "import sys; print(sys.path)" 实测），两个环境同时受影响这一点也对得上。是并发 pip/uv 操作误删，还是别的什么，我没有确证——这是推断。

它与 vLLM、V100 都无关，属于"环境被外部改动"。但值得记一笔：所谓"冻结环境"并不自动安全，跑了几个月的环境也可能被别人/别的项目顺手改动，事后复现失败时先 pip list 对一遍。

7. 顺带的两个发现​

① 下模型：ModelScope 直连比走 HF 代理快约两个数量级。

渠道实测速度结果
hf-mirror.com / huggingface.co（走代理 7890）0.070.5 MB/s942MB 十几分钟没下完，且 resume 失败、从头再来
modelscope.cn（直连，不走代理）31.4 MB/s942MB 31 秒下完
# 用 ModelScope 下模型（直连，先清掉代理环境变量）
env -u HTTP_PROXY -u HTTPS_PROXY -u http_proxy -u https_proxy -u ALL_PROXY -u all_proxy \
  anaconda3/envs/xinv100/bin/python -c "
from modelscope import snapshot_download
snapshot_download('Qwen/Qwen2.5-0.5B-Instruct', local_dir='/home/sumshare/models/Qwen2.5-0.5B-Instruct')"

② ALL_PROXY=socks://... 会让 httpx 直接崩。 这条今天现场复现过：

$ ALL_PROXY=socks://127.0.0.1:7890/ python -c "import httpx; httpx.Client().get('https://example.com', timeout=3)"
ValueError : Unknown scheme for proxy URL URL('socks://127.0.0.1:7890/')

（httpx 0.28.1。）httpx 只认 socks5://，不认 socks:// —— 而 huggingface_hub 依赖 httpx，所以下载前 unset ALL_PROXY。

8. 复现命令速查​

# ── 环境 A：xin（3090，vLLM 0.19.1）─────────────────────
conda create -n xin python=3.10 -y && conda activate xin
pip install torch==2.10.0+cu126 torchvision==0.25.0+cu126 torchaudio==2.10.0+cu126 \
  --index-url https://download.pytorch.org/whl/cu126
pip install vllm==0.19.1 --extra-index-url https://wheels.vllm.ai/0.19.1/cu129
pip install "xinference[all]"

# ── 环境 B：xinv100（V100，vLLM 0.10.0）─────────────────
conda create -n xinv100 python=3.10 -y && conda activate xinv100
pip install vllm==0.10.0 \
  --extra-index-url https://wheels.vllm.ai/0.10.0/cu126 \
  --extra-index-url https://download.pytorch.org/whl/cu126
# vLLM 0.10.0 的 wheel 漏声明了一批依赖，按 pip check 逐个补
pip install "huggingface-hub>=0.13" "tokenizers<0.16,>=0.13" click \
  "regex>=2021.8.3" "typer>=0.12.1" docopt pytz pyside6 six cffi \
  fonttools pyparsing coloredlogs
pip check
pip install "xinference[all]"
# ⚠️ 关键收尾：xinference[all] 会把 transformers 顶到 5.x，务必降回来（问题 F）
pip install "transformers>=4.53.3,<5"      # 会同时把 huggingface_hub 降到 0.36.2

# ── 验证（必须真的加载模型，不能只看 vllm --version）─────
pip check
CUDA_VISIBLE_DEVICES=1 anaconda3/envs/xinv100/bin/python source/v100_vllm_smoketest.py

# ── 启动 ────────────────────────────────────────────────
conda activate xinv100          # V100
xinference-local --host 0.0.0.0 --port 8890

几条通用的：

  1. 同机多架构 GPU 会告警：Detected different devices in the system: ... Please make sure to set CUDA_DEVICE_ORDER=PCI_BUS_ID。混跑时按需设 CUDA_VISIBLE_DEVICES。
  2. 不在同一环境混装 nvidia-*-cu11 与 nvidia-*-cu12，会触发 ncclCommWindowDeregister 这类符号错误。
  3. 判断 vLLM 是否支持某张卡，看 v1/attention/backends/*.py 的 supports_compute_capability，不要看 .so 的架构列表。
  4. 长期建议：V100 的软件支持正在收口（PyTorch、xformers 0.0.31、vLLM 0.20.0 都在去 Volta）。这台机器的新 workload 尽量压在 3090 上，V100 就用 xinv100 这套冻结环境，别升级。

9. 还没解决的问题​

  1. 当时 0.19.1 到底报了什么错？ 记录里没留 traceback，只剩三分钟的时间差。本文给的"被 ERROR 日志误导"是推断，不是史实。
  2. 0.11 ~ 0.18 之间哪些版本还能用？ 我只测了 0.10.0 和 0.19.1，中间的版本是按两条上游变更推出来的区间，没有逐版验证。
  3. TRITON_ATTN 那 25% 差在哪？ V0 引擎 / xformers / V1 引擎 / triton kernel 各占多少，这次没有拆开测。粗测单次运行，样本量为 1。
  4. numpy、async-timeout 为什么会同时从两个环境消失？ 只有时间窗和"当时有人在动用户级 site-packages"这条间接证据，成因未确证。
  5. xformers 0.0.31 官方已声明弃用 V100，为什么 vLLM 0.10.0 那条路径还能跑？ 从实测看，被弃的应该是 xformers 自带的 Flash-Attention 2 构建，而不是 vLLM 用的基础 attention 算子——这一条属于推断，没有去核对 xformers 的构建细节。

来源与核对​

本机实测（2026-09-24，脚本与真实输出留档在 source/vllm-v100-lab/）：

内容位置
0.10.0 在 V100 上的冒烟测试（含两级降级日志）source/v100_vllm_smoketest.py、vllm-v100-lab/smoketest-run-2026-09-24.log
0.19.1 在 V100 上的复测与后端选择vllm-v100-lab/vllm019_v100_smoketest.py、smoketest-0.19.1-on-v100-2026-09-24.log
两套环境的吞吐粗测vllm-v100-lab/vllm_v100_bench.py、bench-0.10.0-xformers.log、bench-0.19.1-triton-attn.log
机器基线、包版本、nm / cuobjdump / sys.path 等现场输出见正文各表，命令均随文给出，可直接复跑

上游一手来源（抓取日期均为 2026-09-24，抓取方式 curl -sS -L 取 GitHub API / 原始页面，JSON 与 HTML 原文留档在 source/vllm-v100-lab/）：

引用来源存档
"will no longer support V100 or older GPUs"github.com/facebookresearch/xformers releases v0.0.31official-xformers-v0.0.31-release.json
"completely removes the dependency of xformers"vLLM PR #29262（2025-11-24 合并）official-pr-29262.json
#22777 实为 closed 未合并vLLM PR #22777（2025-09-23 关闭）official-pr-22777.json
TORCH_CUDA_ARCH_LIST 删掉 7.0vLLM PR #39878（2026-04-23 合并）的 build.sh diffofficial-build-sh-arch-diff.txt、official-pr-39878.json
"does not officially support V100 (sm_70)"（论坛 AI 回复，非维护者口径）discuss.vllm.ai 主题 2605forum-vllm-v100-on-0.20.html