上級 11 分Quantization

Qwen3 GGUF:トークナイザーとチャットの修正 template

端的な回答

GGUF Qwen3 におけるトークナイザーとチャットテンプレートのエラーは、三つの症状として現れます。思考タグが閉じられないこと、生成が止まらないこと、または的外れな回答です。原因はほぼ常に、チャットテンプレートの適用ミスです。GGUF に埋め込まれたテンプレートを使用するには --jinja を追加し、ファイルの出所を確認してください。最終手段として、カスタムテンプレートを使用してください。

Qwen3のGGUFが「でたらめな回答をする」場合、モデルの品質が原因であることはほとんどありません。問題は、プロンプトがモデルに渡される前の整形にあります。このガイドでは、Qwen3のGGUFにおけるトークナイザーとチャットテンプレートのエラーだけを扱います。症状を見分け、ファイルの出所を確認し、テンプレートを修正または置き換える方法を説明します。

著者 Mohamed Meguedmi·更新 2026-09-28·Windows・macOS・Linuxでテスト済み

#認識すべき 3 つの症状

トークナイザまたはチャットテンプレートの問題を示す3つのシグナルがあります。これらはモデル自体の問題ではありません。具体的には、応答内で思考タグ(通常は「think」)が開かれたまま閉じられないこと、応答の論理的な終了位置で停止せず生成が無限に続くこと、あるいは質問がされたことを理解していないかのように的外れな回答を返すことです。いずれの場合も、原因はモデル自体ではなく、入力として受け取るテキストの構造が正しく形成されていないことにあります。

i
Qwen3でこの問題が起きる特有の理由
Qwen3のチャットテンプレートは、それ以前のモデルの多くよりも複雑な構造を扱います。推論モードと直接回答モードの切り替え、ツール呼び出し、そしてリストのスライスなどの構文要素を含むJinja構文です。こうした構文要素のすべてが、初期のllama.cppテンプレートエンジンでサポートされていたわけではありません。

#根本原因:チャットテンプレート

ローカルAIキット

お使いのマシンで、プライベートかつ無料のChatGPTを1時間で構築 — LM Studio、Ollama、Open WebUI、ご自身のドキュメント、クラウド不要。

  • 永久に利用できるオンラインスペース
  • PDF + ファイル
  • 30日間返金対応

言語モデルがメッセージをそのまま直接受け取ることはありません。トークンに変換する前に、チャットテンプレートがメッセージを整形します(発話ターンのタグ、システムプロンプト、開始・終了マーカーなど)。このテンプレートがない場合や、選択が不適切な場合、推論エンジンが正しく解釈できない場合には、モデルに渡されるテキストが学習時の形式と異なるため、出力の品質が低下します。モデルの重みとトークナイザー自体が正しくても、この問題は起こります。

#--jinjaオプション:最初に確認すべき項目

Qwenの公式ドキュメントでは、llama.cppでQwen3のGGUFを起動する際に--jinjaを追加することを明示的に推奨しています。このオプションは、GGUFファイルに埋め込まれたチャットテンプレートを使うよう指定するものです。エンジンがデフォルトで選ぶ汎用テンプレートを使うよりも、この方法を優先するよう案内されています。

Qwenのドキュメントに掲載されているリファレンスコマンド
./llama-cli -hf Qwen/Qwen3-8B-GGUF:Q8_0 --jinja --color -ngl 99 -fa -sm row --temp 0.6 --top-k 20 --top-p 0.95 --min-p 0 -c 40960 -n 32768 --no-context-shift

起動コマンドに--jinjaが含まれていない場合は、ほかの原因を考える前に、まずこのオプションを追加してみてください。このオプションが広く使われるようになる前に作られたスクリプトやインターフェースの多くは、今でもこれを省略しています。そのため、正常なQwen3のGGUFでも「回答がおかしくなる」という報告がかなりあります。

#既知で修正済みの構文解析バグ

llama.cppでは、Qwen3のチャットテンプレートに関する特定のエラーが発生しました。テンプレートエンジンが、ツール呼び出しのロジックで会話履歴を逆順にたどるために使われるJinjaのリストスライス構文(messages[::-1])を解析できなかったのです。報告されたのは、テンプレート内のまさにその行を指す解析エラーでした。

!
覚えておきたいエラーメッセージ
「Expected value expression at row 18, column 30」に続いて、テンプレート内のmessages[::-1]を含む行が表示されるのが、この構文解析バグ特有のエラーです。このバグは、llama.cppリポジトリで後に提出されたプルリクエストによって修正されました。まだこのエラーが出る場合は、まずllama.cppバイナリのバージョンを確認してください。修正前のバージョンである可能性が高いです。
  1. 01
    使用されているllama.cppのバージョンを確認
    古くなったバージョンは、Qwen3テンプレートで使用されるスライス構文のパーサー修正を含んでいない可能性があります。
  2. 02
    新しいバージョンに更新する
    このケースでは、llama.cppの最新バイナリを再コンパイルまたは再ダウンロードすることで解決できます。GGUF自体を編集する必要はありません。
  3. 03
    アップデートが不可能な場合
    問題となっているJinja構文を避けた、簡略化したカスタムテンプレートを--chat-template-fileで指定する。

