We have:
Architecture name: granite_v4
Class names: GraniteMoeHybrid*
HF architecture: GraniteMoeHybridForCausalLM

This creates confusion. Consider either:

Renaming classes to GraniteV4* to match the file/architecture name
Or explain in this PR why "MoeHybrid" is used for a dense model

This is done deliberately to ensure consistency, as all Granite 4.0 models use a single "superset architecture" name GraniteMoeHybridForCausalLM, for simplified model management during training and loading, even for those variants (like the non-Hybrid/non-MoE models) where the name is technically a superset of the functional architecture.
https://huggingface.co/collections/ibm-granite/granite-40-language-models

The HF transformer implementation here uses the granitemoehybrid. If we do not want to associate this architecture with version 4, a better move could be to use granitemoehybrid everywhere.

If this is supposed to support MoE models (even if 8B is dense), the config lacks.
num_experts
num_experts_per_tok
router_aux_loss_coef
Expert-specific parameters

We should at least add a comment to mention that this will be addressed in a future PR or clarity that the scope of this PR is to support only the the dense 8B; MoE variants will be added later.

_3_1_2b_config is defined but not registered.
Register it: models.register_model(_architecture_name, "3.1-2b", ...)
or remove it from this PR

The PR should include:

• Unit tests for the new model architecture
• HF weight loading tests
• Output verification tests

Please add docstrings for classes and key methods
Comments explaining Granite 4.0-specific features (embedding_multiplier, residual_multiplier, attention_multiplier, logits_scaling)

Can confirm that _8b_config matches the actual HF config for ibm-granite/granite-4.0-8b (or 8b-base)

Right now, some values (notably src_vocab_size=49155, pad_id=0, and max_expected_seq_len=8192) look more like the older “tiny-preview” tokenizer / config than the final Granite 4.0 configs, which generally use a 100k vocab and long contexts. I suggest to populate _8b_config directly from HF config
Use config.vocab_size and config.pad_token_id instead of hard-coding the 49k/0 pair unless this is the behavior we want here.

Since this is now applied to Granite 4 as well, it might be clearer to make that comment architecture-agnostic or explicitly say “Llama/Granite”.

inner_dim is computed and never used. We can use it to sanity-check or derive hidden_grow_factor from intermediate_size:
hidden_grow_factor = config.intermediate_size / config.hidden_size

this is actually already happening here

I don't think we have to default to fused, this can be handled through an adapter

Can you please provide more details on what kind of adapter you are referring here?

Implemented this fused logic to let the GraniteBlock accept both fused and unfused weight.

While we could handle this with wg1_fused and allow FMS to work with fused weights, vllm-spyre actually sets fused_weights=False, which creates a problem with mixed configuration.