ggml-org

Radeon VIIとUbuntu 26.04でROCmを動かし、Flash-NextをOpenCodeにつないだ 5年ほど前に組んだデスクトップがある。当時、GPUにはすでに型落ちだったRadeon VIIを5万円くらいで入手して載せた。Stable Diffusionで遊んでいた時期もあったが、飽きてからはすっかり出番がなくなっていた。 最近はローカルLLMが盛り上がっている。とはいえ、パソコンもGPUもクソ高い。新しいGPUを買う前に、あまり期待せず、久しぶりにこのデスクトップに火を入れて環境を組み直してみることにした。 気になったのは、Radeon VIIのROCm公式サポートが切れていることだ。かなり苦戦する覚悟だったが、実際にはChatGPTのGPT-6.1 Terra（medium）に相談しながら、環境の調査から構築、動作確認まで進められた。多少の修正はあったものの、さくさく進む。最終的に、Qwen3.8-Flash-Nextが動き、OpenCodeからローカルモデルへツール付きでアクセスできるようになった。古いデスクトップでvibe codingを試せる環境ができてしまい、だいぶびっくりしている。 この記事は、そのRadeon VIIでROCmを動かし、ローカルLLMをOpenCodeにつなぐまでの記録だ。 結果は、Q2_0量子化版のFlash-Nextで短めの会話の生成が約35 tokens/s。別途、Qwen3.8-27BのQ3量子化版もllama.cppで約21〜22 tokens/s出ている。両者は量子化も実行エンジンも違うため、モデル同士の純粋な比較ではない。 この記事は2026年11月3日時点の実機メモだ。gfx906のROCmはAMDの通常の動作保証対象とは別扱いで、以下は一つの環境で動いた記録だ。アップデート後も同じように動くとは限らない。 環境と構成 項目 今回の環境 GPU Radeon VII、VRAM 16GB、gfx906 CPU Ryzen 5 3600、6コア12スレッド、AVX2 RAM 公称64GB、OSから約60.7GiB OS Ubuntu 26.04.1 LTS カーネル 7.0.0-42-generic、標準のamdgpu/KFD ROCm TheRock nightly 10.3.0a20261102、gfx906向け HIPのバージョン表示 7.18.26434 推論 Strata v0.2.10、gfx906用ソースビルド モデル ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF、Q2_0 コーディングUI OpenCode v1.19.5 Flash-Nextは本体125B、1トークンで有効になるのは約6BのMoEモデルで、別に51BのN-gram参照テーブルがある。Q2_0はパラメーターを削った小型モデルではなく、重みを量子化したものだ。Qwenの説明と量子化版の配布元を参照してほしい。 構成は大きく3層だ。 Ubuntu標準のamdgpu/KFDがGPUを扱う。 gfx906向けROCmのユーザー空間ライブラリとHIPが計算を担当する。 StrataがモデルをGPU・RAM・ストレージに配置し、ローカルAPIを公開する。 コンテナは使わず、ROCmやビルド成果物はホームディレクトリ下に分離した。システムのドライバやAPTリポジトリは変更していない。 まずamdgpuとKFDを確認する 画面が映っているだけではGPU計算が動くとは限らない。まずカーネルドライバとデバイスノードを確認した。 uname -a lspci -nnk | grep -A 4 -i 'vga|display|3d' ls -l /dev/kfd /dev/dri getfacl /dev/kfd /dev/dri/renderD128 このPCでは1002:66afのRadeon VIIをamdgpuが使用し、/dev/kfdとrenderD128にはログインユーザー向けのACLが付いていた。アクセス権の設定方法は環境によって異なる。/dev/dri/renderD128も固定とは限らないので、自分の環境で確認しよう。 gfx906向けROCmをユーザー領域へ TheRockの対応表ではgfx906はビルド対象だが、Sanity Tested・Release Readyにはチェックがない。配布されていることと、実機で動作検証されていることは別だ。 今回はAMDのnightlyから、同じ日付のSDK・ライブラリ・開発ツール・gfx906向けデバイスコードを仮想環境に揃えた。uvは別途用意した。以下の版は実験時点の固定値で、nightlyの保持期間や配布状態によっては取得できなくなる可能性がある。 uv venv ~/rocm-gfx906/venv uv pip install --python ~/rocm-gfx906/venv/bin/python \ --index-url nightly.repo.amd.com \ 'rocm[libraries,devel,device-gfx906]==10.3.0a20261102' source ~/rocm-gfx906/venv/bin/activate rocm-sdk init export ROCM_PATH="$(rocm-sdk path --root)" export HIP_PATH="$ROCM_PATH" export PATH="$ROCM_PATH/bin:$PATH" export LD_LIBRARY_PATH="$ROCM_PATH/lib:$ROCM_PATH/lib64${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" rocminfo これは配置先を分かりやすく書き直した再現例だ。実機では~/.local/share/rocm-gfx906/venvを使った。Ubuntu標準のPythonではvenvのensurepipがなかったため、uvで作成した。 rocminfoではRadeon VIIがgfx906:sramecc+:xnack-として見えた。さらにHIPで4,096要素のベクトル加算、rocBLASで2×2と512×512の行列積を検証した。SDK付属テストも27項目が通過した。 HIP compiled vector addition: PASS (4096 elements) rocBLAS SGEMM 512x512 identity product: PASS Ran 27 tests ... OK amdflangは最初、libquadmath.so.0不足で起動しなかった。今回はlibquadmath0をapt downloadしてユーザー領域に展開し、ライブラリパスを通して解決した。同様にC++開発ヘッダーとGCCの開発ライブラリもユーザー領域へ展開した。一般的な環境では、必要な開発パッケージをディストリビューションの方法で揃える方が簡単だ。無関係なUbuntu版のROCmパッケージを混ぜないようにした。 最初にllama.cppでGPU推論を確認 Strataに進む前に、llama.cppをHIP有効・gfx906指定でビルドした。使用したllama.cppのコミットはf9448cddc48c129a4abc7ff9c2a84c2b4c101c61だ。ビルド方法の基本はllama.cppの公式ドキュメントにある。 llama-cli --list-devicesにROCm0: AMD Radeon VIIが表示され、Qwen2.5-0.5BのGGUFで短い生成に成功。次にQwen3.8-27BのUD-Q3_K_XLも試した。モデルファイルは約13.2GBだ。 llama-server -m /path/to/Qwen3.8-27B-UD-Q3_K_XL.gguf \ -ngl 99 -c 4096 -np 1 --host 127.0.0.1 --port 8082 日本語の短い質問に正常回答し、会話では約21〜22 tokens/s。後にログを詳細化して、66/66層がGPUに配置されていることも確認した。別の8K設定では、約7,390トークンの合成入力を約240 tokens/sで処理した。いずれも今回のハードウェアと設定での観測だ。 Strataをgfx906向けにビルドする StrataのAMD向けドキュメントには、gfx906をwave64互換レイヤーでビルドする手順がある。配布済みのRX 6000/7000/9000向けバイナリをRadeon VIIに流用するのではなく、専用のSTRATA_HIP_GFX906経路を使う。 Strata v0.2.10のソースと、プロジェクトが指定するllama.cppコミット3cf03257f219afbe7334045ff7c6a06ac68c627dを用意した。システムにC/C++開発環境、CMake、Ninja、ROCmの開発ツールが必要だ。 STRATA_SRCとLLAMA_SRCは、それぞれ取得・展開したソースディレクトリ cmake -S "$STRATA_SRC" -B "$STRATA_SRC/build-906" -G Ninja \ -DSTRATA_HIP_GFX906=ON \ -DCMAKE_HIP_ARCHITECTURES=gfx906 \ -DSTRATA_GGML_DIR="$LLAMA_SRC" \ -DCMAKE_C_COMPILER="$ROCM_PATH/bin/amdclang" \ -DCMAKE_CXX_COMPILER="$ROCM_PATH/bin/amdclang++" \ -DCMAKE_PREFIX_PATH="$ROCM_PATH" \ -DCMAKE_BUILD_TYPE=Release cmake --build "$STRATA_SRC/build-906" --target strata strata-device -j 6 実機ではシステムにGCC開発環境がなかったため、APTからダウンロードして展開したlibstdc++-15-devとlibgcc-15-devを指す--gcc-toolchainをC/C++/HIPの各フラグに追加した。上は開発環境が通常の場所にある場合の基本形だ。 ビルド時に互換レイヤーの定義を追加した v0.2.10をそのままビルドすると、cudaDeviceGetStreamPriorityRangeとcudaStreamCreateWithPriorityが未定義になった。gfx906互換ヘッダーinclude/strata/platform/hip_compat/strata_hip.hに、対応するHIP APIへのマッピングを追加して再ビルドした。 #define cudaStreamCreateWithFlags hipStreamCreateWithFlags +#define cudaStreamCreateWithPriority hipStreamCreateWithPriority +#define cudaDeviceGetStreamPriorityRange hipDeviceGetStreamPriorityRange これは今回の版とビルドで必要だったローカル修正だ。将来の版では修正済みかもしれない。ビルド後、strata-device --selftest、gfx906向けGDN演算テスト、専門家演算の比較テストで失敗がないことを確認した。これらは全機能や長時間の安定性を保証するものではない。 Flash-Nextを準備して起動 モデルはISTA-DASLabのGGUFのQ2_0を選んだ。37.6GBの本体と28.8GBの参照テーブル、合わせて約66.4GBだ。今回使用したリビジョンはed59f92082b1e93c0e96d60a8b11aab089b52f09。両ファイルを配布元のSHA-256と照合した。 Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00001-of-00002.gguf SHA256 69820c02ec7d0b45ef2ebb19d6620299db749fe2aded7f39f93c6b88b199b720 Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00002-of-00002.gguf SHA256 316b46f3a2dbd68c900f43136ab9449f9dcc3725dfd8c794847c204bc161e113 転送が途中で停滞して再始動した際、最初の不完全ファイルを引き継がず、新しいファイルとして再取得した。完成後に古い不完全ファイル約17.6GBを削除した。大きなモデルでは、途中再開の動作と空き容量を確認したいところだ。 取得後、Strataに付属するtools/iq_pack.pyでインデックス、dense重み、トークナイザーを準備する。STRATA_GGUF_PYは上で用意した固定コミットのllama.cppにあるgguf-pyを指す。 export STRATA_GGUF_PY="$LLAMA_SRC/gguf-py" python "$STRATA_SRC/tools/iq_pack.py" \ --gguf /path/to/Q2_0/Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00001-of-00002.gguf \ --out /path/to/pack-q2_0 サーバー設定には、ビルドしたstrata、pack、2つのGGUF、付属のdata/expert-profile.binを指定する。主要なエンジン引数は次のとおりだ。 { "exe": "/path/to/build-906/strata", "cwd": "/path/to/Strata", "tokenizer": "/path/to/pack-q2_0/tokenizer", "model_name": "Qwen3.8-Flash-Next-Q2_0-gfx906", "backend": "hip", "gpu": 0, "parallel": 1, "drafting": "off", "args": [ "--pack", "/path/to/pack-q2_0", "--native", "/path/to/Q2_0/Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00001-of-00002.gguf", "--ple-gguf", "/path/to/Q2_0/Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00002-of-00002.gguf", "--expert-profile", "/path/to/Strata/data/expert-profile.bin", "--expert-cache", "auto", "--prefill", "auto", "--max-context", "262144", "--kv", "int8", "--kv-resident", "32768", "--ple-io", "direct", "--spec", "2" ] } パスは自分の環境に置き換える。Pythonの依存パッケージは別の仮想環境にrequirements.txtから導入し、ROCmのライブラリパスも通した状態で、ソースルートからサーバーを起動した。 cd "$STRATA_SRC" python -m serve.server --engine strata --config /path/to/config.json \ --host 127.0.0.1 --port 8081 最初は--specを付け忘れ、ネイティブpackには--spec T (T >= 2)が必要だとエラーになった。--spec 2を追加すると読み込みが進み、日本語での応答に成功した。ここでの--spec 2はエンジンの指定で、MTP補助モデルを導入したという意味ではない。今回draftingはoffだ。 サーバーはローカルのみにbindしている。稼働確認は以下で行える。 curl -s 127.0.0.1 curl -s 127.0.0.1 8Kから32K、256Kへ まず8,192トークンで動作確認し、その後32,768へ増やした。約30,417トークンの合成入力の中央に置いた合言葉を正しく回収できた。入力処理は約71.8秒、約424 tokens/sだった。 次に--max-context 262144 --kv int8 --kv-resident 32768で起動。約248,458トークンの入力でも、中央の合言葉を正しく回収できた。入力処理は約640秒、約388 tokens/sだった。 試行 結果 8K設定、短い会話 約35 tokens/sの生成を観測 32K設定、約30K入力 合言葉を正しく回収、入力約424 tokens/s 256K設定、約248K入力 合言葉を正しく回収、入力約388 tokens/s 長文は同じ日本語の文章を繰り返した合成データで、検索課題も一つだ。複雑な複数文書の理解、長時間稼働、異なるコンテンツで同じ精度・速度が出ることまでは確認していない。短い出力6トークンの生成速度を、長文回答の安定速度として扱うこともしない。 256K起動時は専門家キャッシュが8,235個、空きVRAMは約790MiBだった。GPUがデスクトップ表示も担当しているので余裕は小さめだ。--expert-cache autoやVRAM予約量の調整が必要になる場合がある。Strataのメモリ設定を確認してほしい。 また、今回のStrataの既定設定ではSTRATA_ROUTE_TAIL_SKIP=7が有効で、キャッシュにない専門家の一部を省略する。ログにも回答が少し変わり得ると表示される。7,390トークンの合成入力で1回ずつ試したところ、生成は有効時36.7 tokens/s、無効時33.7 tokens/sで、回答文も少し変わった。各1回の短い応答なので、この差を一般化したり品質差を判断したりはできない。 OpenCodeにつなぐ StrataのOpenAI互換APIを使う。OpenCode v1.19.5をユーザー領域に導入し、~/.config/opencode/opencode.jsonにローカルプロバイダーを追加した。設定形式はOpenCodeのプロバイダー設定を参照した。 { "$schema": "opencode.ai", "model": "strata/Qwen3.8-Flash-Next-Q2_0-gfx906", "provider": { "strata": { "npm": "@ai-sdk/openai-compatible", "name": "Strata (local Radeon VII)", "options": { "baseURL": "127.0.0.1", "apiKey": "local", "timeout": 1200000 }, "models": { "Qwen3.8-Flash-Next-Q2_0-gfx906": { "name": "Qwen3.8 Flash Next Q2_0 (local)", "tool_call": true, "limit": { "context": 262144, "output": 8192 } } } } } } モデルIDは/v1/modelsが返すIDと一致させる。既存設定がある場合は丸ごと置き換えず、必要なプロバイダーを統合してほしい。apiKeyはこのローカルの無認証サーバーに渡すダミー値だ。 opencode models strata opencode 簡単な接続確認として、OpenCodeにテストファイルを読むよう依頼したところ、readツールを呼び出し、ファイル内の合言葉を正しく返した。コードの変更や複雑なエージェント作業の品質までは、この時点では検証していない。 振り返り Radeon VIIの16GB VRAMだけにモデル全体を載せるのではなく、GPUの専門家キャッシュ、RAM、SSDを組み合わせることで、Flash-Nextの推論までたどり着けた。gfx906は標準的な導入経路から外れているため、GPU認識だけで成功とせず、HIP、行列演算、エンジン、実モデル、ツール呼び出しの順に確かめるのが役立った。 一方、今回はnightly ROCm、ソースビルド、互換ヘッダーへの小さな修正を使っている。Qwen3.8-27BはStrataではなくllama.cppで動かしており、Strataで同じ27Bが動くという話ではない。まずは手元で動いた版と設定を記録し、更新するときは一つずつ比較していこうと思う。 この記事について 実はこの記事も、実際に環境を構築したChatGPTのセッションで書いた。会話の中で調べたこと、実行したコマンド、ログに残った測定結果をもとにChatGPTが下書きした。OpenCodeではファイル読み取りツールの呼び出しまで確認したが、複雑なコード修正の成功率はまだ測っていない。これから、この環境でどこまでできるか試していきたい。

