llama.cpp

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 公式サイト

EVO-X2 に RTX 3080 Ti を足すと LLM は何倍速くなるか メモリ 128GB のミニ PC「EVO-X2」に、OCuLink で中古の RTX 3080 Ti をつなぎました。内蔵 GPU とどれだけ差が出るのかを、同じ llama.cpp・同じモデルで測っています。 結果は、VRAM に収まる gpt-oss-20b は約 2.2 倍に速くなり、収まらない gpt-oss-120b は変わりませんでした。さらに、測っている途中で、3080 Ti が本来の約半分の速さしか出ない状態になることにも気づきました。 先に結論 gpt-oss-20b の生成速度は 79.0 → 177.5 t/s（約 2.2 倍）、プロンプト処理は 1929 → 4705 t/s（約 2.4 倍）になりました。VRAM 12GB に収まるモデルを速く動かすという目的は、達成できました。 gpt-oss-120b は、3080 Ti を足しても生成速度が変わりませんでした（56.0 → 55.3 t/s）。プロンプト処理も、最大で約 10% 速くなっただけです。 注意点: 3080 Ti は、軽い負荷だとクロックが上がらず、速度が約半分になります。nvidia-smi でクロックを固定すると解消しました。 3D ベンチと llama.cpp は、公開されているスコアと比べて目立った低下はありませんでした。ただし、OCuLink（Gen4 x4）による低下の割合は、x16 接続と比較して切り分けては測っていません。 接続の方法と、アダプタで詰まった話は、別の記事「EVO-X2 に OCuLink の eGPU を認識させるのに苦労した話」に書きました。 何を期待して、何が得られたか EVO-X2 の 128GB の統合メモリには、大きなモデルを載せられます。ただし、速度は内蔵 GPU の性能までです。VRAM 12GB に収まるモデルは、専用 GPU を足してもっと速く動かしたい、その差を実測したいと考えました。将来は Isaac Sim なども使いたいので、CUDA が使える GPU を足したいという理由もありました。 3080 Ti（中古、購入額 82,000 円）は、内蔵 GPU より速く、比較的コスパが良いと考えて選びました（筆者の判断です。他の GPU との比較は行っていません）。 結果は次のとおりです。 期待 結果 VRAM 12GB に収まるモデルが、内蔵 GPU より速い ✅ gpt-oss-20b の生成が 79.0 → 177.5 t/s（約 2.2 倍）、プロンプト処理が 1929 → 4705 t/s（約 2.4 倍） gpt-oss-120b のような大きなモデルも速くなる ❌ 3080 Ti 単体では載りません。内蔵 GPU と併用しても、生成は変わらず（56.0 → 55.3 t/s）、プロンプト処理は最大で約 10% 速くなっただけです 中古の GPU に初期不良がない ✅ HDMI 2 ポートで映像が出ました。VRAM 検査と PCIe のエラーは 0 件でした（DisplayPort は未確認です） Isaac Sim が動く 未確認（VRAM 12GB は、最小要件の 16GB に届きません） 測定環境 項目 内容 本体 GMKtec EVO-X2（Ryzen AI Max+ 395、メモリ 128GB、BIOS EVO-X2S 1.13）、Ubuntu 24.04、カーネル 7.0.0-38 接続 M.2 → OCuLink（CY）→ MINISFORUM DEG1 → ASUS TUF-RTX3080TI-12G-GAMING（中古）。電源は玄人志向 KRPW-GA750W です。詳細は、冒頭で紹介した別の記事に書きました ドライバ NVIDIA 595.99.02（open、Canonical 署名済みの事前ビルド版） ソフト llama.cpp b11803（Vulkan）。公開値との比較だけ、Windows 11 の CUDA 13.4 版を使いました 測定項目の読み方は、次のとおりです。 pp512 / tg128: pp512 は 512 トークンのプロンプトを読む速度（prompt processing）、tg128 は 128 トークンを生成する速度（token generation）です。単位の t/s は、1 秒あたりのトークン数です。 FA: Flash Attention のことです。llama.cpp では -fa で切り替えます。 ベンチマーク: 内蔵 GPU と 3080 Ti の比較（同条件） 条件は、すべて共通です。llama.cpp b11803、Vulkan、同じモデルファイル、-ngl 99。デバイスだけを GGML_VK_VISIBLE_DEVICES で切り替えました。 モデル 内蔵 8060S（pp512 / tg128） 3080 Ti（pp512 / tg128） 倍率 gpt-oss-20b MXFP4（11.27GiB） 1929 / 79.0 t/s 4705 / 177.5 t/s 約 2.4 倍 / 約 2.2 倍 gpt-oss-20b（FA 有効、3080 Ti はクロック固定。pp512 / tg128） 1938.6 / 77.9 t/s 4232.5 / 160.6 t/s 約 2.2 倍 / 約 2.1 倍 同上（pp2048） 1836.9 t/s 4583.9 t/s 約 2.5 倍 gpt-oss-120b（63GB） 845.2 / 56.0 t/s（2 回の平均） 単体では載りません（59GiB に対して VRAM は 12GiB） 内蔵 GPU との併用は、下の小節に書きました ※ 1 行目の gpt-oss-20b は 3 回の平均です（FA の指定なし。測定時にクロックを固定していたかどうかは、記録していません）。FA 有効の 2 行は別の測定で、nvidia-smi -lgc 1500,2100 と -lmc 9501,9501 で 3080 Ti のクロックを固定しています（内蔵 GPU は既定のままです）。1 行目と FA 有効の行は条件が違うので、値を直接比べないでください。 ※ 3080 Ti を既定のクロックのままで測ると、軽い負荷で速度が大きく落ちます。詳しくは、下の「注意点」の節を参照してください。 $ GGML_VK_VISIBLE_DEVICES=0 llama-bench -m gpt-oss-20b-MXFP4.gguf -ngl 99 -p 512 -n 128 -r 3 | model | size | backend | ngl | test | t/s | | gpt-oss 20B MXFP4 MoE | 11.27 GiB | Vulkan | 99 | pp512 | 4705.25 ± 28.46 | | gpt-oss 20B MXFP4 MoE | 11.27 GiB | Vulkan | 99 | tg128 | 177.46 ± 0.71 | $ GGML_VK_VISIBLE_DEVICES=1 llama-bench ... （内蔵 8060S） | gpt-oss 20B MXFP4 MoE | 11.27 GiB | Vulkan | 99 | pp512 | 1928.57 ± 30.40 | | gpt-oss 20B MXFP4 MoE | 11.27 GiB | Vulkan | 99 | tg128 | 79.00 ± 0.20 | 負荷中の実測値は、最高 50℃、最大 348W（上限は 350W）、リンクは Gen4 x4 でした。カーネルログ（journalctl -k）には、NVRM のメモリ確保エラー（can't alloc VA space for mapping、NV_ERR_NO_MEMORY）が出ます。AER と Xid は 0 件でした。このエラーは、3080 Ti の VRAM をほぼ使い切る実行で出ることを確認しています（12GiB を超えて確保に失敗した実行と、成功した 20b の実行の、どちらでも出ました）。通常の負荷で出るかどうかと、速度への影響は、確認していません。 gpt-oss-120b は、3080 Ti を足しても生成が速くならない 120b（63GB）は 12GiB に載らないので、層を 3080 Ti と内蔵 GPU に分けて測りました（llama-bench -ngl 99 -p 512 -n 128 -r 2 -dev Vulkan0/Vulkan1）。 -ts（3080 Ti / 内蔵） pp512 tg128 3080 Ti の VRAM 最大使用量 内蔵のみ（基準） 845.2 56.0 — 1/6 928.9 55.3 10275 MiB 1/8 924.0 54.8 8627 MiB 1/10 899.3 55.2 6978 MiB 1/4 メモリ確保に失敗（3080 Ti の 12GiB を超えます） プロンプト処理は、内蔵 GPU のみの場合より、最大で約 10% 速くなりました。 生成速度は、ほぼ変わりませんでした（誤差から −2% の範囲です）。 3080 Ti 単体で -ngl を絞った場合は、6 層なら動作し（VRAM は 9033 MiB）、8 層ではメモリ確保に失敗しました。 注意点: -dev Vulkan0/Vulkan1 の指定が必要です。b11803 は、dGPU があると内蔵 GPU を自動では使いません。指定しないと、全層が 3080 Ti に割り当てられて、メモリ確保に失敗します。-dev も -ts も、区切りはスラッシュです。 ⚠️ 注意点: 3080 Ti のクロックが上がらず、速度が約半分になる このベンチで、いちばん意外だったのがこの現象です。 トークン生成（tg）だけを回すと、gpt-oss-20b の tg256 が 87.8 t/s でした。速いときの約半分です。同じ現象は、llama-bench を繰り返し起動する 30 分の試験でも起きました。23:14 以降に SM クロックが 780〜1000MHz に下がり、pp2048 が約 4670 t/s から約 2800 t/s に落ちました。このとき、温度は 50℃ で、熱による制限の形跡はなく、PCIe も Gen4 x4 のままでした。 原因（実測）: tg だけの負荷では、GPU が P3 状態（省電力寄りの動作状態）のまま、SM クロックが 780MHz、メモリクロックが 5001MHz（最大は 9501MHz）に張り付いていました。pp4096 のような重い処理では P0（最大性能）になり、SM クロックは約 1490MHz まで上がります。つまり、軽い負荷では、ドライバがクロックを上げません（設定は既定のままです）。 既定のクロックで測ると、gpt-oss-20b（FA 有効）は pp512 が 2437.9、pp2048 が 3416.6、tg128 が 110.4 t/s でした（平均の SM クロックは 1190MHz）。クロックを固定すると、pp512 が 4232.5、pp2048 が 4583.9、tg128 が 160.6 t/s になりました。 確認用のコマンドです（実行結果を記録したものではありません）。負荷をかけながら、別の端末で見ます。 nvidia-smi --query-gpu=pstate,clocks.sm,clocks.mem --format=csv -l 1 対処: クロックを固定すると解消しました。再起動すると元に戻ります。 固定する（この 3080 Ti での値） sudo nvidia-smi -lmc 9501,9501 sudo nvidia-smi -lgc 1500,2100 元に戻す sudo nvidia-smi -rmc sudo nvidia-smi -rgc nvidia-settings の PowerMizer は使えませんでした。X が gdm のログイン画面のもので、認証がなく、変更できなかったためです。 固定した状態では、待機時も SM クロックが 1500MHz で推移しました（固定の影響と推測しています。待機時の消費電力は測っていません）。 起動時に自動で固定する仕組みは、作っていません。 OCuLink で速度は落ちるのか OCuLink（Gen4 x4）は、PCIe x16 より細い接続です。そのせいで速度が落ちていないかを確かめるため、公開されている測定値と比べました。 公開されている比較（Web 上の情報）では、モデルが VRAM に収まる場合、生成速度の低下は小さいとされています（PCIe 3.0 x1 で 3.4% という Jeff Geerling さんの測定の引用です）。一方、VRAM からあふれる場合のプロンプト処理は、大きく落ちます（Thunderbolt 3 での測定で 54%）。 公開値の多くは DirectX や CUDA での測定なので、同じ EVO-X2 を Windows で起動して測りました。Linux の Vulkan とは別の条件になります。実測の条件（2026-10-27）は、次のとおりです。 Windows 11 build 26300、nvidia 610.88 llama.cpp b11803 の CUDA 13.4 版、-ngl 99 負荷中のリンクは、2 回とも全サンプルが Gen4 x4 Llama 3 8B Q4_K_M（-p 512 -n 512 -r 3）では、pp512 が 5077、tg512 が 141.5 t/s でした。公開値の同じ 3080 Ti（XiongjieDai さんの表、2024 年 5 月の build、RunPod）は、pp512 が 3690、tg512 が 110.6 です。 Llama 2 7B Q4_0（-fa 0,1 -r 5）は、CUDA スコアボード #15013 と比べました。3080 Ti の行はないので、3080 と 3090 を上下の目安にします。 今回の 3080 Ti（FA 無 / 有） 3080（FA 無 / 有） 3090（FA 無 / 有） pp512 4908 / 5689 5014 / 5570 5175 / 5560 tg128 159.3 / 168.5 139.7 / 140.0 158.2 / 161.9 読み取れること: 今回の値は、公開されている 3080 / 3090 の範囲と同程度か、それ以上です。OCuLink（Gen4 x4）が原因で、公開値より遅くなっている兆候は見られません。 公開値には build が古いものが多いので、今回のほうが速い項目には、build の差が含まれています。 限界: 測ったモデルは、全層が VRAM に載ります。そのため、モデルの読み込みが終わったあとは、PCIe をほとんど使いません。この測定で言えるのは、「3080 Ti が公開値と同程度に動いている」ところまでです。PCIe x4 の影響の大きさ（x16 との比較）は、測れていません。 影響が出るのは、モデルの読み込み時間と、VRAM からあふれる処理（CPU や内蔵 GPU との分担）です。このうち、読み込み時間に効くホストから GPU への転送は、6.7 GB/s（理論値の約 85%）でした。 リンクを Gen3 や Gen2 に落とす対照実験は、行っていません（公開値との比較に方針を変えたためです）。 まとめ VRAM 12GB に収まるモデル（gpt-oss-20b）は、内蔵 GPU より、生成が約 2.2 倍、プロンプト処理が約 2.4 倍速くなりました。 VRAM に収まらない gpt-oss-120b は、3080 Ti を足しても生成速度が変わりませんでした。大きなモデルまで速くしたいなら、そのモデルが VRAM に収まる GPU が必要になります（VRAM の大きな GPU は試していないので、これは推測です）。 3080 Ti は、軽い負荷でクロックが上がらず、速度が約半分になります。nvidia-smi -lgc と -lmc で固定するまでは、ベンチの数字を信用しないほうがよいです。 公開スコアと比べて、OCuLink による目立った低下は見られませんでした（Time Spy のグラフィックススコアは、公開値の −2.0%〜+1.9% です）。ただし、x16 接続との比較で切り分けて測ったわけではありません。測ったモデルは VRAM に収まり、PCIe への依存が小さいためです。 次にやること: Linux で CUDA ビルドを使った比較と、Isaac Sim の VRAM の確認です。 ここから先は、補足の資料です。 資料 1: 中古の 3080 Ti は大丈夫だったか（初期確認のまとめ） 映像: HDMI 2 ポートで出ました。DisplayPort は機材がなく、未確認です。外観・ファン・コイル鳴きに問題はありませんでした。 VRAM 検査: memtest_vulkan で約 11.1GB を約 10 分半、約 22,000 回繰り返して、エラーは 0 件でした。 連続負荷: Heaven を 94 分回しました。リンクは Gen4 x4 のままで、Xid と PCIe のエラーは 0 件でした。 3DMark Time Spy（Windows）: グラフィックススコアは 19442 でした。公開値（同じ 3080 Ti）との差は −2.0〜+1.9% です。公開値は検索結果の要約から取ったもので、レビュー本文は確認していません。 Superposition 1080p Extreme: Linux の OpenGL で 10521、Windows の DirectX で 12379 でした。 PCIe エラー: この機種では、カーネルが「platform does not support AER」と出します（AER に対応していません）。そのため、AER が 0 件だったことは、強い証拠ではありません。 資料 2: 用語メモ 用語 この記事での意味 Gen4 x4 PCIe 4.0 の 4 レーンです。理論値は約 7.88 GB/s（16 GT/s）です P0 / P3 GPU の動作状態です。P0 が最大性能で、数字が大きいほど省電力になります AER / Xid AER は PCIe のエラーを報告する仕組みです。Xid は NVIDIA ドライバが出すエラー番号です。どちらもカーネルログ（journalctl -k）で確認します リプレイ PCIe の転送をやり直した回数です（nvidia-smi -q に出ます）。多い場合は、信号品質の問題を疑います 測っていないこと・分かっていないこと ⚠️ DisplayPort、Fire Strike（2 回とも失敗しました）、Steel Nomad は、測れていません。FurMark でクロックが 1305 MHz まで下がった原因も、分かっていません。 ⚠️ 長時間の LLM 連続推論は、測っていません。熱が飽和する数十分以上の負荷は、Heaven の 94 分しか見ていません。 ⚠️ Linux での CUDA の動作は、確認していません（Vulkan のみ測定しました）。Windows の CUDA 版は測定済みです。 ⚠️ OCuLink（Gen4 x4）による低下の割合は、x16 接続との比較では測っていません。 ⚠️ Isaac Sim の動作は、確認していません。

