GLM 5.2 Indexer support

[pcuenca]

Overview

Adds indexer support to GLM 5.2. Currently, indexer tensors are loaded when present, but ignored. If accepted, this PR would in my understanding complete the implementation of GLM 5.2.

The implementation just copies the graph from Deepseek 3.2 and applies the GLM 5.2 changes:

• Only "full" indexers compute top_k, "shared" ones reuse top_k from the previous full layer. In Deepseek 3.2, all indexers are "full".
• The indexer uses interleaved rope, instead of the neox-style used by Deepseek 3.2.

Additional information

• Existing unsloth checkpoints work without conversion. They contain indexer weights at every layer, but only those in "full" indexers are used.
• Here's another checkpoint, quantized using this PR, that can be used for testing purposes. It uses unsloth's imatrix, and preserves indexer weights in Q8_0.
• I verified that generations in greedy mode match the previous implementation for short sequences (indexers are essentially a no-op the first 2048 tokens). I have verified that long sequences remain coherent, but have not compared KLD against a reference implementation.
• I was a bit surprised to find decoding speed to be much slower than with the previous (deepseek2-based) implementation. I haven't investigated the reason yet, if there are ways to make it faster, or if it happens across all sequence lengths.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES, as follows:
  • All code, debugging, and testing performed by a human 🙋‍♂️
  • PR description written by the same person
  • AI was used to ask about the codebase, navigate it, find patterns, identify idiomatic approaches.

[pcuenca]

I considered the alternative to store just two numbers to represent the frequency of full indexers, and the number of prefix full indexers before the regular pattern. I decided towards the array because:

• There are also precedents in the codebase for irregular patterns.
• Deepseek 3.2 could be included in this pattern via get_key_or_arr with a single scalar (all DS indexers are "full").

[pcuenca]

I think this is a previous inoffensive bug introduced during the n_layer refactor; n_layer() excludes MTP layers so this should be 78.

[pcuenca]

Same graph as Deepseek v3.2, except for the two differences noted in the PR description.

I didn't want to touch other modules, but we can generalize these changes into Deepseek's and reuse the graph here.

[am17an]

As I understand GLM 5.2 uses the same lighting indexer as DS3.2 but the top-k is shared across 4 layers. If this is correct then #24231 should be used

[pcuenca]

As I understand GLM 5.2 uses the same lighting indexer as DS3.2 but the top-k is shared across 4 layers. If this is correct then #24231 should be used

Yes, indeed, thanks for linking to it, I had missed the recent activity there.

My understanding is that #24231 is about creating a new op that we can use from both the Deepseek and gml-dsa modeling files when it's merged, and when cuda / metal implementations are added. This PR (mine) is about contributing the remaining aspects of the architecture that were deferred from the initial GLM 5.2 implementation, and that are mostly available in the deepseek 3.2 one.

But I'm new to the project, happy to coordinate with the team as necessary!

[am17an]

Yes, my comment is for your awareness w.r.t. to the lightning indexer and not anything else different for GLM5.2