#llama-serverとllama-cliは動作が異なります

llama.cppのリポジトリで報告されている挙動として、llama-serverで--jinjaを有効にすると、応答から推論ブロック(思考タグの間にある内容)が消えることがあります。一方、同じオプションと同じモデルでllama-cliを使うと、そのブロックは表示されたままです。連携先が出力内の推論内容の存在を前提としている場合(オブザーバビリティやデバッグのためなど)、これはトークナイザーの問題ではなく、2つのバイナリ間の処理の違いです。さらに調査する前に、どちらを使っているか確認する。

この違いは、単に対話セッションを使うのではなく、llama.cpp を組み込んだシステムを構築する場合に実務上の影響があります。llama-cli で出力形式を検証するテストパイプラインを使い、その後 llama-server を介して本番環境にデプロイすると、アプリケーション側のパラメータを一切変更していなくても、この点に関して気づかないうちに退行が生じる可能性があります。本番環境で使うバイナリを明示的に文書化し、ローカル開発で使うバイナリではなく、その本番用バイナリでテストすれば、この落とし穴を避けられます。

#思考モードを強制的に無効化する

Qwen3は、チャットテンプレートのレベルで思考モードと直接回答モードを切り替える仕組みを提供しています。ただし、Qwenの公式ドキュメントによると、思考モードを強制的に無効化するこの仕組み(hard switch)は、llama.cppでは標準で利用できる形では公開されていません。Qwen3.5の派生モデルに関する最近の複数の報告が示すように、コマンドラインオプションでenable_thinkingをfalseに設定しても、バージョンによっては無視されることがあります。

Qwenが文書で示している回避策は、--chat-template-fileでカスタムテンプレートを指定し、リクエスト時にパラメータとして渡すのではなく、テンプレート自体の中でenable_thinkingを明示的にfalseに固定することです。この方法は、お使いのllama.cppのバージョンがどこまで対応しているかに左右される実行時パラメータよりも信頼できます。

誤って一般化しないために明確にしておくべき点があります。報告#20182(「enable_thinking param cannot turn off thinking」)が扱っているのは、ビルド8215でのQwen3.5-9Bです。llama.cppのリポジトリでは今も「bug-unconfirmed」ラベルが付いており、未解決のまま「not planned」としてクローズされています。Qwen3.5ではなく、元のQwen3のGGUFでも同じ挙動が起きることを示す証拠はありません。通常のQwen3でこの症状が出た場合は、このチケットの内容が自動的に確認されたとみなさず、切り分けて別途報告すべき事例として扱ってください。

#第三者が提供するGGUFファイルの出所を確認する

Qwen3のGGUFで発生するトークナイザーの問題の一部は、llama.cppではなくGGUFファイル自体に原因があります。古いバージョンの変換ツールで変換した場合や、トークナイザーが正しくエクスポートされていないファイルでは、同様の症状(生成が終了しない、特殊トークンが正しく認識されない)が現れます。推論エンジン側のバグを調べる前に、使用しているGGUFファイルのサイズと公開日を、信頼できるリポジトリ(Qwen公式、または再量子化の内容が文書化されているリポジトリ)のファイルと比較することで、ファイル自体に原因があるという可能性を除外できます。

ファイルの問題か設定の問題かを素早く判断するための簡単な目安があります。同じGGUFが別のマシンや別のバージョンのllama.cppで正常に動作するなら、ファイル自体が原因である可能性は低いでしょう。一方、同じマシンで同じリポジトリから何度ダウンロードし直しても必ず同じ症状が再現される場合は、ファイルよりもローカル設定(バイナリのバージョン、起動オプション)が原因である可能性が高くなります。

→
役立つヒント
最近ダウンロードしたGGUFで、同じモデルの以前のGGUFにはなかったトークナイザーのエラーが出る場合は、llama.cppのバグを疑う前に、元の配布元からファイルを再ダウンロードすること。ダウンロード時の破損や正常に完了しなかった変換は、よくある原因であり、簡単に切り分けられます。

#量子化のビット数が低すぎる:ツール呼び出しの形式が不正になる

最初の3つとは異なる最後の症状は、ツール呼び出しを伴うエージェントとしての Qwen3 の使用に特に関係します。テキストのフォーマットの問題ではなく、ツール呼び出し自体が切り詰められ、引数が空または構造が不適切(無効な JSON)になります。llama.cpp に特化したコミュニティのトラブルシューティングガイドでは、ツール呼び出しの構造は量子化レベルに敏感であると記載されています。4ビット未満の量子化(Q3、Q2、IQ)は、--jinja を使用してチャットテンプレートが正しく適用されている場合でも、不正なツール呼び出しを生成します。

