执行摘要

• 一句话：Apple Silicon BF16 探测改为失败回退 fp16/fp32
• 推荐动作：值得快速阅读：该 PR 改动简洁但揭示了一个常见陷阱——subprocess.check_output 在非零退出码时抛异常，使下游 fallback 分支成为死代码。对平台层开发者和处理硬件能力探测的工程师有参考价值。无需深入精读其余部分。

功能与动机

macOS 在 CPU 不具备 FEAT_BF16 特性时不会发布 hw.optional.arm.FEAT_BF16 这个 OID，sysctl 会打印 unknown oid 并以退出码 1 结束。原实现使用 subprocess.check_output，非零退出即抛 CalledProcessError，导致 PR body 中描述的 fp16/fp32 兜底分支永远不可达；而 supported_dtypes 在启动阶段被 vllm/config/model.py 读取，异常会直接传播出来使 vLLM 无法启动。官方文档 docs/getting_started/installation/cpu.apple.inc.md 明确说明 macOS CPU 实现只支持 FP32 和 FP16，因此必须让探测失败时走回退路径。

实现拆解

1. 定位问题：vllm/platforms/cpu.py 的 CpuPlatform.supported_dtypes 属性在 macOS arm64 分支使用 subprocess.check_output 配合 shell=True 探测 FEAT_BF16。macOS 在 CPU 不具备特性时不发布该 OID，sysctl 输出错误并以退出码 1 结束，check_output 因而抛出 CalledProcessError，后续 fp16/fp32 兜底逻辑无法执行，异常向上传播到配置解析阶段导致启动失败。
2. 修正探测方式：将 check_output 替换为 subprocess.run，不设 check=True，使非零退出码不会抛异常；通过比对 stdout.strip() 与 b"1" 判断是否支持 BF16，从而在 OID 缺失时正常进入 fp16/fp32 分支。同时把 shell=True 移除，改为参数列表形式，避免整条命令被当作单个 argv 元素再由 shell 解析。
3. 验证与配套：PR 作者在 macOS 15 arm64 上分别验证了 OID 缺失（hw.optional.arm.FEAT_NOPE）与存在（hw.optional.arm.FEAT_BF16）两种情形，确认探测结果正确；本机器上 supported_dtypes 返回 [torch.bfloat16, torch.float16, torch.float32] 与之前一致。未新增自动化测试，因为该行为依赖具体硬件特性，难以在 CI 中复现。该变更仅涉及平台探测逻辑，不影响其他架构分支。

关键文件：

• vllm/platforms/cpu.py（模块 平台层；类别 source；类型 core-logic；符号 supported_dtypes）: 唯一变更文件，修改 CpuPlatform.supported_dtypes 中 macOS arm64 分支的 BF16 探测逻辑，修复 OID 缺失时的启动失败。

关键符号：supported_dtypes

关键源码片段

vllm/platforms/cpu.py

唯一变更文件，修改 CpuPlatform.supported_dtypes 中 macOS arm64 分支的 BF16 探测逻辑，修复 OID 缺失时的启动失败。

@property
def supported_dtypes(self) -> list[torch.dtype]:
    # 处理不同 CPU 架构支持的数据类型列表
    if self.get_cpu_architecture() == CpuArchEnum.POWERPC:
        return [torch.bfloat16, torch.float32, torch.float16]
    elif self.get_cpu_architecture() == CpuArchEnum.ARM and sys.platform.startswith(
        "darwin"
    ):
        # 在 OID 缺失时 sysctl 退出码非零，`check_output` 会抛 `CalledProcessError`，
        # 导致下方 fp16/fp32 兜底分支永远不可达，这里改用 `run` 并检查 stdout。
        bf16 = (
            subprocess.run(
                ["sysctl", "-n", "hw.optional.arm.FEAT_BF16"], capture_output=True
            ).stdout.strip()
            == b"1"
        )
        if bf16:
            return [torch.bfloat16, torch.float16, torch.float32]
        return [torch.float16, torch.float32]
    elif self.get_cpu_architecture() == CpuArchEnum.RISCV:
        return [torch.bfloat16, torch.float16, torch.float32]
    # x86/aarch64 CPU 原生支持 bf16 和 fp16
    return [torch.bfloat16, torch.float16, torch.float32]

评论区精华

该 PR 来自 fork，claude[bot] 自动提示 fork 的 PR 不会自动 review，需要维护者评论 @claude review 才会运行一次性审核。实际没有产生 review 评论；维护者 bigPYJ1151 评论 /ci run 触发了 Buildkite CI #83269，随后直接批准合并。因此没有实质性的技术讨论交锋，属于问题明确、改动直接的小型 bugfix。

• CI 触发与审批 (other): CI 通过后由 bigPYJ1151 直接批准合并，无实质技术分歧。

风险与影响

• 风险：风险较低，但仍需注意以下几点：
  1) 探测逻辑变更：若 sysctl 输出非 b"1"（例如 b"0"）将走 fp16/fp32 回退，符合预期；若 sysctl 本身不存在（极端情况），subprocess.run 与 check_output 同样会抛 FileNotFoundError，行为无差异。
  2) 回归面：去掉 shell=True 后命令以参数列表形式传递，避免了 shell 解析隐式行为，对 sysctl 调用本身无影响。
  3) 测试覆盖缺失：没有自动化测试覆盖该分支，未来重构可能重新引入类似问题。
  4) 影响范围：仅限 macOS arm64 且无 FEAT_BF16 的设备，属于启动路径，影响可控。
  • 影响：对用户：修复了不支持 BF16 的 Apple Silicon 设备上 vLLM 无法启动的问题，使这些设备能按文档回退到 fp16/fp32。对系统：启动路径的 supported_dtypes 不再因探测失败抛异常，配置解析流程恢复稳定。对团队：这是一个范围很小的 bugfix，改动集中在平台适配层，降低后续维护成本，同时为平台探测代码提供了一个更稳健的 subprocess 用法示例。
  • 风险标记：缺少自动化测试, 仅影响 macOS arm64 启动路径

关联脉络

• PR #44201 [CPU][Zen] Route BF16 MoE inference through zentorch on AMD: 同为 CPU 上 BF16 能力支持相关，一个在 kernel/专家层做路由，一个在平台层做能力探测，可对照理解 vLLM 对 CPU BF16 的不同处理层次。