Your current environment

• OS: macOS 26.3.1 (arm64, Apple Silicon)
• Compiler: Apple clang 21.0.0
• Python: 3.12.13 (uv-managed venv)
• torch: 2.11.0
• vLLM commit: 9c61864bf (current main HEAD as of filing)
• VLLM_TARGET_DEVICE: auto-routed to cpu per setup.py:42-44

🐛 Describe the bug

Building from source on macOS arm64 (uv pip install -e .) fails with the following compiler errors in csrc/cpu/cpu_attn_vec.hpp:

csrc/cpu/cpu_attn_vec.hpp:23:13: error: no matching constructor for initialization of 'vec_op::FP32Vec16'
   23 |     return {vec_op::FP32Vec16(bf16_b_reg, 0), vec_op::FP32Vec16(bf16_b_reg, 1)};

csrc/cpu/cpu_attn_vec.hpp:27:13: error: no matching constructor for initialization of 'vec_op::FP32Vec16'
   27 |     return {vec_op::FP32Vec16(bf16_b_reg, 0), vec_op::FP32Vec16(bf16_b_reg, 1)};

(There are 4 errors total — one per FP32Vec16(bf16_b_reg, N) call across lines 23 and 27.)

Root cause

csrc/cpu/cpu_attn_vec.hpp (introduced/expanded by #39445, 22524f7a9) calls:

vec_op::FP32Vec16(bf16_b_reg, 0)

where bf16_b_reg is a vec_op::BF16Vec32. This requires a constructor with signature:

explicit FP32Vec16(const BF16Vec32& v, int upper);

That constructor is defined for x86 only — it appears twice in csrc/cpu/cpu_types_x86.hpp (line 519 for AVX-512, line 628 for AVX-2/256), using _mm512_extracti32x8_epi32 / _mm256_extractf128_si256 intrinsics.

csrc/cpu/cpu_types_arm.hpp has FP32Vec16 with constructors taking const float*, bool, const float*, etc., but no (const BF16Vec32&, int) overload. So when cpu_attn_vec.hpp is compiled on ARM, the call doesn't resolve.

The new code in cpu_attn_vec.hpp is not gated on x86 — there's no #ifdef __x86_64__ / ENABLE_X86_ISA guard around the FP8 KV-cache code path that uses this constructor.

Other backends (cpu_types_neon.hpp, cpu_types_vsx.hpp, cpu_types_arm.hpp, cpu_types_s390x.hpp) likely have the same gap, but ARM is the one I can reproduce on.

Reproduction

git clone https://github.com/vllm-project/vllm.git
cd vllm
uv venv --python 3.12
uv pip install -r requirements/cpu.txt --index-strategy unsafe-best-match
uv pip install -r requirements/build/cpu.txt --index-strategy unsafe-best-match
CC=/usr/bin/clang CXX=/usr/bin/clang++ \
  uv pip install -e . --no-build-isolation --index-strategy unsafe-best-match

The build fails during compilation of csrc/cpu/cpu_attn.cpp (which transitively includes cpu_attn_vec.hpp).

Suggested fix

Two reasonable directions:

1. Add an ARM stub for FP32Vec16(const BF16Vec32&, int) in csrc/cpu/cpu_types_arm.hpp, converting the BF16 register half-by-half (similar to the x86 NEON pattern used for other BF16↔FP32 conversions in that file). Same for any other CPU backends that lack it.

2. Gate the FP8 KV-cache path on x86 in cpu_attn_vec.hpp with #if defined(__AVX512F__) (or whatever the existing convention is), so the unsupported branch never compiles on ARM. Existing files like cpu_attn_amx.hpp already use compile-time guards for AMX-only code.

Option 1 is more invasive but keeps the FP8 attention path available on ARM. Option 2 is quicker and matches how AMX is handled today.

I came across this while rebasing a branch onto main for an unrelated CMake refactor (#41432). Filing in case it's blocking other macOS contributors.

Before submitting a new issue...

• Make sure I already searched for relevant issues — no existing issue mentions cpu_attn_vec.hpp or this regression.