AI Tutorial on KnightLiブログ

LMCache 実用ガイド：vLLM 推論サービスで KV Cache を再利用する

Thu, 25 Jun 2026 09:14:41 +0800

LMCache は LLM 推論でよくある問題を扱います。多くのリクエストは prompt の前半が重複しているのに、サーバーは毎回 prefill を再計算し、GPU 時間を浪費します。

長いシステムプロンプト、RAG テンプレート、複数ターン会話、Agent のツール説明、固定知識コンテキストがあるなら、LMCache は検討する価値があります。主な狙いは repeated prefill を減らし、TTFT を下げることです。

`1`	`https://github.com/LMCache/LMCache`

`1`	`https://docs.lmcache.ai/`

必要かどうか

LMCache は、長い prompt、大きな共通 prefix、RAG の反復、長い会話履歴、長い Agent ツール説明、複数 vLLM インスタンスの共有キャッシュに向いています。短いリクエストや共通 prefix が少ない workload では効果が小さい場合があります。

vLLM MP モードから始める

MP モード：LMCache を独立サービスとして動かし、vLLM が LMCacheMPConnector で接続する。
In-process モード：LMCache を vLLM プロセス内で動かす。

実用上は MP モードがおすすめです。管理、観測、複数インスタンス共有がしやすくなります。

インストール

1
2
3

uv venv --python 3.12
source .venv/bin/activate
uv pip install lmcache vllm

または：

1
2
3

python -m venv .venv
source .venv/bin/activate
pip install lmcache vllm

本番では vLLM、LMCache、connector のバージョン互換性を確認します。

LMCache を起動する

`1`	`lmcache server --l1-size-gb 20 --eviction-policy LRU --chunk-size 16`

--chunk-size 16 はデモ向けです。本番では通常 256 などのデフォルト値を使います。デフォルトポートは ZMQ 5555、HTTP 管理とメトリクス 8080 です。

vLLM を接続する

`1`	`vllm serve Qwen/Qwen3-8B --port 8000 --kv-transfer-config '{"kv_connector":"LMCacheMPConnector", "kv_role":"kv_both"}'`

vLLM 0.20.0 以降では次のように LMCache 側 connector を明示できます。

`1`	`vllm serve Qwen/Qwen3-8B --port 8000 --kv-transfer-config '{"kv_connector":"LMCacheMPConnector", "kv_connector_module_path":"lmcache.integration.vllm.lmcache_mp_connector", "kv_role":"kv_both"}'`

ヒットを確認する

共通 prefix を持つ 2 つのリクエストを送ります。

curl http://localhost:8000/v1/completions   -H "Content-Type: application/json"   -d '{
    "model": "Qwen/Qwen3-8B",
    "prompt": "Qwen3 is the latest generation of large language models in Qwen series, offering a comprehensive suite of dense and mixture-of-experts",
    "max_tokens": 100,
    "temperature": 0.7
  }'

curl http://localhost:8000/v1/completions   -H "Content-Type: application/json"   -d '{
    "model": "Qwen/Qwen3-8B",
    "prompt": "Qwen3 is the latest generation of large language models in Qwen series, offering a comprehensive suite of dense and mixture-of-experts (MoE) models",
    "max_tokens": 100,
    "temperature": 0.7
  }'

1 回目は Stored ... tokens、2 回目は Retrieved ... tokens が見えるはずです。

見るべき指標

hit tokens、hit ratio、キャッシュ取得元、取得時間、TTFT 改善、chunk alignment の影響を確認します。Retrieved が出るだけでは十分ではありません。

効果が出やすい場面

長いシステムプロンプト、固定 RAG テンプレート、Agent ツール説明、複数インスタンス推論サービスです。最初は CPU RAM で試し、Redis、S3、NIXL などの複雑な backend は後で検討します。

In-process モード

`1`	`LMCACHE_CHUNK_SIZE=8 vllm serve Qwen/Qwen3-8B --port 8000 --kv-transfer-config '{"kv_connector":"LMCacheConnectorV1", "kv_role":"kv_both"}'`

簡単ですが、キャッシュは vLLM プロセスに依存します。長期運用では MP モードの方が扱いやすいです。

本番前チェック

LMCache 有効/無効で TTFT を比較する。
prefill latency を単独で記録する。
prefix cache hit tokens と hit ratio を見る。
メモリ安定性を確認する。
vLLM 再起動後の挙動を見る。
並行時の ZMQ、HTTP メトリクス、ログを確認する。
demo ではなく実業務 prompt で測る。

