第1回「EVO-X2（Ryzen AI Max+ 395 / 128GB）でQwen3.8-Flash-Nextを動かした話」
第2回「EVO-X2（Ryzen AI Max+ 395 / 128GB）でQwen3.8-Flash-Nextを高速化した話」
第3回「EVO-X2（Ryzen AI Max+ 395 / 128GB）でQwen3.8-Flash-Nextの高速化の続き」
第4回「EVO-X2（Ryzen AI Max+ 395 / 128GB）でllama.cppをアップデートしただけで、Qwen3.8-Flash-Nextがprefill/decodeともに速くなった話」
の続き。
前回までEVO-X2でQwen3.8-Flash-Nextを動くようにして、高速化して、とやってきたけれど、本当にやりたかったことはここから。
私のローカルLLMの用途の中で、一番大事なのは長文要約＆読解支援で、今この用途でメインに使っているGemma 4 31B(QAT)は、出力は気に入っているのだけど、とても遅い。Qwen3.8-Flash-Nextは代替候補になるのか、というのが今回の確認ポイント。
ちなみに、ローカルLLMを長文読解に使いたいのは危ない用途ではなく、個人情報とか企業秘密とか、そっち方面の問題。
結論
今回はQwen3.8-Flash-Next、Gemma 4 31B、Gemma 4 26B A4B、Qwen3.8 27Bの4つのモデルを比較したが、どのモデルも日本語読解能力に致命的な問題はなく、とんでもない間違いをする、日本語出力が崩壊するということもなかった。
好き嫌いだけだと評価にならないので、事前に質問票と採点基準を作って採点してみたが、点数の高さと感覚的な良さは一致しなかった。これはたぶん採点基準が悪いのではなく、4つのモデルともある程度の品質基準は満たしていて、あとは用途と好みの問題ということなのだろう。
Qwen3.8-Flash-NextがGemma 4 31Bの代替候補になるかという点では、今のところはYES。Qwen3.8-Flash-Nextの速度に慣れてGemma 4 31Bの遅さに耐えられなくなるか、それともQwen3.8-Flash-Nextの出力にやっぱり満足できなくてGemma 4 31Bに戻るかは、しばらく使ってみないと分からない。
まずは軽くチャットしてみた
まずはllama-serverを起動して、他のマシンのブラウザで http://(evo-x2のIPアドレス):(llama-server起動時に指定したポート番号) をアドレス欄に入力して、llama.cppのWeb UIにアクセスしてチャットしてみた。llama.cppのWeb UIも色々設定ができそうだが、何も触らずデフォルト設定のままにした。
最初に「こんにちは。簡単に自己紹介してください」と話しかけたら、中国語で返事が返ってきてちょっとビックリしたが、「日本語で回答をお願いします」と言ったら、その後はちゃんと日本語で対応してくれた。
|
あいさつの後、約1.5万文字（14,875文字）の日本語文章をアップロードして、要約してください→高校生にも分かるように簡単に説明してください、という依頼にもちゃんと答えてくれた。
最初の長文入力では8,181トークンを新規に処理したが、次のターンでは9,229トークン中9,202トークンがキャッシュされ、新規に処理したのは27トークンだけだった。
基本的な日本語能力に問題はなさそうだし、複数ターンのキャッシュもかなり効いていそうなので、もう少し詳しく確認してみることにする。
長文品質評価の設計
テスト用の文書は、第２回にも使った言語処理学会論文誌LaTeXコーパス内の論文
乾孝司・奥村学「テキストを対象とした評価情報の分析に関する研究動向」（『自然言語処理』Vol.13, No.3, 2006年、pp.201–241）
から、1～7章の本文を使用。要旨・キーワード・謝辞・参考文献は除外。配布 .tex が外部参照している表・図は、コーパスデータ内にデータがないため省略注記を入れた。
トークン数は、llama-tokenize.exe + Qwen3.8-Flash-Next で測って19,464、文字数は35,515文字（UTF-8で91,974 bytes）。参考までにGemma 4 31Bのtokenizerでは19,605トークンだったので、今回の4モデル比較ではだいたい2万トークン弱の入力になる。
テスト文書をアップロードして要約してもらって、チャットでただ質問を繰り返しても感覚的な評価しかできないので、数値的な品質評価をするための質問リストと採点基準を作った。
といっても、私は普段からプロンプトきっちり作り込んで自動処理させるのは苦手で、その場のノリで適当にチャットしながら色々進めるタイプなので、最初から基準を作るのも苦手で、チャッピー様に手伝ってもらった。
質問リスト＆採点基準の概要。具体的な質問と採点基準は付録に載せた。
| # | 目的 | 主に見る場所 | 配点 |
|---|---|---|---|
| Q1 | 全文の把握・要約 | 全体 | 20 |
| Q2 | 類似概念の正確な比較 | 3.1節 | 15 |
| Q3 | 文脈依存性を理解できるか | 3.1節 / 3.4節 | 15 |
| Q4 | 後半の情報を正確に拾えるか | 6.1節 | 15 |
| Q5 | 章をまたいだ統合 | 2節 / 6.3節 / 6.5節 | 20 |
| 共通評価 | 指示遵守・根拠外生成・読みやすさ | 全回答 | 15 |
| 合計 | 100 |
llama.cppのWeb UIで、「新チャット」を開いて、「テスト文書を添付」してQ1を質問、次はまた「新チャット」を開いて、「テスト文書を添付」してQ2を質問、というように、質問ごとに新チャットに切り替えて、毎回ファイル添付した。
メインの5問は文章中に書いてあることを正しく答えられるか、というもので、それに加えて、採点対象外の番外編(X1)として書いてないことを捏造しないかという問題を追加。
表3「テキスト評価分析を支える要素技術の概観」について、表に記載されている各列と各行の内容を具体的に説明してください。
文書内に表の内容が含まれていない場合は、その旨を回答してください。
正解は、「表3の本体は文書に含まれていないので、表そのものの列・セル内容は説明できない」。
この他に、テスト中にファイル添付をうっかり忘れて質問してしまったケースがあり、その結果が興味深かったので全モデルに同じテストをした。
テスト条件
今回のテストに使った起動コマンドは以下の通り。パラメータは前回のllama-cliのテストパラメータに合わせた。
入力文章の要約＆読解支援が目的で、創造力はあまり必要ないため、temp(temperature)は低めに設定している。
全モデルでllama.cppは前回使ったunslothのb10798-mix-659e406 Windows ROCm版、MTPありで統一した。
.\llama-server.exe `
-m (モデルのパス) `
-md (MTPドラフトモデルのパス、Qwen3.8 27Bのみ不要) `
--spec-type draft-mtp `
--spec-draft-n-max 2 `
--spec-draft-p-min 0 `
-c 131072 `
-ngl 999 `
-n 1024 `
-ncmoe 0 `
-t 4 `
-tb 4 `
-b 2048 `
-ub 1024 `
-fa auto `
-ctk f16 `
-ctv f16 `
--temp 0.2 `
--top-k 20 `
--top-p 0.8 `
--min-p 0.05 `
--reasoning off `
--jinja `
--parallel 1 `
--host 0.0.0.0 `
--port 8080 `
--sleep-idle-seconds -1 `
-fit off `
--load-mode auto `
--cache-ram 8192 `
--cache-prompt `
-lv 4 `
--log-prompts-dir "C:\llama\logs\prompts"
長文品質評価の結果
まずは数値的な採点結果と、llama-serverのログから取った速度値のまとめ。
これだけ見るとGemma 4 26B A4Bが最高得点で最速で最高のモデルに見えるのだけど、テスト中に実際にチャットした感覚だとそうでもない。
どのモデルも初回のファイル添付時は時間がかかったが、Q2以降はキャッシュが効いて質問をしてから応答が返ってくるまでの時間はかなり短くなった。
| Model | Q1(20) | Q2(15) | Q3(15) | Q4(15) | Q5(20) | 共通(15) | 合計(100) | Q1 PP | Q1 TG | Q1合計時間 |
|---|---|---|---|---|---|---|---|---|---|---|
| Qwen3.8-Flash-Next UD-IQ3_XXS | 19 | 15 | 13 | 15 | 20 | 12 | 94 | 317.23 tok/s | 31.14 tok/s | 77.4秒 |
| Gemma 4 31B IT QAT | 20/20 | 15 | 13 | 15 | 20 | 14 | 97 | 234.53 tok/s | 18.15 tok/s | 120.0秒 |
| Gemma 4 26B A4B QAT | 20 | 15 | 13 | 15 | 20 | 15 | 98 | 1040.90 tok/s | 67.00 tok/s | 27.3秒 |
| Qwen3.8 27B UD-Q5_K_XL | 18 | 15 | 15 | 15 | 20 | 13 | 96 | 291.29 tok/s | 15.46 tok/s | 83.3秒 |
※PP/TGはQ1を最初に実行したときのllama-serverログから計算した値。出力トークン数がモデルごとに違うため、Q1合計時間は厳密な速度ベンチマークではなく、実際にこの質問をしたときの待ち時間の参考値。
点数だけ見ると98点のGemma 4 26B A4Bがトップで、Flash-Nextは94点で一番低い。ただし点差の大半は「内容を読めていない」ことによるものではなく、字数指定の差と、Q3で「例を２つ以上」の指示に対する採点基準で特定の例を必須としていたことによるもの。
※途中で採点基準が適切でないかもしれないと思ったが、途中で基準を変えると訳が分からなくなるので今回はこのまま進めた。
各モデルの主な減点理由は以下。
| Model | 主な減点ポイント |
|---|---|
| Qwen3.8-Flash-Next | Q1が約790字で「1000字程度」より短い。Q3は質問自体は「具体例を2つ以上」なので十分回答できているが、特定の例に2点を割り当てていたため13/15。Q1で第6章の課題を「六点」と書きながら5項目しか列挙していない点、Q5の一部が本文よりやや強い断定になっている点、Q5の800字制限超過で共通点を減点。 |
| Gemma 4 31B | Q3の2点減点はFlash-Nextと同じ理由。Q5が800字以内をやや超えた以外はほぼ満点。 |
| Gemma 4 26B A4B | Q3の2点減点はFlash-Nextと同じ理由。指定された要素の抽出出力と字数遵守は今回もっとも安定していた。 |
| Qwen3.8 27B | Q1が約425字で、1000字程度の指定に対してかなり短い。字数制限のある回答では情報を詰め込みすぎて読みづらい傾向があり、共通の読みやすさでも減点。Q3だけは追加例まで含めて15/15。 |
一方、各モデルとチャットしたときの私の感想はこんな感じ。
- 最初にチャットしたQwen3.8-Flash-Next
「分かりやすい文章だし、予想より良いかも？」 - 次にチャットしたGemma 4 31B
「読んでて安心感がある。さっきのqwenより分かりやすい気がするけど出力に慣れてるだけかも？」 - 次にチャットしたGemma 4 26B A4B
「何がダメというわけではないのだけど、何か説明が足りてない感がある」 - 次にチャットしたQwen3.8 27B
「Q3だけ今までで一番わかりやすいけど、他の質問の出力はイマイチ、プロンプトで文字数を指定したらダメになる？」
今回は速度を測るテストではないが、全体的な速度感(私の主観)は
Gemma 4 26B A4B > Qwen3.8-Flash-Next > Qwen3.8 27B ≒ Gemma 4 31B という感じ。
(Qwen3.8 27BとGemma 4 31BはPPとTGで速度が逆転する)
生成中の文字の流れを撮った動画をGIF化してみた。27Bは動画を取り忘れたため3モデルのみ
各モデルの回答例
回答全文を4モデル×3問分貼るとかなり長くなるので、ここでは差が見えやすかった部分だけを抜粋する。
抜粋ルールは、Q1は各モデルの回答冒頭、Q3はFlash-NextとQwen3.8 27Bの文脈依存性の説明部分、Q5は回答末尾のまとめ部分。表現は読みやすく直したりせず、生出力のまま載せる。
Q1：1000字程度の全文要約
Q1は4モデルとも指定した6項目そのものはほぼ拾えていたが、文章量にかなり差が出た。
| Model | 回答文字数の目安 | 印象 |
|---|---|---|
| Gemma 4 31B | 約1,100字 | 指定字数に近く、各項目を少し膨らませて説明する。読み慣れていることを差し引いても説明文として読みやすい。 |
| Gemma 4 26B A4B | 約986字 | 指定字数をかなり素直に守り、必要事項を効率よく全部入れる。 |
| Qwen3.8-Flash-Next | 約790字 | 少し短いが、必要項目の取りこぼしはほぼない。 |
| Qwen3.8 27B | 425字 | 6項目は入っているが、1000字指定に対してかなり圧縮される。 |
Qwen3.8-Flash-Next
以下に、提示された解説論文の要約をまとめます。
本稿は、テキストから個人の評価情報を発見・抽出・整理する「テキスト評価分析」に関する研究を概説するものである。本分析が扱う主な問題は、テキスト断片における評価が肯定的か否定的かを推定することであり、語句・文・文書という粒度で定式化される。
対象となるテキストデータは、レビューやアンケートなど「意見の収集・集約が目的となっているテキスト」と、チャットや掲示板、Weblogなど「潜在的に意見を含むテキスト」に大別される。前者は質が高く話題が限定されるが、後者は意見の割合が小さく、言語処理の精度が低下しやすいという性質を持つ。
Flash-Nextは冒頭から必要事項を順に拾っていて、読みづらさはあまり感じなかった。ただし上記抜粋部分の範囲外だが「第6章では、今後の課題として六点」と書いた直後に5項目しか列挙していない。内容を大きく読み違えたわけではないが、こういう小さな不整合はあった。
Gemma 4 31B
本論文は、テキストから個人の評価情報を発見・抽出・集約する「テキスト評価分析」に関する研究動向を概説したものです。
1. テキスト評価分析が扱う問題
主に、ある対象に対する評価を記述したテキスト断片が、「肯定的な評価」か「否定的な評価」であるかを推定する問題を扱います。この問題は、語句・文・文書という3つの粒度で定式化されます。2. 対象となるテキストデータの種類
評価文書は大きく2つに分類されます。一つは自由回答アンケートやレビューサイトのように「意見の収集・集約が目的」のテキストで、意見の割合が高く質も比較的良好です。もう一つはチャットやWeb掲示板、Weblogなどの「潜在的に意見を含むテキスト」で、意見の割合が低く、言語処理の精度を低下させる質の低い記述が含まれる傾向にあります。
31Bは質問で指定した6項目をそのまま見出しにして、各項目を順に説明する形になった。上記抜粋部分の範囲外では unpredictable の自動車／映画の例や not による極性反転まで挙げていて、4モデルの中では一番「説明文を読んでいる」感じが強かった。
Gemma 4 26B A4B
本論文は、インターネット上の膨大なテキスト情報から個人の評価情報を抽出し、整理・集約する「テキスト評価分析」に関する研究の現状と展望を概説したものである。
まず、テキスト評価分析が扱う問題は、テキスト中から「評価を記述するもの」を対象とし、その評価が肯定的か否定的かを推定する「評価極性」の判定である。この問題は、語句、文、文書といった粒度ごとに定式化され、肯定・否定の2値分類として扱われることが多い。
対象となるテキストデータは、大きく2つに分類される。一つは、アンケートやレビューサイト、カスタマーサポートの「お客様の声」のように、意見の収集・集約を目的として収集された、比較的良質なテキストである。もう一つは、チャット、Web掲示板、Weblogのように、潜在的に意見を含むテキストであり、後者はテキストの質が低かったり、雑多な内容が含まれていたりする特徴がある。
26B A4Bも必要事項はきちんと拾えている。しかも指定字数への収まりは今回もっとも良かった。間違っているわけではないけど、31Bほど具体例を広げず、必要なことを回答したら先へ進む感じがある。文体が元の論文調を踏襲しているせいか、ちょっと読みづらい感じがある。
Qwen3.8 27B
27Bは回答自体がかなり短いので、ここだけ全文を載せる。
テキスト評価分析は、テキスト中の評価表現から、その評価が肯定極性（良い）か否定極性（悪い）かを推定する問題を扱う。対象データは、レビューやアンケートなど意見収集が目的のテキストと、チャットやWeblogなど潜在的に意見を含むテキストの2種類がある。第3章では、評価表現辞書の構築、評価文書分類、評価文抽出、評価情報の要素組抽出という4つの要素技術が整理されている。評価表現辞書は文脈とは独立した静的な知識であるが、実際の評価極性は文脈に依存して変化するため、要素組抽出では文脈情報を考慮した動的な極性判定が重要となる。評価分析システムは、企業やサイト運営者がマーケティングに活用したり、一般利用者が購入などの意志決定の参考にしたりする目的で利用される。今後の課題としては、「中立」クラスの曖昧さの解消、評価の分類軸の細分化、明示的に表されない評価の処理、Webテキストに対応した基礎言語解析技術の開発、および評価文書の収集方法の確立が挙げられている。
内容だけを見れば悪くない。しかし「1000字程度」に対してこの長さなので、要約というより圧縮された答案に近い。短いこと自体が悪いわけではないけれど、文体が論文調なのもあり、ちょっと読みづらい感じがある。
Q3：文字数制限なしの文脈依存性の説明
Q3は文字数制限を付けなかった。ここではFlash-NextとQwen3.8 27Bの差が面白かったので、この2モデルを抜粋する。
Qwen3.8-Flash-Next
第3.1節（評価表現辞書の構築）:
実際の文脈情報とは独立な、単語単体の評価極性に焦点を当てています。「良い−肯定」のように、単独で評価極性が特定できる静的な知識を扱います。第3.4節（評価情報の要素組の抽出）:
実際の文脈情報を含めた評価極性に焦点を当てています。評価表現だけでなく、評価対象や評価者などの要素を合わせて特定し、文脈によって変化する動的な評価極性を扱います。例文(c)： このベッドは眠気をさそう。
例文(d)： この講義は眠気をさそう。「眠気をさそう」という表現自体に固定的な評価極性はありませんが、文脈である評価対象を考慮することで極性が決定されます。対象が「ベッド」であれば「よく眠れる」という肯定極性となりますが、対象が「講義」であれば「眠くなるのは困る」という否定極性となります。
Qwen3.8 Flash-Nextは質問で要求した2つの例を使い、3.1節と3.4節の違いから具体例へ順に説明した。必要十分で、文章の流れも分かりやすい。
Qwen3.8 27B
つまり、3.1節は「単語自体が持つ基本的な極性」を扱うのに対し、3.4節は「その単語がどのような文脈（対象や関係）で使われているか」によって極性がどう変わるかを扱うという違いがあります。
具体例1: 評価対象によって極性が逆転する場合
- (c) このベッドは眠気をさそう。
- (d) この講義は眠気をさそう。
両文とも「眠気をさそう」という同じ評価表現を含んでいます。しかし、評価対象が「ベッド」の場合は肯定極性（良いこと）であるのに対し、「講義」の場合は否定極性（悪いこと）となります。
補足: 評価者の視点によって極性が異なる場合（3.4.1節）
- りんご１箱あたりの値段が上がった。
同じ表現でも、りんごの消費者にとっては否定極性（値上がりは好ましくない）ですが、生産者にとっては肯定極性（値上がりは好ましい）となる可能性があります。
Qwen3.8 27BはQ1とは別のモデルのように丁寧になった。上記抜粋範囲外の出力を含めると「ベッド／講義」「美味しかった？」に加えて、消費者と生産者で評価が変わる例まで自発的に追加しており、Q3ではQwen3.8 27Bだけ15/15だった。文字数制限がある質問で文章を圧縮しすぎる癖があるのかもしれない、という印象を持ったのはこの差から。
Q5：前半と後半をまたぐ統合問題
Q5は4モデルとも20/20だった。ここでは「必要事項を拾った後、どこまで関係を説明するか」が見えやすかったので、Gemma 4 31B、Gemma 4 26B A4B、Flash-Nextの回答末尾を比較する。
Gemma 4 31B
まず、第6.5節の「評価文書の収集」についてです。前者のように最初から意見が集約された形式ではないため、膨大なWeb上のテキストから、特定の評価対象に関する評価情報が含まれている文書をいかに効率的に獲得・収集するかという手法の確立が不可欠な課題となります。
次に、第6.3節の「明示的に表されない評価」についてです。後者のテキストは記述が断片的であったり、事実の記述形式をとっていたりすることが多く、評価表現辞書にあるような「良い」「悪い」といった明示的な語句に頼るだけでは評価を抽出できません。例えば「電源が入らなくなった」という事実記述から否定的な評価を読み取るような、明示的でない評価を判定する技術の開発が、分析の網羅性を高める上で重要な課題となります。
総じて、潜在的に意見を含むテキストを扱うには、収集段階でのフィルタリングと、抽出段階での文脈や事実からの意味推論という、より高度なアプローチが求められます。
31Bは6.5節と6.3節をそれぞれ説明したあと、最後に「収集段階」と「抽出段階」の2つの問題としてまとめ直している。こういう一段上の整理が自然に入るところが、普段使っていて読みやすいと感じる理由の一つかもしれない。
Gemma 4 26B A4B
「明示的に表されない評価」に関する課題
現在の評価分析技術の多くは、辞書に登録された「美味しい」のような明示的な評価表現に依存しています。しかし、潜在的に意見を含むテキスト（掲示板やWeblogなど）では、評価が明示的な言葉ではなく、「買ってすぐに電源が入らなくなった」といった事実の記述として現れる（evaluative factual）ことがあり、こうした明示的でない評価をいかに捉えるかが技術的な課題となります。「評価文書の収集」に関する課題
既存の研究の多くは、特定の対象に関する評価情報が既に集まった「評価文書」を前提としています。しかし、掲示板やWeblogのような「潜在的に意見を含むテキスト」を対象とする場合、膨大な情報の中から、特定の評価対象に関する記述をどのように効率的に獲得・収集するかという、収集方法の確立自体が大きな課題となります。
26B A4Bは、質問された内容にはきちんと答えていて採点上は満点。ただ、6.3節と6.5節をそれぞれ説明したところで回答が終わっており、31Bのように最後に両者の関係をもう一段まとめ直す文章はない。私が以前から感じていた「何か説明が一歩足りない」は、こういうところかもしれない。
Qwen3.8-Flash-Next
両課題は相互に関連する。潜在的テキストから評価文書を収集する際、明示的な評価表現に依存した抽出手法を用いると、6.3節で指摘された「明示されない評価」を含む文書を取りこぼし、収集自体が不十分になる。逆に、収集を網羅的に行うには、明示されない評価を認識する高度な解析技術が前提となる。さらに、潜在的テキストの質の低さ（6.4節の基礎言語解析の課題）が重なり、収集・抽出の双方で頑健性が求められる。したがって、潜在的テキストを本格的に扱うには、明示されない評価を捉える抽出技術の開発と、それと連動した評価文書収集手法の確立を一体的に進める必要がある。
Flash-Nextはむしろかなり積極的につなげて説明した。31Bと同じく「項目を拾って終わり」ではないのは好印象。一方で、このQ5では上記抜粋の範囲外に「現状の技術は抽出できず」「致命的な低下を招く」など本文より強い断定もあり、共通評価ではそこを減点した。説明を広げることと、根拠の範囲を越えないことのバランスは別問題らしい。
こうして生出力を並べると、今回の採点が「必要な情報を長文から正しく拾えるか」を比べるには役に立った一方で、「説明の分かりやすさ」「読み手に合わせた余白」「このモデルと普段チャットしたいか」までは点数だけでは表せていないことが分かる。
文章中に書いていない内容について聞いたらどうなる？
文章に書いてないことを質問した場合と、うっかりファイル添付を忘れた場合の結果はこんな感じ。
| Model | 表3の内容を聞くX1（「文書にない場合はそう答える」と明示） | ファイル添付を忘れてQ4を質問 | 印象 |
|---|---|---|---|
| Qwen3.8-Flash-Next | 捏造せず、表本体がないと回答 | 資料がないことを指摘したあと、一般的な「中立」の議論を補足 | 最初に止まろうとはするが、その後の余計な一般論は不要 |
| Gemma 4 31B | 捏造せず、表本体がないと回答 | 資料不足を指摘せず、「形式的な中立／認識論的な中立／規範的な中立」など今回の論文とは別の説明をかなり自然に生成 | 今回いちばん怖かった。文章が読みやすいぶん、そのまま信じてしまいそう |
| Gemma 4 26B A4B | 捏造せず、表本体がないと回答 | 資料がないことを指摘したあと、一般論として別の3分類を説明 | 「資料がない」と言える点は良いが、結局何か答えようとする |
| Qwen3.8 27B | 捏造せず、表本体がないと回答 | 資料がないことを指摘したあと、「価値的中立／立場的中立／無関心中立」などの一般論を生成 | 不足には気づくが、やはり親切心で穴埋めしてしまう |
X1は全モデルとも正解だった。文書中に「表本体は省略」と明記され、さらに質問側でも「文書内に含まれていない場合はその旨を回答」と書いておけば、今回の4モデルは勝手に表を復元しなかった。
一方、ファイル添付忘れでは挙動が変わる。3モデルは少なくとも「資料がない」ことには気づいたが、その後に一般知識で答えを補おうとした。Gemma 4 31Bだけは、ファイル添付忘れを指摘してくれないだけでなく、捏造結果も一番読みやすくて一番もっともらしい。
Gemma 4 31Bは普段使っているモデルなので、気づいていないだけで今まで何かやらかしていないか心配になってきた。
つまり「文書にないことを捏造してはいけない」という指示への追従と、「そもそもユーザーが資料を渡し忘れている」と気づけるかは別問題らしい。
結局、Qwen3.8-Flash-NextはGemma 4 31Bの代わりになる？
以前に、Gemma 4 26B A4BとQwen3.8 27BはGemma 4 31Bの置き換え候補として検討して却下したことがある。
その時の印象が、Gemma 4 26B A4Bは「間違ってはいないけど、説明が足りていない感がある」、Qwen3.8 27Bは「プロンプトのちょっとした違いで出力の振れが大きい」というもので、その印象は今回のテストでも変わらなかった。
今回試したQwen3.8-Flash-Nextは、Gemma 4 31Bと比べてものすごく良いわけではなけれど、速度はGemma 4 31Bより速いし、出力も安定していてGemma 4 26B A4Bほどの物足りなさもない。全方面にバランスがいい感じ。
そして、今回Gemma 4 31Bの捏造の怖さが発覚したので、モデルを変えたい気持ちがちょっと強くなっている。
| Model | 得点 | 速度感 | 出力の印象 | 添付忘れ時 | Gemma 4 31Bの代替として |
|---|---|---|---|---|---|
| Gemma 4 31B | 97 | 遅い | 説明が分かりやすく、今回もっとも読みやすい印象 | 資料なしに気づかず、それらしい誤答 | 基準 |
| Gemma 4 26B A4B | 98 | 圧倒的に速い | 必要事項は非常によく拾うが、説明が少し物足りない | 資料不足は指摘するが一般論を追加 | 今回も置き換えるほどではない |
| Qwen3.8 27B | 96 | 31Bと同程度〜少し速い | 内容理解は良いが、字数指定時の文章に癖が強い | 資料不足は指摘するが一般論を追加 | 今回も置き換えるほどではない |
| Qwen3.8-Flash-Next | 94 | 31Bより明確に速い | 31Bほどの安心感ではないが、説明量と読みやすさのバランスが良い | 資料不足を指摘したあと一般論を追加 | 代替候補としてあり |
採点だけならFlash-Nextは4モデル中最下位なのに、常用31Bの置き換え候補として一番気になったのはFlash-Nextだった。
Gemma 4 26B A4BはPP 1000 tok/s超、TG 67 tok/sと別格に速いが、以前から感じていた「正しいけれど説明が少し足りない」という印象は今回も残った。Qwen3.8 27Bは内容理解自体は悪くないが、文字数制限を入れたときの文章の圧縮具合が気になる。
Flash-Nextは31Bを品質で圧倒するわけではないが、Q1ではTG約31 tok/sで、31Bの約18 tok/sより明確に軽快だった。それでいて26Bほど説明が薄い感じもなく、27Bほど出力スタイルの癖も気にならなかった。「31Bから速度を取り戻しつつ、回答品質を我慢している感じがあまりしない」というのが今のところ一番近い。
でも、それは本当にモデルの性能差なのか？
こういうテストをしていると、いつも付きまとう問題。「モデルが悪いのか？使い方が悪いのか？」
文章中に書いてない内容を捏造する問題も、プロンプトに「書いていない場合は～」という指示を入れたらどのモデルも捏造はしなかった。そういう例外処理についてプロンプトで指示しない使い方の方が悪い、とも言える。
けど、今回の添付ファイル忘れのように人間がうっかり間違えることもあるので、そこは指摘してほしい。言語モデルは「書いた通りに動く単なるプログラム」ではないのだから。(あれ？そうだっけ？)
今回はユーザー設定のシステムプロンプト的なものを使わずにテストしたが、もしかしたらGemma 4 26B A4Bの説明の足りなさも、Qwen3.8 27Bの出力の不安定さも、チャットならシステムプロンプト、ハーネスならAGENTS.mdやskillsをちゃんと書けば解決するのかもしれない。
Qwen3.8 27Bの要約が圧縮されて読みにくいのも、「本文を読んでいない人が概要を理解するための要約」と明確に指示していないせいかもしれない。
けど、モデルを変えるたびにシステムプロンプトを組みなおすのも大変だし、パラメータを変えて速度チューニングするのとは違って結果が数値で出ないから泥沼にはまりかねない。
それに加えて、個人的に、過去の思考パターンや好みに引きずられるのが嫌なので、普段からシステムプロンプトはほとんど使っていない。
ということで、もしかしたらモデル本来の性能を生かせていないのかもしれないけど、今回はユーザー設定としてのシステムプロンプトは入れない状態での出力を評価した。
(llama.cppのWeb UIからのシステムプロンプトは入っているので、APIを直接呼び出すのとは違う)
もう１つ今回悩んだのが、temperatureなどのパラメータを、モデルの公式パラメータにするか、私が普段使っているパラメータで揃えるかということ。モデルの公式パラメータはモデルによって違うので、同じパラメーターに揃える方が公平とは言い切れないのだけど、今回は汎用的なパラメータよりは少し長文要約＆読解支援という用途に寄せたパラメータを使った。
これも、パラメータを変えただけで今回の結果とは全然違う結果が出る可能性はある。
テスト中にちょっと脱線したいろいろ
コンテキストが溢れたらどうなるかを試してみた
Qwen3.8-Flash-Nextでコンテキスト長を32,768まで下げて、チャット中にコンテキストがいっぱいになったら何が起こるか(エラーになる？勝手に切り詰める？)を試してみた。
長文テストで使ったのと同じ文章をアップロードして、要約→内容について質問→詳細に聞いてみるを複数ターン繰り返したらすぐにコンテキストがあふれるだろうと思ったのだけど、意外と長いチャットが可能だった。
最初のQ1はchat template込みで19,922トークン。その後、Q1〜Q5、長めの説明、説明の一部掘り下げなどを繰り返し、21回の応答が成功した時点で32,748トークンまで増えた。Web UIの表示も「32.75K / 32.77K、100% used、21 remaining」になっていた。
その次の22回目の送信では、リクエスト全体が32,775トークンになり、32,768を7トークン超えたところで
request (32775 tokens) exceeds the available context size (32768 tokens)
というエラーになった。ログ上も直前まで truncated = 0 のままで、古い履歴を自動的に削って再試行する動きは見られなかった。エラーメッセージが出た後は同じチャット画面ではチャット継続はできず、メッセージを再送信しても同じエラーメッセージが出た。
なお、限界直前に長文前半の第2章について聞き返しても正しく答えられていたので、少なくとも今回の範囲では「上限に近づくにつれて先頭をこっそり忘れる」というより、限界までは保持し、超えた次のrequestを明示的に拒否する挙動だった。
これは使う側としては安心な仕様で、勝手に切り詰められて、しれっとチャット継続されて気づかない方が怖い。
切り詰めテストをしていて初めて気づいたのだけど、今回のllama-serverの起動パラメータには -n 1024 がずっと入っていた。これは1回のリクエストで生成する最大トークン数を1024に制限するもので、コンテキスト長そのものの設定ではない。普段使いのパラメータではなく、前回llama-cliでテストするときに入れて、外し忘れていたもの。
長めの出力を依頼して、1024トークンを越えて途中で切れたときは、「続けてください」と依頼したら続きを出力してくれた。
コンテキストに関してはllama.cppのWeb UIがとても分かりやすい表示画面を用意してくれている。実際に使う時はここを見て、あふれそうになる前にに今までの話をまとめてもらう、という使い方もできそう。
Gemma 4 31BはVulkanとROCmで長文PPに大きな差が出た
今回のテストは4モデルともROCm版のllama.cppで行ったが、当初の予定ではQwen3.8-Flash-Nextは今の私の環境ではROCm版でしか動かないのでROCm版、それ以外の3モデルは普段使っているVulkan版でビルドだけ合わせてb10798-mix-659e406にする予定だった。
追記（2026-09-06） クラッシュについては後で解決してVulkan版でも動作するようになっている
けど、Gemma 4 31Bのテストをするときに、うっかりVulkan版に切り替えるのを忘れて、ROCm版のままテストしてしまい、間違えたと思って再度Vulkan版でやり直したら、なんか異常に遅い。元の常用環境の本家b10549のVulkan版に変えても遅くて、常用環境では--cache-ram 0だけど、テスト用の設定は現在の環境のデフォルト値を採用して--cache-ram 8192なので、--cache-ram 0に戻してもやっぱり遅い。
ログを見たら、気のせいではなく体感以上に差があった。
Q1の約2万トークン入力で比較すると、こうなった。
| llama.cpp / backend | --cache-ram |
Q1 PP | Q1 TG | Q1 prompt eval | Q1 total |
|---|---|---|---|---|---|
| b10798-mix ROCm | 8192 | 234.53 tok/s | 18.15 tok/s | 84.5秒 | 120.0秒 |
| b10798-mix Vulkan | 8192 | 63.87 tok/s | 14.11 tok/s | 310.4秒 | 355.8秒 |
| upstream b10549 Vulkan | 8192 | 63.69 tok/s | 14.36 tok/s | 311.3秒 | 356.2秒 |
| upstream b10549 Vulkan | 0 | 63.64 tok/s | 14.13 tok/s | 311.6秒 | 356.3秒 |
TGもROCmの方が速いが、それ以上にPPの差が大きく、同じb10798-mixでもROCmはVulkanの約3.7倍だった。b10549 Vulkanもほぼ同じPPなので、最近のbuildで遅くなったというより、少なくともEVO-X2 + Gemma 4 31Bの長文入力ではbackend差がかなり大きいらしい。
キャッシュ周りもかなり差があった。b10798-mix Vulkanでは、約2万トークンの長いpromptをRAM prompt cacheへ退避する処理に52.9秒かかった。一方、ROCmでは同種の処理が約1.07秒だった。
さらに常用していたb10549 Vulkanでは、Q2で19,712トークンがキャッシュされ、実際に新規評価するのは75トークンだけなのにprompt evalが37.65秒かかった。--cache-ram 0にしても37.63秒でほぼ変わらなかった。
なので、この後のテストはROCm版をベースにして、出力異常などの問題が出たらVulkan版に戻すことにしたが、結局問題が出ることはなく、ROCm版のまま全てのテストを完了した。
一番最初にevo-x2にllama.cppを入れたときに、追加ライブラリを入れなくて良いからという理由でVulkan版を選択して、それからずっと惰性でVulkan版を使ってきたけれど、もしかしたら今まで「Gemma 4 31Bは遅い」と思っていたのはVulkan版のせいで、ROCm版に変えるだけで、ある程度解決できていたのかもしれない。
llama.cppのUIのtoolについて
今回のテスト中、Qwen3.8 27BのQ2とQ4だけ、出力の途中でスクショのような謎の確認画面が出た。ここで「Deny」をクリックすると、同じ出力をもう1回繰り返すという謎の挙動になった。
調べてみると、今回使ったllama.cppのWeb UIでは自分で設定しなくてもBrowser tool(Current timeとRuntime info)がオンになっていて、モデルが呼び出そうとしたらしい。
ログを見ると、Denyボタンを押した後で再度リクエストが送られ、モデルが再度回答を生成していたので、二重回答はモデル側ではなくllama.cppのWeb UIの問題かもしれない。
なぜQwen3.8 27Bだけツールを呼び出そうとしたのかは謎だけど、本題から逸れるのでとりあえずllama.cppのWeb UIの設定でBrowser toolをオフにしてテストした。
Browser toolをOFFにしてQ2とQ4を再実行すると、確認ダイアログも二重回答も出なくなった。
なお、ここでいうBrowser toolはBrave Searchなどの外部Web検索ではなく、llama.cpp Web UI側で用意されている組み込みのBrowser Tools。今回の画面では2 toolsが有効になっていた。
まとめ
今回やりたかったのは、Qwen3.8-Flash-Nextが「動く」「速くなる」の先で、実際に長文要約＆読解支援の常用モデルになり得るかを確かめることだった。
固定した質問と採点基準では、4モデルとも94〜98点に収まり、大きな読解失敗はなかった。得点だけならGemma 4 26B A4Bが98点でトップ、Flash-Nextは94点で最下位。でも、実際に読んだときの印象はその順位と一致しなかった。
- Gemma 4 31B：やっぱり説明が分かりやすくて読みやすい。ただし遅い。添付忘れ時にもっともらしい誤答を断定したのはかなり怖い。
- Gemma 4 26B A4B：圧倒的に速く、必要事項の拾い出しも上手い。ただ、以前から感じていた「もう少し説明してほしい」は残った。
- Qwen3.8 27B：内容理解は良い。文字数制限なしのQ3はかなり読みやすかったが、字数指定を入れると高密度に圧縮する癖が気になる。
- Qwen3.8-Flash-Next：31Bより明確に速く、回答品質も大きく落ちた感じがしない。今回の4モデルでは、常用31Bの代替として一番「ありかも」と思えた。
また、本筋から外れたところでも、llama.cpp Web UIのprompt cacheはかなり有効に働くこと、32K contextを超えると今回の設定では自動切り詰めではなく明示的にエラーになること、Gemma 4 31BではEVO-X2上のVulkanとROCmで長文PPに約3.7倍の差が出たこと、Browser Toolsがモデルのtool call挙動に影響することなど、いろいろ発見があった。
次は、今回試したllama.cppのWeb UIから普段使っているOpen WebUIに移行したときに、システムプロンプトや履歴、キャッシュの扱いによってチャット感は変わるのかを試す予定だったのだけど、実環境に行く前にパラメータとシステムプロンプトの影響を単体で調べたくなってきたので、そっちが先になる予定。
と言いつつ、また新しいllama.cppや量子化モデルをチェックして沼にハマる可能性もある。
モデルの内蔵知識の深さや、Web検索ツールの使い方の上手さも見てみたい気がする。
テストデータの作り方
乾孝司・奥村学「テキストを対象とした評価情報の分析に関する研究動向」（『自然言語処理』Vol.13, No.3, 2006年、pp.201–241）
この論文の、言語処理学会論文誌LaTeXコーパス
に収録されているLaTeXソースから、本文のみを切り出して、LaTexの記号と図表を除去したテキストファイルを作成した。
文書作成後に、llama-serverやllama-cliと同じフォルダにあるllama-tokenizeを使って、実際のトークン数を確認した。
.\llama-tokenize.exe `
-m "(モデルのパス)\Qwen3.8-Flash-Next-UD-IQ3_XXS-00001-of-00003.gguf" `
-f "(作成した日本語文書ファイルのパス)" `
--show-count `
--log-disable
テスト用の質問リストと採点基準
Q1：全文要約
添付文書全体を、1000字程度の日本語で要約してください。
次の内容を必ず含めてください。
- テキスト評価分析が扱う問題
- 対象となるテキストデータの種類
- 第3章で整理されている主要な要素技術
- 評価表現辞書と文脈依存の評価極性の関係
- 評価分析システムの利用目的
- 第6章で挙げられている今後の課題
文書に書かれていない内容は推測しないでください。
20点の採点基準
- テキスト評価分析＝評価情報を抽出・整理し、肯定/否定などを扱う：2点
- 語句・文・文書という粒度に触れる：2点
- テキストデータを「意見収集が目的」と「潜在的に意見を含む」に分ける：2点
- 第3章の4要素（辞書、文書分類、文抽出、評価組抽出）：4点
- 評価表現辞書は静的知識、3.4では文脈を考慮するという違い：2点
- 評価分析システムの企業側・一般利用者側の2用途：2点
- 第6章の課題を最低3つ正しく挙げる：3点
- 1000字程度、日本語、内容の整理：3点
これは広く読めているかを見る質問です。細部の完全性より、全体構造を落とさないことを重視します。
Q2：3種類の辞書構築方法を比較
第3.1節で説明されている評価表現辞書の構築方法を3種類挙げ、それぞれについて、
・何を情報源として使うか
・どのように評価極性を決めるか
・本文で述べられている主な弱点
を比較してください。
700字以内で、日本語で回答してください。
15点
各方式4点×3＝12点です。
-
語彙ネットワーク
- 辞書・シソーラス・WordNet等：1
- 類義・反義関係やネットワーク上の伝播：1
- 既存言語資源にない新語への対応困難：2
-
共起情報
- 種表現との共起：1
- PMIなどで極性判定：1
- 信頼できる共起情報には巨大コーパスが必要：2
-
周辺文脈
- 種表現＋周辺文脈：1
- 文脈一貫性、逆接等を利用したブートストラップ：1
- 被覆率が低い：2
残り3点は、3方式を混同せず比較できているか。
これは長い説明の中から対応関係を正確に保持できるかを見るのに向いています。
Q3：静的辞書だけでは足りない理由
本文では、単語単体の評価極性だけでは実際の評価を正しく扱えない例がいくつか示されています。
第3.1節と第3.4節の違いを説明したうえで、本文中の具体例を少なくとも2つ挙げ、「文脈を考慮する必要がある理由」を説明してください。
文書にある例だけを使用してください。
15点
- 3.1＝文脈から独立した単語単体の極性を主に扱う：3点
- 3.4＝対象・評価者などを含む評価組と実際の文脈を扱う：3点
- 「ベッドは眠気をさそう」→肯定：2点
- 「講義は眠気をさそう」→否定：2点
- 「このりんご、美味しかった？」は質問であって評価とは限らない：2点
-
par for the courseや「リスクが低い」等、極性発現/変化に触れれば：最大2点 - 全体を「同じ語でも対象・構文・組合せで評価が変わる」と結びつける：1点
ここは単語検索だけではなく、概念を理解して例と結び付けられるかを見る質問です。
Q4：後半needleテスト
第6.1節では「中立」という概念に曖昧さがあると述べています。
本文で「中立」とまとめて扱われうる3種類のケースをすべて挙げ、それぞれの違いと、著者が何を問題視しているのか説明してください。
400字程度で回答してください。
15点
正解は明確です。
- 評価を含まない：3点
- 評価を含むが肯定でも否定でもない：3点
- 肯定と否定の両方を含む：3点
- 3つは性質が異なるのに一括して「中立」と呼ばれている：3点
- 今後「中立」の概念を再整理する必要がある：2点
- 指定程度の簡潔さ：1点
これは第6章なので、長文後半まできちんと参照できるかを見るのに非常に使いやすいです。
Q5：前半と後半をまたぐ統合問題
第2章では評価分析の題材となるテキストを2種類に分類しています。
その2種類の特徴を比較したうえで、第6.3節「明示的に表されない評価」と第6.5節「評価文書の収集」が、特に「潜在的に意見を含むテキスト」を扱う際にどのような課題になるのか、本文に基づいて整理してください。
800字以内で回答してください。
20点
-
「意見の収集・集約が目的」のテキスト：3点
- 自由回答、顧客の声、レビューなど
- 意見割合が高い、対象や話題が比較的限定されやすい
-
「潜在的に意見を含む」テキスト：3点
- チャット、掲示板、Weblog
- 意見割合が低い、雑多、品質も問題になり得る
-
6.3：明示的評価表現がないと現状の手法では扱いにくい：3点
-
6.3の例が事実記述に近いことに触れる：2点
-
6.5：対象についての評価文書群が既に集まっている前提は現実には成り立たない：3点
-
潜在的意見テキストでは「どこに評価文書があるか」自体を探す必要が強くなる：3点
-
第2章と第6章を単に列挙せず、関係を説明できている：3点
これはかなり良い章横断読解になります。
共通15点
5問を通して最後に15点
| 項目 | 点 |
|---|---|
| 文書にない研究・概念・数値を勝手に追加しない | 5 |
| 質問の指定（日本語、字数、列挙数等）を守る | 4 |
| 用語を大きく取り違えない | 3 |
| 読みやすく、重複が少ない | 3 |
特に「文書にない内容」は重要なので、かなり重くします。
明確な幻覚があった場合は、この5点を0にするだけでなく、事実点側でもその項目は加点しない。
検証環境
Hardware
- Device: NucBox_EVO-X2
- CPU / APU: AMD Ryzen AI MAX+ 395 with Radeon 8060S
- CPU clock displayed by Windows: 3.00 GHz
- Installed memory: 128 GB
- Windows usable memory: 63.6 GB
- UMA Frame Buffer: 64 GB
- GPU: AMD Radeon 8060S Graphics
OS
- OS: Windows 11 Pro
- Version: 25H2
- OS Build: 26200.9168
- Installed: 2025-10-24
- Windows Feature Experience Pack: 1000.26100.344.0
llama.cpp
b10798-mix-659e406- build: b10798
- Windows x64 ROCm gfx1151
- Unsloth team build
- URL: https://github.com/unslothai/llama.cpp/releases
EVO-X2にインストール済みのHIP SDK
- HIP SDK: 7.2.60201-38d754472
- HIP compiler: clang 21.0.0git
- HIP target: gfx1151
使用したモデル
Target model
- Repository:
unsloth/Qwen3.8-Flash-Next-GGUF - URL: https://huggingface.co/unsloth/Qwen3.8-Flash-Next-GGUF
- Quantization: UD-IQ3_XXS
- Logger metadata:
IQ3_XXS - 3.0625 bpw - Model file size reported by llama.cpp: 76.32 GiB
- Model params: 176.94B
MTP draft model
mtp-Qwen3.8-Flash-Next-Q8_0.gguf- URL: https://huggingface.co/unsloth/Qwen3.8-Flash-Next-GGUF/tree/main/MTP
比較対象用モデル
Gemma 4 31B
- Repository:
google/gemma-4-31B-it-qat-q4_0-gguf - URL: https://huggingface.co/google/gemma-4-31B-it-qat-q4_0-gguf
- File:
gemma-4-31B_q4_0-it.gguf、mtp-gemma-4-31B-it-Q4_0.gguf
Gemma 4 26B A4B
- Repository:
unsloth/gemma-4-26B-A4B-it-qat-GGUF - URL: https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF
- File:
gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf、mtp-gemma-4-26B-A4B-it-Q8_0.gguf
Qwen3.8 27B
- Repository:
unsloth/Qwen3.8-27B-GGUF - URL: https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
- File:
Qwen3.8-27B-UD-Q5_K_XL.gguf(MTPは内蔵)