Hugging Face、transformersでGGUF（llama.cpp量子化）モデルの実行に対応

利用者はHubのGGUFのmodel_idとfilenameをgguf_fileとして`from_pretrained`に渡すだけでよい。Metal上で重みがパックされたままの場合、ggml/Metalのレイヤーカーネルが自動で読み込まれ、アテンションにはggml-org/ggml-attnが使われる。取得できない場合は警告付きで"sdpa"にフォールバックする。互換する量子化カーネルがなければ、デクォンタイズして読み込むためメモリ使用量が増える。`transformers serve`ではOpenAI互換APIとして提供でき、JanやPiなどのクライアントから接続できる。

ブログの例ではUnslothのQwen3.5-4Bについて、BF16が8.42 GB、Q4_K_Mが2.74 GBとされている。まずQ4_K_Mを試し、メモリに余裕があればQ5_K_MやQ6_Kを検討することが推奨されている。ベンチマークはMacBook Pro M2 Max（32 GB）で実施し、dense小型、dense大型、MoEの3つのGGUFチェックポイントでtransformersはllama.cppに近い速度だったと述べている。ただしtransformers側はprefillを含み、llama-benchはデコードのみのため、同一条件の比較ではないと明記されている。

高速化の中身は、ggml-quantization、ggml-norm、ggml-attn、ggml-gated-delta-netの各カーネルと、MoEのルーティング用に独自実装したtopkカーネルである。加えて`generate`では、パディングのない入力のアテンションマスクを早期に除去する変更（#48814）と、停止判定を非同期にコピーして次ステップで使う変更（#47975）を入れた。後者2つはGGUFに限らず、transformersの他のモデルにも効果がある。

位置づけとしては、効率的なローカル推論ならllama.cppが引き続き推奨エンジンである。今回の統合は、PyTorchでのフックによる中間活性の確認、量子化チェックポイントの評価、GGUF変換の検証、独自のデコード手法の試験に向く。ファインチューニングには`GgufConfig(dequantize=True)`でデクォンタイズして使う。

制約も示されている。パック済み推論経路はMPSのみで、パディング付きバッチは性能が下がる可能性がある。対応アーキテクチャはQwen3.5のdenseとMoE（互換のQwen3.8を含む）に限られ、徐々に拡大する予定である。使いたいGGUFモデルがあれば、チェックポイントと用途を添えてissueを立てるよう呼びかけている。