Local AI setup intermittently fails (~30%): llama-server CUDA crash (cudaErrorSharedObjectInitFailed in flash-attn) on RTX Spark N1X during warm-up

Updated 2026-08-31 after direct reproduction testing. The crash is intermittent (~30% of identical runs), not deterministic, and is present on the latest build tested (b10655) — it was never fixed. Earlier "it works now" observations were sampling luck. --flash-attn off is not a usable workaround at the shipped context size. See Reproducing this (for agents) for a scripted repro.

Summary

Local AI setup fails at the verify-local-ai-inference step with HTTP 500 (InternalServerError). The root cause is a CUDA driver fault inside llama-server's flash-attention kernel during model warm-up, not a setup-engine or VRAM-capacity problem — GPU memory allocation for the model, KV cache, and compute buffers all succeed first.

The fault is nondeterministic: with every argument held constant it fires on roughly 3 of 10 launches. A green setup run is therefore not evidence the problem is gone.

Hardware / environment

Memory topology (this is important)

This is a unified-memory device: one physical pool, statically split between the GPU carveout and the OS.

44,480 + 19,695 ≈ 64,175 MB, i.e. the full 64 GiB less ~1.3 GB of firmware/reserved.

Consequence: VRAM is plentiful (~43 GB free against ~29 GB required) while host RAM is genuinely scarce — under 20 GB total, of which only ~7–9 GB is free. llama-server needs host memory too (CUDA_Host model + compute buffers, plus the MTP draft context), and this is the source of a second, distinct failure mode described below. Any capacity check that reasons only about VRAM will mis-model this hardware.

(An earlier revision of this issue listed "15,087 MB total / 2,671 MB available" and a GPU line where free exceeded total; both have been corrected with directly measured values.)

What happened

Setup pipeline log (setup-engine-*.jsonl):

step.started: Verifying Local AI model load
step.completed: verify-local-ai-inference → Failed
  message: "Local AI inference verification failed: llama-server inference returned HTTP 500 (InternalServerError)."

llama-server.stdout.log shows the model loaded and all buffers were reserved successfully:

load_tensors: offloaded 42/42 layers to GPU
load_tensors:        CUDA0 model buffer size = 21087.70 MiB
llama_kv_cache:      CUDA0 KV buffer size =  5120.00 MiB
sched_reserve:      CUDA0 compute buffer size =  2592.13 MiB
sched_reserve:  CUDA_Host compute buffer size =  2112.14 MiB
sched_reserve: reserve took 75.53 ms, sched copies = 1
cmn common_init_: warming up the model with an empty run - please wait ...
CUDA error: shared object initialization failed
D:\a\llama.cpp\llama.cpp\ggml\src\ggml-cuda\ggml-cuda.cu:106: CUDA error
  current device: 0, in function ggml_cuda_flash_attn_ext_mma_f16_case at ...\fattn-mma-f16.cuh:1945
  cudaFuncSetAttribute(reinterpret_cast<fattn_kernel_ptr_t>(fattn_kernel), ..., nbytes_shared_total)

llama-server.stderr.log:

srv operator(): instance name=qwen3.6-35b-a3b-mtp-q4-k-m exited with status -1073740791
srv operator(): got exception: {"error":{"code":500,"message":"model name=qwen3.6-35b-a3b-mtp-q4-k-m failed to load","type":"server_error"}}

-1073740791 = 0xC0000409 (Windows fail-fast / STATUS_STACK_BUFFER_OVERRUN-class abort) — the child process died hard rather than returning a graceful CUDA error, which the router then surfaced to the setup verification client as HTTP 500.

Analysis

The crash occurs when llama.cpp calls cudaFuncSetAttribute(...) to opt the flash-attention MMA kernel into a large dynamic shared-memory allocation. cudaErrorSharedObjectInitFailed at that specific call, on a very new compute-capability-12.1 (Blackwell, ARM64 "Spark") device with driver 616.55, points to a driver/runtime-level problem rather than anything wrong with the model, download, or memory sizing.

Crucially, the failure is nondeterministic. Holding the model, flags, and context size constant, it fires on ~30% of launches. llama.cpp's kernel selection is deterministic for fixed inputs, so nondeterminism at this driver entry point implicates the driver/CUDA runtime rather than kernel-selection logic upstream. It is also not monotonic in context size (32k OK, 64k crash, 128k OK, 192k OK, 256k crash), which further argues against a fixed shared-memory limit simply being exceeded.

