JANG量子化手法は、大規模モデルのMLXパフォーマンスを向上させます

MLXとGGUF量子化の間の性能ギャップ
この情報源は、大規模言語モデルのための標準的なMLX量子化手法における重大な性能問題について述べています。MMLUベンチマーク(200問)において、MLX用に4ビットに量子化されたMiniMax-M2.5のスコアはわずか26.5%(53/200)でしたが、同じモデルをJANG_2S手法で量子化した場合は74%(148/200)を記録しました。JANG手法は、すべて約25%とほぼランダムな確率に近いスコアだったすべてのMLX量子化レベル(2ビット、3ビット、4ビット)を上回りました。
具体的なベンチマーク結果
詳細なMMLU科目別内訳は、JANG_2Lが一貫してMLX量子化を上回っていることを示しています:
- 抽象代数学: JANG_2L 10/20 vs MLX 4ビット 3/20
- 天文学: JANG_2L 20/20 vs MLX 4ビット 7/20
- 大学レベルのコンピュータサイエンス: JANG_2L 13/20 vs MLX 4ビット 4/20
- 高校生物学: JANG_2L 18/20 vs MLX 4ビット 4/20
MLXの性能が低い根本原因として、「MLXはこのモデルにおいて、直接的な回答の代わりにメタ解説を生成する」ことが特定されました。
モデルサイズと性能比較
Qwen 3.5 122Bモデルについて:
- JANG_4K: 86% MMLUスコア、69 GBサイズ
- MLX 4ビット: 85% MMLUスコア、64 GBサイズ
- JANG_2S: 79% MMLUスコア、38 GBサイズ
- MLX 2ビット: 56.5% MMLUスコア、36 GBサイズ
著者は、「人々はMチップの速度と一貫性をトレードオフしており、MLXにはGGUFに相当するものがない」こと、そして「MacでGGUFを使用する場合のQwen 3.5も、MLXよりも1/3遅い」ことを指摘しています。
MiniMax-M2.5のコード生成問題
参照されたベンチマークから:「MiniMax-M2.5はコードを生成できません — ツール呼び出しで87%、推論で80%の性能にもかかわらず、HumanEval+では10%です。そのコード生成フォーマットに何か問題があります。ただし、推論には優れています。」
入手可能性と実装
現在、以下の方法で利用可能です:
- MLX Studio: https://mlx.studio/ - JANG_Q推論エンジンをネイティブで搭載
- リポジトリ: 自己インストールおよびモデル量子化用
この手法により、「2ビットMLX相当のサイズでMiniMax-M2.5などのモデルを実行しながら、以前はMLXでは不可能だったテスト結果を得る」ことが可能になります。
📖 Read the full source: r/LocalLLaMA
👀 See Also

OpenClaw-Mem0プラグインは、コンテキストウィンドウ外に永続メモリを追加します
openclaw-mem0プラグインは、メモリストレージをOpenClawのコンテキストウィンドウの外部に完全に移行し、圧縮やセッション再起動による損失を防ぎます。クラウドとローカルの両方のセットアップオプションで、自動的な想起とキャプチャを提供します。

repo-mem:オープンソースMCPサーバーがClaude Codeに永続的なチームメモリを追加
repo-memは、SQLiteとGitを使用してClaude Codeセッションに永続的で共有可能なメモリを追加するオープンソースのMCPサーバーです。ユーザーごとのデータベースに観察結果を保存し、それをリポジトリにコミットすることで、チーム間の隔離問題を解決します。

MCPサーバーはAIエージェント向けにセマンティックツールディスカバリーを提供する必要があります
Needと呼ばれるMCPサーバーは、brew、npm、pip、cargoから10,000以上のツールを対象に意味検索を可能にします。エージェントが「これらのPNGを圧縮して」といったタスクを要求すると、pngquantを見つけ、インストールし、実行し、成功したかどうかを報告します。

プロンプトキャッシュMCPプラグインは、安定したコンテキストを特定することで、Claude APIコストを自動的に削減します
プロンプトキャッシュMCPプラグインは、システムプロンプトやツール定義などの安定したコンテキスト部分を自動的に識別し、Anthropicのキャッシュ機能用にマークすることで、コーディングセッションでのAPIコストを80〜92%削減します。