 | 私のプロジェクトでは、これまで Gemini 3 / 2.5 Flash か Flash-lite を使っていました。私のユースケースはどれもエージェント型ではなく、法律から参照を抽出する、分類する、タイトルを格のための形（主格／属格など）に調整する、といったようなアトミックなタスクのための LLM ワークフローです。これらはすべて非英語（LT）言語で行われます。これが、もともと Google のモデルを使っていた理由の一つです。小規模なベース言語に対しては、多言語品質が非常に高いからです。 各リクエストは通常、文脈が 2k～6k トークンに収まります。 最近、少なくとも Gemini 2.5 Flash-lite がひどい結果を出し始めていることを見つけました。さらに、これまで一度も経験したことがなかったループまで起こし始めました。偶然なのか、それとも Vertex API / 彼らのモデル内部で何かが変わったのかは分かりません。 私の環境では RTX 5090 を持っているので、Gemma 4 31B で試してみることにしました。 要件はかなりシンプルです。非英語の言語で可能な限り良いこと、構造化された JSON 応答を生成するのが得意なこと、最大 8K のコンテキスト、そして出力速度をできるだけ速くすること。 そこで、可能な限り最高の品質を絞り出すために、gemma-4-31B-it-GGUF:Q6_K_L + gemma-4-E2B-it-GGUF:Q8_0 の推測デコードを動かしてみました。 さて、少なくとも最初の小さなサンプルテストについて言えることとしては、品質は Gemini 2.5 Flash-lite よりも確実に良いです。しかも速く、ローカルで動きます。得られる出力速度はおおむね 130～200 tok/s で、私が得ている品質に対しては驚異的です。セットアップは 31.5 GB の VRAM を使用し、かろうじて私の GPU に収まる程度です。 私の主張は、データ抽出などの 軽量 な LLM ワークフローや同様のタスクに対しては、もう Vertex API は必要ないということです。 もちろん次のステップは、いくつかの簡単なテストだけでなく、より大規模に試すことです。 同じようなユースケースの人のために共有したいだけですが、試す価値はあります。私の llama コマンドを貼っておきます： [link] [comments] |
Gemma-4-31B＋Gemma-4-E2Bの推測デコーディングで特定タスクにおいて120〜200 tok/sの出力速度を実現
Reddit r/LocalLLaMA / 2026/4/26
💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsTools & Practical Usage
要点
- 著者は、Gemma-4-31B と Gemma-4-E2B を使った推測デコーディングの実装例を共有し、特定のLLMタスクにおいて出力速度を大幅に高められたと報告しています。
- 非アジェント型のワークフロー（1リクエストが2k〜6kトークン程度）での試験では、Gemini 2.5 Flash-liteよりも品質が良いほか、これまでになかったループのような問題も起きにくかったとのことです。
- GGUFの量子化設定（gemma-4-31BはQ6_K_L、gemma-4-E2BはQ8_0）を用い、ローカル実行でおよそ120〜200トークン/秒のスループットを得たと述べています。
- 必要なVRAMは約31.5GBで、RTX 5090ではギリギリ収まるとし、次はより大規模な検証を行う予定だとしています。
- 構造化JSONを生成するデータ抽出・分類などの「軽量」LLM用途では、ローカル実行によりVertex APIの出番を減らせる（ただし追加検証が前提）と結論づけています。
