T4 运行 vLLM 报 Bfloat16 只支持计算能力 8.0 以上的 GPU

在 NVIDIA T4 上启动 vLLM，模型还没开始生成就报：

Bfloat16 is only supported on GPUs with compute capability of at least 8.0.
Your Tesla T4 GPU has compute capability 7.5.

这是运行精度与设备能力不匹配的检查。8.0 指 NVIDIA GPU 的计算能力，不是要求安装 CUDA 8.0；升级 Toolkit 也不能把 T4 的计算能力从 7.5 改成 8.0。下面针对 vLLM 0.6.5 的 CUDA dtype 检查，不能据此推断其他设备后端的 BF16 支持。

为什么没写 bfloat16，仍然选择了它

检查启动日志中的有效 dtype，不要只看自己输入的命令。这个版本使用 --dtype auto 时，会依据模型配置决定精度；模型配置为 BF16 时，自动选择的可能就是 torch.bfloat16。

如果机器有多张卡，还要确认实际分配给进程的是哪张卡。平台指定了可见 GPU 时，保留这项分配；不能为了绕过报错去取消调度器的设备限制。设备可见性本身有问题，可先看PyTorch CUDA 环境的检查方法。

使用 FP16 的前提与改法

模型及当前执行后端支持 FP16、应用接受这次精度变化时，在原启动参数中显式加上：

--dtype half

0.6.5 中 half 与 float16 都表示 FP16。以下是同一设置的 Python 参数片段，需要放进原有的 LLM 初始化，不替代完整的模型配置：

llm = LLM(model=model_path, dtype="half")

这里假定已经从 vllm 导入 LLM，且 model_path 指向原来的模型。BF16 与 FP16 都是 16 位格式，但数值范围不同；不能承诺转换后输出质量完全不变。保留原配置，在有代表性的验证输入上检查输出、异常值和资源用量，通过后再切换业务。

--kv-cache-dtype 控制缓存格式，不能代替模型权重和激活使用的 --dtype。只改缓存参数，模型 dtype 检查仍可能失败。

如果业务需要 FP32

该版本还提供下面的精度参数：

--dtype float

float 与 float32 对应 FP32。模型结构、量化方式和选定后端仍须支持这条路径，不能只凭参数合法就认定整套执行可用。权重与激活的内存需求也可能增加，原来勉强放得下的模型可能改报显存不足。

将已有 BF16 权重转换为 FP32，并不会恢复训练或保存时已经丢失的精度。选择 FP32 是运行方式的调整，不是对原权重质量的保证。

报错消失以后，检查新失败发生在哪一步

启动日志中的有效 dtype 应与预期一致，服务健康检查和一次实际生成也应通过。若之后出现 Triton 编译错误、attention backend 不支持或 KV cache 容量不足，应保留新的完整异常，按对应阶段处理。

通过 BF16 能力检查只解决这项前置条件，不保证 T4 能运行任意模型、量化格式或 attention 后端。恢复时撤销本次 dtype 修改并回到原资源配置；如果原配置本来不受当前 GPU 支持，恢复配置也不会让它突然可用。