This should be reported/tracked upstream against ggml-org/llama.cpp and/or NVIDIA, since the fault originates in ggml-cuda.cu / fattn-mma-f16.cuh and at a driver call, not in this repo's setup code.

Second, distinct failure mode: host RAM

At --ctx-size 262144 the 27B model frequently fails a different way, before reaching any CUDA kernel:

ggml_backend_cpu_buffer_type_alloc_buffer: failed to allocate buffer of size 2315403296
ggml_gallocr_reserve_n_impl: failed to allocate CUDA_Host buffer of size 2315403296
common_speculative_init_result: failed to create MTP context
srv    load_model: failed to create MTP context

The MTP draft context's 2.3 GB host buffer, on top of the 2,208 MiB CUDA_Host compute buffer, does not reliably fit in ~7–9 GB of free host RAM. This is a real capacity problem — just on the host side, not in VRAM.

--flash-attn matrix (b10655, tested 2026-08-31)

There is no workaround at the shipped 262k context. on is what the preset ships and it fires; auto fires; off requires ~73 GB of VRAM because non-flash attention materializes the full attention matrix. Reducing context does avoid it (the 27B loads and serves at 32k), but that is a product tradeoff, not a fix.

Already tested — please don't repeat

• ✅ --flash-attn off — not viable at 262k (73 GB VRAM required).
• ✅ --flash-attn auto — also crashes.
• ✅ Reproduced on both models (35B MoE and 27B dense) and both builds (b10488, b10655).
• ✅ Host memory pressure as the cause of the CUDA fault — ruled out. Free RAM logged before each identical run; the crashing run had more free memory (8,800 MB) than four runs that succeeded.
• ✅ CUDA JIT cache — ruled out. %APPDATA%\NVIDIA\ComputeCache untouched across runs; the build ships an sm_121 cubin (ARCHS = …,1200,1210).

Reproducing this (for agents)

You do not need to run the setup wizard. Drive llama-server directly with the preset's arguments and loop it. Budget ~30 min including download.

Read this first: the fault is intermittent at ~30%. A single passing run proves nothing. Never conclude "fixed" or "not reproducible" from fewer than 10 runs of an identical configuration.

1. Locate the binary and model

ROOT="$LOCALAPPDATA/OpenClawTray-Dev/LocalAI"          # Git Bash path form
EXE="$ROOT/engines/llama-server/b10655/win-arm64/llama-server.exe"
"$EXE" --version    # expect: build 10655 (cb300598d)

If no model is installed, fetch the pinned 27B (17.1 GB) and verify the hash — a truncated download produces confusing unrelated errors:

curl -sL -o Qwen3.6-27B-Q4_K_M.gguf \
  "https://huggingface.co/unsloth/Qwen3.6-27B-MTP-GGUF/resolve/5cb35eb3dcbf52dbce5f87dbc64df6aaffadcace/Qwen3.6-27B-Q4_K_M.gguf?download=true"

sha256sum Qwen3.6-27B-Q4_K_M.gguf
# expect: a7cbd3ecc0e3f9b333edee61ae66bc87ed713c5d49587a8355814722ed329e0f

Pins live in src/OpenClaw.Shared/Inference/Catalog/LocalModelCatalog.cs.

2. run27b.sh — one launch, args mirroring the setup preset

#!/usr/bin/env bash
set -u
FA="$1"; PORT="$2"; OUT="$3"; CTX="${4:-262144}"
EXE="$ROOT/engines/llama-server/b10655/win-arm64/llama-server.exe"
MODEL="/absolute/path/to/Qwen3.6-27B-Q4_K_M.gguf"

"$EXE" --model "$MODEL" --alias qwen3.6-27b-mtp-q4-k-m \
  --host 127.0.0.1 --port "$PORT" \
  --ctx-size "$CTX" --n-predict 8192 --parallel 1 \
  --cache-type-k f16 --cache-type-v f16 \
  --batch-size 4096 --ubatch-size 4096 \
  --flash-attn "$FA" \
  --gpu-layers all --split-mode none --main-gpu 0 \
  --fit off --load-mode dio \
  --spec-type draft-mtp --spec-draft-n-max 3 --spec-draft-backend-sampling \
  --jinja --reasoning on --reasoning-format deepseek --context-shift \
  --temperature 1 --top-k 20 --top-p 0.95 --min-p 0 \
  --repeat-penalty 1 --presence-penalty 0 \
  --no-webui --log-verbosity 4 \
  > "$OUT" 2>&1 &
