Fix Gemma3n not executed as CUDA_GRAPH on NVGPUs

[ORippler]

Gemma3n uses Matrix-Matrix addition as part of project_per_layer_input, erroneously triggering CUDA_GRAPH disablement on NVGPUs even when a batch-size of 1 is used. This PR fixes this issue, while still detecting batched execution for graphs with > 1 GGML_OP_ADD node.

Perf before:

| model                          |       size |     params | backend    | ngl | n_batch |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | ------: | --------------: | -------------------: |
| gemma3n E2B Q8_0               |   4.45 GiB |     4.46 B | CUDA       |  99 |       1 |    pp1000+tg200 |         47.86 ± 1.27 |

Perf after:

| model                          |       size |     params | backend    | ngl | n_batch |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | ------: | --------------: | -------------------: |
| gemma3n E2B Q8_0               |   4.45 GiB |     4.46 B | CUDA       |  99 |       1 |    pp1000+tg200 |        133.08 ± 0.23 |

In the long run, I feel we should either fully support batched inference with CUDA Graphs or refactor the way batch sizes are detected (maybe moving ownership elsewhere?), but I'm still too unfamiliar with the code base to mage suggestions here.

Thoughts?

[slaren]

In the long run the solution will be to move the implementation to the graph plan API, then the heuristics to determine if the graph should be captured or not will be removed. I cannot tell if this workaround will break something else.

[ORippler]

In the long run the solution will be to move the implementation to the graph plan API, then the heuristics to determine if the graph should be captured or not will be removed.

Happy to contribute here, and open to pointers on where to get started!

I cannot tell if this workaround will break something else.

In the mean time, we would nevertheless like for gemma3n to be executable as CUDA GRAPHs on NVPGPUs. I therefore refactored the workaround to now rely on pattern matching of node names. Specifically, it matches for the names of gemma3n's input projection nodes, excluding this one specific occurrence from batch-size determination. As neither the individual node names nor their combined pattern exist in a model graph besides the one of gemma3n (verified this manually), the workaround will not break existing models. While it may potentially break new models that end up using the exact same node pattern, this will come up during the implementation of each new model and can be fixed then.

I moreover verified that gemma3n's output is matching for both CUDA GRAPH and plain CUDA kernel execution for batch-size 1, i.e. that the input projection operation can be "mini-batched" within a CUDA GRAPH when overall batch size is 1.

Last, I generated some e2e performance numbers to high-light the speedups we can gain for gemma3n and to verify that the check does not degrade performance of existing models.

model	size	params	backend	ngl	n_batch	test	t/s	code
gemma3n E2B Q8_0	4.45 GiB	4.46 B	CUDA	99	1	pp100	44.93 ± 0.63	eacdeb5 (master)
gemma3n E2B Q8_0	4.45 GiB	4.46 B	CUDA	99	1	pp100	139.68 ± 0.54	a52592a (this PR)
gemma3n E2B Q8_0	4.45 GiB	4.46 B	CUDA	99	1	tg100	43.97 ± 0.31	eacdeb5 (master)
gemma3n E2B Q8_0	4.45 GiB	4.46 B	CUDA	99	1	tg100	123.94 ± 1.03	a52592a (this PR)
gemma3n E2B Q8_0	4.45 GiB	4.46 B	CUDA	99	2	pp100	92.39 ± 0.80	eacdeb5 (master)
gemma3n E2B Q8_0	4.45 GiB	4.46 B	CUDA	99	2	pp100	93.14 ± 5.71	a52592a (this PR)
llama 3B Q4_K - Medium	1.87 GiB	3.21 B	CUDA	99	1	pp100	324.02 ± 1.41	eacdeb5 (master)
llama 3B Q4_K - Medium	1.87 GiB	3.21 B	CUDA	99	1	pp100	323.77 ± 0.82	a52592a (this PR)
llama 3B Q4_K - Medium	1.87 GiB	3.21 B	CUDA	99	1	tg100	288.85 ± 3.13	eacdeb5 (master)
llama 3B Q4_K - Medium	1.87 GiB	3.21 B	CUDA	99	1	tg100	289.96 ± 1.75	a52592a (this PR)
llama 3B Q4_K - Medium	1.87 GiB	3.21 B	CUDA	99	2	pp100	270.51 ± 15.25	eacdeb5 (master)
llama 3B Q4_K - Medium	1.87 GiB	3.21 B	CUDA	99	2	pp100	263.20 ± 18.06	a52592a (this PR)
qwen3 4B Q4_K - Medium	2.44 GiB	4.02 B	CUDA	99	1	pp100	239.89 ± 1.97	eacdeb5 (master)
qwen3 4B Q4_K - Medium	2.44 GiB	4.02 B	CUDA	99	1	pp100	240.61 ± 0.89	a52592a (this PR)
qwen3 4B Q4_K - Medium	2.44 GiB	4.02 B	CUDA	99	1	tg100	214.54 ± 1.11	eacdeb5 (master)
qwen3 4B Q4_K - Medium	2.44 GiB	4.02 B	CUDA	99	1	tg100	215.57 ± 1.91	a52592a (this PR)
qwen3 4B Q4_K - Medium	2.44 GiB	4.02 B	CUDA	99	2	pp100	184.03 ± 3.30	eacdeb5 (master)
qwen3 4B Q4_K - Medium	2.44 GiB	4.02 B	CUDA	99	2	pp100	186.10 ± 3.88	a52592a (this PR)

Let me know should you still see major issues, and I'll give my best to address them.

[slaren]

Happy to contribute here, and open to pointers on where to get started!

There are some changes that we need to make to ggml-backend and llama.cpp before this can be implemented in the CUDA backend. I will ping you and other NVIDIA developers who also expressed interest when this is done.