■ 現状の構成と課題
・現在は「SillyTavern → uvicorn(FastAPI) → LM Studio」の構成
・uvicorn内でプロンプトを組み立て（多層構造・擬似RAG）してからLM Studioへ送信
・この構成では毎回フルプロンプトを送信している
・LM StudioのAPIは基本的にstateless挙動のため、KVキャッシュがリクエスト間で再利用されない
・結果として「毎回初回と同じ遅い応答開始（長いprefill）」が発生する
■ 確認された挙動
・LM Studio単体UIでは2回目以降が高速 → KVキャッシュ再利用されている
・SillyTavern経由（uvicorn含む）では毎回遅い → KVキャッシュ未再利用
・SillyTavernは外部API利用時、基本的に毎回全履歴を送信する仕組み
・これはOpenAI等の外部APIでも同様（課金はトークンベース）
■ 問題の本質
・KVキャッシュは「同一セッション内の連続推論」でのみ有効
・現在の構成は「毎回新規推論（stateless）」になっている
・外部で履歴管理（擬似RAG）しているため、内部KVと設計が競合している
■ 今後の方針（大枠）
・「KVキャッシュ活用型」に移行する
・現在の構成は一旦リセットし、シンプルな最小構成から再構築する
■ 新構成（ベース設計）
・SillyTavern → uvicorn（FastAPI） → KVキャッシュ保持可能なLLMサーバ
・uvicornは最初「完全パススルー（何も加工しない）」
・まずはKVキャッシュが効く状態を確認することを最優先
■ 使用候補エンジン
・llama.cpp系サーバ（最優先）
理由：KVキャッシュ制御が明確、軽量、GGUFと相性良い
・Ollama（代替候補）
理由：導入が簡単、セッション管理が比較的容易
・vLLM等は今回は優先度低（構成が重く目的とややズレる）
■ 検証ステップ
・Step1：llama.cppサーバを起動（KVキャッシュ有効状態）
・Step2：SillyTavernから直接接続（uvicornなし）
・Step3：2回目以降の応答速度が改善するか確認（KV再利用確認）
・Step4：uvicornを間に挟む（完全パススルー）
・Step5：同様に速度確認（ここで遅くなるなら実装問題）
■ uvicornの役割（初期）
・リクエストをそのまま転送するだけ
・プロンプト加工なし
・セッションIDや履歴も触らない
・目的は「KVキャッシュが壊れないことの確認」
■ 成功条件
・2回目以降の応答開始時間が明確に短縮される
・prefill時間がほぼ発生しない状態になる
・トークン生成速度ではなく「初速」が改善される
■ 成功後の拡張方針
・uvicorn内に徐々にロジックを追加
・ただし「毎回フルプロンプト再送」は避ける
・以下のどちらかに寄せる必要あり
・差分送信型（appendのみ）
・内部セッション保持型
■ 注意点（重要）
・KVキャッシュを活かす場合「履歴はモデル側に持たせる」必要がある
・外部で完全に履歴を再構築するとKVの意味が消える
・つまり「外部RAG型」と「KV活用型」は設計思想が異なる
■ 現構成との関係
・現在の多層プロンプト構造は一旦切り離す
・KV活用が安定してから、再統合を検討
・統合する場合は「どこまで外部管理するか」を再設計する必要あり
■ 最終ゴール
・初回以外の応答開始が高速（体感レスポンス改善）
・長文コンテキストでも安定動作
・必要に応じて外部制御（RAG/人格設計）と共存
追記：
■ SillyTavernの特性
・外部API互換を重視した設計
・毎回履歴を送る前提（ステートレス）
・KVキャッシュ活用には向いていない
・内部状態を持たないため、KVとの相性が悪い
■ Text Generation WebUI（TGWUI）の位置づけ
・UI＋APIラッパー
・内部で履歴とセッションを管理
・同一プロセス内で連続生成するためKVが効く
・外部からフルプロンプトを渡すとKVは効かない
・外部制御型の設計とは相性が悪い
■ TGWUIを使うかどうか
・検証用としては有効（KV挙動の理解）
・本番構成では不要
・理由：内部で履歴管理を持つため外部設計と衝突
コメント