Michael Hospedales

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
  • Essay

    The cache hit that answered the wrong question

    I turned prefix caching back on for a 125B hybrid model on a DGX Spark, with the fixes carried from five open pull requests. Hits landed, a number planted deep in the prompt came back exactly every time, and an 11,000-token prompt dropped from 5.99 s to 0.96 s. Then one request answered the question two other requests were asking. Proving that was not a leak took a better instrument than the one I started with.

  • 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.