AntigravityでLM Studioの応答が途中で途切れる問題の診断と解決法

LM Studio の接続設定を終えて「さあ使えるぞ」と思ったら、長い指示を出すたびに応答が途中でぷつりと途切れる。短いコードの質問は通るのに、リファクタリングを頼むと 50% くらいのところで沈黙します。こういう症状は、接続のセットアップ自体に問題はなくて、ストリーミングの維持に関わる設定が不足しているケースがほとんどです。

私自身も Gemma 4 を LM Studio で動かしながら Antigravity と連携させていたとき、この問題に何度かぶつかりました。「接続できない」系のトラブルシューティングはよく検索で出てきますが、「接続はできているのに途中で切れる」という症状に絞った情報が少なかったので、ここにまとめておきます。

なお、接続そのものが確立できないという場合は、先に LM Studioモデルが認識されない場合の接続確認ガイドをご覧ください。Ollama を使っている方は Ollamaの応答が途中で途切れる問題を直す実践ガイドが参考になります。

「接続エラー」と「途中切断」は別の問題として切り分ける

まず症状を正確に把握しておきましょう。LM Studio 連携のトラブルは大きく3つの層に分けられます。

接続層（ポート・ファイアウォール）は、LM Studio のローカルサーバーに Antigravity が到達できるかどうかです。http://localhost:1234/v1/models にブラウザでアクセスしてモデル一覧が返ってくれば、この層は問題ありません。

モデルロード層（VRAM・メモリ）は、モデルが正常にロードされて短い応答を返せるかどうかです。LM Studio の「Server」タブで短いプロンプトを試して、一文字ずつ流れるように表示されれば問題なしです。

ストリーミング維持層は、長時間の生成中に接続が保たれるかどうかです。今回扱うのはここです。短い指示は通るが長い指示で途中切断される、30 秒以上かかる生成が失敗するという症状が典型的です。

原因1: LM Studio のストリーミングタイムアウト設定

LM Studio の Local Server には、長時間のストリーミング生成に関するタイムアウト設定があります。デフォルトでは短めに設定されている場合があり、複数ファイルを参照しながらのリファクタリング指示などで上限に引っかかりやすくなっています。

確認・変更手順:

LM Studio を開き、左側の「Local Server」タブを選択します。サーバーが起動している状態で「Server Options」（歯車アイコン）を開き、以下の項目を確認してください。

// LM Studio の詳細設定（lm_studio_settings.json の参考値）
// ※ 実際の設定はLM StudioのUIから変更します
{
  "server": {
    "request_timeout": 300,      // デフォルト60秒→300秒に延長
    "stream_timeout": 0,         // 0 = タイムアウトなし
    "max_context_length": 8192   // モデルのコンテキスト長に合わせる
  }
}

設定変更後は LM Studio のサーバーを一度停止して再起動します。Antigravity 側でも接続をリセット（Settings → Local LLM → 接続解除 → 再接続）するとより確実です。

これだけで症状が改善するケースが一番多いです。まずここを試してみてください。

原因2: コンテキスト長の設定が不足している

LM Studio でモデルをロードするとき、コンテキスト長（Context Length）の設定に注意が必要です。デフォルトで 2048 や 4096 になっているモデルが多く、Antigravity から複数ファイルの内容を渡しながら指示を出すと入力だけで上限を超えてしまいます。コンテキストが満杯になると、その時点で出力が強制終了されます。

確認・変更手順:

LM Studio の「My Models」から使用しているモデルを選択し、「Load Model」画面の詳細設定を開きます。

Context Length の設定例（Gemma 4 8B の場合）:
  デフォルト: 2048 または 4096
  推奨: 8192 〜 32768
  ※ VRAM に余裕がある場合は 32768 を設定すると余裕ができます

GPU Layers:
  -1（すべてオフロード）にするとコンテキスト処理が速くなりますが、
  VRAMが不足している場合は部分オフロード（例: 30/40 layers）に調整します

変更後はモデルを一度アンロードして再ロードしてください。LM Studio の右下のメモリ使用量が増えていれば、コンテキスト長が実際に拡張されています。

原因3: VRAM 不足による生成速度の低下

VRAM が不足している状態では、トークンの生成速度が著しく低下します。tokens/s が 1 を下回るような極端な状態になると、Antigravity 側のタイムアウトが先に到達して接続が切れることがあります。

LM Studio のサーバーログ（「Server」タブ → 「Logs」）を見ながら Antigravity から指示を出してみてください。

# LM Studio のログに表示される生成速度の例
# 問題ない場合
[INFO] eval time = 2341 ms / 128 tokens (18.3 ms per token, 54.7 tokens/s)
 
# VRAMが不足して遅くなっている場合
[INFO] eval time = 89420 ms / 128 tokens (698.6 ms per token, 1.4 tokens/s)

1 tokens/s を下回っている場合は、モデルサイズを一段落とすか（例: 27B → 12B）、GPU Layers の割り当てを見直すことをまず検討してください。

量子化レベルも重要です。同じモデルでも Q8_0 より Q4_K_M のほうが VRAM 消費が半分程度になり、速度も上がります。応答品質を保ちながら速度を確保したい場合は Q4_K_M か Q5_K_M がバランスのいい選択肢です。

量子化レベル別のメモリ使用量の目安（Gemma 4 12B の例）:
  Q8_0:   約 13.5 GB（最高品質・最大メモリ）
  Q5_K_M: 約  9.0 GB（バランス型・推奨）
  Q4_K_M: 約  7.5 GB（省メモリ・実用品質）
  Q3_K_M: 約  6.0 GB（最小構成・品質低下あり）

原因4: Antigravity 側のストリーミング受信タイムアウト

上記3つの設定を試してもまだ途切れる場合、Antigravity 側のタイムアウト設定を調整する余地があります。プロジェクト設定ファイルで接続タイムアウトを延長できます。

// .antigravity/settings.json
{
  "localLLM": {
    "provider": "lm-studio",
    "baseUrl": "http://localhost:1234/v1",
    "requestTimeout": 600,
    "streamTimeout": 600,
    "keepAliveInterval": 30
  }
}

requestTimeout と streamTimeout をそれぞれ秒単位で指定します。600（10分）はやや長めですが、数千行のリファクタリングを一度に依頼するようなケースでは必要になることがあります。

keepAliveInterval は 30 秒ごとにキープアライブの信号を送る設定で、ネットワーク層での非活性切断を防ぎます。同一マシン内の通信でも、Antigravity の HTTP クライアントがアイドル判定して接続を閉じるケースがあるため、明示的に設定しておくと安定性が上がります。

診断を進める順番

まとめると、確認する順番はこの通りです。

まず LM Studio サーバーのタイムアウト設定（原因1）を確認します。デフォルトのまま使っていた場合はここで改善するケースが多いです。次に コンテキスト長（原因2）を確認します。短い指示では通るが長い指示で切れる場合、コンテキスト超過の可能性が高いです。次に LM Studio のログで生成速度（原因3）を確認して、VRAM 不足がないか見ます。これらを試してもまだ症状が続くなら、Antigravity 側の設定（原因4）を調整します。

プロジェクトの規模が大きくなると複数の原因が重なることもあります。一つ変えてはテストする、という地道な手順が遠回りなようで実は一番早いです。

LM Studio でのローカル LLM 活用の設定全般についてはローカルLLM設定の基本ガイドでまとめていますので、あわせてご覧いただければ幸いです。