LLM Models Overview
参照元: LiveKit Agents Documentation ロードマップ: 学習ロードマップ
What(何についてか)
LLMはボイスエージェントの推論・応答生成・ツールオーケストレーションを担う中核コンポーネント。LiveKitではInference経由とPlugin経由の2つの利用経路を提供し、AgentSession内外の両方で実行できる。
Why(なぜ必要か)
ユースケースごとに、レイテンシ・精度・コスト・運用負荷の最適点は異なる。InferenceとPluginの選択、モデルパラメータ設計、ツール連携方式(ストリーミング vs collect)を理解しないと、プロダクション運用で不安定になりやすい。
How(どう動くか)
Inferenceモデル
Inference経由でDeepSeek、Gemini、Kimi、OpenAI、QwenのLLM群を利用できる。OpenAI系列ではGPT-4.1/4o/5.x系まで幅広く提供される。Retiredモデルは利用不可で、現行モデルへ移行が必要。
Pluginモデル
PluginはInference未対応モデル、fine-tunedモデル、独自運用を行いたい場合に有効。API key・課金・レート制限は利用者側で管理する。主要プロバイダー(OpenAI、Gemini、Groq、Cerebras、DeepSeek、xAI、Ollama等)はPython/Node.jsの両方をカバーする。
AgentSessionでの利用
from livekit.agents import AgentSession, inference
session = AgentSession(
llm=inference.LLM(model="openai/gpt-4.1-mini"),
)追加パラメータは extra_kwargs(Python)/ modelOptions(Node.js)で指定する。
Inference LLM parameters の要点
- 未対応パラメータはエラーではなく無視される。
- reasoningモデルでは一部パラメータが自動除去される。
max_tokensは旧式で、max_completion_tokensが推奨。- 代表的な制御項目:
- 生成特性:
temperature,top_p,verbosity - 長さ制御:
max_completion_tokens - 推論強度:
reasoning_effort - ツール制御:
tool_choice,parallel_tool_calls - 運用:
metadata,prompt_cache_key,safety_identifier
- 生成特性:
Standalone usage と collect()
AgentSession外でLLMを使う場合、llm.chat() は ChatChunk ストリームを返す。Pythonでは collect() を使うと、ストリーム全体を集約して text / tool_calls / usage をまとめて取得できる。
collect() が自動でツールを実行しないのは設計上の分離による。LLMは「どのツールを呼ぶか」を決めるだけで、実行(副作用)はアプリ側が担う。これにより権限管理、監査、リトライ、タイムアウト制御をアプリ側で明示的に実装できる。
典型フローは以下。
- 1回目
collect()で tool_calls を取得 - アプリがツールを実行
- ツール結果を
ChatContextに挿入 - 2回目
collect()で最終応答を生成
Vision
LLMは画像URLおよびリアルタイム動画フレーム入力に対応可能。具体的な入力制約(形式・サイズ等)はモデル側仕様に依存する。
graph TD A["User speech"] --> B["STT"] B --> C["LLM"] C --> D["TTS"] C --> E{"Tool needed?"} E -->|"Yes"| F["collect() returns tool_calls"] F --> G["App executes tools"] G --> H["Insert tool results into ChatContext"] H --> I["collect() for final answer"] E -->|"No"| I
Key Concepts
| 用語 | 説明 |
|---|---|
| inference.LLM | LiveKit Inference経由でLLMを利用するクラス |
| extra_kwargs / modelOptions | モデルパラメータ指定ポイント |
| collect() | Pythonでストリーム結果を集約し、text/tool_calls/usageを返すAPI |
| tool_calls | LLMが要求するツール実行計画 |
| reasoning_effort | reasoningモデル向けの推論強度制御 |
実装時の判断軸
まずInferenceで構築し、未対応要件が出たらPluginへ拡張するのが運用コスト面で有利。collect() はバックグラウンド処理やツール実行型ワークフローで有効。リアルタイム逐次表示が必要なUIでは、collectよりチャンクストリーム処理を優先する。