#ローカルLLM

前回のM1 Max検証と同じGGUFを、EVO-X2（Ryzen AI Max+ 395 / gfx1151）のWindows + ROCmで動かした。未マージPRの自前ビルドでは最初の計算で落ち、マージ後の公式Windows ROCmバイナリで通った。詰まりの原因、コンテキスト長が128Kで頭打ちになる理由、6万トークン超を投げたときの3モデル比較まで。

8月26日公開のQwen3.8-Flash-Next（125B MoE + 51B N-gram埋め込み）をM1 Max 64GBで動かした。N-gram表を専用シャードに分けたAtomicChatのM64版GGUF 85GBと、未マージのllama.cpp PR #27742の自前ビルドで、wired上限の設定を変えずにpp512 182 tok/s、tg128 17.6 tok/s。思考xhighの暴走、BBS生成の1行バグ、NSFW拒否の境目、VLMのOCRまで。

前日のM1 Max検証に続き、EVO-X2（Ryzen AI Max+ 395）のllama.cpp ROCmビルドでQwen3.8-27B Q8_0を検証。思考だけでmax_tokensを使い切って本文が返らない現象と、MTP投機的デコードの採択率がコードと日本語会話で大きく割れる実測まで。

8月14日公開のQwen3.8-27BをM1 Max 64GBでテスト。Ollamaは0.17.7だとpull自体が拒否され0.32.14への更新が必要だった。mlx-community/Qwen3.8-27B-4bitはmlx-vlm経由ですんなり動作。

M1 Max 64GBでQwen3.6-35B-A3BのMoEルーターをモンキーパッチして層ごとのエキスパート選択を実測し、観測ベースの事前ウォームアップと素のmmapキャッシュの生成速度を比較した。Qwen3.5-122B-A10B-4bitがこの環境でMetalのOOM例外を出す実測込み。

Liquid AIのLFM2.5-1.2B-JP-202606をM1 Max 64GBで実測。llama.cpp/Ollama/MLXの3系統でデコード速度・JSON構造化・ツール呼び出し・会話のナチュラルさ・長文入力を検証した。Q4_K_Mで208tok/s、Q8_0で157tok/sだがモデル名ハルシネーションが消える差も出た。

Gemma 4 12B UnifiedはVision Encoderを持たない。E4Bの150M 16層Transformerが35Mの線形投影に変わり、パッチ間アテンションはLLM本体48層の双方向アテンションに吸収されている。Fuyu、EVE、Mono-InternVLの先行研究から、encoder-free設計が何を捨てて何で補っているかを掘った。

M1 Max 64GBでHy-MT2 1.8B Q4_K_M (1.08GB) をllama-serverに載せ、JSON・SRT・HTML・用語拘束・少数言語まで投げて入出力を確認。1.25bit 440MB版は標準llama.cppでロード不可、30B-A3B (hy_v3) もMacの標準ルートで動かない。

M1 Max 64GBにoMLX 0.3.9.dev2を入れて、SSD KVキャッシュ2回目prefill短縮、Gemma 4 VLM MTPオン/オフ、DFlash vs 通常エンジン、omlx launch copilotの実動作を順に測る。VLM入力はWAI-Animaで生成したかなちゃん画像で揃えた。

oMLX 0.3.9.dev2のリリースノートを読む。Gemma 4 VLMのMTP、DFlash対応、SSD KVキャッシュ、`omlx launch copilot`まわりが、Codex/Copilotなど常駐エージェントをMacローカルLLMに繋ぐ時にどこへ効くかを整理した。

Ollama 0.17.1未満のGGUFローダーに境界外読み取り脆弱性。公開API化したローカルLLMでは、環境変数、APIキー、system prompt、会話断片の漏えいまで疑う必要がある。

M1 Max 64GB + mlx-vlm 0.5.0でGemma 4 MTP drafterを実測。26B A4B (MoE) だけ+13%速くなり、公式が一番効くと言った31B DenseとE4Bは逆に遅くなった。コード生成と短文haikuで結論が反転する。