MiMo 2.6 Distill 9BをMacで動かす：導入手順とコード生成の実測

MiMo-V2.6-Distill-Qwen-9Bは、今回検証したMac構成でローカル実行できました。ユニファイドメモリ18 GiBのApple M3 Proで、コミュニティ版Q3_K_M GGUFとllama.cppを使用しています。読み込みとテキスト生成には成功しましたが、試した小さなコーディングタスクは、すべての合格条件を満たせませんでした。

この違いが今回の重要な結果です。メモリに収まるモデルが、自分のタスクでも信頼できるとは限りません。また、蒸留9Bチェックポイントは、ホスト型のMiMo 2.6 Proモデルとは別のものです。

実際に使用した構成

Xiaomiの元のチェックポイントとコミュニティ配布のGGUFは別の成果物です。後者は量子化した変換版です。Xiaomi公式のQ3版と呼ばず、配布元とリビジョンの両方を記録してください。

リビジョンを固定してダウンロードし、検証する

信頼できるパッケージ配布元からllama.cppをインストールします。検証したMacではHomebrewを使いました。十分な空き容量があるディレクトリに、今回と同じリビジョンのファイルをダウンロードします。

brew install llama.cpp
mkdir -p mimo26-test
cd mimo26-test
curl -fL --retry 2 \
  'https://huggingface.co/bartowski/MiMo-V2.6-Distill-Qwen-9B-GGUF/resolve/4371da10c84fb26da3592d4cf312d24aa82b7b65/MiMo-V2.6-Distill-Qwen-9B-Q3_K_M.gguf' \
  -o model-Q3_K_M.gguf
shasum -a 256 model-Q3_K_M.gguf

検証したSHA-256は次のとおりです。

d98e54ec9650b6554cfdeea531e2420009207d50471170d0c3640483df8e87eb

ランタイム、ログ、通常のシステム動作に必要なディスク容量も別に確保してください。GGUFのサイズはダウンロード容量であり、必要なメモリ全体を表してはいません。新しくインストールしたllama.cppは検証時のビルドと異なる可能性があるため、結果を比べる前にllama-cli --versionを記録します。

上限を設定した短いリクエストを実行する

/usr/bin/time -l llama-cli \
  -m model-Q3_K_M.gguf \
  -c 2048 -n 256 \
  --single-turn --temp 0 --seed 42 --no-warmup \
  -p 'Write a Python function unique_in_order(values) that removes duplicates while preserving first occurrence order. Inputs are hashable. Return only the function, with no explanation.'

これは実際に実行したコマンドの構成です。/usr/bin/time -lは今回macOSで使った測定オプションであり、Linuxにも同じフラグがあるとは限りません。コンテキストは意図的に小さくしています。この実行で、大幅に長いコンテキスト、マルチモーダル入力、同時リクエストまで検証したわけではありません。

生成コードで確認できた失敗

1回目の実行では、次の関数が返されました。

def unique_in_order(values):
    if not values:
        return []
    result = [values[0]]
    for value in values[1:]:
        if value != result[-1]:
            result.append(value)
    return result

この関数は隣接する重複を取り除きますが、離れた位置に再び現れる値を除去できません。生成された関数を次の4ケースで確認しました。

2回目は、離れた位置に重複値を含む例をプロンプトに加えましたが、同じ2ケースで失敗しました。3回目は最初のプロンプトを繰り返し、最初と同じ関数が返されました。これは1つの小さなタスクを3回試した動作確認です。代表性のある精度ベンチマークではなく、別の量子化版でも同じ結果になる証拠でもありません。

実行時間とメモリの数値をどう読むか

経過時間には起動と読み込みも含みます。最初の2回はローカルのブログビルドと実行時間が重なり、3回目はそのビルドの終了後に実行しました。この数値は、このマシンでの観測結果として扱ってください。条件を統制した速度比較ではありません。全ケースに合格しなかったため、正しい解答を得るまでの総時間は測定していません。

macOSが報告したプロセスの最大常駐メモリ量は、順に約1.91、3.86、3.84 GiBでした。これはOSのプロセス統計であり、専用GPUのVRAM測定値でも、モデルに必要なユニファイドメモリ全体でもありません。メモリマッピング、共有バッファー、他のアプリも、この数値の解釈に関係します。この検証で言えるのは「この18 GiBのMacで動いた」ということです。「必要なのは4 GiBだけ」「どの8 GiB GPUでも動く」という主張はできません。

ダウンロード可能なテスト記録には、生成された関数、期待した出力と実際の出力、測定設定を収録しています。

次に試すこと

明確な合格条件を持つタスクを使い、生成されたコードは実行前に確認してください。ローカル出力が失敗した場合、プロンプト、量子化、モデルの変更は、それぞれ新しい結果を確認する必要がある実験です。どの変更も、今回の失敗を必ず直せるとは限りません。

ホスト型推論については、MiMo APIガイドで別の接続経路を説明し、料金ガイドで直接サービスの単価を扱っています。ホスト型のProと今回のローカル9B変換版は別モデルなので、一方の結果をもう一方のテストとして解釈しないでください。