llama.cppのSYCLバックエンド向けにPR出しましたよ、っと。 oneAPI関連の更新に合わせて。 生成速度は変化なし（ほぼ誤差）、プロンプト評価は向上。 もうoneAPIの番人になりつつあるな、オレ llama.cpp#31540

遺伝的アルゴリズム×ローカルLLMで、自分の研究分野の「研究仮説」を考えるAIエージェントを動かす🧬 English version: github.com/otsukiLabo-NUCOE/creative-ai-hypothesi… ! ご利用にあたって この記事で紹介するコードは、研究成果の再現と活用のために公開しているものです。個別のサポート（インストールや実行時のトラブル、環境ごとの不具合への対応、使い方の個別相談など）はできかねます。 コードの利用、およびその結果（生成された仮説・研究計画の下書き・出典の内容など）の利用は、ご自身の責任で行ってください。これらの利用によって生じたいかなる損害についても、筆者は責任を負いません。 このAIエージェントを使うには、ある程度のITリテラシーが必要です。 具体的には、次のような操作を自分で行えることを前提にしています。 PowerShell（またはターミナル）でのコマンドの実行と、フォルダの移動 Python の環境構築（インストール、仮想環境、pip によるライブラリの導入） 環境変数の設定、Python ファイルの簡単な編集（設定値や一覧の書き換え） エラーメッセージを読み、検索などで原因を調べること （任意の手順5～6）llama.cpp やLLMのモデルのダウンロードと、ファイルの配置 このAIエージェントで生成した仮説や研究計画の下書きをもとに、論文・学会発表などで研究成果を公表する場合は、下記の論文を引用してください（引用情報は記事末尾の「引用のお願い」にあります）。 コードは MIT ライセンスで公開しています（無保証）。OpenAlex・arXiv・Hugging Face などの外部サービスは、それぞれの利用規約に従ってご利用ください。 はじめに この記事は、筆者の論文 Otsuki A. Comparing Genetic Algorithms and LLMs for Research-Hypothesis Generation: Mainstream Convergence of LLMs, Wider Hypothesis Exploration by Combinatorial Search, and the Limits of Literature-Distance Novelty Metrics. Informatics. 2026; 13(10):174. doi.org で公開したコードを使って、自分の研究分野の新しい研究仮説を、AIエージェントに考えさせるための手順を解説するものです。 論文の内容は、紹介動画（YouTube）でも解説しています。研究の背景や結果の全体像をつかみたい方は、あわせてご覧ください。 youtube.com このエージェントは、次の4つの部品でできています。 語彙：その分野の「手法（Method）」「課題（Problem）」「目標（Goal）」の単語の一覧。分野の論文でよく使われるキーワードから自動で作れます 知識空間：その分野の論文（タイトル＋要旨）を集めて、文の埋め込みでベクトル化したもの 遺伝的アルゴリズム（GA）：語彙の組合せ（手法×課題×目標）を進化させ、既存の研究から離れていて、かつ文献の裏付けもある仮説を探す ローカルLLM（任意）：選んだ仮説をもとに、研究計画の下書きを書く 論文データベースには無料の OpenAlex を使い、それ以外はすべて手元のPCだけで動きます。Claude や ChatGPT などの有料サービスは使いません。 ! 最初に知っておいてほしいこと（論文の結論より） このエージェントが出す仮説は「既存の論文から離れている」「LLMに自由に考えさせるより幅広い」ことは確かめられています。ただし、仮説が独創的で価値があることまでは保証しません。 論文では、文献からの距離で測る新規性の指標が、ICLR の査読者の評価とほぼ無関係だった（ρ $2264 0.06）ことも報告しています。また、効果を確かめたのはAI分野だけです。出てきた仮説は「アイデアの候補」として、最終的には人が吟味してください。 全体像 手順 すること 所要時間の目安（CPUのみ） 準備 環境構築、OpenAlex のAPIキーの取得 20～30分 手順0 分野の番号を調べる 数分 手順1～2 語彙を自動で作り、確認して書き込む 数分（語彙の手直しが必要なら追加で） 手順3 知識空間を作る 数分 手順4 仮説を作る 初回2～3分 手順5～6（任意） ローカルLLMで仮説を研究計画の下書きにする 数分～数十分 動作環境 筆者が動かした環境です。 Windows 11（macOS / Linux でも Python 部分は同じ手順で動きます） Python 3.13 メモリ 16GB 以上推奨（手順5でLLMを動かす場合は、モデルの大きさに応じてさらに必要） GPU はなくても動きます（手順5は GPU があると大幅に速くなります） インターネット接続（OpenAlex への問い合わせと、埋め込みモデルの初回ダウンロードに使います） 準備1：環境構築 リポジトリを取得する git clone otsukiLabo-NUCOE/creative-ai-hypothesis-generation cd creative-ai-hypothesis-generation git がない場合は、次のURLから ZIP をダウンロードして展開しても構いません（GitHub のページの「Code」→「Download ZIP」でも同じです）。 github.com/otsukiLabo-NUCOE/creative-ai-hypothesi… Zenodo にも版ごとに保存してあります。 版 DOI 内容 v1.0.5（この記事の手順に対応） doi.org サンプル原稿（examples/）を、この記事の手順6と同じ --seed 5 で作ったものに差し替え。LLMサーバーがエラーを返しても、下書きを途中で失わずに保存するよう修正 v1.0.4 doi.org 手順を飛ばしたときに警告を表示。下書きの先行研究（Related Work）・数式（Mathematical Formulation）・実験計画（Experimental Design）を詳しく書く機能、Reproducibility を実際の設定値から書く機能、サンプル原稿（examples/）を追加 v1.0.3 doi.org 下書きに、知識空間の実在の論文を出典として付ける機能を追加 v1.0.2 doi.org 自分の分野で使うためのスクリプト（make_concepts.py など）を追加 v1.0.1（論文で引用している版） doi.org 論文の実験のコード・データ・ログ ! この記事で使う make_concepts.py・build_knowledge_space_openalex.py・top_hypotheses.py は v1.0.2 以降、下書きに出典を付ける機能は v1.0.3 以降に入っています。 仮想環境を作ってライブラリを入れる python -m venv .venv Windows .venv\Scripts\activate macOS / Linux source .venv/bin/activate pip install -r requirements.txt GPUがないPCで torch のダウンロードが重いとき requirements.txt の torch は、そのままだとCUDA版を取りに行くことがあります。CPU版だけでよい場合は、先に次を実行してから pip install -r requirements.txt を実行してください。 pip install torch --index-url download.pytorch.org 主なファイル パス 中身 code/make_concepts.py 分野を指定して、語彙（concepts.py）を自動で作る code/build_knowledge_space_openalex.py OpenAlex から知識空間（data/corpus.jsonl）を作る code/top_hypotheses.py GAで仮説を作り、全組合せの上位の仮説も表示する code/creative_ai_agent_local_llm.py 選んだ仮説を、ローカルLLMで研究計画の下書きにする（実在の論文を出典として付ける） code/concepts.py 語彙（手法・課題・目標の一覧）。手順2で書き換わる code/creative_ga.py 提案モデル本体（埋め込み、新規性、有用性、GA） prompts/ LLMに渡すプロンプト 準備2：OpenAlex の APIキー（無料）を取る OpenAlex は、世界中の学術論文の情報（タイトル・要旨・キーワードなど）を無料で公開しているデータベースです（openalex.org ）。経営学・経済学・医学・人文学なども含みます。 キーなしでも使えますが、同じネットワークの利用者全員で1日あたり約100回までしか問い合わせできません（大学のネットワークでは、他の人の利用ですぐに尽きることがあります）。知識空間を作るには60回ほど問い合わせるので、無料のAPIキーを取ることを強くおすすめします。 openalex.org を開き、メールアドレスを登録してキーを取ります。 手順を実行する PowerShell（またはターミナル）で、キーを環境変数に設定します。 Windows PowerShell（そのウィンドウを閉じるまで有効） $env:OPENALEX_API_KEY = "取得したキー" macOS / Linux export OPENALEX_API_KEY="取得したキー" 自分の研究分野で仮説を作る（経営情報学の例） ここからは、経営情報学（Management Information Systems）を例に、一連の手順を説明します。手順0～4は、同じ PowerShell のウィンドウで続けて実行してください（ウィンドウを閉じると、APIキーの設定が消えます）。 まず、リポジトリの code フォルダに移動しておきます。 cd <リポジトリを置いた場所>\creative-ai-hypothesis-generation\code 手順0：研究分野の番号を調べる OpenAlex では、論文が分野ごとに分類されていて、それぞれに番号（subfield ID）があります。ブラウザで次のURLを開きます。search= の後ろに分野名を英語で入れます（単語の間の空白は %20 にします）。 api.openalex.org 次のような結果が表示されます（見やすく整えています）。 { "results": [ { "id": "openalex.org", "display_name": "Management Information Systems", "field": { "id": "openalex.org", "display_name": "Business, Management and Accounting" } }, { "id": "openalex.org", "display_name": "Information Systems and Management", ... }, { "id": "openalex.org", "display_name": "Health Information Management", ... } ] } "display_name" が目的の分野になっている結果を探します。その "id" の末尾の数字が分野の番号です。経営情報学は 1404 です。 その下の "field" の "id" の末尾の数字（経営情報学なら 14）は、手順3で使います。 URLの最後の &select=id,display_name,field は、必要な項目だけを表示するための指定です。これを付けないと、同じ階層のすべての分野の一覧（"siblings"）まで表示され、番号が見つけにくくなります。 主な分野の番号 分野 subfield ID field 経営情報学（Management Information Systems） 1404 14 情報システムと経営（Information Systems and Management） 1802 18 戦略・経営（Strategy and Management） 1408 14 マーケティング（Marketing） 1406 14 経済学・計量経済学（Economics and Econometrics） 2002 20 人工知能（Artificial Intelligence） 1702 17 情報システム（Information Systems） 1710 17 制御・システム工学（Control and Systems Engineering） 2207 22 医療情報管理（Health Information Management） 3605 36 哲学（Philosophy） 1211 12 科学史・科学哲学（History and Philosophy of Science） 1207 12 手順1：語彙を自動で作り、確認する --dry-run を付けて実行すると、concepts.py を書き換えずに、作られる語彙を表示だけします。 python make_concepts.py --subfield 1404 --dry-run make_concepts.py は、指定した分野の論文で多く使われているキーワードの上位200個を OpenAlex から取り出し、決まったルールで「手法・課題・目標・除外」に振り分けます（生成AIは使いません）。 出力例（経営情報学、2021～2025年の論文） 200 keywords fetched from OpenAlex Method (12): - Decision Support System - Enterprise Resource Planning - Business Intelligence - Artificial Intelligence - Process Mining - Data-driven Decision Making - Balanced Scorecard - Accounting Information Systems - Big Data - Blockchain - Demand Forecasting - Predictive Analytics Problem (9): - Risk Management - Demand Uncertainty - Data Security - Information Asymmetry - Information Sharing - Data Privacy - Implementation Barriers - Cybersecurity - Supply Chain Disruption Goal (8): - Competitive Advantage - Operational Efficiency - Firm Performance - Customer Satisfaction - Organizational Performance - Continuous Improvement - Cost Reduction - Key Performance Indicators excluded as context/noise (first 15): ['inventory management', 'fintech', 'supply chain management', 'small and medium-sized enterprises', 'digital transformation', ..., 'COVID-19 pandemic', 'exam dumps', ...] 「Method（手法）」「Problem（課題）」「Goal（目標）」の一覧を見て、その分野の語彙として妥当かを確認します。最後の行は、語彙から外したキーワード（対象や文脈を表す言葉や、ノイズ）です。 妥当な場合 → 手順2へ進みます。 おかしな語がある場合（例：手法なのに課題に入っている、大事なキーワードが除外されている）→ 後述の「語彙がうまく作れないとき」に沿って直し、もう一度 --dry-run で確認します。 make_concepts.py のオプション オプション 既定値 意味 --subfield $2014 OpenAlex の分野の番号 --search $2014 分野の番号の代わりに（または加えて）、キーワードで論文を絞り込む（例：--search "digital transformation"） --from / --to 2021-01-01 / 2025-12-31 キーワードを数える論文の期間 --n-method / --n-problem / --n-goal 12 / 10 / 8 各役割の語数（上限。条件に合う語が少なければ、それより少なくなる） --margin 0.08 手がかり語がないキーワードを、埋め込みだけで役割に入れるときの基準（後述） --dry-run $2014 書き換えずに表示だけする 手順2：語彙を concepts.py に書き込む --dry-run を外して実行します。 python make_concepts.py --subfield 1404 最後に「concepts.py updated (〇〇 hypotheses)」と表示されれば完了です。元のファイルは concepts.py.bak として残ります。この例では、手法12 × 課題9 × 目標8 = 864通りの仮説の中から探すことになります。 ! 手順を飛ばしたときは、スクリプトが警告します（v1.0.4 以降）。 語彙を書き込まずに手順3を実行した場合、語彙を作った分野と FIELDS が合っていない場合、語彙を変えたのに知識空間を作り直していない場合などに、警告を表示します。止まった場合は、表示された指示に従ってください（そのまま続けたいときは y を入力するか、--force を付けて実行します）。各警告の意味は「トラブルシューティング」にまとめています。 ! 語彙を変えたら、必ず次の手順3で知識空間を作り直してください。 ZIPから展開したばかりのフォルダには、論文の実験で使ったAI分野の知識空間が入っています。手順3を飛ばすと、経営情報学の仮説をAI分野の論文と比べることになり、新規性が見かけ上高くなったり、無関係な論文が出典に選ばれたりします（v1.0.4 以降では、この状態を検出すると警告が表示されます）。 手順3：知識空間を作る（数分） その語彙で、OpenAlex から論文を集めます。 python build_knowledge_space_openalex.py 最後に「done: {'past': 〇〇, 'future': 〇〇}」と表示されれば完了です。結果は data/corpus.jsonl に保存されます。 語彙の各単語で検索した論文と、分野全体からランダムに選んだ論文を集めます。 past はGAが比べる論文（既定値は2021年1月～2025年6月）、future は評価用に取っておく論文（2025年7月～12月）です。 ! 経営情報学以外の分野では、FIELDS を変えてください。 build_knowledge_space_openalex.py の冒頭にある FIELDS は、論文を集める分野の大きな区分（field）の番号です。既定値は経営情報学向けの "14|17|18"（経営・経営学・会計 ／ コンピュータ科学 ／ 意思決定科学）になっています。手順0で控えた "field" の番号に変えてください（例：哲学なら "12"）。複数の区分を含めるときは | でつなぎます。 手順4：仮説を作る python top_hypotheses.py GAで作った仮説（seed 1～5）と、全組合せの中の上位10件の仮説が表示されます。 出力例（経営情報学。期間や取得した論文によって変わります） --- GA (seed 1-5) seed=1: Demand Forecasting for Organizational Performance to solve Data Privacy N=0.503 U=0.629 f=0.554 seed=2: Decision Support System for Continuous Improvement to solve Risk Management N=0.501 U=0.606 f=0.543 ... --- top 10 of all combinations Demand Forecasting for Organizational Performance to solve Data Privacy N=0.503 U=0.629 f=0.554 Decision Support System for Continuous Improvement to solve Risk Management N=0.501 U=0.606 f=0.543 Artificial Intelligence for Cost Reduction to solve Information Asymmetry N=0.556 U=0.518 f=0.541 ... 例えば「Artificial Intelligence for Cost Reduction to solve Information Asymmetry」は、「AIを使って情報の非対称性の問題を解き、コストを削減する」という仮説です。 スコアの意味 記号 意味 計算方法 N（新規性） 既存の論文からどれだけ離れているか 仮説の文（例：「Using AI to address Information Asymmetry in order to improve Cost Reduction.」）と、知識空間の各論文をベクトル化し、最も似ている論文との類似度を1から引いたもの U（有用性） 組合せの各ペアが文献で裏付けられているか 「手法×課題」「手法×目標」「課題×目標」の3つのペアが、それぞれ文献でどれだけ扱われているかの平均 f（適応度） GAが最大化する値 f = 0.6 N + 0.4 U N が高いだけだと「突飛で意味のない組合せ」になりやすく、U が高いだけだと「ありふれた組合せ」になります。GAは、その間のちょうどよい仮説を探します。GAの設定（個体数10、世代数20、評価回数200など）は code/creative_ga.py の冒頭にあります。 手順5（任意）：ローカルLLMのサーバーを起動する 気に入った仮説を、ローカルLLMで研究計画の下書きにします。初めての場合は、先に llama.cpp とモデルを用意します。 github.com/ggml-org/llama.cpp/releases から、自分の環境に合うビルドをダウンロードして展開します。 Windows・GPUなし：llama-bXXXX-bin-win-cpu-x64.zip Windows・NVIDIA GPU：llama-bXXXX-bin-win-cuda-12.4-x64.zip と cudart-llama-bin-win-cuda-12.4-x64.zip（同じフォルダの直下に中身を全部展開します） Hugging Face から GGUF 形式のモデルをダウンロードします。CPUでも動かしやすいのは、8B程度のモデル（例：Llama-3.1-8B-Instruct の Q8_0 版、約8GB）です。 PowerShell をもう1つ開いて、llama-server.exe のあるフォルダに移動してから、サーバーを起動します（パスは自分の環境に合わせます）。 cd C:\llama.cpp .\llama-server.exe -m "<モデルのパス>\Meta-Llama-3.1-8B-Instruct-Q8_0.gguf" --port 8080 -c 8192 --jinja C:\llama.cpp は、llama.cpp を展開したフォルダの例です。llama-server.exe がその下のフォルダ（例：build\bin）にある場合は、そのフォルダに cd してください。 .\ は「今いるフォルダの」という意味です。PowerShell では、今いるフォルダのプログラムを実行するときに必要です（付けないと「認識されません」というエラーになります）。 cd せずに、C:\llama.cpp\llama-server.exe -m … のようにフォルダごと指定して実行しても同じです。 -m のあとには、手順2でダウンロードしたモデル（.gguf ファイル）のパスを、" で囲んで書きます。 しばらく待つと、次のように自動で表示されます。 起動できたときの表示（抜粋。入力するものではありません） llama_server: model loaded llama_server: listening on 127.0.0.1 ! 上の2行は画面に出る表示の例です。PowerShell に入力しないでください（入力すると「用語 'llama_server:' は、コマンドレット…として認識されません」というエラーになります。エラーが出ても害はありません）。 「listening on http://127.0.0.1:8080」と表示されれば起動完了です。このウィンドウは、下書きができるまで閉じないでください。 使い終わったら、このウィンドウで Ctrl＋C を押すとサーバーが止まります。 手順6（任意）：研究計画の下書きを書かせる 元の PowerShell（手順0～4を実行したウィンドウ）で、次を実行します。 $env:LLAMA_SERVER_MODEL_NAME = "Llama-3.1-8B-Instruct" python creative_ai_agent_local_llm.py --seed 5 --source ga --seed 5 の数字を、下書きにしたい仮説の seed に変えます。手順4の「GA (seed 1-5)」と同じ seed なら、同じ仮説が使われます（ここでは seed 5 の仮説で書かせています）。 LLAMA_SERVER_MODEL_NAME は、ログに記録するモデル名です（使うモデルは手順5で起動したものになります）。 最初に「[ga, seed=5] …（N=…, U=…, f=…）」と、使う仮説が表示されます。手順4の「GA (seed 1-5)」の5行目と同じ仮説になっているか確かめてください。 CPU で書くので、十数分～数十分かかります（LLMを4回呼びます。下の「先行研究・数式・実験計画の書き方」を参照）。 出典（参考文献）も自動で付きます（v1.0.3 以降。下の「出典の付け方」を参照）。 下書きの末尾には、この記事の「引用のお願い」と同じ、論文の引用のお願いが付きます。 「Reproducibility」の節は、LLMには書かせず、スクリプトが実際の設定値（GAの世代数・個体数・seed、知識空間の論文数、スコア、LLMのモデル名と生成設定、ログの場所）から書きます（v1.0.4 以降）。LLMに書かせると、穴埋め（[insert script name] など）や設定の誤りが残るためです。 最後に次のような表示が出れば完了です。 written: results/manuscripts/ga_seed05_20261101_153012.md (log: results/writer_logs/ga_seed05_20261101_153012.json) code フォルダの1つ上の results\manuscripts\ に、Markdown の下書きが保存されています。メモ帳や VS Code で開いて確認してください。results\writer_logs\ には、使ったプロンプト・設定・選んだ参考文献・LLMの生の応答が記録されます。 完成イメージ（サンプル） 経営情報学の例で、上の手順0～6（--seed 5、Llama-3.1-8B-Instruct）をそのまま実行し、スクリプトが書いた下書きを PDF にしたものです（英語、約3,300語、A4で10ページ）。手は一切加えていません。 仮説は「Business Intelligence for Competitive Advantage to solve Demand Uncertainty」（N=0.42, U=0.604, f=0.494）です。 サンプルの PDF（全10ページ。クリックすると GitHub 上で全ページを読めます） 元の Markdown と、LLMへの指示・生の応答を記録したログも、同じ examples/ フォルダにあります。以下は PDF の一部です。 1ページ目。Related Work は、出典をテーマごと（BIの基礎、意思決定、需要の不確実性、競争優位など）に紹介しています。タイトルの下の「=====」は、LLMが書いた記号がそのまま残ったものです。 Mathematical Formulation の節。記号の表、各構成要素の式、手法→課題→目標のモデル（式1～3）、意思決定問題（式4～6）が続きます。 節 中身 Abstract・Introduction・Proposed Method 1回目の呼び出しで書いた全体の構成 Related Work 出典をテーマごとに紹介し、最後に研究のすき間と貢献（8本のうち7本に言及） Mathematical Formulation 記号の表、データ収集・分析・意思決定の式、手法→課題→目標のモデル、意思決定問題、アルゴリズム、仮説 H1～H3、前提（番号付きの式6本） Experimental Design H1～H3 を確かめる研究計画（差の差分法、データと標本、検出力分析の式、変数の測り方の表、分析計画、妥当性への脅威など） Reproducibility スクリプトが実際の設定値から書いた節 References 知識空間から選んだ実在の論文8本（DOI付き）と、論文の引用のお願い ! 体裁は整っていますが、研究としての新規性があるとは限らず、中身にも粗が残っています。 このサンプルでも、例えば次のような粗が見られます。 課題の変数 U を「不確実性の減少量」と定義しているのに、仮説 H1 を「\alpha_1 < 0」としていて、符号の向きが逆になっている 関数 \phi・\psi の具体的な形が書かれていない 研究デザインが、出典の1本に引きずられて「競合する小売2社の比較」になっており、統計的な検定ができない こうした粗の多くは、下書きを書く LLM の性能に左右されます。 このサンプルは、CPU でも動かせる小さなモデル（Llama-3.1-8B-Instruct、80億パラメータ）で書いたものです。スクリプトは、指示文で「式の形を必ず書く」「記号を一貫させる」などを指定し、式が少なければ書き直させていますが、小さなモデルでは指示を守り切れず、上のような誤りが残ります。より大きく性能の高いモデル（例：70B 級のモデルや gpt-oss-120b）に替えれば、一般にこうした誤りは減ると期待できます。モデルを替えるには、手順5で別のモデル（GGUF ファイル）を指定してサーバーを起動し、手順6の LLAMA_SERVER_MODEL_NAME をそのモデル名にします（ただし、このサンプルでは大きなモデルは試していません）。一方で、仮説そのものの新規性は、GA が選んだ組み合わせで決まるため、LLM を替えても変わりません。 また、どのモデルでも誤りがなくなる保証はないので、下書きの中身は必ず自分で確認してください。 このサンプルの仮説を経営情報学の査読基準で見た評価は、「参考：生成された仮説を査読の目で見る（経営情報学の例）」を参照してください。 自分の下書きを PDF にするには VS Code の拡張機能「Markdown PDF」などで、Markdown を PDF に変換できます。数式（$$ … $$）をきれいに表示したい場合は、数式に対応した拡張機能（例：「Markdown Preview Enhanced」の PDF 出力）を使ってください。 出典の付け方（v1.0.3 以降） ローカルのLLMはインターネットにつながっていないため、「出典を書いて」と頼むだけでは、実在しない論文をそれらしく作ってしまう（捏造する）おそれがあります。そこで、このスクリプトは次の仕組みで、実在する論文だけを出典にします。 論文を選ぶ： 手順3で集めた知識空間の中から、仮説の文と、その3つの組（手法×課題、手法×目標、課題×目標）に最も近い論文を、合わせて8本選びます。 書誌情報を取る： 選んだ論文の著者・年・掲載先・DOI を、OpenAlex（arXiv の論文なら arXiv）から取得します。 LLMに渡す： 論文のタイトル・年・要旨の一部を番号付きでLLMに渡し、「この一覧の論文だけを [1] [2] の形で引用する。他の文献は書かない。要旨から言えないことに引用を付けない」と指示します（prompts/writer_with_references_system_prompt.txt）。 参考文献を付ける： 参考文献の一覧は、LLMには書かせず、スクリプトが正確な書誌情報で末尾に付けます。LLMが勝手に一覧を書いた場合は削除します。 引用を確かめる： 一覧にない番号が本文に出てきた場合は、警告を表示し、下書きの末尾にも注意書きを付けます。 下書きの末尾に付く参考文献の例（経営情報学） References [3] Let$00EDcia Siguinolfi De Lima, Elder Elisandro Schemberger, Mariana Sbaraini Cordeiro et al. (2024). A methodology for risk analysis and management on information assets of public or private organizations mapped by systematic literature review. Contribuciones a las Ciencias Sociales. doi.org [6] Marion Toussaint, Sylv$00E8re Krima, Herv$00E9 Panetto (2024). Industry 4.0 data security: A cybersecurity frameworks review. Journal of Industrial Information Integration. doi.org ... オプション 意味 --refs 8（既定） 知識空間から8本の論文を選んで出典にする。数を変えるときは --refs 12 のように指定 --refs 0 出典を付けない（論文の実験と同じ書き方） ! 出典は「仮説に近い論文」であって、文献調査の結果ではありません。 選ばれるのは知識空間（手順3で集めた論文）の中で、文章が近い論文だけです。その分野の重要な先行研究が含まれるとは限りません。 書籍の章のような、内容の薄い文献が選ばれることもあります。 LLMが、要旨から言えないことに引用を付けている可能性もあります。 本文の引用が、その論文の内容と合っているか、必ず原典で確認してください。 研究として使う場合は、自分で文献調査を行ってください。 先行研究・数式・実験計画の書き方（v1.0.4 以降） 長い下書きを一度に書かせると、小さなLLMでは「Related Work」が出典を2～3本並べただけの1段落になったり、「Mathematical Formulation」が R + D + C = Firm Performance のような1行だけになったり、「Experimental Design」が「ケーススタディで評価する」程度の1段落になったりします。そこで v1.0.4 では、本文を書いた後に、この3つの節だけを別々にLLMに書き直させます。 順番 書く節 LLMに渡すもの 書かせる内容 1回目 下書き全体 仮説・スコア・出典の一覧 全体の構成 2回目 Related Work 仮説と、1回目の Proposed Method と、出典の一覧（要旨は1回目より長い最大1,500文字） 出典の全部を、テーマごと（手法・課題・目標など）に、各論文が何をどう調べ何を示したかを2～4文で紹介し、論文どうしを比べ、最後に「研究のすき間（Research Gap）」と、この仮説がそれをどう埋めるか・貢献 3回目 Mathematical Formulation 仮説と、1回目の Proposed Method 記号の表、各構成要素の式、手法→課題→目標のモデル（P = \alpha_0 + \alpha_1 M + \dots、G = \beta_0 + \beta_1 P + \dots）、意思決定（最適化）問題、アルゴリズム、検証できる仮説（例：H1: \alpha_1 < 0）、前提 4回目 Experimental Design 仮説と、Proposed Method と、3回目の数式 3回目の仮説 H1～H3 を確かめる研究計画：研究デザイン、データと標本（標本数は検出力分析で決める）、変数の測り方の表、手順、推定と検定、内生性への対処、比較対象との評価、頑健性と妥当性への脅威、倫理 指示文は prompts/related_work_system_prompt.txt・prompts/formulation_system_prompt.txt・prompts/experimental_design_system_prompt.txt にあります。Related Work の書き直しは、出典を付けるとき（--refs が1以上）だけ行います。分野に合わせて書き換えることもできます。 オプション 意味 （指定なし） 3つの節を詳しく書き直す --no-detail 書き直さない（v1.0.3 までと同じ） --detail ファイル名.md すでに作った下書きの3つの節だけを書き直し、～_detailed.md として保存する（元のファイルは変えない） すでにある下書きの3つの節だけを書き直す例 python creative_ai_agent_local_llm.py --detail ..\results\manuscripts\ga_seed05_20261101_153012.md ! 先行研究のまとめ・式・計画は「叩き台」です。 小さなLLM（8Bなど）では、式の重複、記号の揺れ、指示したのに具体的な数字（「5年間」「100人以上」など）を書いてしまう、といった粗が残ります。研究計画として使う前に、先行研究の紹介が各論文の内容と合っているか（原典で確認）、式の意味・符号・変数の測り方が研究として妥当か、必ず自分で確認・修正してください。 ! この下書きは、評価実験をしていません。 GAが選んだ仮説をもとに、LLMが「研究計画の下書き」として書いた文章です。LLMには、渡した論文以外の文献や、架空のデータ・実験結果を作らないこと、実験の部分は「今後の計画」として書くことを指示しています（prompts/writer_with_references_system_prompt.txt）。内容の正しさや価値は、必ず自分で判断し、研究として進める場合は実際のデータで検証してください。 生成の設定（環境変数） 環境変数 既定値 意味 LLAMA_SERVER_ENDPOINT 127.0.0.1 LLMサーバーのURL LLAMA_SERVER_MODEL_NAME gpt-oss-120b ログに記録するモデル名 LLM_MAX_TOKENS 6000 生成する最大トークン数 LLM_DETAIL_MAX_TOKENS 4000 先行研究・数式・実験計画の節（2～4回目）の最大トークン数 LLM_TEMPERATURE 0.7 温度 LLM_TOP_P 1.0 top-p LLM_TIMEOUT_S 7200 応答を待つ最大秒数 注意 手順0～4は、同じ PowerShell のウィンドウで続けて実行してください。 ウィンドウを閉じると、APIキーの設定（$env:OPENALEX_API_KEY）が消えます。 手順3で「the daily request budget is used up」と表示された場合は、OpenAlex の無料枠が尽きています。APIキーを設定するか、日本時間の午前9時（UTCの0時）以降にやり直してください。 手順5のサーバーのウィンドウと、手順6を実行するウィンドウは別です。 語彙がうまく作れないとき make_concepts.py の仕組み make_concepts.py は、OpenAlex から取り出したキーワードを、次の順で「手法（Method）」「課題（Problem）」「目標（Goal）」「除外（other）」に振り分けます。 除外の判定： 埋め込みモデルで、キーワードが「除外の例の単語」（対象・文脈・ノイズ）にいちばん近ければ除外する。 手がかり語： キーワードに「手がかり語」が含まれていれば、その役割にする（例：「Demand Uncertainty」は課題、「Firm Performance」は目標）。キーワードの最後の語が最優先です。 埋め込みの類似度： 手がかり語がなければ、「役割ごとの例の単語」にいちばん近い役割にする。ただし、2番目との差が --margin（既定 0.08）より小さければ除外する。 「手がかり語（CUES）」と「役割ごとの例の単語（EXAMPLES）」は、スクリプト冒頭の固定の一覧です。 code/make_concepts.py（冒頭。一部省略） EXAMPLES = { # 役割ごとの例の単語（埋め込みで比べる相手） "Method": ["machine learning", "regression analysis", "simulation", "process mining", "blockchain", ...], "Problem": ["risk", "fraud", "information overload", "supply chain disruption", "data privacy", ...], "Goal": ["firm performance", "customer satisfaction", "competitive advantage", "operational efficiency", ...], "other": ["small and medium-sized enterprises", "COVID-19 pandemic", "banking sector", "case study", ...], } CUES = { # 手がかり語（キーワードに含まれていれば、その役割にする） "Problem": ["risk", "uncertainty", "asymmetry", "fraud", "failure", "disruption", "barrier", ...], "Goal": ["performance", "efficiency", "advantage", "satisfaction", "value", "productivity", ...], "Method": ["system", "analytics", "learning", "mining", "model", "intelligence", "analysis", ...], } ! この2つの一覧は、経営・情報系の分野に合わせてあります。 物理・化学・医学・人文学などでは、一覧を分野に合わせて書き換えないと、意図した語彙が作られないことがあります（例：物理の「quantum entanglement」は、どの手がかり語にも当てはまらず除外されるかもしれません）。 よくある症状と直し方 手順1の --dry-run で結果を確認し、次の表に沿って一覧を直します。直したら、もう一度 --dry-run で確認し、納得できるまで繰り返します。 症状 原因 直し方 手法なのに課題（または目標）に入る 誤った役割の手がかり語を含んでいる（例：「Risk Model」） CUES を見直し、分野でよく使う語尾を正しい役割に入れる 大事なキーワードが除外される 「除外の例の単語」に近い、または判断が曖昧 その役割の手がかり語を CUES に、似た語を EXAMPLES に加える。--margin を下げる（例：0.04）と除外が減る（誤りは増える） 分野の対象（業種・国・病名など）が語彙に入る 対象の言葉が「除外の例の単語」に似ていない 分野でよく出る対象の言葉を EXAMPLES["other"] に数個加える ある役割の語が少ない その役割の手がかり語が分野に合っていない 分野で課題を表す語（例：医学なら「disease」「side effect」、物理なら「decoherence」「noise」）を CUES["Problem"] に加える 語彙全体が分野と合わない 分野の番号が広すぎる・狭すぎる 別の番号を試すか、--search で絞る 書き換えの例：物理（量子コンピューティング） EXAMPLES には各役割に分野の典型的な語を5～12個、CUES にはその役割を表す語尾を中心に入れます。 code/make_concepts.py（書き換えの例） EXAMPLES = { "Method": ["variational quantum eigensolver", "quantum error correction", "tensor network", "density functional theory", "monte carlo simulation", "machine learning"], "Problem": ["decoherence", "gate error", "noise", "barren plateau", "scalability limits", "crosstalk"], "Goal": ["fidelity", "coherence time", "quantum advantage", "accuracy", "scalability", "energy efficiency"], "other": ["superconducting qubits", "trapped ions", "review", "experimental demonstration", "theory"], } CUES = { "Problem": ["error", "noise", "decoherence", "plateau", "crosstalk", "leakage", "loss", "instability"], "Goal": ["fidelity", "advantage", "accuracy", "efficiency", "time", "speedup"], "Method": ["algorithm", "eigensolver", "correction", "network", "theory", "simulation", "learning", "code"], } python make_concepts.py --search "quantum computing" --dry-run 最後は手で直してよい make_concepts.py は叩き台を作る道具です。思いどおりにならない語は、concepts.py を直接開いて手で直してください。GAは語彙の組合せの中からしか探せないので、分野で重要な課題や、最近注目されている手法を研究者の目で加えることが、仮説の質を大きく左右します。手で直したら、手順3で知識空間を作り直してください。 論文が少なかった語を確認する 要旨にほとんど出てこない語は論文が集まらず、その語を含む組合せが見かけ上「新しい」と判定されます（例：最初から入っているAI分野の語彙の「Miscalibrated Uncertainty」は1件しか集まらず、新規性の上位に入っていました）。手順3の後に次のコードで確認し、件数が少ない語は、よく使われる言い方に直してください。 code/check_terms.py import json log = json.load(open("../data/corpus_build_log.json", encoding="utf-8")) for q in log["queries"]: if q["route"] == "targeted" and q["n"] < 25: print(q["window"], q["q"], q["n"]) print("集まった論文の数:", log["n_records"]) （応用）仮説の文の型を変える 仮説は code/concepts.py の2つの関数で英文にしてから、論文と比べています。 code/concepts.py（抜粋） def hypothesis_text(m, p, g): return f"Using {m} to address {p} in order to improve {g}." # 仮説全体の文（新規性の計算に使う） def pair_texts(m, p, g): return (f"{m} for {p}", f"{m} for {g}", f"addressing {p} to improve {g}") # 2つずつの組（有用性の計算に使う） 研究の形が「手法で課題を解き、目標を良くする」に合わない場合は、一覧の名前（Method・Problem・Goal）はそのままで、中に入れる言葉の意味と、文の型を対応させて書き換えます。 分野の例 一覧に入れる言葉 hypothesis_text の型の例 経済学の実証研究 Method：分析手法、Problem：要因・政策、Goal：結果の変数 Using {m} to estimate the effect of {p} on {g}. 哲学 Method：理論・立場、Problem：問い・概念、Goal：説明したい対象 Applying {m} to the question of {p} to explain {g}. 医学 Method：介入・治療、Problem：疾患・症状、Goal：改善したい指標 Using {m} to treat {p} in order to improve {g}. pair_texts の3つの組も同じ意味になるよう書き換えます（例：哲学なら f"{m} on {p}"、f"{m} explaining {g}"、f"{p} and {g}"）。埋め込みの計算は自動でやり直されます。 知識空間を別の方法で作る arXiv から作る場合（AI・物理・数学など arXiv に論文が多い分野） 元からある build_knowledge_space.py も使えます（APIキーは不要）。冒頭の CATS（arXiv のカテゴリ。一覧は arxiv.org ）と WINDOWS（期間）を書き換えて実行します。1回の検索ごとに数秒あけるので、10～20分かかります。 CATS = "(cat:cs.RO OR cat:cs.AI OR cat:cs.LG)" # 例：ロボット工学とAI WINDOWS = { "past": ("202301010000", "202512312359"), "future": ("202601010000", "202603312359"), } 自分で集めた論文データを使う場合 PubMed などから集めた論文を、1行に1論文の次の形式で data/corpus.jsonl に保存すれば使えます。タイトルと要旨は英語にし、window は "past"（比べる論文）か "future"（評価用。数件でもよいので必ず入れる）にします。 {"id": "PMID12345", "title": "英語のタイトル", "abstract": "英語の要旨", "date": "2024-05-01", "window": "past"} 結果の読み方と注意点 論文の実験から分かった、使うときの注意です。 N（新規性）が高い ≠ 独創的 N は「文章として既存の論文に似ていないこと」を測っているだけです。ICLR の 9,755件で調べたところ、この値は査読者の評価とほぼ無関係でした。 GAは「同じ質の仮説を、より幅広く」出す道具 この規模では、ランダム探索や山登り法と比べて、より良い仮説を見つけるわけではありません。違いは、試行ごとに多様な仮説を出す点です。 LLM自身に提案させると、主流のテーマに偏る 論文では、2つのモデル × 2つのプロンプト × 2つの温度のすべてで、LLMの提案はGAより多様性が低く、既存研究に近い結果でした。「LLMに考えさせると似たようなアイデアばかり出る」と感じるときに、GAによる組合せ探索が役に立ちます。 LLMに原稿や仮説を採点させても当てにならない 8Bと70BのLLMに採点させたところ、ほぼ全部同じ点になったり、提示順に左右されたりしました。仮説の良し悪しは、人が判断してください。 参考：生成された仮説を査読の目で見る（経営情報学の例） 「完成イメージ（サンプル）」（--seed 5）の仮説は「Business Intelligence for Competitive Advantage to solve Demand Uncertainty」（N=0.42, U=0.604, f=0.494）でした。情報システム（BI）が主役なので、経営情報学のテーマとしては筋が通っています。しかし、経営情報学の査読基準（新規性、情報システム研究としての貢献、理論的な基礎、測定、研究デザイン）に照らすと、このままでは新規性はほとんどありません。 「BI や IT の能力が競争優位をもたらすか」は、経営情報学で長く研究されてきた中心的なテーマです。 「情報システムが、環境の不確実性に対処する力を高める」という考え方も、組織の情報処理理論でよく知られた考え方です。 また、市場の需要の不確実性は企業の外にある条件なので、BI が「解消する」課題としてではなく、BI の効果を強めたり弱めたりする条件（調整変数）として扱うのが一般的です。 この結果は、Informatics 論文の主張と一致しています。 GA は LLM より幅広い組み合わせを探せます。 しかし、文献からの距離で測る新規性は、研究として本当に新しいかとは別物です（論文タイトルの「Limits of Literature-Distance Novelty Metrics」の部分）。 今回の仮説も、文献から見るとそこそこ離れた組み合わせですが、研究者の目で見ればよく知られた関係の組み合わせです。 この仮説を研究の種として育てるなら GA が出した組み合わせは出発点として使い、次のどれかで独自の切り口を加える必要があります。 IT の役割を具体的にする： 「BI 一般」ではなく、例えば「AI を組み込んだ BI」や「現場の担当者が自分で分析するセルフサービス BI」の利用が、需要予測の精度や意思決定の速さを通じて競争優位に効くか、という具体的な仕組みを問う。 理論の枠組みを入れる： 組織の情報処理理論を使い、「需要の変動が大きい環境ほど、BI の能力が業績を高める効果が大きい」という調整効果の仮説を立てる。 測定とデザインを直す： 手法は「BI の能力（尺度）や導入時期」、課題は「需要予測の誤差や売上の変動係数」、目標は「ROA や業界内での相対的な業績」で測る。小売2社の比較ではなく、多数の企業のパネルデータで検定できるようにする。 ! このエージェントは「研究者が自分では思いつかない組み合わせを、幅広く示す」道具です。示された組み合わせが研究として新しいか、意味があるかは、先行研究を自分で調べたうえで判断してください。 トラブルシューティング 症状 対処 WARNING: concepts.py still contains the default vocabulary of the paper (AI). と表示されて止まる 手順2（--dry-run を外して語彙を書き込む）が抜けています。python make_concepts.py --subfield 番号 を実行してから、手順3をやり直してください WARNING: the vocabulary was made for subfield ... but FIELDS ... is ... と表示されて止まる 語彙を作った分野と、build_knowledge_space_openalex.py の FIELDS が合っていません。表示された値（例：FIELDS = "12"）にスクリプト冒頭の FIELDS を書き換えてから、やり直してください NOTE: ... term(s) of concepts.py were not used to build the knowledge space と表示される concepts.py に手で加えた語が、知識空間に反映されていません。python build_knowledge_space_openalex.py を実行し直してください NOTE: OPENALEX_API_KEY is not set. と表示される APIキーが設定されていません。準備2を参照して設定してください（このままでも動きますが、無料枠が尽きることがあります） WARNING: the knowledge space was not built with the current vocabulary と表示される 語彙（concepts.py）を変えたのに、知識空間を作り直していません（手順3の抜け）。このまま進むと、別の分野の論文と比べることになり、新規性が見かけ上高くなったり、無関係な論文が出典になったりします。python build_knowledge_space_openalex.py を実行してから、やり直してください（v1.0.4 以降で表示されます） the daily request budget is used up と表示されて止まる OpenAlex の無料枠が尽きています。APIキーを設定するか、日本時間の午前9時以降にやり直す can't open file '...\make_concepts.py' などと表示される code フォルダにいません。cd で code フォルダに移動してから実行する make_concepts.py などのファイルがない v1.0.1 以前の版です。v1.0.2 以降を取得し直す Could not reach llama.cpp server 手順5の llama-server が起動しているか、ポート番号（8080）が LLAMA_SERVER_ENDPOINT と合っているかを確認する 下書きが途中で終わる（末尾に INCOMPLETE と出る） $env:LLM_MAX_TOKENS = "8000" のように上限を増やして、もう一度実行する 下書きが要旨（Abstract）だけで終わる 8B程度の小さいモデルでは、全体を一度に頼むと途中で終わることがあります（論文でも報告した現象です）。より大きなモデルを使うか、上限を増やして試す llama-server がGPUを使わない／DLLのエラーが出る CUDA版の2つのZIPの中身を、同じフォルダの直下に展開したか確認する 初回の実行が遅い 埋め込みモデルのダウンロードと、全仮説・全論文の埋め込みの計算のため。2回目以降は data/cache/ を使うので速くなります まとめ 分野の番号を指定するだけで、make_concepts.py がその分野の語彙（手法・課題・目標）を自動で作る build_knowledge_space_openalex.py でその分野の論文を集め、top_hypotheses.py で研究仮説の候補を作る 気に入った仮説は、creative_ai_agent_local_llm.py でローカルLLMが研究計画の下書きに膨らませる 振り分けのルールは経営・情報系に合わせてあるので、分野によっては手がかり語・例の単語の書き換えや、語彙の手直しが必要 出てきた仮説の価値は自動では保証されないので、最後は人が判断する コード・データ・プロンプト・ログはすべて公開しています。個別のサポートはできかねますが、不具合の報告や改善案は GitHub の Issue で受け付けています（対応をお約束するものではありません）。 引用のお願い このAIエージェントで生成した仮説や研究計画の下書きをもとに研究成果を公表する場合は、次の論文を引用してください。 Otsuki A. Comparing Genetic Algorithms and LLMs for Research-Hypothesis Generation: Mainstream Convergence of LLMs, Wider Hypothesis Exploration by Combinatorial Search, and the Limits of Literature-Distance Novelty Metrics. Informatics. 2026; 13(10):174. doi.org @article{Otsuki2026, author = {Otsuki, Akira}, title = {Comparing Genetic Algorithms and {LLMs} for Research-Hypothesis Generation: Mainstream Convergence of {LLMs}, Wider Hypothesis Exploration by Combinatorial Search, and the Limits of Literature-Distance Novelty Metrics}, journal = {Informatics}, year = {2026}, volume = {13}, number = {10}, pages = {174}, doi = {10.3390/informatics13100174} } 使ったコードの版を示したい場合は、あわせて Zenodo の DOI（「準備1：環境構築」の表を参照）も記載してください。 参考 論文の紹介動画（YouTube）：youtube.com 論文：Otsuki A. Comparing Genetic Algorithms and LLMs for Research-Hypothesis Generation: Mainstream Convergence of LLMs, Wider Hypothesis Exploration by Combinatorial Search, and the Limits of Literature-Distance Novelty Metrics. Informatics. 2026; 13(10):174. doi.org コード：otsukiLabo-NUCOE/creative-ai-hypothesis-generation この記事の英語版（English version）：github.com/otsukiLabo-NUCOE/creative-ai-hypothesi… アーカイブ（v1.0.5、この記事の手順に対応）：doi.org アーカイブ（v1.0.4）：doi.org アーカイブ（v1.0.3）：doi.org アーカイブ（v1.0.2）：doi.org アーカイブ（v1.0.1、論文で引用している版）：doi.org llama.cpp：ggml-org/llama.cpp 埋め込みモデル：sentence-transformers/all-MiniLM-L6-v2