echo "pid=$!"

--log-verbosity 4 is required — at the default verbosity the CUDA error lines are not printed.

3. repeat.sh — the actual experiment

#!/usr/bin/env bash
set -u
CTX="${1:-65536}"; N="${2:-10}"
for RUN in $(seq 1 "$N"); do
  LOG="rep-$CTX-$RUN.log"; rm -f "$LOG"
  bash run27b.sh on 58030 "$LOG" "$CTX" > /dev/null
  until grep -aqE "model loaded|CUDA error|out of memory|model loading error" "$LOG" 2>/dev/null; do
    sleep 3
  done
  if   grep -aq "model loaded" "$LOG";                              then R="OK"
  elif grep -aq "CUDA error: shared object initialization failed" "$LOG"; then R="CUDA_SHARED_OBJ_FAIL"
  elif grep -aq "failed to allocate" "$LOG";                        then R="HOST_ALLOC_FAIL"
  else R="OTHER"; fi
  echo "ctx=$CTX run=$RUN -> $R"
  taskkill //F //IM llama-server.exe > /dev/null 2>&1
  sleep 5
done

Run it: bash repeat.sh 65536 10

4. Interpreting results

Expected at ctx=65536, --flash-attn on: roughly 3 crashes in 10. Observed run:

27b-ctx-65536.log -> CRASH     corr-2.log -> ok
rep-65536-1.log   -> CRASH     corr-3.log -> ok
rep-65536-2.log   -> ok        corr-4.log -> ok
rep-65536-3.log   -> ok        corr-5.log -> ok
corr-1.log        -> CRASH     corr-6.log -> ok
TOTAL: 3 crashes / 10 runs

To confirm the model serves traffic when it does load:

curl -s -X POST http://127.0.0.1:58030/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3.6-27b-mtp-q4-k-m","messages":[{"role":"user","content":"ping"}],"max_tokens":32,"stream":false}'

5. Hygiene

• Run the model from a scratch directory; do not write into LocalAI/models, and leave state.json / llama-server-models.ini alone, or you will disturb the installed setup.
• taskkill //F //IM llama-server.exe between runs; confirm with tasklist | grep -i llama and check nvidia-smi returns to idle (~1.3 GB used).
• ⚠️ LocalAI/logs/llama-server.*.log are bounded and rotating with no backups. A later run will silently destroy the evidence from a failing one. Copy logs out to a scratch directory immediately after any crash.

Remaining next steps

• Report upstream to ggml-org/llama.cpp and/or NVIDIA, with emphasis on the nondeterminism at cudaFuncSetAttribute.
• Re-test with a newer NVIDIA driver for the RTX Spark N1X once available (only 616.55 has been tested).
• Consider whether the eligibility check should account for host RAM on unified-memory devices, not just VRAM.
• ⚠️ Because the failure rate is ~30%, any "this is fixed" claim needs a double-digit number of runs to support it.

Related

• Setup logs: %APPDATA%\OpenClawTray-Dev\Logs\Setup\setup-engine-*.jsonl (+ .journal.jsonl)
• llama-server logs: %LOCALAPPDATA%\OpenClawTray-Dev\LocalAI\logs\llama-server.stdout.log, llama-server.stderr.log
• Note: the original run predates commit 34b914b5 ("fix(setup): don't roll back completed work on capability-verification failure"), so the downloaded model/runtime were rolled back on that failure; that rollback behavior is already fixed on main — unrelated to the CUDA crash itself.
• Diagnostics for this failure were improved separately: the HTTP error body and llama-server log tail are now surfaced to the setup UI, which previously reported only the bare HTTP 500.

Inspect src/OpenClaw.Shared/Inference/Catalog/LocalModelCatalog.cs for the pinned model and llama-server build, then use the documented direct binary arguments with run27b.sh and repeat.sh. Done means reproducing the CUDA shared-object failure across repeated runs, distinguishing it from host allocation failures, and providing the evidence for upstream llama.cpp or NVIDIA tracking.