GitHub Repo
Ollamaコミュニティ、MLXの混合量子化モデル読み込み不具合を報告 インポート成功後も推論できない可能性
Ollama 0.35.1のコミュニティ事例では、MLXモデルの層ごとの量子化設定が正しく適用されず、読み込み時にテンソル形状の不一致が生じる可能性が示された。モデル設定から混合精度の使用は確認できるが、根本原因と他モデルへの影響範囲は上流での確認を待つ。

10月4日、OllamaコミュニティからMLXモデルの互換性に関する報告があった。Apple Siliconで混合精度の重みをインポートした際、モデルの作成処理は成功と表示されるものの、実際に生成リクエストを送るとHTTP 500が返されたという。事例ではOllama 0.35.1とM4 Proを使用し、実験的なインポート経路でmlx-community/Qwen3-Coder-Next-4bitをモデル化していた。エラーは読み込み段階で初めて発生した。問題報告
このモデルは「4bit」という名前だが、すべての層が同じ精度ではない。公開されているconfig.jsonでは、グローバル設定が4ビット、グループサイズが64要素に指定されている一方、48層にわたるmlp.gateとshared_expert_gateにはそれぞれ8ビットが指定されており、上書き設定は計96項目ある。モデル設定には512個のエキスパートと2048次元の隠れ状態も記載されているため、読み込み側はパッケージ化された重みを正しく解釈できるよう、層ごとの設定を保持する必要がある。モデル設定
MLXのドキュメントによると、量子化行列では複数の重み値を符号なし32ビット整数にパックし、スケール係数はgroup_sizeごとにまとめて扱う。この仕様に基づくと、同じパック幅を8ビットではなく4ビットとして誤読した場合、推定される論理幅は2倍になり、必要なスケール係数も増える。報告された重み形状は(512,512)、スケール係数の形状は(512,32)だった。これを4ビットとして解釈すると、スケール係数は64列必要と見なされる。これは報告者が示した根本原因の仮説と整合するが、メンテナーがプログラムの不具合を確認したことを意味するわけではない。MLX演算ドキュメント
ローカル推論のデプロイでは、この事例はインポート成功と実行可能性の間に検証の抜けがあることを浮き彫りにしている。エンジニアリングチームは、デプロイの受け入れ手順に最小限の生成リクエストを加え、層ごとの量子化メタデータとテンソルサイズを照合することで、大きな重みを書き込んだ後に互換性の問題が見つかる事態を避けられる。今後は、上流で上書き設定の処理方法が確認されるか、インポート前の検査が追加されるか、混合精度モデルによる回帰テストが導入されるかに注目したい。確認時点で問題は未解決であり、現時点の証拠からすべてのMLXモデルに一般化することはできない。また、推論品質が気づかれないまま低下することも確認されていない。現在のステータスと再現手順