Model Integration Contracts
What are MICs?
MIC packages a model’s real usage code, a smaller version of the model for fast runs, and reviewed expected results. Transformers CI runs that usage and reports when behavior changes.
usage.mdMarkdown with executable exampleassertions.jsonexpected inputs/outputsYou or your agent can drive the whole workflow: create a MIC, run checks, investigate failures, and propose fixes.
01 / Understand
How do we create the shrunk model?
An agent can drive this entire workflow with tmic. Agent mode returns structured questions for review and upload decisions.
tmic run HuggingFaceTB/SmolLM-135M --mode agent --regenerate --namespace huggingface-micThe agent resumes the same command with answers as needed. Explore each step below.
01 / Smaller dimensions, same kinds of layers
Reduce hidden sizes, attention heads, and depth. Keep each distinct layer pattern and preserve architecture features such as RoPE and MoE. Some families need a specific recipe.
02 / Same vocabulary, tokenizer, and processor
Copy preprocessing files byte for byte. Preserve vocabulary size, special tokens, and input dimensions such as image patches and audio features.
03 / Seeded random weights, or a small overfit
Try random weights first. If the model ignores relevant inputs, overfit on the contract’s small training batch and check again. A recipe can also require overfitting for readable generation.
04 / Check that the small model is useful
Perturb inputs to check sensitivity, then reload the saved model and check finite outputs, loss, and gradients. Reject failed builds; freeze and pin the accepted weights for repeatable checks.
05 / Publish in huggingface-mic
Upload the slim model, usage.md, and reviewed expectations to a versioned model repository in the huggingface-mic organization. Validate the published snapshot, then update the shared fleet to pin it for CI.
01 / Understand
Inside usage.md
The code in usage.md is a fully valid Transformers Python script: generate text, then take one training step using the same model.
Generation
## Generate
```py runnable:generate
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
model_id = "HuggingFaceTB/SmolLM-135M"
tokenizer = AutoTokenizer.from_pretrained(model_id)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "left"
model = AutoModelForCausalLM.from_pretrained(model_id)
prompts = ["The capital of France is",
"The capital of Germany is"]
inputs = tokenizer(prompts, return_tensors="pt", padding=True)
outputs = model.generate(**inputs, max_new_tokens=4,
do_sample=False, pad_token_id=tokenizer.eos_token_id)
new_tokens = outputs[:, inputs["input_ids"].shape[1]:]
print(tokenizer.batch_decode(new_tokens, skip_special_tokens=True))
```Load the model and tokenizer, left-pad a batch of prompts, and generate without sampling. MIC records the generated tokens and selected logits for comparison with expected outputs.
Training
## One training step
```py runnable:generate:2
answers = [" Paris", " Berlin"]
tokenizer.padding_side = "right"
batch = tokenizer(
[p + a for p, a in zip(prompts, answers)],
return_tensors="pt", padding=True)
labels = batch["input_ids"].masked_fill(
batch["attention_mask"] == 0, -100)
model.train()
optimizer = torch.optim.SGD(model.parameters(), lr=0.01)
loss = model(**batch, labels=labels).loss
loss.backward()
optimizer.step()
print(f"loss: {loss.item():.4f}")
```Continue with the same model and prompts. Right-pad the training batch and ignore padding in the labels. MIC records the loss, checks selected gradients are finite and nonzero, and checks that weights changed.
01 / Understand
Inside assertions.json
For the prompt “The capital of France is”, this slim model’s recorded output starts with “ Paris”.
{
"outputs": {
"generated_tokens": [[7042, 7042, 7042, 7042]],
"generated_text": [" Paris Paris Paris Paris"],
"next_token_logits": [[12.8125, 3.046875, 7.59375, 5.03125]],
"training": {
"loss": 0.2566872537136078,
"updated": true
}
}
}Generation assertions
Token IDs and text must match exactly. Selected logits are compared with numeric tolerances. This small model repeats “Paris”; that is its recorded behavior for this prompt.
Training assertions
Compare the loss with its baseline, check finite, nonzero gradients, and verify an optimizer step changed the weights. The gradient records are omitted above.
02 / Use in CI
How MICs are used
A very fast CPU job (few seconds per model) runs the small models on PRs and on main. No GPU is needed for these checks.
Check the affected models
Model or processor changes select the relevant MICs. Changes to shared code or dependencies can select the whole fleet.
Check the whole fleet
Pushes to main run both fleets, checking the integrated code against the same reviewed expectations.
The job is currently observational: failures are reported without blocking the PR.
03 / Investigate
A MIC failed in CI. What next?
Ask your agent to inspect the failure and reproduce it with the recorded framework revision, fleet snapshot, and runtime.
Fix the code
The agent can reproduce the regression, patch the code, and rerun the same MIC against the existing baseline.
Review the baseline
For an intended change, the agent records candidate outputs and explains the diff. Review changed expectations before publication.
Fix setup or metadata
The agent can check dependencies, platform, and dtype, repair setup or stale known-failure entries, then rerun.
03 / Investigate
Give your agent the failing case.
Share the Run or Trace link. The agent can inspect the assertion, fetch pinned references, reproduce the failure, and propose a fix with evidence.
| Model | Variant / platform | Latest check | Failure |
|---|---|---|---|
| Wav2Vec2 | bfloat16 / CPU | Failed | logits delta 0.000977 exceeds tolerance |
What to inspect
Output: logits · comparison against the reviewed baseline Record: contract + target + variant + platform + framework SHA + fleet SHA Open: Trace · Run · Baseline · Contract
Run & Trace
Find the failing assertion or traceback, runtime versions, selected case, and reproduction command.
Baseline & Contract
Open the pinned reference and usage. Understand the expected output and the exact call producing it.
Latest & history
Compare the latest result with daily bars. Repeated failures are observations, not a count of distinct bugs.
04 / Agents on the Hub
Improve discoverability for agents through the HUB
A proposed link from the original Hub model to its MIC would give an agent a tested starting point, instead of another snippet to debug.
A broken README sends the agent guessing
An example may no longer work with the installed Transformers or Torch. The agent tries package versions, patches loaders, or switches models—and still may not know whether the output is correct.
Run the example in its tested environment
The agent follows the model’s MIC link to executable usage.md, the exact tested versions of Transformers, Torch, tokenizers, and other dependencies, and reviewed inputs and expected outputs.
A verified starting point, less trial and error. “Working” applies to the recorded target, inputs, and environment; the original checkpoint needs its own passing record.
Explore MIC
Try it. Explore the models. Follow the results.
MIC repository ↗
Code, documentation, and the tmic CLI.
MIC on the Hub ↗
Published small models, executable usage, and reviewed expectations.
huggingface.co/huggingface-micMIC dashboard ↗
CI failures, recorded checks, and links to investigate.
MIC failuresGive these links to your agent to get started.