# Granite 4.0 Hybrid vs Granite 4.2 Dense: identify the model first

Distinguish Granite 4.0 H-Small hybrid MoE from Granite 4.2 dense models using exact architecture metadata, model scale and task acceptance.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/granite4-hybrid-vs-granite42-dense/
Language: en

Granite version numbers and the H architecture label describe different aspects of a model's identity. Granite 4.0 H-Small and Granite 4.2-8B should not be treated as an isolated experiment in hybrid versus dense computation.

## Identify the exact architectures

The [4.0 H-Small card](https://huggingface.co/ibm-granite/granite-4.0-h-small/raw/main/README.md) describes a 32B model whose architecture includes GQA, Mamba2 and shared-expert MoE components. Its architecture table lists 4 attention layers and 36 Mamba2 layers.

The [4.2-8B card](https://huggingface.co/ibm-granite/granite-4.2-8b/raw/main/README.md) describes a decoder-only dense transformer. The [hybrid implementation documentation](https://huggingface.co/docs/transformers/en/model_doc/granitemoehybrid) identifies a separate model implementation, while the [4.2 technical article](https://huggingface.co/blog/ibm-granite/granite-4-2) explains the newer dense reasoning family.

## Keep comparison axes separate

These candidates differ in generation, scale, architecture and post-training. A quality difference between them cannot be assigned solely to the presence or absence of Mamba2.

| Axis | What must remain explicit |
| --- | --- |
| Version | The released family generation |
| Architecture | Hybrid MoE or dense transformer |
| Scale | The exact selected checkpoint size |
| Post-training | Instruction and reasoning behavior |
| Runtime | Implementation used for that architecture |

The H label is not a quantization level. Likewise, a newer version number does not imply that its architecture matches every earlier Granite checkpoint.

## Use a task that reveals actual suitability

Prepare a fictional instruction task requiring a short technical summary with one exception and one fixed term. Add a separate small code-repair task with an independently checkable boundary condition.

Compare the final accepted outcomes, not an assumed architectural ranking. The summary tests instruction retention; the code fixture tests executable behavior. They can produce different model-selection decisions even on the same machine.

## Diagnose loading and behavior separately

A runtime that recognizes a dense Granite class may still need separate support for the hybrid implementation. Failure to load one checkpoint says nothing directly about how accurately that checkpoint would answer.

Once both run through documented paths, preserve their valid templates and generation conditions. If one input is truncated or formatted incorrectly, resolve that before interpreting a task difference. Do not attribute an ordinary integration error to an entire architecture family.

## Write a model-identity decision

Keep repository revisions, architecture class, artifact format and task results together. State explicitly that the comparison changes several axes. A controlled architecture ablation would need a different experimental design.

The useful conclusion is that one exact released model suits the checked workload under the recorded conditions. It does not establish universal hybrid superiority, dense superiority or a predictable speed ratio. Correctly naming the model is the first step toward a comparison that other engineers can understand and reproduce.

## Related reading

- [GPU monitoring without excess charts: five observation levels](/journal/gpu-monitoring-scorecard/)
- [Reproducible inference stacks: preserving a GPU pilot’s result](/journal/software-stack-reproducibility/)