翻訳LLMの「思考トークン予算」は1024で十分だった：訳質を落とさず速度を2倍にした検証
きっかけ
ローカルLLMを使ったPDF翻訳ツールの処理速度を改善できないかと考えたことがきっかけです。
これまで推論時の思考トークン上限（reasoning_budget_tokens）を 3072 に設定していましたが、「本当にそこまで長考させる必要があるのか？」「思考予算を削ることで、訳質を保ったまま翻訳を高速化できるのではないか？」という疑問を持ち、思考予算ごとの訳質と速度のベンチマーク測定を行いました。
学んだこと
検証の結果、思考予算は 1024 トークン がベストバランスであることがわかりました。
- 速度が2倍強に向上する: 長い段落の翻訳において、所要時間の中央値が 108.5秒（3072）から 54.6秒（1024）へと半減し、1分あたりの処理段落数が 2.0 から 4.3 へと倍増した。
- 訳質は上限なしと変わらない: 盲検評価（ブラインドテスト）において、1024トークン制限と無制限の間で勝敗に有意な差はなく、判定の揺れの範囲内に収まった。
- 512まで削ると破綻リスクがある: 思考予算を512まで落とすと、思考途中の下書きメモが訳文に出力されてしまう不具合が発生した（1024以上では発生ゼロ）。
- 「thinking なし」は明確に劣化する: 完全に思考をオフにすると誤りの指摘が約1.6倍に増加したため、思考プロセスそのものは翻訳品質の担保に不可欠である。
自分なりの理解
思考モデル（Reasoning LLM）において、「長考させればさせるほど出力が良くなる」というのはタスクによっては成り立たない、という点です。
翻訳というタスクにおいては、構文の解釈や訳語の選定に必要な「最低限の思考の足場」さえあれば十分であり、それ以上の長考はレイテンシ（待ち時間）を悪化させるだけの冗長なプロセスになりがちです。一方で、思考を完全に奪うと翻訳精度が落ち、思考時間を極端に短く（512トークン）制限すると「思考の整理が終わらないまま出力に移る」ため、思考メモが漏れるといった別の不具合を生みます。
品質を落とさずにスピードを最大化する「スイートスポット」が、今回の環境では 1024 トークンでした。
実践へのつなげ方
ローカルLLMを実務ツールに組み込む際は、推論モデルの「思考予算（reasoning budget）」をデフォルトや安全側の大きな値のまま放置せず、タスクごとに最適化を図るべきだと実感しました。
評価の際は、単に速度を見るだけでなく、
- ブラインドテストによる品質の同等性確認（長考させたものと差があるか）
- 極端に削ったときの副作用の確認（プロンプトやメモの漏れがないか）
- 思考ゼロとの比較（そもそも推論モデルを使う価値があるか）
の3点をセットで検証するアプローチが、他のタスク（要約やコード生成など）でも有効に機能します。
次に試すこと
翻訳ツールの設定（config/config.toml）の [llm] reasoning_budget_tokens を 3072 から 1024 に書き換えて反映し、日常の翻訳作業で体感速度と安定性を確認します。