これは一体どんなモデルなのか

LiveKit がどう最適化したかを話す前に、まず Gemma 4 自体を知っておきましょう。これは Google DeepMind が今年発表したオープンソースモデルファミリーで、「オープンウェイト」路線を採っています。重みが公開されており、緩やかな Apache 2.0 ライセンスの下で誰でもダウンロードして使え、自分のマシン上でローカル実行することも可能です。クラウド API を必ず経由する必要はありません。

LiveKit が今回選んだのはこの 31B クラスです。ファミリーの中で最も高性能でありながら、扱いに困るほど大きくもなく、サーバー上で音声 Agent 用に稼働させるのにちょうど良いサイズです。これ以降に挙げる数字はすべて、この 31B クラスを LiveKit プラットフォーム上で動かして得たものです。

速くて、安くて、賢い

LiveKit は Gemma 4 31B を、市場の主要な商用大規模モデルと並べて比較しました。相手は GPT-4.1、GPT-4.1 mini、Gemini 2.5 Flash です。結論はシンプルに「速い・安い・賢い」の3点。順番に見ていきましょう。

⚡速さ：応答はほぼ即レス

テキストチャットなら、AI が2秒考えてから返してきても誰も気にしません。しかし電話となると話は別です。話し終えた瞬間、相手の沈黙が0.5秒を超えると違和感を覚え、1秒を超えると会話がいかにも不自然になってしまいます。この「どれだけ速く話し出すか」を測る指標が「ファーストトークン遅延」で、話し終えてからモデルが最初の一語を出すまでの待ち時間を指します。Gemma 4 31B はわずか192ミリ秒、GPT-4.1 は1006ミリ秒。この800ミリ秒あまりの差が、「即レス」と「気まずい沈黙」を分ける境界線と言っていいでしょう。

💰コスト：2割にも満たない出費

コスト面は実際の価格で見てみましょう。大規模モデルは token（おおむね文字・単語に対応）単位で課金され、入力と出力で価格が分かれます。以下は100万 token あたりの公式価格（米ドル）です。

GPT-4.1 と比較すると、入力価格は5分の1（0.4ドル対2ドル）、出力価格は7分の1未満（1.2ドル対8ドル）です。音声シナリオでよくある入力対出力 3:1 の混合比率で計算すると、総合コストはおよそ GPT-4.1 の6分の1、つまり約83%安くなります。同じく低価格を売りにしている GPT-4.1 mini と比べても、出力価格はさらに低いのです。24時間365日電話を受け続け、使用量に応じて費用がかさむ音声サービスにとって、これはかなりの節約になります。

🧠賢さ：安くて速いのに、鈍くはなっていない

安くて速いとなると、誰もが気になるのは「その分、性能が落ちていないか」でしょう。LiveKit は性能をいくつかの項目に分けてスコアリングしており、使用したのは同じ「ホテルフロント」リファレンス評価です。結果はほぼ全項目で満点近く。ツール呼び出し・複数ターンにわたる会話の一貫性・情報の正確性はすべて満点、指示遵守は98点、簡潔さは96点、総合のタスク完了率は88点でした。音声アシスタントにとって、手順通りに一つずつ業務をこなし、それまでの会話内容を覚えておく能力は、まさにこれらの項目にかかっています。

速さ・コスト・賢さの3項目を一つの表にまとめると、Gemma 4 31B の行はすべてでトップを取っています——遅延が最も短く、コストが最も低く、性能スコアが最も高い。リアルタイム音声というシナリオにおいては、この中で最もコストパフォーマンスの高い選択と言えます。

同じモデルなのに、なぜ LiveKit 上ではより速いのか

同じ Gemma 4 31B でも、稼働させるプラットフォームが違えば速度は数倍も変わります。LiveKit いわく、これは意図的に選んだ路線であり、アーキテクチャもハードウェアも「速さ」を追求して最適化したとのことです。

ハードウェア面では、LiveKit は同一データセンター内にホスティングされた専用 GPU を使用しており、モデルと計算リソースを近接配置することで迂回を減らしています。計測結果では、話し終えてから最初の返答が聞こえるまで、LiveKit はわずか354ミリ秒。一方、OpenRouter のような複数プロバイダー間で転送する従来型ルーティングでは1876ミリ秒かかります。1秒あたりの生成文字数も天と地ほどの差があります——158 対 33 です。

補足しておくと、OpenRouter はリクエストを複数の第三者プロバイダー間で転送する仕組みのため、遅延や可用性はルートによって変動します。ここで挙げた数値は、テスト時に選択できた最適な Gemma 4 31B ルートによるものです。

コード1行の変更だけで切り替え完了

導入は非常に手軽です。すでに LiveKit Agents で音声 Agent を構築している場合、Gemma 4 31B に切り替えるには設定を1行追加し、モデルを指定するだけ。それだけで LiveKit の GPU 計算リソースをそのまま利用できます。

# Gemma 4 31B，跑在 LiveKit 自己的 GPU 上
from livekit.agents import AgentSession

session = AgentSession(
    llm="google/gemma-4-31b-it",
)

これらの数字がどこまで信頼できるか、LiveKit は測定基準も明らかにしています。ページ上のすべての数値は、同一のオープンソース「ホテルフロント」リファレンス Agent（GitHub 上で公開）を使い、同一の評価フロー、同一の遅延定義に基づき、実際の音声通話を想定した方法で計測されたものです。ファーストトークン遅延は各シナリオ・各対話ターンごとに繰り返しサンプリングされ、性能スコアはタスク形式の採点を伴う同一の対話セットを使用しています。比較対象は GPT-4.1、GPT-4.1 mini、Gemini 2.5 Flash。これらはすべて LiveKit 側が提供したデータであり、最終的には公式ページの内容が基準となります。

LiveKit は音声 AI を手がける企業です。今回、Google のオープンソースモデル Gemma 4 31B（オープンソース＝重みが公開されており誰でも無料で利用できる）を自社プラットフォームに載せ、音声向けに専用チューニングを施しました。狙いは音声 Agent の新しいデフォルトの頭脳になることです。同じ質問を投げても、応答までの待ち時間は1秒台から200ミリ秒以内に短縮され、コストはわずか6分の1。導入もコード1行の変更だけで済みます。

しかし同じ Gemma でも、稼働させるプラットフォームが変われば速度は数倍も変わります。速さの鍵はモデル自体ではなく、どこで・どう動かすかにあるのです。

同じ Gemma 4 31B なのに、なぜ LiveKit 上ではより速いのか。差は「動かし方」にあります。小互が LiveKit ホテルに電話をかけて予約を申し込み、「部屋を1室予約したいのですが」と言い終えた瞬間、2つのルートでは応答速度がまったく違ってきます。

音声シナリオにおける現在のデフォルトモデル GPT-4.1 と並べてみると、最も体感しやすいのは「応答までの待ち時間」です。同じ質問を投げても、片方はほぼ即レス、もう片方は明らかに間が空いてしまいます。