未対応のGGUFをStrataで動かす：Qwen3.8 Distill Q4_K_MのCUDA改修と数値検証 普段、ローカル環境ではEmperoのQwen3.8-35B-A3B-Distill-GGUFをllama.cppで使用していた。最近、100B パラメーターを超えるような大規模なモデルをローカル環境で実行可能なStrataが注目されている。 Qwen3.8-35B-も同様のエンジンで実行できれば管理するツールを少なくできると考え検討を進めた。 ここでは、モデルの取得から、CUDAビルド、エラーの原因調査、llama.cppとの数値比較までを紹介する。 結論から述べると、Q4_K_Mのモデルは2か所の修正で起動し、RTX 8000 (48 GB) 単体で推論できた。 さらに、同じGGUFを使用したllama.cppとの比較では、回答546ステップの平均KL divergenceが0.00194となり、llama.cpp自身のCPU/GPU間の差 (0.00358) より小さかった。ただし、これは特定の環境・モデルでの検証結果であり、すべてのQ4_Kモデルへの対応を保証するものではない。 ! この記事は2026年11月3日時点の検証記録であり、Strata公式の修正ではない。既存のStrataインストールや他のモデル用エンジンは変更せず、検証専用ソースからビルドした。 1. 何を検証したのか LLMを動かすには、モデルの重みと推論エンジンの両方が必要になる。モデルは学習済みの数値データで、エンジンはその数値を使って次の単語を計算するプログラムと考えると分かりやすい。 今回の組み合わせは次のとおり 項目 内容 モデル Empero Qwen3.8-35B-A3B-Distill モデル形式 GGUF、Q4_K_M、約21.7 GB (配布ページ表記) 推論エンジン Strata v0.2.10 (改修版) 比較対象 llama.cpp (固定コミット) OS Ubuntu Linux 主なGPU NVIDIA Quadro RTX 8000 48 GB (Compute Capability 7.5) 別に搭載したGPU RTX 5060 Ti 16 GB (今回は使用しない) ソフトウェア Git、CMake、Ninja、C++コンパイラ、CUDA Toolkit、Pixi GGUF・量子化・MoE GGUFは、モデルの重みや構成情報を保存するファイル形式で、今回使ったQ4_K_Mは量子化形式の名称で、大きな重みを主に4ビット程度で圧縮して保存している。 圧縮するとGPUメモリ使用量を減らせる一方、エンジンは各形式に合った復号・計算処理を実装している必要がある。 今回対象のモデル名の35B-A3Bは、総パラメータがおよそ350億、1トークンの計算で使うパラメータがおよそ30億という意味である。 これは **MoE (Mixture of Experts) ** という構造によるもので、MoEでは入力に応じて一部の小さなネットワーク (Expert) を選択する。Expert内部にはGate/UpとDownという行列があり、Strataではそれぞれに対応する量子化形式を登録している。 2. 検証用の作業環境の作成 以下のコマンドは同じターミナルで順番に実行する。WORKなどの変数は、そのターミナル内でのみ有効である。パスは例示用の作業ディレクトリを基準にし、各自の環境へ置き換える必要がないようにした。 WORK="${PWD}/empero-strata-test" mkdir -p "${WORK}" && cd $_ Python環境はPixiで管理する export PIXI_VERSION="latest" export PIXI_HOME="${PWD}/tools/pixi" export PIXI_BIN_DIR="${PIXI_HOME}/bin" export PIXI_CACHE_DIR="${PWD}/.cache/pixi" export PIXI_NO_PATH_UPDATE=1 export TMP_DIR="${PWD}/tmp" mkdir -p "${PIXI_HOME}" "${PIXI_BIN_DIR}" "${PIXI_CACHE_DIR}" "${TMP_DIR}" curl -fsSL pixi.sh | sh export PATH="${PIXI_BIN_DIR}:${PATH}" pixi init --channel conda-forge . pixi add python=3.12 numpy huggingface_hub Pixiが未導入なら公式インストール手順を参照する。nvcc、CMake、Ninja、C++コンパイラが見つからない場合は、先にビルド環境を用意する。PixiはPythonパッケージを管理するが、CUDAドライバを代わりにインストールするわけではない。 3. モデルをHugging Faceから取得 今回のモデルは、Hugging Faceの以下のリポジトリで配布されている。 huggingface.co 複数の量子化形式があるが、検証したファイルはQwen3.8-35B-A3B-Q4_K_M.ggufである。hf downloadなら、必要なGGUFだけを取得できる。 mkdir -p "$WORK/models" pixi run hf download \ empero-ai/Qwen3.8-35B-A3B-Distill-GGUF \ Qwen3.8-35B-A3B-Q4_K_M.gguf \ --local-dir "$WORK/models" 4. Strata v0.2.10のソースを取得 StrataはGPU向けのローカルLLM推論エンジンである。今回は通常のアプリやインストール済みのstrataコマンドを改造せず検証専用のソースを取得した。 SRC="$WORK/Strata-v0.2.10-empero" git clone --branch v0.2.10 --depth 1 \ Niko1221/Strata "$SRC" cd "$SRC" git describe --tags --always -> v0.2.10 ! 当初、公式ソースのままモデルを起動しようとすると、GGUFの形式がStrataの通常のモデル選択に登録されていなかった。そこでstrata launchではなく、Qwen3.6系のGGUFを読み込む実行ファイルstrata-q36を直接使用した。 エラー1：SSMのQ4_Kを読み込めない 実行時、次のエラーで停止した。 strata-q36: blk.0.ssm_alpha.weight is Q4_K, expected F32, BF16, F16 or Q8_0 ssm_alphaは、モデル内部の Gated DeltaNet (状態を保持しながら計算する仕組み) で使われる重みで、Strataのupload_f32()はこれをGPU上で32ビット浮動小数点数 (F32) として利用するが、元のGGUFにあるQ4_K形式を展開する処理が不足していた。 つまり、保存形式を読み取るコードが対応していなかった。 5. パッチ1：SSMのQ4_K復号を追加 src/qwen35/q36_engine.cu内のupload_f32()にQ4_KからF32への展開処理を追加した。次のPythonスクリプトは、既存のQ8_0分岐の直前にコードを挿入する。元のGGUFは書き換えない。 pythonコード cd "$SRC" pixi run python3 - <<'PY' from pathlib import Path p = Path("src/qwen35/q36_engine.cu") s = p.read_text() anchor = " else if (t.type == 8 && h.size() % 32 == 0) {" marker = "// Empero Q4_K -> F32" patch = r''' else if (t.type == 12 && h.size() % 256 == 0) { // Empero Q4_K -> F32 for (size_t bi = 0; bi < h.size() / 256; ++bi) { const uint8_t* b = src + bi * 144; const uint16_t hd = uint16_t(b[0]) | (uint16_t(b[1]) << 8); const uint16_t hm = uint16_t(b[2]) | (uint16_t(b[3]) << 8); const float d = f16_to_f32(hd); const float dmin = f16_to_f32(hm); const uint8_t* scales = b + 4; const uint8_t* qs = b + 16; for (int j = 0; j < 8; ++j) { int sc, m; if (j < 4) { sc = scales[j] & 63; m = scales[j + 4] & 63; } else { sc = (scales[j + 4] & 15) | ((scales[j - 4] >> 6) << 4); m = (scales[j + 4] >> 4) | ((scales[j] >> 6) << 4); } for (int k = 0; k < 32; ++k) { const uint8_t q = qs[32 * (j / 2) + k]; const int v = (j & 1) ? (q >> 4) : (q & 15); h[bi * 256 + j * 32 + k] = (d * sc) * v - (dmin * m); } } } } ''' if marker in s: print("Patch 1 already applied") else: assert s.count(anchor) == 1, "想定と異なるソース構造です" p.write_text(s.replace(anchor, patch + anchor, 1)) print("Patch 1 applied") PY Patch 1 applied Q4_Kでは、256個の値を1ブロックとして圧縮しており、この実装では各ブロックのスケール情報と4ビット値からF32を復元する。復号方法はStrata内の参照実装q36ref.cuと照合した。なお、この修正は今回の形状で動作したものであり、あらゆるテンソル形状に対して検証済みという意味ではない。 6. パッチ2：Expert DownのQ4_Kの有効化 最初の修正でSSMのエラーは解消したが、次に以下のエラーが出た。 strata-q36: blk.5.experts are Q4_K/Q4_K, which the native expert kernels do not take (build with -DSTRATA_Q6K_EXPERTS=ON for Q6_K) 末尾にQ6_Kのビルドオプションが表示されているが、今回の原因はQ4_KをExpertのDown側に登録していなかったことだった。 src/kernels/cuda/iq_kernels.cuにはSTRATA_GU_FMTSとSTRATA_D_FMTSという対応形式一覧があり、Q4_K (型番号12) はGate/Up側には存在したがDown側にはなかった。そこで、Down側の一覧にX(12)を追加した。 pythonスクリプトcd "$SRC" python3 - <<'PY' from pathlib import Path p = Path("src/kernels/cuda/iq_kernels.cu") lines = p.read_text().splitlines(keepends=True) found = changed = 0 for i, line in enumerate(lines): if not line.startswith("#define STRATA_D_FMTS(X)"): continue found += 1 if "X(12)" in line: continue assert line.count("X(13)") == 1 lines[i] = line.replace("X(13)", "X(12) X(13)", 1) changed += 1 assert found == 2, f"想定外の定義数: {found}" if changed: p.write_text("".join(lines)) print(f"Patch 2: {changed} definitions updated") PY -> Patch 2: 2 definitions updated 差分確認するなら git diff -- src/qwen35/q36_engine.cu src/kernels/cuda/iq_kernels.cu 既存のQ4_K計算コードをDown側でも呼び出せるようにする修正となっている。変更内容は小さいが、ソース側で対応を宣言しただけでは数値が正しいとは限らないため後述の検証を行った。 7. 修正済みStrataをCUDAビルド CMakeはビルド設定を作るツール、Ninjaは実際のコンパイル処理を進めるツールである。 今回はRTX 8000 (SM 7.5) とRTX 5060 Ti (SM 12.0) の両方に対応する形式でコンパイルした。実際のベンチマークにはRTX 8000だけを使用している。 BUILD="$SRC/build-q36-empero" cmake -S "$SRC" -B "$BUILD" -G Ninja \ -DCMAKE_BUILD_TYPE=Release \ -DSTRATA_ENABLE_CUDA=ON \ -DSTRATA_NATIVE_EXPERTS=ON \ -DSTRATA_Q6K_EXPERTS=ON \ -DSTRATA_MMQ_KQUANTS=ON \ -DCMAKE_CUDA_ARCHITECTURES="75-real;120-real" cmake --build "$BUILD" --target strata-q36 -j 32 -> [165/165] Linking CXX executable strata-q36 SM 12.0に未対応のCUDA Toolkitではビルドできないので、その場合は対応するCUDA Toolkitを使用するか、RTX 8000専用として-DCMAKE_CUDA_ARCHITECTURES=75に変更する。CPUスレッド数に合わせて-j 32は調整できる。 8. 起動と速度測定 --modelでGGUFファイルを指定する。CUDA_VISIBLE_DEVICES=0はGPUを1台に限定する設定である。番号0がどのGPUかはnvidia-smiで確認しておく。 GGUF=${WORK}/models/Qwen3.8-35B-A3B-Q4_K_M.gguf CUDA_VISIBLE_DEVICES=1 "$BUILD/strata-q36" \ --model "$GGUF" \ --max-context 8192 \ --bench-pp 2048 \ --bench-tg 128 \ --mtp 0 \ --no-warmup Logstrata-q36: <...>/empero-strata-test/models/Qwen3.8-35B-A3B-Q4_K_M.gguf: 753 tensors (layout checked), 1.65 GiB on the GPU in 1.1 s (the routed experts are placed after the engine's buffers) strata: K-quant prompt kernels from <...>/empero-strata-test/Strata-v0.2.10-empero/build-q36-empero/libstrata_kq.so (STRATA_MMQ_KQ=1) strata-q36: prompt experts on MMQ (int8) strata-q36: context 8192 cells, prompt chunk 4096, MTP block loaded, 42.16 GiB of VRAM free strata-q36: every routed expert in VRAM (18.66 GiB) in 6.6 s bench 0: pp2048 3391.4 tok/s, tg128 101.7 tok/s bench 1: pp2048 3470.4 tok/s, tg128 102.1 tok/s bench 2: pp2048 3478.2 tok/s, tg128 102.0 tok/s ppは入力を読み込む速度 (Prefill) 、tgは回答を1トークンずつ生成する速度 (Decode) である。--mtp 0は投機的デコードを無効化する指定であり、今回の比較では計算経路を単純にするために使用した。 実測では、753テンソルの構造検証を通過し、Expertの重み18.66 GiBをすべてVRAMに配置できた。 試行 Prefill (pp2048) Decode (tg128) 0 pp2048 3391.4 101.7 1 pp2048 3470.4 102.1 2 pp2048 3478.2 102.0 これはRTX8000単体、Context上限8,192の測定である。測定に使用したのはベンチマーク用トークン列なので自然言語の回答品質を示す数字ではない。 9. 比較用のllama.cppを取得してビルド 「エラーなく動く」ことと「計算が正しい」ことは異なる。そこで、同じGGUFを対応済みのllama.cppでも実行し、計算結果を比較した。 再現性を高めるため、llama.cppはStrata v0.2.10が参照しているコミット3cf03257f219afbe7334045ff7c6a06ac68c627dに固定した。 LLAMA_SRC="$WORK/llama.cpp-parity" LLAMA_SHA="3cf03257f219afbe7334045ff7c6a06ac68c627d" git clone --depth 1 ggml-org/llama.cpp "$LLAMA_SRC" git -C "$LLAMA_SRC" fetch --depth 1 origin "$LLAMA_SHA" git -C "$LLAMA_SRC" checkout --detach "$LLAMA_SHA" git -C "$LLAMA_SRC" rev-parse HEAD ビルドするのはllama.cppの推論ライブラリである。 LLAMA_BUILD="$LLAMA_SRC/build-parity" cmake -S "$LLAMA_SRC" -B "$LLAMA_BUILD" -G Ninja \ -DCMAKE_BUILD_TYPE=Release \ -DGGML_CUDA=ON \ -DBUILD_SHARED_LIBS=ON \ -DLLAMA_BUILD_TESTS=OFF \ -DLLAMA_BUILD_EXAMPLES=OFF \ -DCMAKE_CUDA_ARCHITECTURES=75 cmake --build "$LLAMA_BUILD" --target llama -j 32 -> [222/222] Creating library symlink bin/libllama.so.0 bin/libllama.so 次に、Strata付属のq36_llama_dump.cppをコンパイルした。このツールはllama.cppのトークンID・各層の出力・ logits (次トークンの候補ごとの点数) をファイルに保存するためのもの。 TOOLS="$WORK/tools" mkdir -p "$TOOLS" g++ -O2 -std=c++17 \ "$SRC/tools/qwen35/q36_llama_dump.cpp" \ -I"$LLAMA_SRC/include" \ -I"$LLAMA_SRC/ggml/include" \ -L"$LLAMA_BUILD/bin" \ -Wl,-rpath,"$LLAMA_BUILD/bin" \ -lllama -lggml -lggml-base -pthread \ -o "$TOOLS/q36_llama_dump" ldd "$TOOLS/q36_llama_dump" | grep -E 'llama|ggml|not found' Strataの独立した参照実装もビルド cmake --build "$BUILD" --target strata-q36ref -j 32 -> [2/2] Linking CXX executable strata-q36ref lddでnot foundが表示されなければ、共有ライブラリが解決できている。 10. 数値的な正しさの比較 文章を読んで「自然だから正しい」と判断するだけでは、GPU用の計算処理の検証として不十分である。今回はStrata公式のtools/qwen35/にある比較スクリプトを使用した。 比較の対象は3種類 llama.cpp GPU：比較の基準となる計算結果 llama.cpp CPU：同じソフトウェアでもCPUとGPUでどれだけ差が出るか Strata：今回修正した高速エンジン。必要に応じて逐次参照実装strata-q36refとも比較 まず10種類の問題で回答を比較 parity.pyは、短い物語・Pythonコード・計算問題・説明文など、10種類のプロンプトで比較を行う。 RESULTS="$WORK/results" mkdir -p "$RESULTS" && cd $_ pixi run python "$SRC/tools/qwen35/parity.py" \ --ref "$BUILD/strata-q36ref" \ --dump "$TOOLS/q36_llama_dump" \ --model "$GGUF" \ --out "$RESULTS/parity-10" \ --n 64 Logp00: 48/64 greedy tokens equal; layers max rel err 0.7524 (layer 36), median 0.03055; diverges at {'step': 48, 'strata': [34227, 0.004119873046875], 'llama': [25292, 0.03865623474121094]} p01: 3/64 greedy tokens equal; layers max rel err 0.1742 (layer 39), median 0.04114; diverges at {'step': 3, 'strata': [1445, 0.04456138610839844], 'llama': [1005, 0.011854171752929688]} p02: 64/64 greedy tokens equal; layers max rel err 0.4023 (layer 26), median 0.04085 p03: 8/64 greedy tokens equal; layers max rel err 0.1388 (layer 11), median 0.03517; diverges at {'step': 8, 'strata': [8364, 0.19606590270996094], 'llama': [27286, 0.184661865234375]} p04: 15/15 greedy tokens equal; layers max rel err 0.2196 (layer 36), median 0.04316 p05: 64/64 greedy tokens equal; layers max rel err 0.2272 (layer 39), median 0.02473 p06: 17/64 greedy tokens equal; layers max rel err 0.1535 (layer 35), median 0.03603; diverges at {'step': 17, 'strata': [506, 0.10254287719726562], 'llama': [321, 0.23025894165039062]} p07: 52/52 greedy tokens equal; layers max rel err 0.3421 (layer 36), median 0.03568 p08: 64/64 greedy tokens equal; layers max rel err 0.1636 (layer 35), median 0.03495 p09: 17/24 greedy tokens equal; layers max rel err 0.1314 (layer 36), median 0.03526; diverges at {'step': 17, 'strata': [47, 0.023038864135742188], 'llama': [1948, 0.08147048950195312]} identical greedy answers (up to 64 tokens or the end of the answer): 5 of 10 prompts; worst layer error 0.7524 この検証では、10問中5問が回答終了まで同じGreedyトークン列となった。残りの5問は途中で違うトークンを選んだ。ただし、ひとたび違うトークンを選ぶと、その後の入力履歴も変わるので、これだけでは数値誤差の大きさを判断できない。 同じ入力履歴を与えて確率分布を比較 そこでkl.pyを使った。ここではllama.cppが生成したトークンを各実装に強制的に与えるTeacher forcingを行う。たとえるなら、2人の学生に前の問題の答えを同じように渡し、次の問題でどれだけ異なる計算結果を出すか比較するような方法である。多分。 次トークンの確率分布の差を、KL divergenceで測定する。KLは0に近いほど分布が一致する。また、確率が最大のトークン (Top-1) が同じかも調べる。 pixi run python "$SRC/tools/qwen35/kl.py" \ --ref "$BUILD/strata-q36" \ --dump "$TOOLS/q36_llama_dump" \ --model "$GGUF" \ --parity "$RESULTS/parity-10" \ --out "$RESULTS/kl-10" \ --ref-args "--max-context 4096 --chunk 512 --mtp 0 --no-graph --no-warmup" Logp00: 65 steps (65 answer); cpu: KL 0.01036 (answer 0.01036) top-1 0.938; strata: KL 0.00314 (answer 0.00314) top-1 0.985 p01: 65 steps (65 answer); cpu: KL 0.00073 (answer 0.00073) top-1 1.000; strata: KL 0.00053 (answer 0.00053) top-1 1.000 p02: 65 steps (65 answer); cpu: KL 0.00172 (answer 0.00172) top-1 0.985; strata: KL 0.00218 (answer 0.00218) top-1 0.969 p03: 65 steps (65 answer); cpu: KL 0.00475 (answer 0.00475) top-1 0.985; strata: KL 0.00259 (answer 0.00259) top-1 0.985 p04: 65 steps (15 answer); cpu: KL 0.01299 (answer 0.00063) top-1 0.985; strata: KL 0.01192 (answer 0.00110) top-1 0.985 p05: 65 steps (65 answer); cpu: KL 0.00139 (answer 0.00139) top-1 0.985; strata: KL 0.00097 (answer 0.00097) top-1 0.985 p06: 65 steps (65 answer); cpu: KL 0.00530 (answer 0.00530) top-1 0.969; strata: KL 0.00322 (answer 0.00322) top-1 0.985 p07: 65 steps (52 answer); cpu: KL 0.01820 (answer 0.00106) top-1 0.985; strata: KL 0.01739 (answer 0.00060) top-1 0.969 p08: 65 steps (65 answer); cpu: KL 0.00251 (answer 0.00251) top-1 0.985; strata: KL 0.00132 (answer 0.00132) top-1 1.000 p09: 65 steps (24 answer); cpu: KL 0.02208 (answer 0.00619) top-1 0.954; strata: KL 0.01900 (answer 0.00447) top-1 0.969 -- all steps cpu vs llama.cpp HIP: mean KL 0.00800 (median 0.000373, p99 0.1727), top-1 0.9769 over 650 steps strata vs llama.cpp HIP: mean KL 0.00623 (median 0.000241, p99 0.1144), top-1 0.9831 over 650 steps ratio strata / floor: 0.78 -- answers only cpu vs llama.cpp HIP: mean KL 0.00358 (median 0.000307, p99 0.0339), top-1 0.9780 over 546 steps strata vs llama.cpp HIP: mean KL 0.00194 (median 0.000149, p99 0.0194), top-1 0.9853 over 546 steps ratio strata / floor: 0.54 kl.pyでは、修正済みの高速Strataとllama.cpp GPUを、同一のトークン列を入力するTeacher-forced方式で比較した。また、llama.cpp CPU/GPU間の誤差を基準値とした。ログ中のHIPは固定表記であり、実際にはCUDAを使用した。 測定範囲 比較対象 Mean KL Top-1一致率 全650ステップ llama.cpp CPU 0.00800 97.69% 全650ステップ 修正済みStrata 0.00623 98.31% 回答546ステップ llama.cpp CPU 0.00358 97.80% 回答546ステップ 修正済みStrata 0.00194 98.53% 回答範囲での平均KL比は0.54倍となり、Strata公式の評価目安である1.5倍以内を満たした。 一方、Greedy生成では10プロンプト中5件が完全一致した。残り5件は途中で生成トークンが分岐したが、Teacher-forced比較では入力履歴を統一しているため、98.53%のTop-1一致率と矛盾しない。 別途実施した17ステップの比較では、高速Strataと参照実装strata-q36refのTop-1が17/17で一致し、平均KLは0.00029681だった。 以上から、今回のQ4_K対応による大きな数値的不整合は認められなかった。ただし、個々のQ4_K演算の完全な正しさを証明するものではない。 おわり。 参考資料 Empero Qwen3.8-35B-A3B-Distill-GGUF (Hugging Face) Strata v0.2.10 (GitHub Release) SSM読み込み処理：q36_engine.cu ExpertのCUDAカーネル：iq_kernels.cu llama.cppの出力取得ツール：q36_llama_dump.cpp Strataの生成一致検証：parity.py StrataのKL検証：kl.py Hugging Face CLI：hf download

LFM3が登場したので、いくつかのモデルと比較してみた【ご参考まで】 はじめに 2026年10月27日、Liquid AIから新しいモデル「LFM3」が公開されました。 私は個人で、ローカルAIを使ったテキストエディタ「OnecaratEditor」を開発しています。無料版（Free）の標準モデルは、同じLiquid AIのLFM2.5-1.2B-JPです。有料版のOnecaratEditor Coreでは、これに加えてGemma 4 E4Bを選べるようにしています。 同じメーカーから新しい世代のモデルが登場したので、気になったのは次の点でした。 「LFM3に置き換えたほうが、アプリの使い勝手は良くなるのだろうか？」 モデルの公開ベンチマークは参考になりますが、私が知りたいのは、実際にアプリで使っている要約、校正、翻訳、議事録作成などで違いが出るかどうかです。 そこで、現行のLFM2.5、日本語処理の置き換え候補としてLFM3の2種類、比較用にGemma 4を加えた4モデルで検証してみました。 結果がまとまったので、今回はその比較データと、LFM3について分かったことを参考程度に公開しておきます。 結論から書くと、OnecaratEditorの標準モデルは、Free版・Core版ともに現時点ではLFM2.5-1.2B-JPのままにすることにしました。ただし、LFM3にも良くなっている部分があり、単純に「新モデルのほうが悪い」という結果ではありません。 ! この記事は、OnecaratEditorの用途、検証条件、2026年11月時点の推論環境で得られた結果です。モデル全体の性能を順位付けするものではありません。LFM3のツール呼び出しや長いコンテキストを使う能力は、今回の比較では評価していません。 1. LFM3はどんなモデルなのか 最初に、LFM3について簡単に整理します。 今回試したLFM3-1.7Bは、約17億パラメータのテキストモデルです。Liquid AIの公開情報によると、ローカル環境で動かすエージェントや、特定用途に合わせた利用を想定しています。 主な特徴は次のとおりです。 項目 LFM3-1.7Bの特徴 パラメータ数 約1.73B モデルの構造 畳み込み、Sliding-Window Attention（SWA）、Global Attentionを組み合わせた構造 コンテキスト長 最大256Kトークン（モデル仕様上） 対応言語 日本語を含む16言語 主な想定用途 ローカルエージェント、ツール呼び出し、構造化出力、用途別の追加学習 4bitモデル 約1GBのGGUFが公開されている ※仕様はLiquid AIのモデルカードを参照しています。 ここでひとつ注意したいのは、LFM3-1.7Bと、私が使っているLFM2.5-1.2B-JPは、同じ条件のモデルではないことです。 LFM2.5-1.2B-JPは日本語向けのモデルですが、LFM3-1.7Bは多言語やエージェント用途も想定しています。パラメータ数も違います。 つまり、今回調べたいのは「どちらが優秀か」ではなく、日本語の文章処理を中心とするアプリで、標準モデルを変更する価値があるかという点です。 LFM3を2種類用意した理由 LFM3は、次の2つのGGUFを試しました。 量子化 ファイルサイズ 特徴 QAD-Q4_0 約1.05GB 量子化で失われた精度を補うために追加学習したモデル Q4_K_M 約1.1GB 一般的によく使われる4bit系の量子化 QADはQuantization-Aware Distillationの略です。Liquid AIの説明では、Q4_0への量子化で失われる精度を回復するよう学習したチェックポイントとされています。 そこで、「ファイルサイズが少し小さいQAD版のほうが、品質も良いのだろうか？」という点も比較してみることにしました。 2. 比較対象と検証方法 今回比較したモデルは次の4つです。 モデル 量子化 比較での位置づけ LFM2.5-1.2B-JP Q4_K_M 現行の標準モデル。比較基準 LFM3-1.7B QAD-Q4_0 新しい標準モデルの候補① LFM3-1.7B Q4_K_M 新しい標準モデルの候補② Gemma 4 E4B Q4_K_M Core版で選択できる高品質モデル。品質の比較対象 検証環境 項目 内容 CPU Ryzen 5 5600X GPU NVIDIA GeForce RTX 3060 12GB メモリ 32GB OS Windows 11 推論エンジン llama.cpp / llama-server（Vulkan、検証用b12058） 比較対象 OnecaratEditorで使う文章処理・チャットなど LFM3は新しいモデル構造のため、執筆時点でアプリに同梱しているllama.cpp b9193では読み込めませんでした。そこで、4モデルともLFM3に対応した同じ検証用ビルドで測定しています。 検証はClaude Codeで自動実行しました。実際のアプリで使っているプロンプトや設定を基準に、llama-serverへ直接リクエストを送る方式です。そのため、画面描画やアプリ内の通信中継にかかる時間は、以下の速度には含まれていません。 何を比較したのか 文章の要約、校正、翻訳、議事録生成、TODO抽出、チャット、JSON形式の出力など、28ケースを用意しました。 テストデータには架空の会社名、担当者名、会議内容を使用しています。通常の入力に加え、あえて扱いにくい文章や、高めのtemperatureを使う条件も含めました。 評価は大きく2つに分けています。 自動判定：必要な形式や項目がそろっているかなどを確認する 文章の採点：内容が正確か、元文書にない情報を作っていないか、指示を守っているかを確認する 文章の採点は、28ケース×4モデルの112出力を、モデル名を伏せてClaudeとChatGPTにそれぞれ評価してもらいました。評価が大きく分かれた出力は、私自身でも確認しています。 採点基準は5段階です。 点数 評価の目安 5 そのまま使える 4 軽微な表記調整だけで使える 3 手直しすれば使える 2 捏造・事実誤認・指示違反などがある 1 実用が難しい 特に厳しく見たのは、元文書にない数字、担当者、期限などを勝手に補っていないかです。 なお、この点数は難しいケースを含む独自テストの結果なので、普段の利用者の満足度を示すものではありません。 3. 品質比較：LFM3は良くなったのか まずは文章のブラインド評価です。 モデル 平均点 / 5 4点以上 捏造 言語混在 指示違反 LFM2.5-1.2B-JP 2.14 18% 13 2 13 LFM3 QAD-Q4_0 2.21 11% 6 4 14 LFM3 Q4_K_M 2.11 14% 5 6 18 Gemma 4 E4B 4.11 79% 2 0 3 ※各モデル28出力の結果です。「捏造」「言語混在」「指示違反」はそれぞれ独立に判定した該当出力の件数で、同じ出力が複数の項目に該当する場合もあります。 最初に気づくのは、LFM2.5とLFM3の平均点がほぼ同じということです。 QAD版は2.21点、Q4_K_M版は2.11点でした。現行モデルの2.14点と比べても、この28ケースの結果だけで明確な優劣があるとは判断できません。 ただ、平均点よりも興味深かったのは、間違え方が違っていたことです。 LFM3は捏造が減る一方、指示違反が増えた 元の文書にない内容を作ってしまうケースは、LFM2.5-JPの13件に対し、LFM3ではQAD版が6件、Q4_K_M版が5件でした。 この点はLFM3の良い傾向です。議事録やTODOのように、元の情報を正しく残すことが重要な用途では、捏造が減るのは歓迎したい変化です。 一方で、指定したタグを出さない、余計な前置きを付ける、原文をそのまま返すといった指示違反は、LFM3で増えました。 また、文章中に中国語や韓国語などの語が混ざるケースも、現行モデルより多くなっています。 つまり、今回の比較では、 「LFM3は内容を勝手に補うことが減った一方、出力形式や日本語だけで返すという条件には注意が必要」 という傾向が見えました。 もちろん、各28出力なので、すべての入力で同じ傾向が出るとは限りません。採用する用途に合わせて確認する必要がありそうです。 Gemma 4は品質に差があった 一方、Gemma 4 E4Bは平均4.11点、4点以上が79%でした。 今回の文章処理では、LFM系の3モデルよりも、指示を守りながら使える回答を出すケースが多い結果です。 ただし、Gemma 4はパラメータ規模や実行時の負荷が異なります。同じ大きさのモデル同士の勝負ではありませんし、品質だけで標準モデルを決められるわけでもありません。Core版でGemma 4を「標準」ではなく「選択できるモデル」にしているのも、この負荷の差が理由です。 小型モデルで気になった失敗例 今回の検証では、次のような出力がありました。 音声メモの「あした連絡する」が、TODOでは「今日連絡する」になる 修理金額の48,000円が40,000円になる 校正で、分かりやすい誤字があるのに原文を無修正で返す（これはLFM系の3モデルとも同じ挙動だったので、モデルというよりプロンプト側の問題と見ています） 議事録で、同じ文章のまとまりを繰り返してしまう 指定した出力形式には合っているのに、本文に誤った情報が含まれている これらは今回のテスト全体から見つかった例で、すべてが特定の1モデルに起きたという意味ではありません。 特に最後の点は重要だと感じました。自動判定がPASSでも、文章として正しく使えるとは限りません。 今回は、形式上はPASSだった出力のうち41件が、別途行ったブラインド採点では2点以下になりました。 モデルを比較するときは、JSONが出せるか、指定のタグが付くかだけでなく、中身まで見ないと判断を誤りそうです。 4. 速度比較：標準モデルとして使えるか 次は処理速度です。 文章の品質が良くなっても、普段の操作で待ち時間が大きく増えるなら、標準モデルへの採用は慎重になります。 GPUでの生成速度 本番計測での結果は次のとおりです。 モデル 自動判定PASS / 88 生成速度（文字/秒） VRAM（参考） LFM2.5-1.2B-JP 63 401 2.1GB LFM3 QAD-Q4_0 62 278 2.4GB LFM3 Q4_K_M 62 267 2.5GB Gemma 4 E4B 85 106 4.5GB ※自動判定の88件は、28ケース×3回（高めのtemperatureを使うケースは5回）の合計です。生成速度と自動判定は本番計測、VRAMは事前に行った22ケースのスモークテストで確認した値です。4モデルとも同一GPU・同一推論エンジンを使用しました。ここでの自動PASSは形式などの判定であり、前の表の文章採点とは別です。 LFM3は、現行のLFM2.5-JPに比べて、生成速度が約3割低い結果でした。 一方、Gemma 4は品質では大きく上回っていますが、生成速度はさらに低くなっています。 普段の要約や校正のように、短い操作を何度も行う用途では、この違いは無視しにくいところです。 CPUだけで動かした場合 同じPCでGPUへのオフロードを無効にしたところ、次のようになりました。 モデル 生成速度（token/秒） LFM2.5-1.2B-JP 41 LFM3 QAD-Q4_0 35 LFM3 Q4_K_M 34 Gemma 4 E4B 11 GPUの表は「文字/秒」、こちらは「token/秒」なので、数値をそのまま比較することはできません。 この測定は、Ryzen 5 5600Xを搭載した同じPCでのCPU-only実行です。低スペックノートPCで実測したわけではありません。 ただ、CPUだけで使う場合も、LFM3が現行モデルより少し遅く、Gemma 4はさらに負荷が大きいという傾向は確認できました。 応答が始まるまでの時間にも違いがあった もうひとつ確認したのが、TTFT（Time To First Token）です。 これは、リクエストを送ってから最初のトークンが返るまでの時間です。チャットでは、生成速度と同じくらい体感に影響することがあります。 TTFTは、プロンプトのキャッシュが効くかどうかで大きく変わります。そこで、起動直後（コールド）、キャッシュなしの初回、同じプロンプトの再送（キャッシュあり）の3つに分けて見ました。 モデル コールド 初回（キャッシュなし） 同一プロンプト再送 再送時に再処理したトークン数 LFM2.5-1.2B-JP 250 ms 69 ms 13 ms 4 LFM3 QAD-Q4_0 346 ms 111 ms 97 ms 454 LFM3 Q4_K_M 344 ms 112 ms 97 ms 454 Gemma 4 E4B 849 ms 278 ms 56 ms 5 ※いずれも中央値。再処理トークン数は再送時の中央値で、LFM3は129〜516トークンの幅がありました。 コールドと初回では、LFM3は現行モデルの1.4〜1.6倍ほど遅く、これはモデル自体の差です。 ただ、それ以上に気になったのが右の2列です。同じプロンプトを再送しているのに、LFM3では約450トークンを再処理していました。LFM2.5-JPは4トークン程度です。その結果、再送時のTTFTだけ13 ms対97 msと、7倍を超える差になっています。 LFM3にはSWA（Sliding-Window Attention）という構造が含まれています。今回使ったllama-server b12058では、その構造とコンテキストのチェックポイント復元処理の組み合わせによって、入力の一部が再処理されていることが分かりました。 つまり、再送時の差の大部分は推論エンジン側の要因で、モデル自体の差は「現行より少し遅い」程度です。LFM3が常に応答開始の遅いモデルというわけではありません。 実際、別途行った再現実験では、--swa-fullを指定すると再送時のTTFTが122 msから19 msに短縮されました。ただし、生成速度が193から169 token/秒に下がり、測定した処理全体の時間も増えます。損益分岐は出力約107トークンで、要約のように出力が数百トークンになる処理では総時間が悪化するため、今回は採用しませんでした。 このあたりは、推論エンジンの更新で変わる可能性があります。 5. LFM3を試して分かったこと ここまでの結果から、LFM3について気づいた点を整理してみます。 ① QAD-Q4_0とQ4_K_Mに明確な差は出なかった 自動判定はどちらも62/88件でPASS、文章採点も2.21点と2.11点でした。生成速度も近い値です。 後述する思考混入の出方も、スモークテストではQ4_K_M側だけ、本番ではQAD側だけと出る側が逆で、統計的にも有意ではありませんでした。両者を区別する材料にはなっていません。 QAD版のほうが良さそうに見える項目はありますが、今回のケース数では、積極的にQADを選ぶ根拠までは得られませんでした。 ただし、これはQADに効果がないという結論ではありません。量子化の影響を詳しく比較するなら、Q8_0なども含め、別の条件で評価したいところです。 ② 思考モードはOFFでも出力を確認したほうがよい LFM3は、モデル仕様上、思考（reasoning）が既定で有効です。Liquid AIのモデルカードにも、enable_thinking=Falseで無効化できるものの、動作が一貫しない場合があると説明されています。 今回も、思考OFFを指定しているのに、<think>関連の文が回答に混じるケースがありました。頻度は、思考OFFで流した全系列の合計で、QAD版が7/231件、Q4_K_M版が1/231件です。サーバー側で--reasoning offを併用した系列でも1/100件に減りはしますが、0にはなりませんでした。 特に、定型的な文章処理やJSON出力のように、回答本文だけを受け取りたい用途では注意が必要です。 これはLFM3を使えないという話ではありませんが、思考OFFの設定だけを信用せず、実際の出力を確認したほうがよさそうです。 なお、思考を有効にしたまま使う場合は別の注意があります。今回の検証では、Gemma 4 E4Bは思考を抑止しないと、思考で生成予算を使い切って本文が空のまま終わるケースがありました。小型モデルで思考モードを使うなら、生成トークン数の上限と合わせて確認する必要があります。 ③ 高いtemperatureでは言語混在が気になった 今回のテストでは、temperatureを0.95にした条件で、LFM系のモデルに言語混在や指示違反が目立ちました。LFM3でも、日本語の文中に別の言語が混ざる例がありました。 一方、今回試した0.4以下の条件では言語混在は確認されていません。ただし、0.5〜0.9の間は測定していないため、どこが境界になるかまでは分かりません。 Liquid AIが一般的なチャット用途向けに推奨しているtemperature=0.1などの設定も、ひとつの参考になりそうです。ただし今回の主目的は、アプリの既定設定での置き換え判断だったため、推奨設定での最適性能を競う比較ではありません。 ④ LFM3の本領は、今回とは別の用途にあるかもしれない LFM3-1.7Bは、ローカルエージェント、ツール呼び出し、長いコンテキストなども重視したモデルです。 今回のテストは、日本語の短い文章を要約する、校正する、指定形式に整えるといった処理が中心でした。 そのため、最大256Kトークンのコンテキストや、ツールを選んで呼び出す能力については、何も結論を出せません。 LFM3の公開ベンチマークと今回の結果が違って見えるとしても、測っている用途が異なります。エージェント機能を中心に据えたアプリなら、改めて評価する価値があると思います。 6. 結論：今回はLFM3への移行を見送る 今回の比較を踏まえて、OnecaratEditorでは次の判断にしました。 用途 判断 理由 標準モデル（Free / Core） LFM2.5-1.2B-JPを維持 今回の日本語処理でLFM3の明確な品質向上が見られず、速度も現行モデルが有利 LFM3 QAD-Q4_0 / Q4_K_M 標準採用を見送る 捏造が減る良さはあるが、指示違反・言語混在・速度も含めると置き換える理由が弱い Core版の選択モデル Gemma 4 E4Bを継続 品質は良いが処理速度と負荷が大きいので、GPU搭載機で品質を重視する場合の選択肢として エージェント・長コンテキスト 判断保留 今回は未評価。別の用途として検証が必要 ポイントは、LFM3の品質が現行モデルと近かったことだけではありません。 捏造が減ったのは良い変化 ただし、指示違反や言語混在には注意が必要 生成速度は今回の環境で約3割低い チャットの応答開始時間は、推論エンジンとの組み合わせにも左右される QAD版とQ4_K_M版に、採用判断を変えるほどの差は見られなかった 速度について、判断の決め手になった数字をひとつ挙げておきます。アプリで最も頻度の高い「チャットの2ターン目以降」のTTFTは、CPU-onlyの条件でLFM3が838 ms、LFM2.5-JPが44 msでした。前述のとおり、この差の大部分は推論エンジン側のキャッシュ処理によるものですが、現時点のユーザー環境ではこの差がそのまま体感に出ます。 これらを合わせて考えると、現時点のOnecaratEditorで標準モデルを変更するメリットは小さいと判断しました。 一方で、Gemma 4のように高い品質が出るモデルは処理も重くなります。小型のローカルLLMでは、品質だけでなく、処理速度や使う機能との相性を含めて選ぶ必要があります。 今後、llama.cppのキャッシュ周りの挙動が変わったり、長文処理やツール呼び出しを使う機能を評価したりする際には、LFM3をもう一度試すつもりです。 おわりに 新しいモデルが公開されると、どうしても試してみたくなります。 今回は、現在の標準モデルと同じLiquid AIの新世代モデルだったので、もし品質と速度の両方が改善するなら、置き換えたいと考えていました。 しかし、実際にアプリの用途に合わせて比べてみると、新しいモデルだから、そのまま置き換えたほうが良いとは限らないことが分かりました。 特に印象に残ったのは、LFM3では捏造が減ったものの、指示違反や言語混在が増えたことです。平均点だけを見ていたら、この違いには気づかなかったと思います。 また、QADによる量子化の違いや、SWAと推論エンジンのキャッシュの組み合わせなど、LFM3を試したからこそ見えてきた点もありました。 結論として採用は見送りましたが、モデルごとの得意・不得意を数字で確認できたのは収穫でした。 あくまで、ひとつのアプリと環境での比較です。同じようにローカルLLMを製品やツールに組み込んでいる方の参考になれば幸いです。 参考リンク Liquid AI：LFM3発表記事 Liquid AI：LFM3-1.7B モデルカード Liquid AI：LFM3-1.7B GGUF（QAD版を含む） llama.cpp：LFM3対応 PR #31252 OnecaratEditor 公式サイト

Crew's first job is four questions: what do I actually need, what do I actually want, what actually helps, and what am I trying to accomplish? Local engine underneath: ggml-org/llama.cpp How do you share one GPU between a local model and games? #LocalLLM #homelab

Betelgeuse: Running Qwen 3.8 Flash Next at 22 tok/s sustained (spiking to 48 tok/s) on an RTX 3060 12GB + 16GB DDR4 RAM 100% bit-exact! About two months ago I posted here about trying to predict which MoE experts get used on the next token to speed up CPU/GPU offload on Qwen 3.6 35B. Quick confession on that older post before anything else: I ended up throwing that prototype away. To get the big numbers I was seeing back then, I was basically cheating with gate pruning (dropping cold experts when their router weights were low). It made the tok/s counter go brrr, but on an already low-bit quant it quietly degraded output quality and reasoning. I didn't want to ship something that lobotomizes the model just to look fast in a screenshot, so I scrapped it. When Qwen 3.8 Flash Next dropped, I wanted to see if we could actually run the 68GB GSQ-RCO-IQ2_XS build at real usable speeds on a normal budget gaming PC—without dropping a single expert. For context, here is the exact box I tested this on (I actually pulled my extra RAM sticks out specifically to test what a regular 16GB PC gets): - GPU: RTX 3060 12GB - RAM: 16GB DDR4, single-channel (~19 GB/s) - OS: CachyOS / Arch Linux (tested inside a strict MemoryMax=12G cgroup) - Storage: Consumer PCIe NVMe SSD (~2.1 GB/s) If you try to load a 68GB MoE on 12GB VRAM + 16GB RAM in stock llama.cpp, you already know what happens: mmap thrashes the OS page cache to death, you get ~1,500 major page faults per token, and generation crawls at 1.47 tok/s. Then I tested Strata. Strata is super cool and hits 40+ tok/s if you have 48GB–64GB of RAM to mlock 24GB+ of experts in system memory. But on a 16GB RAM setup, it refuses to load unless you force --low-ram mmap, where it drops down to 8.11 tok/s because it's bound by cold SSD reads. So over the last week I built Betelgeuse (bel-cli / bel-server, a fork of llama.cpp, and I'm also opening a clean upstream PR for llama.cpp even if it probably won't get merged lol). What it actually does under the hood: - Zero gate pruning / 100% bit-exact: Every single one of the 10 routed experts per layer across all 48 layers is computed at full precision. We verified 28,080 router records and 576 generated tokens byte-for-byte against golden stock output (0.000e+00 diff). - Arrival-Slack VRAM Slot Pool (~5,000 slots in VRAM): All 49 dense layers + GDN + QSA + LM head stay in ~3.2 GB of VRAM. The remaining VRAM holds ~5,000 expert slots distributed non-uniformly (240 slots/layer on early layers 0–4 where there is 0ms of compute slack, 92 on middle layers, 60 on tail layers). - In-Stream GPU Doorbell + 1-Split CUDA Graph Replay: Instead of ggml_backend_sched splitting the graph 48 times per token to ask the CPU which experts missed (which burns ~360ms/token in cudaStreamSynchronize), a custom in-stream CUDA kernel resolves hits in ~2 µs on-device and only rings a mapped host doorbell when an expert is missing. Per-layer token embeddings (per_layer_token_embd) are also staged to CUDA0 so the entire decode pass runs as 1 single CUDA Graph replay. - RAM Victim Cache + io_uring Pager: When an expert gets evicted from the VRAM pool, it moves into a dedicated host RAM victim cache instead of getting thrown away.VRAM and RAM stay 100% exclusive instead of duplicating the same hot experts in the OS page cache. Physical NVMe reads drop from ~71 MB/token down to 12.43 MB/token. - No duplicate 35GB expert bloat on disk: Instead of keeping 35GB of dead expert tensors inside Shard 1 .gguf AND another 35GB in experts.bin, we stripped the expert payloads out of Shard 1 so the main GGUF is only 3.2 GB (Dense.gguf) + 35.3 GB (experts.bin, 4KB-aligned single-read blobs) + **26.8 GB (**PLE.gguf n-gram shard). Measured Results (RTX 3060 12GB + 16GB DDR4, MemoryMax=12G) |Engine|Cold Decode (Run 1)|Warm Decode (Run 2)|Peak Bursts|Prompt Processing (PP)|Physical SSD Reads|Output Parity| |:-|:-|:-|:-|:-|:-|:-| |Stock llama.cpp (mmap)|1.47 tok/s|1.63 tok/s|~2 tok/s|14–20 tok/s|208–312 MiB/tok|Baseline| |Strata (--low-ram mmap)|8.11 tok/s|8.11 tok/s|~9 tok/s|34.6 tok/s|~105 ms pool wait|~0.022 KL| |Betelgeuse (bel-server)|16.80 tok/s|22.03 tok/s|Up to 48 tok/s|16.2 – 19.3 tok/s|12.43 MiB/tok|100% Byte-Exact| On warm runs it holds 21.8–22.03 tok/s sustained across long coding prompts, and when generation hits stretches where all 10 routed experts are resident in the VRAM/victim pools, it spikes up to 48 tok/s. Links & What's Next - GitHub (Betelgeuse Engine — bel-cli & bel-server): [https://github.com/Betelgeuse-AI/Betelgeuse] - HuggingFace (Pre-packed Alpha-Orionis-XS 3.2GB Dense + Experts bundle): https://huggingface.co/Betelgeuse-AI/Alpha-Orionis-XS - Upstream llama.cpp PR: [https://github.com/ggml-org/llama.cpp/pull/31469] 1. Even on the massive Q8_K_XL quant (~190GB total), bel-server runs at 8 tok/s cold and 12 tok/s warm (with bursts up to 21 tok/s) on the exact same 12GB 3060 + 16GB DDR4 box, where stock llama.cpp immediately OOMs or crawls at <0.1 tok/s. 2. Zero experts are dropped or thresholded (0.000e+00 diff across 28,080 router records and 576 tokens vs unmodified stock). The speedup comes from eliminating the 48 per-layer CPU/GPU scheduler splits (KICK/WAIT doorbell around the shared expert), keeping the RAM victim cache strictly exclusive of VRAM (MOE_DROP_MMAP), and pre-staging cold misses via the upgraded oracle + 4KB-aligned io_uring pack. What I'm working on next: We're currently bringing this exact streaming + victim-cache architecture over to DeepSeek V4.1 Flash (1017)—early testing under development is already sitting around ~25 tok/s on the same hardware class. Happy to answer any questions or have people poke holes in the benchmarks! Leave us a Star :)

Four GPUs, One Quantization Ladder: Gemma 4 E2B From a 4 GB Laptop to an NVIDIA L4 --- title: "Four GPUs, One Quantization Ladder: Gemma 4 E2B From a 4 GB Laptop to an NVIDIA L4" published: true description: "Gemma 4 E2B from BF16 to Q2_K on a Tesla T4, an NVIDIA L4, a GTX 1650 laptop and an RTX 3050 desktop, with byte-identical GGUF files and the same llama.cpp build. The ladder keeps its shape on all four cards, 218 questions die on all four, and any two GPUs grade 2 to 4 questions differently at BF16." tags: gemma, llamacpp, quantization, nvidia cover_image: raw.githubusercontent.com --- This article provides a step by step guide to running Gemma 4 E2B's quantization ladder, BF16 down to Q2_K, on four NVIDIA GPUs with the same nine GGUF files and the same llama.cpp build, and comparing the four cards question by question. xbill9/gemma-graveyard The first article asked every rung of the ladder the same 250 GSM8K questions on a Tesla T4. The second repeated it on an NVIDIA L4 in AWS. This one adds two consumer cards: a GTX 1650 Ti laptop GPU with 4 GB and an RTX 3050 desktop card with 8 GB. All four run llama.cpp b11699 on files with the same sha256, and each card gives identical text when BF16 is run twice. --- The Results in Brief The ladder keeps its shape on all four GPUs. Against each card's own BF16, F16 to Q5_K_M lose 1 to 8 answers, Q4_K_M and Q4_0 lose 9 to 19, Q3_K_M loses 42 to 49, and Q2_K gets 3 to 6 right out of 250. The counts agree; the questions move. Any two GPUs grade 2 to 4 questions differently at BF16 and 12 to 22 at Q4_0. No question is lost at F16 or Q8_0 on all four cards, while 216 are lost at Q2_K on all four. 218 questions die at some rung on every GPU, and 147 of them die first at the same rung on every GPU. The 4 GB laptop runs every quantized rung entirely on its GPU. BF16 and F16 do not fit, so llama.cpp splits them between GPU and CPU, and they decode at 9.2 and 9.6 tokens per second against 45.9 for Q8_0 on the same card. The cover lays the four GPUs' grades over each other. One row per rung, BF16 at the top and Q2_K at the bottom, one cell per question: marigold where all four GPUs answer right, grey where all four answer wrong, violet where they disagree. docs/make_cover_gpu4.py draws it from the committed rows. --- What Changes and What Stays | | Tesla T4 | NVIDIA L4 | GTX 1650 Ti | RTX 3050 | | :--- | :--- | :--- | :--- | :--- | | Where | GCE n1-standard-2 | AWS g6.xlarge | laptop | desktop | | GPU memory | 15,360 MiB | 23,034 MiB | 4,096 MiB | 8,192 MiB | | Compute capability | 7.5 | 8.9 | 7.5 | 8.6 | | Host CPU | 2 vCPU | AMD EPYC 7R13 | Intel i7-10750H | Intel i7-5820K | | Driver | 615.71.10 | 595.112.07 | 615.71.10 | 615.78.08 | The same on all four: llama.cpp b11699 with GGML_CUDA=ON, built for each card's own compute capability; the nine GGUFs and Google's QAT Q4_0 file, byte for byte; the 250 questions in data/heldout.jsonl; temperature 0, one request at a time, thinking off, 1,024 max tokens, llama-server -c 4096 -np 1 --seed 0. Every rung runs with -ngl 99 except BF16 and F16 on the GTX 1650 (Step 4). --- At This Point You Should Have… - An NVIDIA GPU with at least 4 GB and a CUDA toolkit - About 58 GB of free disk for the checkpoint, the nine GGUFs and the QAT file - A clone: git clone https://github.com/xbill9/gemma-graveyard - The T4 run's committed results in runs/2026-10-27-ladder/ --- Step 1 — Build llama.cpp at the Same Tag On the RTX 3050: git -C ~/llama.cpp worktree add --detach /android/graveyard/llama.cpp b11699 cd /android/graveyard/llama.cpp cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=86 -DCMAKE_BUILD_TYPE=Release cmake --build build -j12 --target llama-server llama-quantize The one build flag that changes per card is CMAKE_CUDA_ARCHITECTURES: 75 for the T4 and the GTX 1650, 89 for the L4, 86 for the RTX 3050. nvidia-smi --query-gpu=name,memory.total,compute_cap,driver_version --format=csv name, memory.total [MiB], compute_cap, driver_version NVIDIA GeForce RTX 3050 OEM, 8192 MiB, 8.6, 615.78.08 🔎 Tip: keep the pinned build in its own worktree. The desktop already had a newer llama.cpp checkout (b11983). git worktree add --detach <dir> b11699 gives a second working copy at the tag from the same clone, so the measured build and the everyday build sit side by side. --- Step 2 — Rebuild the Ladder and Check It Against the T4 ladder.sh converts the checkpoint to BF16 and F16 and quantizes seven rungs from BF16. Each run script then compares every file's size and sha256 with the T4's ladder.tsv: diff <(cut -f1,3,4 runs/2026-10-27-ladder/ladder.tsv) <(cut -f1,3,4 runs/2026-10-29-3050/ladder.tsv) && echo "ladder matches T4 sha256" ladder matches T4 sha256 The GTX 1650 and the RTX 3050 both print the same line, and Google's QAT Q4_0 file matches too (sha256 fa401b55…). Across the four machines, the GGUF bytes are identical; the card, its driver, its CUDA version and the kernels built for it are what differ. 🔎 Tip: the converter writes the checkpoint directory into the GGUF. convert_hf_to_gguf.py copies the model card and takes the model's name from the directory it reads. A checkpoint taken straight from the Hugging Face cache snapshot has neither the README.md nor the name gemma-4-E2B-it, and gives different bytes. Download with hf download google/gemma-4-E2B-it --local-dir <dir>/gemma-4-E2B-it. --- Step 3 — Prove Each Card Repeats Itself BF16 on 50 questions, twice, on every GPU: ./graveyard.py repeat runs/2026-10-29-3050/determinism-1 runs/2026-10-29-3050/determinism-2 BF16 {"rung": "BF16", "n": 50, "mismatched_extracted": 0, "mismatched_text": 0, "mismatched_right": 0, "right_a": 46, "right_b": 46} The T4, the L4 and the GTX 1650 give the same result: 0 mismatched characters and 46 of 50 right both times. Each card on its own is deterministic, so a difference between two cards comes from the GPU and its CUDA stack. --- Step 4 — Fit the 16-bit Rungs on 4 GB BF16 and F16 need a 4,384.87 MiB GPU buffer for their 36 layers (from the T4's load log), and the GTX 1650 has 4,096 MiB. With -ngl 99 the load fails. graveyard.py run --ngl auto leaves -ngl off, and llama.cpp's fit step places what it can: common_params_fit_impl: - CUDA0 (NVIDIA GeForce GTX 1650 Ti with Max-Q Design): 14 layers, 2546 MiB used, 1125 MiB free load_tensors: offloaded 14/36 layers to GPU load_tensors: CUDA0 model buffer size = 2407.92 MiB Every other rung fits whole. Q8_0 on the same card: load_tensors: offloaded 36/36 layers to GPU load_tensors: CUDA0 model buffer size = 2342.30 MiB The split changes speed and leaves the grades in line with the other GPUs: the GTX 1650's BF16 scores 229, the same as the T4 and the L4, and grades 2 to 4 questions differently from each of them. The 8 GB RTX 3050 holds BF16 whole at 4,651 MiB. --- Step 5 — Run the Ladder on Each Card and Score It Each run script runs the nine rungs and QAT Q4_0, then scores every rung against that card's own BF16: ./graveyard.py bury runs/2026-10-29-3050 BF16 F16 Q8_0 Q6_K Q5_K_M Q4_K_M Q4_0 Q3_K_M Q2_K --json graveyard-ladder.json Right answers, out of 250: | Rung | T4 | L4 | GTX 1650 | RTX 3050 | | :--- | :--- | :--- | :--- | :--- | | BF16 | 229 | 229 | 229 | 232 | | F16 | 229 | 229 | 228 | 232 | | Q8_0 | 227 | 228 | 229 | 226 | | Q6_K | 229 | 227 | 226 | 227 | | Q5_K_M | 231 | 228 | 226 | 226 | | Q4_K_M | 224 | 221 | 222 | 221 | | Q4_0 | 222 | 220 | 216 | 218 | | Q3_K_M | 191 | 186 | 183 | 191 | | Q2_K | 3 | 6 | 5 | 3 | Lost, against the same card's BF16: | Rung | T4 | L4 | GTX 1650 | RTX 3050 | | :--- | :--- | :--- | :--- | :--- | | F16 | 1 | 1 | 2 | 1 | | Q8_0 | 4 | 3 | 2 | 7 | | Q6_K | 4 | 6 | 7 | 8 | | Q5_K_M | 3 | 6 | 6 | 8 | | Q4_K_M | 9 | 14 | 12 | 14 | | Q4_0 | 15 | 16 | 19 | 16 | | Q3_K_M | 42 | 45 | 49 | 44 | | Q2_K | 226 | 225 | 225 | 229 | Lost: right at BF16, wrong at this rung, on the same GPU. The failures fall into the same kinds on every card. Q3_K_M runs out of room: 33 to 36 of its losses on each GPU are answers cut off at 1,024 tokens. Q2_K loops: 208 to 228 of its 250 answers repeat a line five or more times, and 246 to 249 hit the token cap. --- Step 6 — Line the Four GPUs Up, Question by Question docs/gpu4_derived.py rebuilds the T4's grid from its committed results and reads the other three from their rows, then compares all six pairs of GPUs at every rung: python3 docs/gpu4_derived.py > runs/2026-10-29-3050/four-gpus.txt | Rung | Graded differently, any two GPUs | Lost on all four | | :--- | :--- | :--- | | BF16 | 2 to 4 | — | | F16 | 3 to 5 | 0 | | Q8_0 | 3 to 9 | 0 | | Q6_K | 4 to 10 | 2 | | Q5_K_M | 7 to 10 | 1 | | Q4_K_M | 9 to 15 | 5 | | Q4_0 | 12 to 22 | 5 | | Q3_K_M | 26 to 34 | 20 | | Q2_K | 6 to 9 | 216 | Graded differently: right on one GPU and wrong on the other, at that rung, for the closest and the furthest of the six pairs. - The light rungs lose different questions on each card. F16 and Q8_0 lose 1 to 7 answers per GPU, and none of them is lost on all four. - The deep losses are shared. Q3_K_M loses 20 questions on all four GPUs and Q2_K 216. - Most of the graveyard is common ground. Each GPU has 226 questions that die at some rung, the RTX 3050 230. 218 die on all four, and 147 die first at the same rung on all four. One question dies only on the RTX 3050 (test-358) and one only on the GTX 1650 (test-147). - BF16 itself moves a few answers. 227 questions are right at BF16 on all four cards and 18 wrong on all four. Against the L4, the RTX 3050's BF16 changes the text of 31 answers out of 250, the extracted number of 4 and the grade of 3. --- Step 7 — Google's QAT Q4_0 on Four Cards ./graveyard.py bury runs/2026-10-29-3050 BF16 QAT_Q4_0 Q4_0 --json graveyard-qat.json | GPU | QAT Q4_0 right | Q4_0 right | QAT Q4_0 lost | Q4_0 lost | | :--- | :--- | :--- | :--- | :--- | | T4 | 221 | 🥇 222 | 15 | 15 | | L4 | 219 | 🥇 220 | 15 | 16 | | GTX 1650 | 🥇 222 | 216 | 11 | 19 | | RTX 3050 | 🥇 221 | 218 | 15 | 16 | QAT Q4_0 scores 219 to 222 on the four cards and plain Q4_0 216 to 222. On the T4 and the L4 the plain file is ahead by 1; on the GTX 1650 QAT is ahead by 6 and on the RTX 3050 by 3. The two files lose mostly different questions: on the RTX 3050, 5 questions are lost under both, 10 only under QAT and 11 only under the plain Q4_0. Across the four GPUs, 6 of QAT's losses and 5 of Q4_0's are lost on every card. --- Step 8 — Speed on Each Card Median decode speed in tokens per second. Each column is one machine; read down a column. | Rung | T4 | L4 | GTX 1650 | RTX 3050 | | :--- | :--- | :--- | :--- | :--- | | BF16 | 40.0 | 50.1 | 9.2 | 40.3 | | F16 | 39.6 | 50.0 | 9.6 | 40.3 | | Q8_0 | 64.3 | 83.0 | 45.9 | 67.8 | | Q6_K | 70.8 | 98.1 | 57.2 | 75.3 | | Q5_K_M | 78.7 | 107.7 | 61.9 | 82.2 | | Q4_K_M | 84.1 | 118.7 | 66.5 | 91.5 | | Q4_0 | 🥇 93.6 | 125.6 | 🥇 70.8 | 🥇 99.7 | | Q3_K_M | 74.2 | 111.1 | 55.9 | 64.2 | | Q2_K | 74.0 | 🥇 139.5 | 62.2 | 95.0 | - Q4_0 is the fastest rung on three of the four cards; on the L4 it is Q2_K, which is wrong on 244 of 250 questions. - Q5_K_M decodes 1.21 to 1.35 times as fast as Q8_0 on each card (arithmetic, from the table). Q8_0 is the baseline here because it is the largest rung that fits whole on all four GPUs. - Q3_K_M is slower than Q4_0 on every card, and on the RTX 3050 it is slower than Q8_0. - BF16 and F16 run at the same speed on the T4, the L4 and the RTX 3050. On the GTX 1650, with 22 of 36 layers on the CPU, they run at a fifth of Q8_0's speed. The full ladder with QAT took 5 hours 16 minutes on the RTX 3050 and 12 hours 25 minutes on the GTX 1650, from the first log line to the last (run-3050.log, run-1650.log). --- Compare and Contrast | | T4 | L4 | GTX 1650 | RTX 3050 | | :--- | :--- | :--- | :--- | :--- | | BF16 right of 250 | 229 | 229 | 229 | 🥇 232 | | Q5_K_M lost | 🥇 3 | 6 | 6 | 8 | | Q4_0 right, tok/s | 222, 93.6 | 220, 125.6 | 216, 70.8 | 218, 99.7 | | Every rung whole on the GPU | 🟢 yes | 🟢 yes | ❌ BF16, F16 split | 🟢 yes | | Same text twice at BF16 | 🟢 yes | 🟢 yes | 🟢 yes | 🟢 yes | --- So, Which One? On any of the four cards, take Q5_K_M: 39.0% of BF16's bytes, 226 to 231 right, 3 to 8 answers lost against the card's own BF16, and 1.21 to 1.35 times Q8_0's decode speed. For the fastest file that stays within 19 answers, take Q4_0, the fastest rung on three of the cards. On a 4 GB card, every quantized rung fits whole and the 16-bit rungs run at under 10 tokens per second. To compare two quantizations question by question, run both on one GPU: a different card moves 2 to 4 grades at BF16 and up to 34 at Q3_K_M. --- Summary The goal of this article was to run Gemma 4 E2B's quantization ladder on four GPUs, from a 4 GB laptop card to a data-centre L4, and see which grades hold. The key was holding everything else fixed: byte-identical GGUFs, the same llama.cpp tag and the same sampling, with each card checked to give identical text twice. The four-GPU results were: - 🟢 All nine GGUFs and the QAT file match the T4's sha256 on every machine, and BF16 gives identical text twice on 50 questions on every card. - 🟢 The ladder keeps its shape on all four GPUs: F16 to Q5_K_M lose 1 to 8, Q4_K_M and Q4_0 lose 9 to 19, Q3_K_M loses 42 to 49. - 🟢 Q5_K_M is the best trade on every card: 226 to 231 right at 1.21 to 1.35 times Q8_0's speed. - 🟢 A 4 GB GTX 1650 runs every quantized rung whole on the GPU; BF16 and F16 run split, 14 of 36 layers on the GPU, at 9.2 and 9.6 tokens per second. - ⚠️ Any two GPUs grade 2 to 4 questions differently at BF16 and 12 to 22 at Q4_0; no question is lost at F16 or Q8_0 on all four. - ⚠️ 218 questions die on all four GPUs, 147 of them first at the same rung. - ⚠️ QAT Q4_0 and plain Q4_0 trade places by card: plain ahead by 1 on the T4 and L4, QAT ahead by 6 on the GTX 1650 and by 3 on the RTX 3050. - ❌ Q3_K_M loses 42 to 49, mostly answers cut off at 1,024 tokens; Q2_K gets 3 to 6 right, with 208 to 228 looping answers per card. Scope: one run of each rung per GPU on four NVIDIA cards (a Tesla T4 on GCE, an L4 on AWS, a GTX 1650 Ti laptop GPU and an RTX 3050 desktop card), 250 GSM8K test questions, greedy, thinking off, 1,024 max tokens, llama.cpp b11699 built for each card. Determinism checked at BF16 on each card. The T4 grid is rebuilt from its committed per-question results. The hosts also differ in CPU, RAM, driver and CUDA version, and on the GTX 1650 BF16 and F16 run split between GPU and CPU. Speed is compared within each card only. The strategy for measuring Gemma 4's accuracy one quantization rung at a time on four GPUs was validated with an incremental step by step approach. --- References - Accuracy vs Speed: Gemma 4 E2B Quantization Tradeoffs, BF16 to Q2_K, the T4 article - Performance vs Quality: Gemma 4 E2B Quantization on an NVIDIA L4 and a Tesla T4, the L4 article - gemma-graveyard on GitHub - GTX 1650 run: runs/2026-10-29-1650 - RTX 3050 run: runs/2026-10-29-3050 - llama.cpp - google/gemma-4-E2B-it - google/gemma-4-E2B-it-qat-q4_0-gguf - GSM8K

LFM3の6モデルとベンチマークの読み方、LFM3-1.7B（公式Q8_0）をBionicで通常会話させた記録 !LFM3の6モデル・ベンチマーク・ローカル検証の解説 執筆：あきらパパ ／ 確認日：2026-10-29（JST）／ 実機検証：2026-10-28 :::note warn この記事では次の4つを区別しています。 - メーカー発表：Liquid AIの説明と、Liquid AI自身の測定。筆者は再現していません。 - ローカル観測：筆者の1台の環境で確認したこと。 - 独自調整：本検証で使った通常会話専用テンプレート。BionicやLiquid AIの公式推奨ではありません。 - 未検証：確かめていないこと。 ::: 1. LFM3の新しい点（メーカー発表） - 共通基盤LFM3-1.7B-Baseから、用途別の6モデルを構成（Baseは6つに数えない） - 文字・視覚・音声・統合に加え、生成しない判定モデル（d1系）を同じファミリーに含む - 旧2.6Bモデル比でパラメータ35%減、事前学習22Tトークン - 文字モデルの文脈長は256K 公式ブログは2026-10-27表記です。公式Xの発表投稿は2026-10-28に確認しました（反響の量は調べていません）。 2. 用途別6モデル（メーカー発表） !LFM3ファミリーの6モデルと共通基盤 | 正式型番 | 実パラメータ | 入力 | 出力 | 役割 | 文脈長（仕様） | 本記事での検証 | |---|---|---|---|---|---|---| | LFM3-1.7B | 1.73B | 文字 | 文字 | 文章、ツール呼び出し | 256K | 通常会話・単回長文生成（Q8_0） | | LFM3-VL-2B | 1.92B | 文字・画像・動画 | 文字 | 視覚入力の理解 | 128K | 未検証 | | LFM3-Audio-2B | 2B（総数） | 文字・音声 | 文字・音声 | 音声対話（18言語の音声） | 32K | 未検証 | | LFM3-Omni-2B | 2.17B（総数） | 文字・画像・動画・音声 | 文字・音声 | 複数モーダルの統合 | 32K | 未検証 | | d1-2B | 1.92B | 文字・画像・動画 | 型付き判定・抽出、確率 | 判定・抽出 | 128K | 未検証 | | d1-Omni-2B | 2.17B | 文字・画像・動画・音声 | 型付き判定・抽出、確率 | 判定・抽出（会話モデルではなく、音声出力なし） | 128K | 未検証 | - 型番の2Bは厳密な総数ではありません（Bは10億）。 - 文脈長はトークン上限（入力＋出力）です。256Kは日本語256,000文字の保証でも、完全な記憶でもありません。 - d1系の確率は、モデルの判定の寄り具合を示す値で、正解の保証ではありません。 - 公式は文字モデルをagentic codingや複雑な多段推論には推奨しておらず、知識に依存するタスクは検索との併用を案内しています。 3. アーキテクチャ（メーカー発表） !三つの読み方と24層 24層の内訳は、gated short convolution 13層（近くの並び）、sliding-window attention 5層（256トークンの窓内の関係）、global attention 6層（全体の関係）です。 4bitで文字モデル約1GBというのもメーカー説明です。約1GBは必要RAMの総量ではなく、KVキャッシュとランタイムの分が加わります。本記事で使うQ8_0（1.85GB）とも別の数字です。 4. ベンチマーク（メーカー測定） !LFM3-1.7B、LFM2.5-2.6B、Qwen3.5-9Bのベンチマーク比較 以下は、Liquid AIが自社のモデルカードに掲載した測定値です。第三者の再現でも、筆者の再測定でもありません。 4-1. 各ベンチマークが見ているもの | ベンチマーク | 見ているもの | |---|---| | LiveClaw | OpenClawを使うエージェント課題の達成 | | BFCL V4 | 正しい関数・引数を選ぶツール呼び出し | | MCP-Atlas | ツールを伴う長い課題 | | SWE-bench Verified | 実リポジトリの課題修正（OpenCode経由） | | LiveCodeBench v6 | プログラミング問題のコード生成 | | IFEval | 検査可能な指示条件を守れるか | | GPQA Diamond | 専門的な科学の難問 | | RULER 128K | 長い入力内の情報を扱えるか | 4-2. 8指標×6モデル すべて高いほどよい指標です。 | ベンチマーク | LFM3-1.7B | LFM2.5-2.6B | MiniCPM5-2B | Gemma4-E4B | Qwen3.5-4B | Qwen3.5-9B | |---|---|---|---|---|---|---| | LiveClaw | 45.60 | 14.70 | 30.37 | 20.36 | 19.94 | 35.77 | | BFCL V4 | 71.39 | 55.89 | 62.65 | 48.25 | 55.12 | 62.83 | | MCP-Atlas | 32.57 | 16.45 | 26.38 | 6.19 | 41.37 | 42.67 | | SWE-bench Verified (OpenCode) | 43.40 | 18.00 | 34.80 | 0.50 | 41.20 | 51.20 | | LiveCodeBench v6 | 73.46 | 60.57 | 70.52 | 71.00 | 61.99 | 69.86 | | IFEval | 96.66 | 95.39 | 87.83 | 90.02 | 92.52 | 92.08 | | GPQA Diamond | 63.37 | 57.78 | 65.15 | 57.88 | 75.76 | 80.40 | | RULER 128K | 65.56 | 1.15 | 37.96 | 18.82 | 84.63 | 87.11 | 4-3. 評価条件 | 項目 | 条件 | |---|---| | 精度・実行 | 全モデルBF16／vLLM | | 最大context | LFM3-1.7B・Qwen3.5-4B・Qwen3.5-9B：262,144／LFM2.5-2.6B・MiniCPM5-2B・Gemma4-E4B：131,072 | | サンプリング | 原則 temperature 0.6、top_p 0.95 | | BFCL V4 | greedy、最大出力32,768 tokens | | LiveClaw | OpenClaw、最大出力8,192 tokens | | SWE-bench Verified | OpenCode、最大250 turn | | MCP-Atlas | 最大256 turn | ハーネスやturn上限、モデル別のcontext上限に差があるため、完全に同一条件の比較とは言えません。 4-4. 読み方 - 同じ行のモデル同士だけを比べます。 異なるベンチマークの点数は尺度も意味も違うので、横に比べません。全指標を一律に「正答率」とも読みません。 - 差を性能の倍率に変換しません。 - LFM2.5-2.6B比：8指標すべてで上回ります。IFEvalの差（96.66対95.39）は小さめです。 - Qwen3.5-9B比：上回るのはLiveClaw（45.60対35.77）、BFCL V4（71.39対62.83）、LiveCodeBench v6（73.46対69.86）、IFEval（96.66対92.08）。下回るのはMCP-Atlas（32.57対42.67）、SWE-bench Verified（43.40対51.20）、GPQA Diamond（63.37対80.40）、RULER 128K（65.56対87.11）です。 - Qwen3.5-4B比：MCP-Atlas、GPQA Diamond、RULER 128Kで下回り、他の5指標で上回ります。 - MiniCPM5-2B比：GPQA Diamond以外の7指標で上回ります。 - Gemma4-E4B比：8指標すべてで上回ります。SWE-bench 0.50やMCP-Atlas 6.19のような極端な値は、ハーネスやcontext上限の差の影響が切り分けられていないため、単独で実力の結論にしません。 - 表全体の平均は、性質の違う指標の非加重平均になるため、万能な順位としては使いません。 読めること：メーカー条件（BF16）では、LFM3-1.7Bはツール呼び出し・エージェント課題・指示条件の指標で高いスコアです。 読めないこと：日本語会話の品質、安全な自動操作、量子化版（Q8_0やQ4_0）での同等性、長文の実用精度。また、コード問題を正しく解くことと、自律的に開発を完遂することは別です。公式も文字モデルをagentic codingには推奨していません。 4-5. VL・Audio・Omni・d1（メーカー発表） 公式ブログでは、視覚系62評価の単純平均として、LFM3-VL-2B（実パラメータ1.92B、型番2B）が71.4、Gemma4 12Bが71.7、GPT5.6 Lunaが73.4、Gemini3.5 Flash Liteが70.0と示されています。このテスト集合では近い結果ですが、あらゆる画像質問に同じ強さとは言えません。 Audioは18言語の音声対話、Omniは画像・音声の統合、d1は生成せず型付き判定と確率を返す役割です。文字モデル以外の5モデルは本端末で未検証です。 4-6. 速度の数値について 公式の端末速度比較はQ4_0／llama.cpp／context 32Kの条件です。本記事の測定（10章）はQ8_0の単回測定なので、公式値とは比較しません。 5. 検証環境（ローカル観測） | 項目 | 値 | |---|---| | 端末 | Apple M4 Max／64GB | | アプリ | Bionic 1.1.9（build 6） | | ランタイム | Metal llama.cpp 2.65.1（Bionic側の版数） | | モデル | LiquidAI/LFM3-1.7B-GGUF の LFM3-1.7B-Q8_0.gguf | | サイズ | 1,846,238,496 bytes（1.85GB） | | 整合性 | SHA256が公式LFSと一致。GGUF内のchat_templateも公式と一致 | ランタイムの2.65.1はBionic側の版数で、llama.cpp本体のGitHubリリース番号（参照したのはb11938）とは別の番号です。llama.cppのmasterに src/models/lfm3.cpp が存在することも確認しました。Liquid AIのllama.cpp導入ガイドは例に旧LFMのものが混ざっているので、古いビルド番号の例をLFM3対応版として読まないよう注意してください。 参照（確認日2026-10-28）： - lmstudio.ai - github.com/ggml-org/llama.cpp/releases/tag/b11938 - docs.liquid.ai 6. モデルの選択と読み込み !公式配布からロード、短い3問、用途判断までの流れと通信の境界 公式GGUFをダウンロード済みである前提です。Bionic公式ガイドのモデルの項と筆者の観測にもとづく流れです。 1. モデル選択で「Local」を選ぶ 2. 配布者が LiquidAI、ファイルが LFM3-1.7B-Q8_0.gguf であることを照合する 3. 既存のQ8_0を選び、loadする 非公式の変換版は対象外です。サイズとSHA256を、Hugging Faceのファイルページの値と照合します。 # 公式GGUFを既に持っている前提の例です。本記事の制作中にこのコマンドは実行していません shasum -a 256 LFM3-1.7B-Q8_0.gguf 7. 調整前に起きたこと（ローカル観測） - Bionicが渡す作業用指示・環境情報・ツール定義に反応し、単純な質問でも存在しないフォルダの探索を繰り返しました。 - 最初の短い会話テストが通っても、通常会話で安定する保証にはなりませんでした。 - System Promptの変更とThinking offだけでは解消しませんでした。 - 調整前には、中国語の混入や指定した文数を守らない応答も見られました。 8. 通常会話専用テンプレート（独自調整） :::note info 各設定欄へ到達する正確なメニュー階層は記録していないため、記載しません。画面の項目名や配置はバージョンで変わる可能性があります。他端末での再現は未検証です。 ::: 8-1. 変更前に原本を保存する 1. モデル設定のプロンプトテンプレート（Jinja）欄の内容を全文コピーし、手元に別ファイルとして保存します。元に戻すときの最優先の原本です。 2. これから変える設定項目の現在値を控えます。スクリーンショットには個人のパスなどが写ることがあるので、手元だけで保管してください。 8-2. 独自テンプレートの処理内容 本検証で使ったテンプレートの全文は、この記事では配布しません。公式テンプレートは次のURLで確認できます。 huggingface.co 独自テンプレートは、公式のChatML形式を土台に次の処理をしています。 - tools=[] にして、ツール定義を渡さない - 新しい短い日本語のsystemを入れる - 履歴から、userと、ツール呼び出しを含まないassistantだけを取り出す - user本文に </environment> があれば、最後の区切りより後ろだけを残す - enable_thinking=false 結果として、ツール定義・環境情報・作業用指示（既存のsystem／developer指示）の3つを会話に渡しません。 :::note alert 通常会話専用です。 作業用指示とツール文脈を保持しないため、ファイル操作・コーディング・自動操作などのエージェント用途には使わないでください。また </environment> の処理はすべてのuser messageにかかるので、本文にこの文字列を含めると、それより前の内容が失われることがあります。 ::: 8-3. 推論設定 | 項目 | 値 | |---|---| | Temperature | 0.1 | | top_k | 50 | | repeat penalty | 1.1 | | Thinking | off | | context length | 8192 | | GPU offload | 24 | | max concurrent predictions | 1 | | Unified KV Cache | off | | Context Checkpoints | 0 | テンプレートと各設定のどれがどれだけ効いたかは切り分けていません。全項目が必須とは言えません。 8-4. 適用と確認 1. shellをoffにして、モデルを再ロードします。 2. 新しい会話で、9章の質問を順に送ります。 9. 結果（ローカル観測） !独自調整の前後と、残る誤答・未検証 ※図の会話例は簡略表記です。図の除外情報の3つめは作業用指示です。各設定の因果は未分離です。 | 質問 | 応答 | 判定 | |---|---|---| | 五十音順で、あ・い・う・えの次 | お | 正答 | | （続けて）では、その次 | おの次はか | 正答（文脈を保持） | | 空が青い理由 | レイリー散乱について日本語で回答 | 内容は妥当 | | あ、い、う、え、の次は？ | 的外れな返答 | 誤答が残る | 4問とも探索ループは出ませんでした。ただし「回答が返る」「正答する」「用途に合う」は別々に判断する必要があります。 10. 長文生成の単回測定（ローカル観測） 5章の環境と8章の設定のまま、新しい会話で「日本語の物語を10,000文字以上、全20章で」と指示しました。 | 項目 | 値 | |---|---| | 測定日 | 2026-10-28 | | 出力文字数 | 5,276文字（Pythonの len()、改行・見出し込み）→ 10,000文字の指定は未達 | | 入力トークン | 149 | | 出力トークン | 3,471 | | 生成速度 | 139.56 tokens/秒 | | 生成時間 | 24.86467秒 | | 入力処理込みの時間 | 24.97247秒 | | TTFT（最初のトークンまで） | 0.10781秒 | | 停止理由 | eosFound（モデルが自発的に終了） | 測定方法：lms の prediction.output.stats の値とサーバーログを照合しました。直後に自動で走った会話タイトル生成（別の出力、22.53秒）は含めていません。 - 1回だけの測定で、この環境・この設定に限った数字です。 - 上限による打ち切りではなく、指定の半分ほどでモデル自身が書き終えています。 - 物語の内容の正確さと、全20章の指定を守ったかは評価していません。 出典：筆者の検証記録（非公開） 採用を判断するときは、自分の用途に近い短い実務サンプルで、正答と指定条件を確かめてから使ってください。 11. 失敗したときの切り分け | 症状 | 確認すること | |---|---| | フォルダ探索が続く | テンプレートが置き換わっているか、shellがoffか、再ロードしたか | | 設定を変えても挙動が同じ | 再ロード後の新しい会話で試しているか | | 曖昧な質問で外れる | 「五十音順で」のように条件を具体的に書く。それでも外れる場合は用途に合わない可能性 | | 作業系の指示が効かない | 仕様どおり（8-2の制約）。作業用途には使わない | | 原因がわからない | 次章の手順で元に戻す | 12. 元の設定に戻す 1. テンプレート欄に、8-1で保存した原本を貼り戻します。これを最優先にしてください。 2. 保存していない場合に限り、公式の chat_template.jinja（8-2のURL）を使えます。読者自身の設定のバックアップではなく、版が違えば手元のGGUFの内蔵テンプレートと一致しない可能性があります。 3. 8-1で控えた値に各設定を戻し、モデルを再ロードして新しい会話で確認します。 GGUFファイル自体は変更していないので、再ダウンロードは不要です。 13. ライセンスと通信 - 重みの公開は、無条件の商用利用許可ではありません。LFM Open License v1.0 の第1条・第5条に、年間売上1,000万米ドルを基準とする条件があります。該当し得る場合は原文を読み、必要なら別契約を確認してください。 huggingface.co - ローカル実行でも、検索・API・ツール接続を使えば通信が発生します。 14. 未検証 メーカーのベンチマークの再現、長文の内容精度と全20章の遵守、文脈長の全長、速度の再現性と他条件での速度、消費電力、通信遮断状態での動作、音声・画像・動画、自動操作、他端末での再現。LFM3-1.7B以外の5モデルは試していません。 出典（確認日2026-10-29） - liquid.ai - 2章の表の各正式型番のリンク先（Hugging Faceの公式モデルカード） - x.com （2026-10-28に確認）

The latest version of llama.cpp already supports huihui-ai/Huihui-DeepSeek-V4.1-Flash-1017-abliterated-GGUF, and also supports the Strata Patch (ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF) as well as the Unsloth (Patch). huggingface.co github.com/ggml-org/llama.cpp/releases/tag/b11870

mistralai/Mistral-Large-4-1T-A52B · Hugging Face huggingface.co huggingface.co huggingface.co from Mistral: Mistral Large 4 - Le Chonk Mistral Large 4 is our largest and most capable model to date: a 1 trillion-parameter natively multimodal Mixture-of-Experts model with 49 billion active parameters per token (52 billion including embeddings and output layers), trained from scratch on 3,800 NVIDIA Grace Blackwell GPUs in Mistral's own datacenters in Europe. Mistral Large 4 unifies instruction following, reasoning, coding, and agentic workflows in a single set of weights. While a generalist model, it shows especially good performance on workloads such as cybersecurity, finance, and law, and it surpasses frontier closed models on visual grounding. It is natively fluent in 160+ languages, including every official language of the European Union. Find more information on our blog. The model is also served on the Mistral API as mistral-large-4. Key Features Mistral Large 4 includes the following architectural choices: - ~1T total / ~52B active parameters: granular Mixture-of-Experts with 128 routed experts (4 active per token) and 1 shared expert. - 1M context length, for long-context workloads. - Multimodal input: accepts text and image input, with text output. Pixtral-style vision encoder trained to handle variable image sizes and aspect ratios. - Instruct and Reasoning functionalities with function calls, reasoning effort configurable per request. Mistral Large 4 offers the following capabilities: - Reasoning Mode: three reasoning efforts — low, medium, high (default) — so the same model can answer a quick chat reply or work through a complex agentic run. - Vision: analyzes images, charts, technical drawings, and documents, with state-of-the-art visual grounding among open weights. - Multilingual: natively fluent in 160+ languages, including all official languages of the European Union. - System Prompt: strong adherence and support for system prompts. - Agentic: native function calling, JSON output, and strict JSON schema enforcement. - Cybersecurity: state of the art among open-weight models for security work, while refusing malicious requests. - Large Context Window: supports a 1M context window. We release this model under the Mistral Ecosystem Open-Weight License: a modified version of the MIT license, for both commercial and non-commercial use — operating a Model-as-a-Service business requires a separate commercial license with Mistral. llama.cpp suport merged: llama.cpp#31376

llama.cpp looks to be cloning openai's realtime websocket API with this audio model as its first use case? I guess this model is either the first speech-to-speech of its kind, OR it's the first good-enough one. I'm thinking I need to give this more testing! - https://github.com/ggml-org/llama.cpp/pull/31287 - https://github.com/ggml-org/llama.cpp/pull/31269