[joelteply]

Why: /train on a qwen35 model aborted the serving process from inside a CUDA kernel (unary.cu, SQR on a viewed k_conv, 5090 2026-10-06). CUDA supports_op returned true unconditionally for SQR/SQRT/SIN/COS/LOG while those kernels assert a contiguous src0, and the scheduler trusted it.

Changes:

• CUDA supports_op: SQR/SQRT/SIN/COS/LOG report the contiguity their kernel asserts. They're split out of the NONE/VIEW/PERMUTE/… case group, which stays true.
• ggml_opt_alloc refuses the job: before anything is allocated, every compute node of a training graph must be supported by the device backend. A "no" refuses the job with the op, node and source named (ggml_opt_refusal).
  • Inference keeps its fallback; only a training graph turns the "no" into a refused job.
  • supports_op stays the one place that knows (Cormac's shape).
• llama_opt_failure carries the reason, and server-train reports it instead of "did not fit in device memory".
• ggml_acc_or_set: a viewed gradient (a slice of a fused QKV) is accumulated from a contiguous copy, so the VIEW backward stays on the device. The new check found this: it had been running through the CPU fallback.

Measured, 0.8B qwen35 (unsloth/Qwen3.5-0.8B-GGUF):

Engine	Result	/health
without the L2/ACC rule fixes	refused: the training graph has a node CUDA0 cannot run: ACC 'grad for Qcur-23' …, then SQR … on 'k_conv-22' (a non-contiguous view)	ok throughout
with them	trains on the GPU, no refusal (loss 0.5924)	ok

Remaining sweep (Fable): other backward rules that apply a unary op straight to a view (sin/cos, abs, relu, exp, swiglu's silu). This check now names each one as a refused job instead of a crash.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Q4NU4VNiELPQfBpCacDZGc

[joelteply]

APPROVED at 9652942. This is the shape we agreed on: supports_op stays the one place that knows (SQR/SQRT/SIN/COS/LOG now report the contiguity their kernel asserts, and CLAMP keeps its unconditional yes), and ggml_opt_alloc turns a device 'no' into a refused JOB before allocating, naming the op, node and source, carried through llama_opt_failure to /train's error. ggml_acc_or_set copies a viewed gradient, and skips the copy where grad_accs requires in-place accumulation. Correct. The supports_op change is also a strict win for inference: those ops on a view now fall back instead of asserting. One check before it reaches every node: the refusal is broader than the old behaviour. A training graph with ANY op the GPU doesn't implement used to run with that op on the CPU; now the whole job is refused. Please run the configs that trained before (the 1.5B parity set, and the 0.8B at both depths, which you have) and confirm none is now refused. A previously-working graph turned into a refusal would be a regression that reads as safety.