講人話：Hugging Face 嘅 Transformers 支援超過 750 種模型，測試套件主線上有 88,000+ CPU 測試、每日跑 200,000+ GPU 測試，仲包管線、訓練、分佈式、量化同注意力 kernel。全跑喺每個 PR 要幾多 GPU 全日 busy，唔實際；排定跑發現回歸，往往已入 main。
佢哋嘅解法是縮水：照原 checkpoint 配置，做少幾層、窄幾點嘅 fixture，但每類 layer 都有，tokenizer 同 processor 檔案不動；一次發布，長期重用。喺 CPU 上面跑「快速集成測試」。喺 CPU 研究入面，實驗性 UMT5 fixture 用 66 MB weights，對照原 checkpoint 1,227 MB。呢個亦解決「太大模型唔啱標準 GPU runner」嘅局面：fixture 可以喺 CPU 跑。
集成測試通常「load 個模型、跑個 forward pass 就收工」。但 UMT5 個 bug 嘅 forward pass 係正常嘅——模型唔崩、output 得睅有得睇，只有 decoder mask 錯，先至瞟到未來 token。所以光做 forward pass 攔唔到。
佢哋而家嘅做法係 MIC（Model Integration Contract），三個組成：
- fixture：上面嘅縮水模型，發布一次、pin 死。
- usage path：一份可以跑嘅 Markdown 範例，寫住「人哋對呢個模型做乜」，例如生成文字、跑一個訓練 step。
- baselines：跑 usage path 時記錄落嘅 output，有人工審過。
合約成立嘅條件：喺 fixture 上跑 usage path，要再出返 baselines。一組合約對應一個架構加一條 usage path，唔對應單個 checkpoint——同架構嘅 checkpoint 可以共用 fixture，但各留各嘅期望輸出。發布喺 huggingface-mic。
舉例：SmolLM 合約會做「The capital of France is」呢類 prompt，compare token IDs 同已記錄答案；另外比 training loss、檢查梯度有限（finite）、驗證 optimizer step 有改到 weights。
Hub 上有一個 fleet dataset，每個 MIC pin 喺一個 frozen revision，連同錄 baselines 用嘅 package versions；每次 CI run 記錄佢用嘅 fleet revision，之後可以重現。
模姐驗嚇貨：呢篇嘅重點唔係「Hugging Face 好叻」，而係佢哋點樣將一個會瞟答案嘅 bug 變成一整套測試標準。兩個月喺 main，forward pass 全 pass，排定 regression run 全 blind——呢個同我哋日常見到嘅「model eval 全綠但實際 deploy 出風」嘅情況好似。縮水 fixture 呢招，同我哋用 tiny-random-* checkpoints 有相似，但佢哋加咗 usage path 同 baselines 兩個維度，令測試唔再只係「能載入、能跑」，而係「要出到正確嘅嘢」。好，呢個係一個有價值嘅方向。
但要注意：呢個係廠商自己嘅測試機制，唔係獨立驗證。佢哋話 fix 咗，佢哋話攔到，呢啲係佢哋嘅聲明。第三方有冇獨立重現過 UMT5 個 mask 問題、或者驗證過 MIC 對其他架構嘅有效性，呢度冇嘅。
模姐｜深度調教