まとめ

LMCache は、長い prompt が繰り返し現れる推論サービスに向いています。生成そのものを万能に速くするのではなく、repeated prefill を再利用可能な KV Cache に変えます。vLLM を使っているなら、まず MP モードでローカル検証し、実トラフィックで TTFT を比較しましょう。

Gemini Computer Use 入門：Gemini 3.5 Flash でブラウザを操作する

Thu, 25 Jun 2026 09:12:44 +0800

Gemini API の Computer Use は、モデルが回答するだけでなく、画面を見て、どこをクリックするか、何を入力するかを判断し、その操作をクライアント側のコードに渡す機能です。

ブラウザ自動化 Agent、Web フローのテスト、繰り返しフォーム入力、ページ情報の整理などに向いています。ただし、モデルが直接ブラウザを操作するわけではありません。モデルは操作を提案し、実行、スクリーンショット返送、停止制御はクライアント側が担当します。

公式ドキュメント：

`1`	`https://ai.google.dev/gemini-api/docs/computer-use?hl=zh-cn`

仕組み

タスク、ツール設定、現在の画面状態を Gemini に送る。
Gemini がクリック、入力、スクロール、ページを開くなどの操作を返す。
Playwright などでその操作を実行する。
新しいスクリーンショットを撮って Gemini に返す。
完了、安全確認、または停止条件まで繰り返す。

推奨モデルは gemini-3.5-flash です。Interactions API の tools に次を指定します。

{
  "type": "computer_use",
  "environment": "browser"
}

Python の最小例

1
2

pip install google-genai playwright
playwright install chromium

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    model="gemini-3.5-flash",
    input="Search for 'Gemini API' on Google.",
    tools=[
        {
            "type": "computer_use",
            "environment": "browser",
            "enable_prompt_injection_detection": True,
        }
    ],
)

print(interaction)

enable_prompt_injection_detection は有効にしておくのがおすすめです。Web ページ内に敵対的な指示文が含まれる可能性があるためです。

Playwright で実行する

from playwright.sync_api import sync_playwright

SCREEN_WIDTH = 1440
SCREEN_HEIGHT = 900

playwright = sync_playwright().start()
browser = playwright.chromium.launch(headless=False)

context = browser.new_context(
    viewport={"width": SCREEN_WIDTH, "height": SCREEN_HEIGHT}
)
page = context.new_page()
page.goto("https://www.google.com")

座標は正規化されていることが多いため、実際の画面座標に変換します。

def denormalize_x(x: int, screen_width: int) -> int:
    return int(x / 1000 * screen_width)


def denormalize_y(y: int, screen_height: int) -> int:
    return int(y / 1000 * screen_height)

モデルが返した function_call を実行し、実行後にスクリーンショットを返します。難しいのは最初の API 呼び出しではなく、このループを安定させることです。

小さく始める

最初は実アカウントや本番画面を避け、検索、ローカルテストページ、フォーム検証など低リスクなタスクにします。各ステップの intent を確認し、モデルの判断が妥当かを見ます。

安全境界

サンドボックス化したブラウザ、コンテナ、VM を使う。
履歴、自動入力、保存済みパスワードへのアクセスを禁止する。
ログイン、支払い、投稿、メッセージ送信、規約同意ではユーザー確認を必須にする。
CAPTCHA や人間確認を回避させない。
許可リストまたは禁止リストを用意する。
プロンプト、スクリーンショット、操作、安全判断、実行ログを残す。

Function Calling との違い

Function Calling はモデルが API を選び、構造化パラメータを埋める仕組みです。Computer Use は実際の UI を見て操作します。安定した API があるなら Function Calling を優先し、画面操作が必要な場合に Computer Use を使います。

よくある落とし穴

モデルが自分でブラウザを操作すると思い込む。
座標変換を忘れる。
ポップアップや Cookie バナーがある状態から始める。
最大ステップ数や停止条件を入れない。
金融、医療、アカウント安全など重要な判断に使う。

実用的な構成

agent/
  client.py
  browser.py
  actions.py
  safety.py
  recorder.py
  prompts.py

API 呼び出し、UI 実行、安全ポリシーを分けておくと、後でブラウザ以外の環境にも広げやすくなります。

まとめ

Gemini Computer Use は、固定スクリプトだったブラウザ自動化を、画面状態に応じて次の操作を決める形へ近づけます。使うなら、実行環境を固定し、操作ループを安定させ、安全ルールを先に置くことが重要です。