Gb10 cuda graph fix

[sumergoconicio]

 Fixes a bug where the CUDA graph warmup loop fails to complete on models
 with variable-shape noop nodes (VIEW/PERMUTE/RESHAPE/TRANSPOSE) in the
 decode graph. This affects all model architectures, not just hybrids.

 Root cause: `ggml_cuda_graph_update_required` uses `cgraph->uid` as a
 shortcut for reuse detection. Decode graphs change uid on every token,
 so the warmup resets perpetually -- it captures once, then immediately
 invalidates itself on the next call.

 Fix: When uid changes but node count matches, compare the structural
 properties (op, type, ne[], nb[] for both the node and its sources).
 Data pointers are excluded (cudaStreamCaptureModeRelaxed handles runtime
 patching). Noop nodes are excluded (their shapes vary with context).

 ## Testing
 - `test-backend-ops` full suite: pass
 - `compute-sanitizer --tool memcheck`: clean
 - Benchmark: no regression on standard Qwen 4B and hybrid Bonsai 27B

[Copilot]

Pull request overview

Combines a CUDA graph warmup fix with unrelated DGX Spark Q1_0/Q2_0 CUDA optimizations.

Changes:

• Adds structural CUDA graph reuse detection.
• Adds Blackwell MMVQ and experimental MMQ kernels.
• Documents GB10 benchmarking and development history.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 16 comments.

Show a summary per file

File	Description
ggml-cuda.cu	Graph reuse and Blackwell dispatch
mmq-blackwell-q1.cu	New low-bit MMA kernel
mmvq.cu	Blackwell vector-dot routing
vecdotq.cuh	Aligned Q1/Q2 load variants
GB10-PATCHES.md	GB10 experiment ledger

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[bri-prism]

Thanks, the root-cause analysis here looks right to me. The old fallback memcmps the whole stored ggml_tensor, including the src[] tensor-object addresses, and those change on every graph rebuild, so once the uid shortcut misses, warmup can never complete. A structural comparison is the right shape for the fix. Three things before this can land:

1. Scope. This branch carries all of #79 (the Blackwell kernel, vecdotq/mmvq changes, and GB10-PATCHES.md) plus the one fix commit. Those files are under separate review on #79 and shouldn't ride along here. Please rebase this PR onto prism with just 17dfc6c so the two reviews don't collide.

2. The structural check needs to compare data pointers and op_params. There is no kernel-arg patching on the replay path in this tree (no cudaGraphExecKernelNodeSetParams calls, no cpy-arg maintenance), and cudaStreamCaptureModeRelaxed doesn't patch anything at replay time, it only relaxes what's legal during capture. So replaying the captured executable is only correct when every non-noop node's data pointer is bit-identical to what it was at capture. When that holds, comparing pointers costs nothing and reuse still engages; when it doesn't hold, the comparison is the only thing preventing kernels from silently reading and writing stale addresses. The stored props already have everything needed: compare n->data against p->data, n->src[j]->data against node_src_data_ptrs[j], and memcmp op_params for non-noop nodes. If you find these comparisons fail across decode steps in practice, that's not a reason to drop them, it means reuse is unsound for that graph and re-capture is required. (If they're added, also refresh the stored node_props on the match path so later comparisons see current pointers.)

3. Evidence. test-backend-ops doesn't exercise graph replay, so could you add: (a) an output A/B, graphs on vs GGML_CUDA_DISABLE_GRAPHS=1, on both a dense and a hybrid model, generating long enough to cross a KV padding boundary (512+ tokens), expecting identical output; and (b) the measured decode tok/s delta on GB10 with the fix, since engaging replay is the point of the change.

One question: what's making the uid churn per token on GB10 in the first place? On H100 the same-uid path replays fine on the same model family (scheduler-level graph reuse keeps the cgraph object stable), so if sched reuse is failing on GB10 specifically, this fallback may be compensating for a regression a layer up, and it'd be good to know which before relying on it.

Happy to re-review quickly once it's rebased down to the fix commit.