 | もううんざりです（unsloth や他の多くの人たちも）。「新しいモデルが欲しい人がいて、既にそういう人たちがいるんだから、まず自分たちが最初に原因になろう」というやり方はやめてほしいです。けれど一方で、裏付けを取ることは（ほとんどの他の量子化作者と同様に）決してしません。例えば、量子化がまともかどうかを確認するために、PPL で「NaN」のような致命的な欠陥がないかチェックしたり、PPL と KLD の数値を測定して公開したりすることです。 この突貫の最新の証拠は、MiniMax-M2.7-GGUF の「UD-Q4_K_XL」です。単純な PPL の測定で、このモデルが壊れていることが分かります。 量子化 PPL 測定で出てくる「NaN」が何か聞いている人向けに説明すると、通常それはバックエンドのカーネル、あるいは量子化そのものに数値的な問題が存在することを示します。ですがこれは、急いで作って一度も確認されていない量子化エラーのようなものです。 私は、他の HF プロバイダ（aessedai/MiniMax-M2.7-Q5_K_M --> 157.226 GiB (5.906 BPW) および ubergarm/MiniMax-M2.7-IQ5_K --> 157.771 GiB (5.926 BPW)）の類似の量子化も確認しましたが、同様のエラーは存在しません。 しかし、これはバックエンドのカーネルの話でもなければ、unsloth が大々的に売り込んでいる「poisoned CUDA 13.2」の話でもありません。 これらは、量子化を急いで公開する前に避ける方法があります（例えば、 どうか unsloth、QA の流れに並び、HF 上で既に受け入れられている「GGUF 量子化コミュニティ」の方針に従い、PPL と KLD のデータを透明性をもって提供してください。少なくとも、衛生（hygene）対策として、こうした失態を避けるために社内ででもやってください。突貫はしないでください！
VS
[link] [comments] |
unsloth - BROKEN（UD-Q4_K_XL）でのMiniMax-M2.7-GGUF --> 使用を避ける
Reddit r/LocalLLaMA / 2026/4/13
💬 オピニオンSignals & Early TrendsTools & Practical Usage
要点
- Reddit投稿者は、unslothが公開した「MiniMax-M2.7-GGUF（UD-Q4_K_XL）」がPPL測定で壊れている（broken）可能性が高いと主張している。
- 投稿者は、NaNを示すような数値的問題は、量子化やバックエンドカーネルの「急ぎで未検証の誤り」を示唆するため、公開前に検証すべきだと批判している。
- 同等モデルの他HFプロバイダ（aessedai/MiniMax-M2.7-Q5_K_M、ubergarm/MiniMax-M2.7-IQ5_K）では同種のエラーが見られなかったと比較している。
- 「--validate-quants」等で検証する手順や、GGUF quantingコミュニティで受け入れられているPPL/KLDの透明な提示を求めている。
- 投稿者はunslothの「poisoned CUDA」のような話題よりも、QA（品質保証）と公開前チェックの不足が問題だと位置づけている。
