ggml: add graph_reused

[am17an]

Overview

Add reused member variable to ggml_cgraph so backends can take advantage of the graph reuse functionality. Currently when graph_reuse in invoked, the CUDA backend still does the props change check to figure out if the graph has changed or not, where in fact graph_reuse (to my understanding) guarantees this to be true. This helps bypass a mildly expensive O(n) check.

Additional information

Testing: I tested various combinations like --n-cpu-moe, -nkvo and -ngl and verified it works. Additional testing would be welcome.

Results on a 5090:

Model	Test	t/s cuda_mul_fused	t/s ggml_graph_reuse	Speedup
gemma4 ?B Q4_0	tg128	219.43	231.50	1.06
gemma4 ?B Q4_0	tg128@d16384	183.23	191.91	1.05
gemma4 ?B Q4_0	tg128@d32768	175.15	182.58	1.04
gpt-oss 20B MXFP4 MoE	tg128	313.29	323.01	1.03
gpt-oss 20B MXFP4 MoE	tg128@d16384	279.59	288.05	1.03
gpt-oss 20B MXFP4 MoE	tg128@d32768	258.80	266.12	1.03
qwen35 27B Q4_K_M	tg128	65.04	66.61	1.02
qwen35 27B Q4_K_M	tg128@d16384	62.45	63.61	1.02
qwen35 27B Q4_K_M	tg128@d32768	59.65	60.70	1.02
qwen35moe 35B.A3B Q4_K_S	tg128	194.52	206.56	1.06
qwen35moe 35B.A3B Q4_K_S	tg128@d16384	184.11	196.36	1.07
qwen35moe 35B.A3B Q4_K_S	tg128@d32768	175.95	187.60	1.07

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES, for general understanding of the scheduler

[JohannesGaessler]

This would work from a llama.cpp perspective but I'm not convinced it's the right way to handle this from a ggml perspective. In my opinion we should attach a ggml_guid and write the code around that. With a GUID the contract for "user code" would be "if you change the graph you must change the GUID", it's not clear to me what the correct way to use a reused flag would be.

[gaugarg-nv]

Will there ever be a case where versions match, but node count doesn't?
If not, maybe we can make this an assert?

[am17an]

Yes will add an assert, it should not happen

[am17an]

I added a version number, currently we don't have a guid generator in master. If the current version is acceptable, I can add a guid generator however I think a simple static version counter is also fine imo. The idea of versioning that anything that mutates the cgraph should have increment the version number.

[jeffbolznv]

Should all splits really be the same uuid?

[am17an]

I don't see any additional benefit of having a per split uuid as of now

[am17an]

I think you're right though, it makes sense to have a per split uuid

[jeffbolznv]

This should be atomic