Hermes Agentコミュニティ、コンテキスト上書きの修正を提案　カスタムプロバイダー名の変換で設定が無効になる可能性

Hermes Agentコミュニティは10月6日、カスタムのOpenAI互換プロバイダーでコンテキスト長を解決する際、古い検出結果が引き続き使われることと、ユーザーが設定した上書き値が無視されることの2つの問題が起きる可能性を報告した。この事例では、v0.21.5、Docker、セルフホストのLiteLLMプロキシが使われ、起動ログと関数の検査結果が添付されている。現時点ではコミュニティからの報告であり、影響範囲は上流での確認を待っている。問題報告

公式ドキュメントでは、context_lengthは入力と出力のtoken数を合算した上限として定義されており、Hermesはこれを履歴の圧縮タイミングの決定とリクエストの検証に使用する。値の解決では手動設定が永続キャッシュより優先され、キャッシュは再起動後も保持される。そのため、プロキシ側の修正をデプロイした後も、クライアントが異なる容量を認識している場合がある。プロバイダーのドキュメント

報告者によると、同じモデルエイリアスの背後で容量の異なるデプロイを設定したところ、起動時のプローブで取得された24,000 tokenがキャッシュされた。容量の小さいデプロイを削除して再起動しても、Hermesはその値を使い続け、初期化に失敗した。model.context_lengthを設定しようとすると、実行時にcustom:litellmがcustomとして解決され、名前の比較でルートが変更されたと誤判定されて上書き値が消去された。報告者は、実際のエンドポイントに合ったmodel.base_urlも明示的に設定すれば、上書きが有効になると述べている。再現手順と一時的な対処方法

ドラフトのPR #133615は名前の比較のみを扱う。名前付きのカスタムプロバイダーと、実行時のcustomを同一のIDとして扱う一方、異なる名前付きプロバイダー同士は区別する。作者は関連する8件のテストが通過したと報告しているが、これは作者による検証であり、マージまたは正式リリースを示す証拠はまだない。また、永続キャッシュに有効期限がない問題も、この修正案の対象外である。修正案

運用エンジニアにとって、この事例はコンテキストのエラーを調査する際、バックエンドの容量、クライアントのキャッシュ、設定が実際に反映されているかを併せて確認する必要があることを示している。今後は、プロバイダーIDの修正がマージされるか、キャッシュに再検証の仕組みが導入されるかを追う価値がある。現時点の証拠だけでは、すべてのLiteLLMやカスタムエンドポイントに影響すると結論づけることはできない。