!
テンプレートが原因だと判断する前に確認すること
GGUFのQ5_K_MまたはQ6_Kではツール呼び出しが正しく動作するのに、同じモデルのQ3またはQ2では失敗する場合、原因はチャットテンプレートではなく、量子化そのものです。重みの精度低下は、テキスト全体の品質よりも、厳密な構造(JSON、タグ)の生成に強く影響します。文書で示されている対処法は、テンプレートを手直しすることではなく、より高精度の量子化形式に戻すことです。

この点は見逃されがちです。一見すると、よくあるトークナイザーの問題に見えるためです。応答が途中で切れると、まずチャットテンプレートが正しく閉じられていないのではないかと考えてしまいます。実際に見分ける手がかりは、症状が現れる状況です。テンプレートの問題は、ツール呼び出しを含まない単純なテキストを含め、すべての応答に影響します。一方、ツール呼び出しに関する量子化の問題は、通常、自由形式のテキスト応答には影響せず、ツール呼び出しプロトコルが要求する厳密なJSON構造でのみ現れます。

#トラブルシューティング早見表

観察された症状、最も可能性の高い原因、最初に試すべき対策
症状最も可能性の高い原因最初に試す修正
「think」タグがいつまでも閉じられないチャットテンプレートが適用されていません起動時に --jinja を追加する
終了しない生成テンプレートが正しく解釈されていない、または存在しない--jinjaがあるか確認し、なければllama.cppを更新する
起動時に「Expected value expression」エラーが発生Jinjaのスライシングパーサーのバグ(PR #13573で修正)llama.cppを最近のバージョンに更新する
llama-serverでは思考ブロックが表示されないが、llama-cliでは表示される文書で確認できる、2つのバイナリ間の処理の違いllama-cliでテストして確認し、その後チケット#14894の進展を追う
enable_thinking=false は無視されますllama.cppには、強制的に切り替えるためのスイッチが標準では公開されていません--chat-template-file を使用してテンプレートに enable_thinking=false を設定する
途中で切れるツール呼び出し、または無効なJSON量子化のビット数が低すぎる(Q3、Q2、IQ)少なくともQ4_K_Mに上げる。できればQ5_K_MまたはQ6_Kにする
同じモデルの古いGGUFより、新しいGGUFのほうがバグが多い変換に問題があるファイル、またはダウンロード中に破損したファイル元の配布元(Qwen公式または定評のあるリポジトリ)から再ダウンロードする
よくある質問
自分のQwen3 GGUFが「think」タグを一向に閉じないのはなぜですか?+
チャットテンプレートが誤って適用された場合の最も一般的な症状です。まず、--jinjaをコマンドに含めており、GGUFに内蔵されたテンプレートを使用しているかを確認してください。多くの古いスクリプトやインターフェースでは、このオプションの一般化以前に存在しないデフォルトテンプレートが使用されています。
--jinja オプションは Qwen3 のテンプレート問題をすべて解決しますか?+
ほとんどのケースは解決できますが、すべてではありません。リストのスライス構文を解析する際のバグが、llama.cppの一部のバージョンに影響を及ぼしました(現在は修正済み)。思考ブロックの表示はllama-serverとllama-cliで異なる場合があり、量子化のビット数が低すぎると、テンプレートが正しくてもツール呼び出しが正常に動作しなくなることがあります。
llama.cppでQwen3の思考モードを恒久的に無効にするにはどうすればよいですか?+
コマンドラインで渡した enable_thinking パラメータは、バージョンによっては無視されることがあります。Qwenが文書で示している方法は、--chat-template-file でカスタムテンプレートを指定し、そのテンプレート内で enable_thinking を直接 false に設定することです。使用しているビルドの具体的な対応状況に左右されるリクエストパラメータとして渡す方法の代わりに、こちらを使います。
最近ダウンロードされたQwen3のGGUFファイルは、以前のものと異なる挙動を示します。なぜですか?+
llama.cppのバグを疑う前に、まずファイルの出所と完全性を確認してください(Qwenの公式配布元または信頼できるリポジトリから再ダウンロードしてください)。不完全なGGUF変換やダウンロード時の破損は、テンプレートのバグに非常によく似たトークナイザーの症状を引き起こしますが、ファイルを再ダウンロードすれば解消できます。
--jinjaを使ってもQwen3のツール呼び出しが途中で切れるのはなぜですか?+
コミュニティによるトラブルシューティングガイドには、ツール呼び出しの構造が量子化の影響を受けやすいことが記載されています。4ビット未満の量子化(Q3、Q2、IQ)では、正しいテンプレートを使用しても、形式が不正なJSONが生成されます。まず試すべき修正は、Q4_K_M、またはそれよりビット数の多い量子化(Q5_K_M、Q6_K)に引き上げることです。
enable_thinking が無視されるバグは、Qwen3.5だけでなくQwen3にも影響しますか?+
最も詳しく記録されている報告(issues #20182、#20409)は、明示的にQwen3.5の派生モデルを対象としており、「bug-unconfirmed」のステータスのまま、未解決でクローズされています。元のQwen3のGGUFでも同じ挙動になると確認できる情報はありません。同じだと決めつけず、個別に確認する必要があります。
このガイドは役に立ちましたか?

ご意見、誤りのご指摘、補足はありますか?ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。