update breadcrumbs

app/src/content/article.mdx

@@ -170,11 +170,11 @@ We needed to separate two principles that were so far intertwined, <Tenet term="
 
 What was the solution to this? Let's talk about modular transformers.
 
-<div class="crumbs">
+<Note variant="info">
 <strong>TL;DR:</strong> Read the code in one place, <Tenet term="one-model-one-file" display="one model, one file." position="top" />. Keep semantics local (<a href="#standardize-dont-abstract">Standardize, Don't Abstract</a>). Allow strategic duplication for end users (<a href="#do-repeat-yourself">DRY*</a>). Keep the public surface minimal and stable (<a href="#minimal-user-api">Minimal API</a>, <a href="#backwards-compatibility">Backwards Compatibility</a>, <a href="#consistent-public-surface">Consistent Surface</a>).
 
 <strong>Next:</strong> how modular transformers honor these while removing boilerplate.
-</div>
+</Note>
 
 
 ## <a id="modular"></a> Modular transformers
@@ -355,11 +355,11 @@ More importantly, the auto-generated modeling file is what users _read_ to under
 
 What does that give us?
 
-<div class="crumbs">
+<Note variant="info">
 <strong>TL;DR:</strong> A small <code>modular_*.py</code> declares reuse; the expanded modeling file stays visible and <Tenet term="one-model-one-file" display="unique" position="top"/>. Reviewers and contributors maintain the shard, not the repetition.
 
 <strong>Next:</strong> the measurable effect on effective LOC and maintenance cost.
-</div>
+</Note>
 
 
 ### A maintainable control surface
@@ -386,11 +386,11 @@ The _attention computation_ itself happens at a _lower_ level of abstraction tha
 
 However, we were adding specific torch operations for each backend (sdpa, the several flash-attention iterations, flex attention) but it wasn't a <Tenet term="minimal-user-api" display="minimal user api" position="top" />. Next section explains what we did.
 
-<div class="crumbs">
+<Note variant="info">
 Evidence: effective (i.e., maintainable) LOC growth drops ~15× when counting shards instead of expanded modeling files. Less code to read, fewer places to break.
 
 <strong>Next:</strong> how the attention interface stays standard without hiding semantics.
-</div>
+</Note>
 
 ### <a id="attention-classes"></a> External Attention classes
 
@@ -423,11 +423,11 @@ MyModelOutputAnnotated = Annotated[MyModelOutput, "shape: (B, C, H, W)"]
 ```
 
 
-<div class="crumbs">
+<Note variant="info">
 Attention semantics remain in <code>eager_attention_forward</code>; faster backends are opt-in via config. We inform via types/annotations rather than enforce rigid kwargs, preserving integrations.
 
 <strong>Next:</strong> parallel partitioning is declared as a plan, not through model surgery.
-</div>
+</Note>
 
 ### <a id="simpler-tensor-parallelism"></a> Configurable Tensor Parallelism
 
@@ -479,11 +479,11 @@ The `tp_plan` solution allows users to run the same model on a single GPU, or di
 
 Semantics stay in the model (a Linear stays a Linear), parallelization is orthogonal and declared via strings: "colwise" splits columns of weights/bias across ranks; "rowwise" splits rows; packed variants shard fused weights; The mapping keys accept glob patterns like `layers.*.mlp.down_proj` to target repeated submodules.
 
-<div class="crumbs">
+<Note variant="info">
 Parallelization is specified in the configuration (<code>tp_plan</code>), not through edits to <code>Linear</code>s. Glob patterns target repeated blocks; modeling semantics stay intact.
 
 <strong>Next:</strong> per-layer attention/caching schedules declared in config, not hardcoded.
-</div>
+</Note>
 
 ### <a id="layers-attentions-caches"></a> Layers, attentions and caches
 
@@ -514,11 +514,11 @@ and the configuration can be _explicit_ about which attention type is in which l
 
 This is <Tenet term="minimal-user-api" display="minimal" position="top" /> to implement on the user side, and allows to keep the modeling code untouched. It is also easy to tweak.
 
-<div class="crumbs">
+<Note variant="info">
 Allowed layer types are explicit; schedules (e.g., sliding/full alternation) live in config. This keeps the file readable and easy to tweak.
 
 <strong>Next:</strong> speedups come from kernels that don't change semantics.
-</div>
+</Note>
 
 
 ### <a id="community-kernels"></a>Community Kernels
@@ -535,11 +535,11 @@ This also opens another contribution path: GPU specialists can contribute optimi
 
 Even more resources have been added, like the formidable [kernel builder](https://github.com/huggingface/kernel-builder) with its connected resources to [help you build kernels with it](https://github.com/huggingface/kernel-builder/blob/main/docs/writing-kernels.md) and [with nix](https://github.com/huggingface/kernel-builder/blob/main/docs/nix.md).
 
-<div class="crumbs">
+<Note variant="info">
 Models define semantics; kernels define how to run them faster. Use decorations to borrow community forwards while keeping a consistent public surface.
 
 <strong>Next:</strong> what modularity looks like across the repo.
-</div>
+</Note>
 
 
 ## A Modular State
@@ -587,10 +587,10 @@ Another problem is, this visualization only shows `modular` models. Several mode
 
 Hence the next question, and how do we identify modularisable models?
 
-<div class="crumbs">
+<Note variant="info">
 Llama-lineage is a hub; several VLMs remain islands — engineering opportunity for shared parents.
 <strong>Next:</strong> timeline + similarity signals to spot modularisable candidates.
-</div>
+</Note>
 
 
 ### Many models, but not enough yet, are alike
@@ -628,11 +628,11 @@ Here `roberta`, `xlm_roberta`, `ernie` are `modular`s of BERT, while models like
 <Image src={classicEncoders} alt="Classical encoders" zoomable caption="<strong>Figure 7:</strong> Family of classical encoders centered on BERT, with several models already modularized." />
 
 
-<div class="crumbs">
+<Note variant="info">
 Similarity metrics (Jaccard index or embeddings) surfaces likely parents; the timeline shows consolidation after modular landed. Red nodes/edges = candidates (e.g., <code>llava_video</code> → <code>llava</code>) for refactors that preserve behavior.
 
 <strong>Next:</strong> concrete VLM choices that avoid leaky abstractions.
-</div>
+</Note>
 
 ### VLM improvements, avoiding abstraction
 
@@ -704,10 +704,10 @@ But this is _within_ the modeling file, not in the `PreTrainedModel` base class.
 
 What do we conclude? Going forward, we should aim for VLMs to have a form of centrality similar to that of `Llama` for text-only models. This centrality should not be achieved at the cost of abstracting and hiding away crucial inner workings of said models.
 
-<div class="crumbs">
+<Note variant="info">
 Keep VLM embedding mix in the modeling file (semantics), standardize safe helpers (e.g., placeholder masking), don't migrate behavior to <code>PreTrainedModel</code>.
 <strong>Next:</strong> pipeline-level wins that came from PyTorch-first choices (fast processors).
-</div>
+</Note>
 
 
 ### On image processing and processors
@@ -718,11 +718,11 @@ The gains in performance are immense, up to 20x speedup for most models when usi
 
 <Image src={fastImageProcessors} alt="Fast Image Processors Performance" zoomable caption="<strong>Figure 9:</strong> Performance gains of fast image processors, up to 20x acceleration with compiled torchvision." />
 
-<div class="crumbs">
+<Note variant="info">
 PyTorch-first lets processors assume torch/torchvision and run the whole pipeline on GPU; big per-model speedups.
 
 <strong>Next:</strong> how this lowers friction for contributors and downstream users.
-</div>
+</Note>
 
 
 ## Reduce barrier to entry/contribution
@@ -738,11 +738,11 @@ These additions are immediately available for other models to use.
 Another important advantage is the ability to fine-tune and pipeline these models into many other libraries and tools. Check here on the hub how many finetunes are registered for [gpt-oss 120b](https://huggingface.co/models?other=base_model:finetune:openai/gpt-oss-120b), despite its size!
 
 
-<div class="crumbs">
+<Note variant="info">
 The shape of a contribution: add a model (or variant) with a small modular shard; the community and serving stacks pick it up immediately. Popularity trends (encoders/embeddings) guide where we invest.
 
 <strong>Next:</strong> power tools enabled by a consistent API.
-</div>
+</Note>
 
 
 ### <a id="encoders-ftw"></a> Models popularity
@@ -759,11 +759,11 @@ In that regard, we DO want to be a modular toolbox, being <Tenet term="minimal-u
 
 So, how do these design choices, these "tenets" influence development of models and overall usage of transformers?
 
-<div class="crumbs">
+<Note variant="info">
 Encoders remain critical for embeddings and retrieval; maintaining them well benefits the broader ecosystem (e.g., Sentence Transformers, FAISS).
 
 <strong>Next:</strong> dev tools that leverage unified attention APIs and PyTorch-only internals.
-</div>
+</Note>
 
 
 ## A surgical toolbox for model development
@@ -780,11 +780,11 @@ One particular piece of machinery is the `attention mask`. Here you see the famo
 
 <HtmlEmbed src="transformers/attention-visualizer.html" frameless />
 
-<div class="crumbs">
+<Note variant="info">
 Uniform attention APIs enable cross-model diagnostics (e.g., PaliGemma prefix bidirectionality vs causal).
 
 <strong>Next:</strong> whole-model tracing for ports and regressions.
-</div>
+</Note>
 
 
 ### Logging entire model activations
@@ -797,11 +797,11 @@ It just works with PyTorch models and is especially useful when aligning outputs
 <Image src={modelDebugger} alt="Model debugger interface" zoomable caption="<strong>Figure 10:</strong> Model debugger interface intercepting calls and logging statistics in nested JSON." />
 </Wide>
 
-<div class="crumbs">
+<Note variant="info">
 Forward interception and nested JSON logging align ports to reference implementations, reinforcing "Source of Truth."
 
 <strong>Next:</strong> CUDA warmup reduces load-time without touching modeling semantics.
-</div>
+</Note>
 
 
 
@@ -815,11 +815,11 @@ Having a clean _external_ API allows us to work on the <Tenet term="code-is-prod
 
 It's hard to overstate how much of a lifesaver that is when you're trying to load a model as fast as possible, as it's the narrowest bottleneck for your iteration speed.
 
-<div class="crumbs">
+<Note variant="info">
 Pre-allocating GPU memory removes malloc spikes (e.g., 7× for 8B, 6× for 32B in the referenced PR).
 
 <strong>Next:</strong> consistent interfaces allow transformers-serve.
-</div>
+</Note>
 
 
 
@@ -845,11 +845,11 @@ curl -X POST http://localhost:8000/v1/chat/completions \
 
 For model deployment, check [Inference Providers](https://huggingface.co/docs/inference-providers/en/index) or roll your solution using any of the excellent serving libraries. 
 
-<div class="crumbs">
+<Note variant="info">
 OpenAI-compatible surface + continuous batching; kernels/backends slot in because the modeling API stayed stable.
 
 <strong>Next:</strong> reuse across vLLM/SGLang relies on the same consistency.
-</div>
+</Note>
 
 
 ## Community reusability
@@ -866,11 +866,11 @@ Adding a model to transformers means:
 This further cements the need for a <Tenet term="consistent-public-surface" display="consistent public surface" position="top" />: we are a backend and a reference, and there's more software than us to handle serving. At the time of writing, more effort is done in that direction. We already have compatible configs for VLMs for vLLM (say that three times fast), check [here for GLM4 video support](https://github.com/huggingface/transformers/pull/40696/files), and here for [MoE support](https://github.com/huggingface/transformers/pull/40132), for instance.
 
 
-<div class="crumbs">
+<Note variant="info">
 Being a good backend consumer requires a consistent public surface; modular shards and configs make that stability practical.
 
 <strong>Next:</strong> what changes in v5 without breaking the promise of visible semantics.
-</div>
+</Note>
 
 ## What is coming next