[Tips] shasta のモデルロード挙動について - krugle-jp/Krugle-Library GitHub Wiki

前提

shasta は、KLiP などのクライアントから推論リクエストを受けると、指定されたモデルを GPU の VRAM 上にロードして処理を行います。

このとき、リクエストには contextLength や maxTokens などのパラメータが含まれており、shasta はその条件に合わせて必要な VRAM を確保してモデルを展開します。

ここで重要なのは、同じモデル名でも、リクエスト時のパラメータが違うと別条件として扱われることです。

つまり、すでに同じモデルが動いていても、contextLength や maxTokens が異なれば、そのまま使い回せず、再ロードが発生することがあります。

よくある例

例1: 15B モデルを標準設定で使う

たとえば、最初のクライアントが krugle-code-15b-chat に対して、次の設定でリクエストしたとします。

contextLength: 16384
maxTokens: 4096

この場合、shasta はこの条件で必要な VRAM を確保して、15B モデルをロードします。

目安としては、約14GB程度の VRAM を使います。

同じように krugle-code-35b-chat を同条件で使うと、こちらは 約28GB程度の VRAM が必要になります。

VRAM 使用量はあくまで参考値です。

実際には入力文脈量や運用条件によって前後します。

例2: 15B と 35B を同時に動かしたい

GPU に十分な VRAM があれば、複数モデルを同時にロードして並行利用できます。

※ 後述の環境設定変更が必要ですのでご注意ください。

たとえば、15B と 35B をどちらも以下の設定で使う場合です。

contextLength: 16384
maxTokens: 4096

必要 VRAM の目安は次の通りです。

15B: 約14GB
35B: 約28GB

合計すると、ざっくり 42GB 以上の VRAM が必要になります。

そのため、GPU の VRAM が足りていれば並行利用できますが、余裕がない環境では片方のロードが外される可能性があります。

例3: VRAM が足りないとどうなるか

たとえば、32GB VRAM の GPU 環境で、すでに krugle-code-35b-chat がロードされているとします。

この時点で、おおよそ 28GB を使用している想定です。

その状態で krugle-code-15b-chat の追加要求が来ると、さらに約14GB必要になるため、単純には載りきりません。

この場合、shasta は 今ロード済みの 35B モデルをリセットして、新しく 15B モデルをロードすることがあります。

この切り替えが起きると、利用者からは次のように見えます。

急に最初の応答が遅くなる
さっきまで速かったのに急に重くなる
利用タイミングによって体感速度が変わる

共有 GPU 環境では特に起きやすい動きです。

例4: 同じモデルでも設定値が違うと再ロードされる

KLiP User #1 が krugle-code-15b-chat を以下の設定で使っているとします。

contextLength: 16384
maxTokens: 4096

この状態で、KLiP User #2 も同じ設定で krugle-code-15b-chat にアクセスするなら、shasta は すでにロード済みのモデルをそのまま利用できます。

この場合、再ロードは不要です。

ただし、KLiP User #2 が次のような別設定でリクエストすると話が変わります。

contextLength: 32768
maxTokens: 4096

この場合、shasta は既存の 16384 / 4096 向けロード状態をそのまま使えないため、いったんモデルをリセットして、32768 / 4096 用にロードし直します。

この再ロードには時間がかかるため、結果として次のような影響が出やすくなります。

最初の返答が遅くなる
ほかの利用者にも待ち時間が波及する
共有環境全体で体感速度が不安定になる

例5: 設定値は同じなのに後半だけ遅い

これもよくあるケースです。

たとえば、最初は contextLength: 16384 / maxTokens: 4096 で快適に動いていたとしても、会話が長引いて履歴が肥大化したり、添付文脈や RAG の参照情報が増えたりすると、後半になるほど重くなることがあります。

この場合は設定値が変わっていないので、一見すると原因が分かりにくいのですが、実際にはセッションの入力総量が増えているのが原因です。

こうしたケースでは、

新しいセッションに切り替える
長い履歴をそのまま持ち越さない
添付文脈を絞る

といった対応が有効です。

運用ルール

shasta を安定して使うためには、クライアントごとに設定をばらつかせず、できるだけ運用ルールをそろえるのが大事です。

1. モデルごとに標準パラメータを決める

まずは、環境内で使う標準値を決めておくのがおすすめです。

たとえば以下のような形です。

標準設定

contextLength: 16384

maxTokens: 4096

KLiP や AI-Web など、複数のクライアントがある場合も、できるだけこの値にそろえて運用します。

2. 高コンテキスト設定は通常運用にしない

contextLengthに大きな値を設定するのはたしかに便利ですが、そのぶん VRAM を圧迫しやすく、再ロードやモデル切り替えの原因にもなります。

常用設定ではなく、本当に必要なケースだけで使うのが安全です。

3. 同時に使うモデル構成は先に決めておく

共有 GPU 環境では、あとから場当たり的にモデルを追加すると、VRAM 不足で既存モデルが外されることがあります。

そのため、どのモデルを同時に使うか、そのとき必要 VRAM がどれくらいか は、先に見積もっておくのがおすすめです。

4. 長いセッションは重くなる前提で考える

設定値が同じでも、対話履歴、添付ファイル、RAG の追加文脈などが積み上がると、後半になるほど重くなります。

長めのセッションでは、次のような運用を前提にしてください。

会話が長くなったら新しいセッションに切り替える
必要な履歴だけを要約して引き継ぐ
不要な添付文脈を減らす

5. 同時ロード数を増やすときは VRAM とセットで考える

shasta では MAX_LOADED_MODELS で同時ロード数を調整できます。

設定ファイル:

/etc/systemd/system/shasta.service

変更例:

MAX_LOADED_MODELS=3

反映:

sudo systemctl daemon-reload
sudo systemctl restart shasta

ただし、設定だけ増やしても VRAM が足りなければ意味がありません。

「何個まで載せるか」ではなく、「本当に載るだけの VRAM があるか」まで含めて考える必要があります。

6. 性能問題が出たら、まずロード状況を見る

体感だけで「Shasta が重い」と判断するのではなく、まず現在のロード状況やメモリの使い方を確認するのがおすすめです。

特に次のようなときは、モデル再ロードや VRAM 不足を疑ってください。

急に最初の応答が遅くなった
同じモデルなのにタイミングによって速さが違う
セッション後半だけ重い
共有環境で誰かが高負荷設定を使っている

まとめ

shasta は、クライアントから渡される contextLength や maxTokens に応じて、必要な VRAM を確保してモデルをロードします。

そのため、同じモデルでも設定値が違えば再ロードが発生し、最初の応答までの待ち時間が増えることがあります。

さらに、VRAM に収まらない新しい要求が来た場合は、いまロード済みのモデルを外して、新しい要求を優先することがあります。

共有環境ではこの影響が他ユーザにも及ぶため、モデル構成と VRAM 設計はかなり重要です。

また、実際の性能は設定値だけではなく、対話履歴、添付文脈、RAG による追加情報など、セッション内の実際の入力総量にも左右されます。

安定運用のためには、次の方針を基本にするのがおすすめです。

クライアント間でパラメータセットをできるだけそろえる
高コンテキスト設定は必要なときだけ使う
同時稼働モデル数と VRAM 総量を先に見積もる
長期セッションでは履歴肥大化も前提にする

すぐ確認したいときのチェックポイント

contextLength / maxTokens がクライアントごとにばらついていないか
高負荷設定が常用されていないか
共有環境で想定以上のモデルが同時に動いていないか
セッション履歴や添付文脈が肥大化していないか
モデル再ロードが頻発していないか