この記事でやったこと
- 前編と同じメール優先度（urgent／high／medium）判定で、メールを長くしたときの精度を測定
- 元メール100件（英語と日本語訳）に中立な背景文を足して、256〜2,048トークン相当にした
- 判定の手がかりになる本文の位置と、背景文の繰り返しの有無も変えた
- 件名あり／件名なしの2通りで測定
- 先頭256トークンだけを渡して本文が切れる条件も測定
- 入力の長さごとの速度とGPUメモリを測定
- すべてRTX 5090 1枚で実行
TL;DR（分かったこと）
前提：
- urgent：メールの優先度ラベル。このデータでは中身がほぼフィッシングメール
- TF-IDF：782件の件名＋本文で学習した古典的な分類器（TF-IDF特徴量＋ロジスティック回帰）の略称
- Clef系：Clef 27BとClef-Flash。Cloudflareの、文章を生成せず選択肢の確率を返すモデル（Decision Model）
- Qwen3.5-9B：生成LLM。JSONで答えさせる
- 英日：英語の原文と、その日本語訳
- 長文（2,048トークン）では、TF-IDFのurgent再現率は0.00まで落ちる。Clef／Clef-Flashは英日とも0.99以上を保つ。
- 目安（見逃し・誤警報とも5%以下）を英日の全長で満たしたのは、Clef-Flashだけ。日本語では、Qwen3.5-9Bが1,024トークン、Clef 27Bが2,048トークンで外れる。
- 件名を消しても、Clef系は英日とも長文で再現率0.99以上を保つ。長文に強いのは件名のおかげではない。一方、Qwen3.5-9Bは日本語2,048トークンで0.82に下がる。
- 先頭256トークンだけを渡して本文が切れると、Clef系は誤警報が増え、Qwen3.5-9Bは見逃しが増える（再現率0.04〜0.14）。Clef系のurgent判定は、件名だけを根拠にしていた（件名も消すとurgentは0件）。
- 速度は、Clef-FlashがQwen3.5-9Bの約2倍（2,048トークンで189 ms対375 ms）。
- GPUメモリの増分は、Clef-Flashが約8GiB、Clef 27Bが約20GiB、Qwen3.5-9Bが約6GiB。
図1 英語でのurgent再現率。対象は元メール100件のうちurgent 50件で、各長さの値は本文の位置（冒頭・中央・末尾）と背景文の繰り返し（あり・なし）の6条件の平均。帯は95%区間。TF-IDFは512トークンでほぼ検出できなくなる
対象読者
- メールやチケットの振り分けを、ローカルGPU上で済ませたい人
- 長いメールを、Decision Modelと生成LLMのどちらで判定するか迷っている人
この記事は後編です。元のメール（背景文なし）での精度、日本語訳と件名の有無の影響、ラベルの説明文の影響は、前編で扱いました。
注意点：評価に使ったのはAIが生成した合成データで、ラベルが人間の判断と合うかは検証していません（Claudeによる確認のみ）。実験コードは公開していません。結果に影響する設定は、末尾の「再現に必要な設定」に載せています。プロンプトの全文と起動引数は、前編にあります。
比べた条件
前編・後編で、次の条件を比べています。後編は「長いメール」の回です。
| 比較の軸 | 前編（元のメール） | 後編（長いメール） |
|---|---|---|
| 長さ | 元のまま（英語で平均約500字） | 背景文を足して256〜2,048トークン相当 |
| 言語 | 英語3,123件、日本語訳100件 | 英語・日本語訳とも元メール100件から作成 |
| 件名 | 件名＋本文／本文のみ／件名のみ | 件名あり／件名なし |
| ラベルの説明文 | データに合わせた説明／一般的な緊急度 | データに合わせた説明のみ |
| 本文の切れ | なし | 先頭256トークンだけを渡す条件 |
| 速度 | 元のメール | 入力長ごと、GPUメモリも |
前編のおさらい
前編の要点です。
- データ：weijianzhg/email-triage-action-seed1（英語の合成メール3,905件）を、調整用（782件）と評価用（3,123件）に分けています。ラベルはurgent（フィッシング）、high（仕事の対応が必要な正規メール）、medium（個人・旅行）です。
- 方法：Decision Model2は、ラベルの説明文を選択肢として渡して確率を返します。Qwen3.5は、同じ説明文をシステムプロンプトに入れ、JSONで答えさせます。TF-IDFは、文字の並び（2〜4文字）の頻度を特徴量にして、調整用データで学習したロジスティック回帰です。Decision ModelとQwen3.5には例を見せません（ゼロショット）。
- 指標：Macro-F1、urgent再現率（urgentのうちurgentと判定できた割合）、FPR（urgentでないメールをurgentと判定した割合）です。
- 判定の目安：「フィッシングの見逃しが5%以下（urgent再現率0.95以上）」かつ「誤警報が5%以下（FPR 0.05以下）」です。結果を見る前に決めました。この記事では、長さごとに崩れたかどうかをこの線で判断します。
- 元のメールの結果：英語の評価用データでは、Qwen3.5-9Bが0.956、Clef 27Bが0.916、Clef-Flashが0.892、TF-IDFが0.983（Macro-F1）でした。どのモデルもTF-IDFに届いていません。日本語訳100件では、Clef 27BとQwen3.5-9Bが0.909、Clef-Flashが0.881でした。
- 件名の効き方：元のメールで件名だけを渡すと、Clef系はurgentと言い続けて誤警報が増え、Qwen3.5-9Bは見逃しが増えました。
実験環境（RTX 5090、llama.cpp v0.6.0）と6つのモデルは前編と同じです。詳細は次の折りたたみにあります。速度はWSL2上の測定なので、同じ環境の中での比較として読んでください。
実験環境と比較したモデル（前編と同じ）
表1 実験環境
| 項目 | 内容 |
|---|---|
| GPU | NVIDIA GeForce RTX 5090（VRAM 32GB、電力上限575 W） |
| CPU・メモリ | AMD Ryzen 9 9950X3D2（16コア）、31GiB（WSL2に割り当てられた量） |
| OS | Windows上のWSL2（Ubuntu 26.04.1 LTS、カーネル6.18.40.1-microsoft-standard-WSL2） |
| ドライバ・CUDA | NVIDIAドライバ616.92（CUDAドライバAPI 13.4）、CUDA Toolkit 12.8 |
| 推論エンジン | llama.cpp v0.6.0（commit d812350）3を、GCC 14.4.0でCUDA有効・sm_120 向けにソースビルド |
| Python環境 | Python 3.12.15、PyTorch 2.11.0+cu128、Laya SDK 0.4.2（transformers 5.19.0）、scikit-learn 1.9.1。公式実装との照合だけtransformers 5.10.2 |
| 測定条件 | 並列数1の逐次処理。他のGPUジョブは速度測定のあいだ停止 |
| 実行日 | 2026-10-10〜11 |
速度はWSL2上で測っているので、絶対値は他の環境にそのまま当てはまりません。同じ環境の中での比較として読んでください。
表2 比較したモデル
| 表示名 | 方式 | サイズ | エンジン・量子化 | チェックポイント |
|---|---|---|---|---|
| Laya（英語） | Decision Model | 421M | llama.cpp・BF16 | ggml-org/Laya-GGUF |
| Laya（多言語） | Decision Model | 322M | Laya SDK・FP16 | convaiinnovations/laya |
| Clef-Flash 9B | Decision Model | 9B | llama.cpp・Q4_K_M | ggml-org/Clef-Flash-GGUF |
| Clef 27B | Decision Model | 27B | llama.cpp・Q4_K_M | ggml-org/Clef-GGUF |
| Qwen3.5-0.8B | 生成LLM | 0.8B | llama.cpp・Q4_K_M | unsloth/Qwen3.5-0.8B-GGUF |
| Qwen3.5-9B | 生成LLM | 9B | llama.cpp・Q4_K_M | unsloth/Qwen3.5-9B-GGUF |
GGUFはllama.cppで動かすためのモデルファイルの形式、Q4_K_Mは4ビット量子化、BF16・FP16は量子化しない16ビット精度です。
- Clef-FlashはQwen3.5-9Bから、Clef 27BはQwen3.8-27B（比較したQwen3.5とは別世代）から追加学習したモデルです。
- 入力は全モデル共通の
Subject: …とBody: …です。Decision Modelは1回で複数の質問に答えられますが、今回は優先度の質問1問だけを渡しました。 - Qwenは2つの出力方式（自由生成のJSON、JSON schemaで制約）で測りましたが、出力が全件で同一だったので、1系列として扱います。
長文メールの準備
前編のデータは、英語で平均約500字のメールです。長文への耐性を測るため、前編で日本語に訳した元メール100件（urgent 50／high 25／medium 25）の英語原文と日本語訳に、背景文を足して長文を作りました。次の4つの条件を変えて測っています。
- 長さ：256／512／1,024／2,048トークン相当になるまで背景文を足します（トークン数はQwen3.5のトークナイザーで数えました）。文字数にすると、英語で約1,100／2,400／4,900／10,000字、日本語で約470／900／1,800／3,500字です。元メールの平均は、英語が約500字、日本語訳が約270字です。
-
位置：元のメールの本文（判定の手がかりはすべてここにある）を、
Body:欄の冒頭・中央・末尾に置きます。件名は常に先頭です。 - 背景文の繰り返し：背景文を、毎回異なる段落にするか（なし）、同じ段落を繰り返すか（あり）を変えます。なしは、中立な背景段落（依頼・期限・金額・リンクを含まない60段落）から重複なく引きます。ありは、3段落と定型の注記2種（後述の確認で残ったもの）を繰り返します。
- 先頭だけを与える条件：各メールの先頭256トークンだけを与えます。長さそのものの影響と、入力が切れる影響を切り分けます。
同じ長さ・同じ繰り返し条件なら、位置を変えても背景文は同じです。位置の効果が、背景文の違いと混ざらないようにするためです。背景段落は、英語・日本語それぞれで書き下ろしました。実際の長文の例は、次の折りたたみにあります。
長文メールの実例と日本語訳（512トークン相当、本文は中央、背景文の繰り返しなし）
件名と元の本文（DHLを装った偽の配達通知）は元データのままで、前後に中立な背景文を足しています。背景文は途中を略し、URLは無効化しています。
Subject: DHL: Your package delivery failed - Reschedule immediately
Body:
The allotment gardens behind the station are divided into narrow plots, each tended by
a different household. Some grow neat rows of vegetables, while others are full of fruit
bushes, sunflowers and small sheds decorated with recycled windows and doors.
［背景文：あと3段落（略）］
Dear Customer,
We attempted to deliver your package (Tracking #DHL4829571036) but no one was available
to receive it. This package will be returned to sender within 24 hours if not rescheduled.
Reschedule delivery: hxxp://dhl-redelivery-schedule[.]info/track
You will need to verify your address and pay a small redelivery fee of $1.99.
DHL Express Customer Service
Chess pieces have changed shape over the centuries, and many regional styles once existed.
［背景文：あと3段落（略）］
同じメールの日本語訳（元の本文のみ）です。
Subject: DHL：お荷物の配達ができませんでした - 直ちに再配達をご手配ください
Body:
お客様各位
お荷物（追跡番号 DHL4829571036）をお届けにあがりましたが、
受け取れる方がご不在でした。24時間以内に再配達のご手配がない場合、
このお荷物は差出人へ返送されます。
再配達の手配：hxxp://dhl-redelivery-schedule[.]info/track
ご住所の確認と、再配達手数料$1.99のお支払いが必要です。
DHLエクスプレス カスタマーサービス
背景文がラベルを変えていないかは、Claude 3体（Haiku 5.5・Sonnet 5.5・Opus 5.5）に、正解ラベルを見せずに確認させました。
- 背景段落のうち、守秘義務・所在地などの定型文4種は「正規メールらしさを示す手がかり」と指摘されたので、削除してメールを作り直しました。
- 2,048トークンの長文40ペアで、3体とも元メールと同じラベルを付けました。
長文の結果
件名＋本文の全文を入力すると、Clef／Clef-Flashは英日とも2,048トークンまで崩れませんでした（図2）。Qwen3.5-9Bも英語では保ちますが、日本語では1,024トークンから見逃しが出はじめます。TF-IDFが崩れたのは、図1のとおり512トークンからです。
TF-IDFは文字の並びの頻度で判定するので、背景文が長くなるほど、本文の特徴が背景文に薄められます。英語の2,048トークン相当では、元の本文は文字数で入力の約5%（約500字／約10,000字）しかありません。調整用データには長文がないため、背景文の文字の並びはurgentの特徴と合わず、urgentと判定されなくなったと考えられます（推測で、特徴量の分析はしていません）。
図2 入力長別のurgent見逃し率（上段、1 − 再現率）と誤警報率（下段）。帯は95%区間、破線は目安の0.05。Clef／Clef-Flashは上下段ともほぼ0のまま（重なりを避けるため、系列を左右に少しずらしている）
Layaは、長くなるほど誤警報が増える傾向でした。入力の上限の扱いがエンジンごとに違い、どちらも学習時より長い入力をうまく扱えていない可能性があります（推測）。
- Laya（英語）：学習時の入力上限は512トークンですが、llama.cppは上限を超えても入力を切らず、そのまま処理します。
- Laya（多言語）：SDKが1,024トークンで入力を切ります。
なお、Laya（英語）のトークナイザーで数えると、日本語のトークン数は、長さをそろえるのに使ったQwen3.5のトークナイザーの約2倍になります。そのため、Laya（英語）に日本語の2,048トークン相当を入れた600件のうち、75件（12.5%）がHTTP 500になりました。llama-serverが一度に処理できるトークン数の上限（-ub 4096）を超えたためです。エラーは母数に残しています。
目安を、モデルと長さごとに当てはめたのが図3です。本文の位置3通り×背景文の繰り返し2通りの6条件のうち、最悪の値で判定しています。
図3 目安（再現率0.95以上かつFPR 0.05以下）を満たすかどうか。位置と背景文の繰り返しの全6条件の最悪値で判定。○は全条件で満たす。TF-IDFは英語の調整用データで学習したため、日本語は対象外
英日ともに全長で目安を満たしたのはClef-Flashだけです。ただし、各条件はurgent 50件・非urgent 50件で、1件の差で判定が変わります（限界を参照）。Clef 27BとQwen3.5-9Bの日本語での差は、傾向としての示唆にとどめます。
件名を消した長文
長文での強さが件名のおかげかどうかを確かめるため、長文から Subject: の行を消し、Body: 欄だけを渡して測り直しました。ほかの条件（長さ・位置・背景文の繰り返し）は同じです。結果は表3のとおりです。
表3 件名あり／件名なしでの、2,048トークン相当のurgent再現率とFPR（6条件の平均）
| モデル | 英語 再現率 件名あり → なし |
英語FPR 件名あり → なし |
日本語 再現率 件名あり → なし |
日本語FPR 件名あり → なし |
|---|---|---|---|---|
| Clef 27B | 1.000 → 1.000 | 0.023 → 0.020 | 1.000 → 1.000 | 0.043 → 0.047 |
| Clef-Flash 9B | 0.993 → 1.000 | 0.020 → 0.027 | 0.997 → 0.997 | 0.020 → 0.030 |
| Qwen3.5-9B | 0.983 → 0.977 | 0.023 → 0.027 | 0.950 → 0.820 | 0.027 → 0.037 |
| 参照：TF-IDF | 0.00 → 0.00 | 0.00 → 0.00 | （対象外） | （対象外） |
Clef系は、件名がなくても英日とも全長で再現率0.99以上を保ちました。長文に強いのは、本文から判定できているためと考えられます。
対照的に、Qwen3.5-9Bは日本語で件名を消すと、長くなるほど見逃しが増えました。2,048トークンでは平均0.82で、最悪の条件では0.48です。日本語の長文で件名ありのときに見逃しが少なかったのは、件名に支えられていたためでもあります。
件名なしでは、Clef-Flashの日本語でFPRが0.06（50件中3件）になる条件があり、目安をわずかに外れます。前編の元のメール（件名なし）でも0.06なので、長さではなく件名を消した影響とみられます。英語では、Clef 27BとClef-Flashが全長で目安を満たしました。
本文が切れたとき
先頭256トークンだけを与えると、1,024トークン以上のメールでは、元の本文が入りません。モデルに見えるのは件名と背景文だけです。ここで振る舞いが分かれました（図4）。
図4 元の本文を置いた位置ごとの、urgent再現率（上段）と誤警報率（下段）。塗りは全文入力、白抜きは先頭256トークンのみで、縦線が両者の差。中央・末尾では、先頭256トークンに本文が入らない
- Clef系：件名の手がかりでurgentと言い続けます。見逃しはほとんど増えませんが、件名が強いhighメール（障害報告など）をurgentにする誤りが増えます（FPR 0.16〜0.26）。
- Qwen3.5-9B：本文の根拠が見えないとurgentと言いません。見逃しは大きく増えますが（再現率0.04〜0.14）、誤警報は増えません。
件名も消して背景文だけを見せると、Clef系もQwen3.5-9Bも、urgentと判定したメールは1件もありませんでした（1,024トークン以上で本文が中央・末尾の場合。英日とも再現率・FPRとも0.00）。
つまり、上でClef系がurgentと言い続けた根拠は、件名だけだったことになります。背景文そのものが誤警報を生んでいるわけではありません。
本文が切れる運用で、フィッシングの見逃しを避けたいならClef系が、誤警報を避けたいならQwen3.5-9Bが向いています。参考までに、件名だけで学習したTF-IDFは、本文を読まないので背景文の影響を受けず、長文の全条件でMacro-F1 0.92を保ちます。このデータは、件名だけでもかなり判定できます。
速度とGPUメモリ
並列数1で、ウォームアップ20件のあと30件を3周しました（各長さ90リクエスト）。各周で順序を入れ替え、同じ入力が連続しないようにしています。結果は図5です。数字はHTTP往復を含む壁時計時間で、サーバー側の処理時間との差は1〜5 msでした。
図5 左：入力長別のレイテンシ中央値（ms、対数軸。両端の数字は元メールと2,048トークン相当の値。灰色のTF-IDFはCPU上のプロセス内呼び出し）。右：モデル読み込み前からのGPUメモリの増分（GiB。TF-IDFはGPUを使わない）
- 元のメールでは、前編のとおりClef-FlashがQwen3.5-9Bの約4.8倍速い結果でした。2,048トークンでも189 ms対375 msで、約2倍の差が残ります。
- Clef 27Bは、2,048トークンで581 ms（1.7通/秒）、GPUメモリを約20GiB使います（Clef-Flashは約8GiB、Qwen3.5-9Bは約6GiB）。受信箱を逐次処理するなら十分な速さです。
- Layaは11〜45 msで、LLMの中では最速ですが、精度は目安に届きません。
- TF-IDFは、元メールで約0.5 ms、2,048トークン相当でも約3.5 msでした（件名のみは長さによらず約0.3 ms）。CPU上のプロセス内呼び出しで、HTTPの往復を含みません。速さは圧倒的ですが、長文では前の節のとおり件名＋本文のTF-IDFはurgentを検出できません。
- 入力トークン数は、元メールで約250〜365、2,048トークン相当で約2,200です（ラベルの説明文と質問文のトークンを含みます）。
まとめ
前後編を通すと、選び方は次のようになります。
- 英語の短いメールで、ラベル付きの事例があるなら：TF-IDF（前編）。ただし、背景文を足すと512トークンで崩れたので、署名や引用で長くなるメールには向きません。
- 長文や日本語が混ざるなら：Clef-Flash。このデータと条件では、英日の全長で目安を満たし、2,048トークンでも189 ms、GPUメモリの増分は約8GiBでした。
- Clef 27B：元のメールではClef-Flashよりやや高い（0.916対0.892）ものの、日本語の2,048トークンで目安を外れ、速度は約3倍遅く、GPUメモリも約2.6倍使います。
- 入力を先頭で切る運用なら：見逃しを避けたいならClef系、誤警報を避けたいならQwen3.5-9B。ただし、Clef系のurgent判定は件名だけが根拠になるので、まず全文を渡せないかを考えるのが先です。
- 件名：Clef系は件名がなくても長文で崩れませんでした。Qwen3.5-9Bは、日本語の長文で件名がないと見逃しが増えます。
限界
前編と共通の限界（urgentがフィッシングを指すこと、Claude系だけでの確認、モデル間の交絡、公開済みのモデルだけの検証）は、前編を参照してください。後編に固有の限界は次のとおりです。
- 件名の扱い：件名を消す比較は、件名の行を丸ごと消す方法だけで測りました。件名を無関係な文に差し替える、件名と本文の手がかりを矛盾させる、といった条件は試していません。
- サンプル数：各条件はurgent 50件・非urgent 50件です。1件の差で、目安を満たすかどうかが変わります（FPR 0.06は3件、再現率0.94は47件に相当）。
- 日本語は翻訳100件です。日本語で新規に書いた長いメールでの評価は未実施です。
- 背景文の種類：背景文は中立な話題の段落だけです。実際の長いメールに多い、引用された過去のやりとりや署名は試していません。
- 未実施：Q8_0／BF16での比較、GPUの非決定性（同じ入力を2回流したときの一致率）の測定。
再現に必要な設定
この記事の実験コードは公開していません。プロンプトの全文とllama-serverの起動引数は、前編の「再現に必要な設定」に載せています。ここでは、長文の評価で追加した設定を示します。
Laya（多言語）の呼び出し
SDKをプロセス内で呼びました。質問は前編と同じ内容で、入力の上限は1,024トークンです。
agent = laya.load("convaiinnovations/laya", subfolder="multilingual", revision="7b928d8…")
out = agent.system_one(入力テキスト, questions, max_len=1024)
データの作り方
- 元メール100件の選び方：評価用から、似たメールのグループごとに1件に絞り、urgent 50・high 25・medium 25をシード42で無作為に選びました。
- 背景文の足し方：Qwen3.5のトークナイザーで数えて、目標のトークン数を超えない範囲で、段落を順に足します。入りきらない最後の段落は、文単位で入るところまで足します。段落の区切りは2トークンとして数えました。
- 繰り返しなし：中立な60段落をシャッフルして、順に使います。
- 繰り返しあり：中立な段落から無作為に3つを選び、定型の注記2種と合わせた5つを並べ替えて、繰り返します。
- シード：背景文の選び方と並び順は、（元メール、言語、長さ、繰り返しの有無）ごとに固定しています。位置3通りは同じ背景文を使います。
- 位置：「冒頭」は本文を背景文の前に、「末尾」は後ろに置きます。「中央」は、背景文の段落を前後に半分ずつ分けて、本文を挟みます。件名は常に先頭です。
- 先頭だけを与える条件：背景文の繰り返しなしのメールを、先頭から256トークンのところで切ります。
- 背景段落：英語・日本語それぞれ60段落です。自然・歴史・暮らし・食べ物などの話題で、依頼・期限・金額・リンクを含みません。定型の注記2種は、書式の注記（"Formatting note: this message was composed in plain text. …"）と、環境配慮の注記（"Environmental note: this organisation aims to reduce paper use …"）です。
- 日本語訳：意味、期日、依頼、金額、URL、固有名詞を変えないことを条件に、Claude Opus 5.5で1件ずつ訳しました。
- 背景段落の確認：Claude 3体に、132段落（英日の中立段落と定型の注記）を1つずつ渡し、依頼・期限・脅し・金額・リンク、または正規・不審の手がかりを含むかを判定させました。
- Claude 3体による確認：ラベルの確認では、件名・本文と、データに合わせた説明文だけを渡し、ラベルを1つ選ばせました。正解ラベルとカテゴリは見せていません。
集計と速度測定
- 予測できなかった場合（出力が解釈できない、選択肢にない値、通信エラー）は、誤りとして数え、母数から外しません。Laya（英語）の日本語75件（HTTP 500）を除き、0件でした。
- 指標：Macro-F1は3ラベルのF1の平均です。urgent再現率とFPRは、urgentを陽性、highとmediumを陰性として、予測ラベルから計算しました。Decision Modelの予測は、確率が最大の選択肢です。
- 95%区間：パーセンタイル法です。元のメールでの差は、似たメールのグループ単位で、予測を組にしたまま再標本化しました（ペアのブートストラップ、1,000回）。長文は元メール単位で再標本化しました（再現率とFPRは2,000回、Macro-F1は1,000回）。
- 目安の判定（図3）：位置3通り×背景文の繰り返し2通りの6条件で、再現率の最小値とFPRの最大値を使いました。
- 速度の測定対象：英語の元メールと、背景文の繰り返しなしの長文（先頭だけの条件を除く）から、長さごとに30件を無作為に選び（シード42）、全モデルで同じ入力を使いました。元メールも1つの「長さ」として扱っています。
- 手順：ウォームアップ20件のあと、30件×5段階の長さを3周しました。各周で順序を入れ替え、同じ入力が連続しないようにしています。
-
時間の測り方：1リクエストの往復の壁時計時間です。サーバー側の時間は、llama-serverの
/metricsのprompt_seconds_totalとtokens_predicted_seconds_totalの差分です。Laya（多言語）はプロセス内の呼び出しなので、この2つは一致します。 -
件名を消した条件：長文の入力から
Subject:の行を消し、Body:\n以降だけを渡しました。先頭256トークンの条件は、件名ありで切った入力から件名の行を消したものです（本文の量は件名ありと同じ）。Qwen3.5は自由生成のJSONだけで測っています。
データの出典はweijianzhg/email-triage-action-seed（Apache-2.0）で、日本語の100件はその派生物です。日本語訳・長文・背景段落は、aoyama2222222222/email-triage-long-en-ja（Apache-2.0）で公開しています。
参考文献
- ggml-org/Clef-Flash-GGUF, revision
4a192915ef971886004b5b13294f2b4c7a7fc39d. https://huggingface.co/ggml-org/Clef-Flash-GGUF - ggml-org/Clef-GGUF, revision
63840a1a68cb7084c88610cffc328509356b04cb. https://huggingface.co/ggml-org/Clef-GGUF - ggml-org/Laya-GGUF, revision
22265007700297ba9e128297e82540cf28c5d7d4. https://huggingface.co/ggml-org/Laya-GGUF - convaiinnovations/laya（multilingualを含む）, revision
7b928d828b7b0e022f929d9bd2e44165aa270148. https://huggingface.co/convaiinnovations/laya - unsloth/Qwen3.5-9B-GGUF, revision
3885219b6810b007914f3a7950a8d1b469d598a5. https://huggingface.co/unsloth/Qwen3.5-9B-GGUF - unsloth/Qwen3.5-0.8B-GGUF, revision
6ab461498e2023f6e3c1baea90a8f0fe38ab64d0. https://huggingface.co/unsloth/Qwen3.5-0.8B-GGUF - 参照トークナイザー：Qwen/Qwen3.5-9B, revision
c202236235762e1c871ad0ccb60c8ee5ba337b9a. https://huggingface.co/Qwen/Qwen3.5-9B
-
weijianzhg/email-triage-action-seed, revision
8c98baa8b10a1dddd676c860d9e1b86c89141c38, Apache-2.0. https://huggingface.co/datasets/weijianzhg/email-triage-action-seed ↩ -
Xuan-Son Nguyen, Victor Mustar「New in llama.cpp: Decision Models」（ggml-org、2026-10-02）. https://huggingface.co/blog/ggml-org/decision-models-in-llamacpp ↩
-
ggml-org/llama.cpp v0.6.0, commit
d81235049384534c167caea52b85a694f6103d14. https://github.com/ggml-org/llama.cpp ↩