#llama.cpp

前回の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投機的デコードの採択率がコードと日本語会話で大きく割れる実測まで。

DEV記事のPDF RAGをM1 Max 64GBで実装し、CLIPで画像、bge-m3 + Qwen3.6 35Bで日本語まで通した実験ログ。モダリティギャップ、推論サーバー並走クラッシュ、LLM-jp 4-8Bの指示追従失敗まで実機の挙動を記録。

DEV Communityの記事をもとに、FastAPIでOpenAI互換RAG APIを作り、llama.cpp、Chroma、Open WebUIをつなぐ構成の位置づけと実装上の落とし穴を整理する。

Xiaomi MiMo-V2.5のウェイト公開後、Mac/ROCmとクラウドGPU（RunPod/GCE）での実行可否を調べた。手元機ではまだ厳しいが、RunPodの4x H200で約14ドル/時間、GCE SpotのH100なら約1.6ドル/時間で動かせる。

NIIが公開したLLM-jp-4-32B-A3B-thinkingをEVO-X2（Ryzen AI Max+ 395）のROCmで動かした。62.9 t/sでQwen3.5-35B-A3Bの44.7 t/sを大きく上回るが、thinking制御やKVキャッシュ消費、知識カットオフに課題あり。日本語比較テストとコード生成テストの結果も。

AMD Lemonade v10.0.1をRyzen AI Max+ 395環境で検証。LLM・画像生成・音声認識・音声合成の4モデル同時起動、NPU Hybrid実行、Vulkan vs ROCmの実測比較と共有メモリ漏れの発見まで。

AMDが開発するオープンソースのローカルAIサーバーLemonadeは、llama.cppやFastFlowLMなど複数バックエンドをGPU/NPU/CPU横断で管理し、OpenAI互換APIでテキスト・画像・音声を統合提供する。

Qwen3.5-35B-A3BはSSM+Attentionハイブリッドで40層中10層しかKVキャッシュを使わない。llama-serverでctx-sizeを4096→65536に拡張してもVRAM増加は800MB、速度低下ゼロ。q8_0 KV量子化の実測とTurboQuantの現状も。

GMKtec EVO-X2 (Ryzen AI Max+ 395) 環境でAMD Software 26.3.1更新後、Vulkanバックエンドがデバイスメモリを正常に確保できなくなりCPUフォールバックする問題の調査と解決記録。BIOS VRAM配分を32GB/32GBに変更することで解決。

BERT perplexityスキャン→LLM判定→エスカレーションの3段パイプラインを、Win/Mac/Linux対応のPythonツールにパッケージング。インストーラーがllama-serverとGGUFモデルまで自動で落としてくる。