Qwen3-Coder-Next 8-Bit ベンチマーク：MLX vs Ollama
TLDR: RAM 128gb 搭載の M5-Max は、MLX を使って Qwen3-Coder-Next 8-Bit から 1 秒あたり 72 トークンを出力します
概要
このベンチマークでは、同一の Qwen3-Coder-Next モデルを Apple Silicon 上で 8-bit 量子化して実行する、2 つのローカル推論バックエンド――MLX（Apple のネイティブ ML フレームワーク）とOllama（llama.cpp ベース）――を比較します。目的は、生のスループット（トークン/秒）、最初のトークンまでの時間（TTFT）、そして実世界のさまざまなプログラミング課題に対する全体的なコーディング能力を測定することです。
手法
セットアップ
- MLX バックエンド：
mlx-lmv0.29.1 が内蔵の OpenAI 互換 HTTP サーバーでmlx-community/Qwen3-Coder-Next-8bitをポート 8080 にて提供。 - Ollama バックエンド： Ollama が OpenAI 互換 API でポート 11434 にて
qwen3-coder-next:Q8_0を提供。 - 両バックエンドは、ストリーミングを有効にした OpenAI クライアントライブラリを用いて、同一の Python ベンチマークハーネス経由でアクセスしました。
- 各テストはプロンプトごとに3 回実行しました。結果は平均化し、最初の反復の TTFT（モデルの初期コールドスタート：ロード）を除外しました。
指標
| 指標 | 説明 |
|---|---|
| Tokens/sec（tok/s） | 1 秒あたりに生成された出力トークン数。高いほど良い。ストリーミングされたチャンクを数えることで概算（1 チャンク ≈ 1 トークン）。 |
| TTFT（Time to First Token：最初のトークンまでの時間） | リクエスト送信から最初のトークンを受信するまでのレイテンシ。低いほど良い。プロンプト処理＋初期デコードを測定。 |
| 総時間 | 応答全体にかかったウォールクロック時間。低いほど良い。 |
| メモリ | psutil により、各実行の前後でのシステムメモリ使用量を測定。 |
テストスイート
6 つのプロンプトを設計し、簡単な補完から複雑な推論まで幅広いコーディング課題をカバーしました：
| テスト | 説明 | 最大トークン | 測定するもの |
|---|---|---|---|
| 短い補完 | 回文チェック関数を書く | 150 | 最小レイテンシのコード生成 |
| 中程度の生成 | 型ヒント付きで LRU キャッシュクラスを実装する | 500 | 構造化されたクラス設計、API の正しさ |
| 長い推論 | 例を挙げて async/await とスレッド（threading）を説明する | 1000 | 拡張された文章生成、技術的な正確さ |
| デバッグ課題 | マージソート＋二分探索のバグを見つけて修正する | 800 | バグの特定、コード理解、説明 |
| 複雑なコーディング | コンテキストマネージャ付きの、スレッドセーフな上限付きのブロッキングキュー | 1000 | 高度な並行性パターン、API 設計 |
| コードレビュー | 性能／正確性／スタイルの観点で 3 つの関数をレビューする | 1000 | 複数関数の分析、具体的な提案 |
結果
スループット（1 秒あたりのトークン数）
| テスト | Ollama（tok/s） | MLX（tok/s） | MLX の優位性 |
|---|---|---|---|
| 短い補完 | 32.51* | 69.62* | +114% |
| 中程度の生成 | 35.97 | 78.28 | +118% |
| 長い推論 | 40.45 | 78.29 | +94% |
| デバッグ課題 | 37.06 | 74.89 | +102% |
| 複雑なコーディング | 35.84 | 76.99 | +115% |
| コードレビュー | 39.00 | 74.98 | +92% |
| 全体平均 | 35.01 | 72.33 | +107% |
短い補完のウォーム実行平均（コールドスタートの反復を除外）。*
最初のトークンまでの時間（TTFT）
| テスト | Ollama TTFT | MLX TTFT | MLX の優位性 |
|---|---|---|---|
| 短い補完 | 0.182s* | 0.076s* | 58% 速い |
| 中程度の生成 | 0.213s | 0.103s | 52% 速い |
| 長い推論 | 0.212s | 0.105s | 50% 速い |
| デバッグ課題 | 0.396s | 0.179s | 55% 速い |
| 複雑なコーディング | 0.237s | 0.126s | 47% 速い |
| コードレビュー | 0.405s | 0.176s | 57% 速い |
ウォーム実行の値のみ。コールドスタートは 65.3s（Ollama）対 2.4s（MLX）で、最初のモデルロードに要しました。*
コールドスタート
各バックエンドへの最初のリクエストには、モデルのロード時間が含まれます：
| バックエンド | コールドスタート TTFT | 注記 |
|---|---|---|
| Ollama | 65.3 秒 | 84 GB の Q8_0 GGUF をメモリにロード |
| MLX | 2.4 秒 | 事前にシャーディングされた MLX 重みをロード |
MLX のコールドスタートは 27 倍高速 です。MLX の重みは Apple Silicon の統一メモリアーキテクチャ向けにあらかじめシャーディングされているのに対し、Ollama は llama.cpp を通して GGUF の重みを変換・マッピングする必要があるためです。
メモリ使用量
| バックエンド | メモリ（Before） | メモリ（After：安定化後） |
|---|---|---|
| Ollama | 89.5 GB | ~102 GB |
| MLX | 54.5 GB | ~93 GB |
両バックエンドは、モデルが完全にロードされると（84 GB モデルに対して約 90〜102 GB：ランタイムのオーバーヘッド込み）同程度のメモリ使用量に落ち着きます。MLX はモデルがまだメモリ上に常駐していなかったため、ベースラインのメモリ使用量が低い状態から開始しました。
能力評価
生の速度のほかにも、両バックエンドで、モデルはすべてのコーディング課題において高品質な出力を生成しました（同一のモデル重みのため、出力品質はバックエンドに依存しません）：
- バグ検出: テストコード内の両方のバグ（マージでの末尾要素の欠落、二分探索での整数除算と無限ループ）を、両方のバックエンドにおいて全反復で正しく特定できました。
- コード生成: LRUキャッシュとブロッキングキューのための、構造化された型ヒント付きの実装を作成しました。適切な標準ライブラリ要素（
OrderedDict、threading.Condition）を使用しました。 - コードレビュー: 実際の問題（素朴なメールの正規表現、
Counterを使わない手動の単語カウント、type()とisinstance()の使い分け）を特定し、具体的に改善された実装を提示しました。 - 一貫性: 応答品質は反復を通じて安定していました——同じバグが見つかり、同じパターンが使われ、トークン数も同程度で、テストした温度（0.7）での決定的な挙動が示されました。
結論
- MLXはOllamaより2倍高速 です。Apple Silicon上のこのモデルで、平均72.3 tok/s vs 35.0 tok/s。
- TTFTはMLXで約50%低いです。すべてのプロンプト種別で、ウォームアップ後は一定です。
- コールドスタートはMLXで劇的に改善されています（2.4s vs 65.3s）。これはインタラクティブ用途で重要です。
- MLX上でのQwen3-Coder-Next 8-bitは約75 tok/s で、リアルタイムのコーディング支援に十分な速さです。短い補完では即時感があり、長い出力ではスムーズにストリーミングされます。
- Apple Silicon上での大規模モデルのローカル推論では、MLXが明確な勝者です。Ollamaのllama.cppバックエンドよりも有利で、統合メモリアーキテクチャとMetal GPUアクセラレーションをより効果的に活用しています。
