GitHub Repo
Ollamaコミュニティの実測:M5 Proでは量子化された意思決定モデルのプロンプト処理がBF16より遅い
10月7日に公開されたOllamaコミュニティのテストでは、M5 Pro上でMLX量子化形式を使った3種類の意思決定モデルは、長いプロンプトのリクエスト遅延がBF16より大きかった。報告には測定方法と再現手順が添えられているが、逆量子化がボトルネックなのかは、メンテナーによる確認を待つ必要がある。

Ollamaコミュニティは10月7日、ローカルエージェントを開発する人にとって注目すべき性能報告を公開した。M5 Pro、48 GBメモリ、Ollama 0.40.0の環境で、3種類の意思決定モデルは、MLX量子化版のほうが長いプロンプトの処理にBF16版より時間がかかった。テストはリアルタイムのスネークゲームで行われ、モデルは次のゲーム更新サイクルまでに各判断を終える必要があったため、測定対象はリクエスト遅延だった。テスト報告
報告者は/v1/systemoneを使い、約120、500、1,100、1,900 tokenの4種類の入力長について、それぞれ異なるリクエストを8回ずつ測定した。ほかのモデルは読み込まない状態に保った。約1,900 tokenの場合、tev1のBF16の中央値は685ミリ秒、NVFP4は759ミリ秒だった。nimbleはそれぞれ1,234ミリ秒と1,433ミリ秒、clef-flashはBF16が1,280ミリ秒、MXFP8が1,423ミリ秒だった。短い入力では差は小さく、プロンプトが長くなるにつれて遅延の差が広がった。測定データ
この結果は、重みのメモリ使用量と応答速度をそれぞれ検証する必要があることを示している。MLXの量子化行列積インターフェースは、重みを圧縮するだけでなく、グループごとのスケーリング情報を使い、ビット数と量子化モードに応じて演算を行う。ドキュメントはデータ表現を説明しているが、ビット数を下げればすべてのワークロードで遅延が短くなるとは保証していない。エンジニアリング上の推論として、アプリケーションがプロンプト全体の処理に時間を費やす場合は、その段階にかかる時間を実測して比較すべきだ。MLX技術ドキュメント
報告者は差の原因をprefillにあるとし、逆量子化コストが演算に影響している可能性を推測している。しかし、この説明を確認できるカーネルプロファイリングはなく、メンテナーからの返信も修正へのリンクもない。この単一マシンでのテスト結果を、すべてのAppleチップ、モデル、テキスト生成の用途に当てはめることはできない。リアルタイム意思決定エージェントの導入を準備するチームは、公開された手順を自社の入力長で再実行し、メモリ使用量と遅延分布を記録したうえで、上流プロジェクトから複数のハードウェアでの再現結果や量子化カーネルの分析が示されるかを確認するとよい。再現方法と現在の状況