Clover-35B-A3B-Preview試用記：気になったのはGPUなしでの使い道 はじめに Clover-35B-A3B-PreviewのQ4_K_Mを RTX 3060（VRAM 12GB）搭載のPCで試しました。GPUに一部の層を載せた場合の生成速度は約 7 tok/s、GPUへのオフロードを無効にした場合は約 4 tok/sでした。 要約や簡単なゲームの生成も試しましたが、GPUを使える今の環境では、速度と品質のバランスから積極的に切り替えたいと思うほどの結果にはなりませんでした。 一方、GPUを使わずに出力品質を保ったまま、約 4 tok/sで生成できている点には、別の用途を考える余地を感じました。 この記事では、GPUあり・なしの実行結果と所感、今回使った環境での導入手順をまとめています。 ! 条件をそろえたベンチマークではありません。速度とRAMの数値は参考値で、品質の評価も少数のタスクを試した筆者の所感です。また、今回はGPU搭載PCでGPUへのオフロードを無効にした検証のため、GPU非搭載PCでの動作の実用性まで確認したものではありません。 GPUあり・なしの実行結果 両方とも同じPCとQ4_K_Mのモデルを使用しました。 項目 GPUを使う設定 GPUへのオフロードを無効にした設定 GPUに載せる層数 22（-ngl 22） 0（-ngl 0） KVキャッシュ オフロードを無効にする指定なし --no-kv-offload を指定 Flash Attention --flash-attn on を指定 明示指定なし 生成速度 約7 tok/s 約 4 tok/s RAM使用量の増加分 約24GB 約27GB 検証環境と共通設定 項目 設定・環境 CPU Ryzen 7 3700X GPU RTX 3060（VRAM 12GB） メモリ 64GB OS Windows 11／WSL上のUbuntu 26.04 WSLのメモリ上限 48GB モデル Clover-35B-A3B-Preview 量子化 Q4_K_M（ファイルサイズ約21GiB） コンテキスト長 32,000 CPUスレッド数 8 同時処理数 1 使ってみた感想 ここからは、簡単な質問、要約、HTMLゲームの生成を試した感想です。出力品質については、GPUあり・なしで違いはないような気がします。 簡単な質問：悪くない まずは、どの時期の情報を答えるかや、文字化けがないかを見るため、簡単な質問をしました。 初回の応答については、始まるまでに長い待ち時間が発生します。 要約：品質は良いが、構成や書式が安定しない 以前、google/gemma-4-26b-a4b-qat を使い、G検定の教本内容を学習用に要約したことがありました。今回は、そのときの出力と比較しました。 要約の品質には、見た範囲では大きな差は感じませんでした。しかし、生成するたびに構成や書式が大きく変わる点が気になりました。書式を指定するプロンプトや生成設定を詰める余地がありそうです。 temperatureなどの生成設定に影響している可能性はありますが、設定値の確認や条件をそろえた比較は今回していません。 HTMLゲーム：動くものの、遊びの工夫は物足りない ローカルで動くHTML形式のインベーダーゲームを作らせてみました。 生成されたゲームは動きましたが、遊んで面白くするための工夫は物足りないと感じました。このタスクでは、以前の gemma-4-26b-a4b-qat の出力のほうが好みでした。 今回使った環境での導入手順 以下は、RTX 3060搭載PCのWSL上で、CUDA対応のllama.cppを用意する手順です。GPUを使わない設定も、このビルドで試しています。今回はGPU非搭載PC向けのビルド手順ではありません。 今回の検証では、llama.cppのClover対応PR #31306 のコードを取得する必要があります。(2026.11.1時点) 1. ビルド環境を用意する UbuntuからGPUを利用できることと、CUDA Toolkitが導入されていることが必要です。 未導入であれば、以前に書いた次の記事の第1章から第2章を参照してください。 zenn.dev また、ビルド用のツールが未導入であれば、追加で次のようにします。 sudo apt update sudo apt install -y build-essential cmake ninja-build git python3-venv python3-pip 今回の検証時のビルドツールの各バージョンは次のとおりでした。 ツール 検証時のバージョン CUDA Toolkit 13.3（nvcc V13.3.73） Ninja 1.13.2 GCC／G++ 15.2.0 2. 作業ディレクトリとソースコードを用意する 作業ディレクトリは任意の場所に変更してください。 mkdir -p ~/workspace/Clover-35B-A3B-Preview cd ~/workspace/Clover-35B-A3B-Preview git clone ggml-org/llama.cpp llama.cpp-clover cd llama.cpp-clover git fetch origin pull/31306/head git switch -c clover-pr-31306 FETCH_HEAD 3. CUDAを有効にしてビルドする 以下は、command -v nvcc の出力が /usr/local/cuda/bin/nvcc だった場合の例です。異なるパスが出た場合は、CMAKE_CUDA_COMPILER を置き換えてください。 cmake -S . -B build-clover-cuda -G Ninja \ -DCMAKE_BUILD_TYPE=Release \ -DGGML_CUDA=ON \ -DCMAKE_CUDA_COMPILER=/usr/local/cuda/bin/nvcc \ -DCMAKE_CUDA_ARCHITECTURES=86 \ -DLLAMA_CURL=OFF \ -DLLAMA_BUILD_TESTS=OFF \ -DLLAMA_BUILD_SERVER=ON \ -DLLAMA_BUILD_EXAMPLES=ON cmake --build build-clover-cuda \ --target llama-server llama-cli \ -j 8 ビルドできたら、バージョンを確認します。 ./build-clover-cuda/bin/llama-server --version version: 0.7.0-dev (build 11955, commit cb09d4355) built with GNU 15.2.0 for Linux x86_64 4. モデルをダウンロードする 作業ディレクトリに戻り、Python仮想環境とダウンロード用のCLIを用意します。 cd ~/workspace/Clover-35B-A3B-Preview python3 -m venv .venv source .venv/bin/activate python -m pip install -U huggingface_hub 使用した配布先は Diffuspace/Clover-35B-A3B-Preview-GGUF です。今回はQ4_K_Mをダウンロードしました。 hf download Diffuspace/Clover-35B-A3B-Preview-GGUF \ Clover-35B-A3B-Preview-Q4_K_M.gguf \ --local-dir models 5-A. GPUを使う設定で起動する場合 引き続き ~/workspace/Clover-35B-A3B-Preview で実行します。 ./llama.cpp-clover/build-clover-cuda/bin/llama-server \ -m models/Clover-35B-A3B-Preview-Q4_K_M.gguf \ -c 32000 \ -ngl 22 \ -t 8 \ -np 1 \ --flash-attn on \ --host 127.0.0.1 \ --port 8080 主なパラメーターは次のとおりです。 パラメーター 今回の設定 -c 32000 コンテキスト長を32,000に設定 -ngl 22 GPUに22層を載せる -t 8 CPUスレッド数を8に設定 -np 1 同時処理数を1に設定 --flash-attn on Flash Attentionを有効化 5-B. GPUへのオフロードを無効にして起動する場合 ./llama.cpp-clover/build-clover-cuda/bin/llama-server \ -m models/Clover-35B-A3B-Preview-Q4_K_M.gguf \ -c 32000 \ -ngl 0 \ --no-kv-offload \ -t 8 \ -np 1 \ --host 127.0.0.1 \ --port 8080 -ngl 0 でモデルのGPUオフロードを無効にし、--no-kv-offload でKVキャッシュもCPU側に置きます。KVキャッシュ自体を無効にする設定ではありません。この構成で、約 4 tok/sの生成を確認しました。 6. ブラウザから試す どちらの設定でも、Windows側のブラウザで次のURLを開きます。 localhost プロンプトを送ったら、Windowsのタスクマネージャーなどで使用状況を確認します。GPUの状態は、別のWSLターミナルでも確認できます。 watch -n 1 nvidia-smi GPUなしのRAGをもう一度試したい GPUを使える今回の環境では、速度と出力品質の両面から、普段の用途で切り替える決め手は得られませんでした。 一方、GPUへのオフロードを無効にしても約 4 tok/sで生成できたことから、GPUを積んでいないPCでRAGを使う可能性を改めて検討したくなりました。 実は、優先順位は非常に低いもののGPUなしのRAGを実装するという仕事上のタスクがあります。この条件での仕事は約1年ぶりになりますが、試してみたいと思います。結果はまたレポートできればと思います。

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