Software engineer / Miami, FL

Writing

Field note · vLLM

cache_kernels.cu fails to build on aarch64 with CUDA 13.0

A KV-cache batching optimization calls cuMemcpyBatchAsync with a signature the CUDA 13.0 aarch64 driver API does not have. The build stops before anything runs.

Hardware
NVIDIA DGX Spark · aarch64
CUDA
13.0.1
Software
Docker base nvidia/cuda:13.0.1-devel-ubuntu22.04
/workspace/csrc/cache_kernels.cu(115): error: argument of type "size_t *" is incompatible with parameter of type "CUstream" (aka "CUstream_st *")

Symptom

Building vLLM from source for aarch64 against CUDA 13.0.1 — the nvidia/cuda:13.0.1-devel-ubuntu22.04 base image — fails during kernel compilation. The build never finishes; nothing runs yet. A second error follows immediately after the one above, same file, next line:

/workspace/csrc/cache_kernels.cu(116): error: too many arguments in function call

Root cause

Commit 4a06e1246, "[Perf] Batch KV cache swap copies via cuMemcpyBatchAsync," calls cuMemcpyBatchAsync with a function signature that doesn't match the CUDA 13.0 driver API on aarch64 — the parameter types are wrong, passing a size_t * where the API expects a CUstream. The likely explanation is a CUDA API version mismatch: cuMemcpyBatchAsync's signature under CUDA 13.0 on aarch64 may simply differ from whatever version this code was written and tested against. That's not confirmed — just the working theory.

Fix

Revert the commit:

git revert --no-edit 4a06e1246

The reverted commit is a performance optimization — batching KV cache swap copies — not a feature the server needs in order to run, so the cost of reverting is low.

This looks aarch64-specific: DGX Spark, and plausibly other aarch64 platforms like Jetson. x86_64 builds may not be affected at all, though that isn't confirmed here either.

Status
workaround
First seen
April 3, 2026

Have a thought about this?

Questions, corrections, and your own experience are welcome. Reply by email

All writing
  • Field note

    Detecting which inference engine owns a port: vLLM vs. llama.cpp

    Detection that infers the engine from the port number breaks the moment either engine moves. Moving llama.cpp onto the port normally used by vLLM mislabeled it, and downstream code silently wrote null. /props is a clean discriminator: llama-server serves it, and the vLLM OpenAI-compatible server has no such route and returns 404. A second gotcha in the same detour: docker ps --filter publish= does not match a container using host networking.

  • Field note

    Which NVFP4 MoE backend actually works on SM121 (it depends on the model)

    One model needs --moe-backend cutlass and is slow under marlin. Another needs VLLM_SCALED_MM_BACKEND=marlin and crashes without it. NVIDIA officially recommends marlin. All three statements are true.