PhoneLLM Alpha 1の仕様で最も誤解しやすいのが「30B total parameters、3.5B active」という表現です。
1トークンを処理するときに使われるパラメータが約3.5Bなら、24GB GPUでも余裕で動くように見えるかもしれません。
しかしMoEモデルでは、推論時に一部のエキスパートだけを使うことと、モデル全体の重みを保持することは別問題です。
PhoneLLM Alpha 1のBF16チェックポイントは30B級の重みを持つため、3.5Bの一般的なdenseモデルと同じVRAM感覚では扱えません。
さらに電話AIでは、LLMだけがGPUを使うわけではありません。
音声認識（ASR）、音声合成（TTS）、同時会話のKVキャッシュ、ランタイムの作業領域まで考える必要があります。
本記事では「起動できる可能性」と「安定して電話AIとして運用できる構成」を分けて整理します。
PhoneLLM Alpha 1はPipecatチームが公開した、voice agent用途を狙うオープンウェイトモデルです。
ベースはNVIDIA Nemotron 3 Nano 30B-A3B。Hybrid Mamba-TransformerのMixture-of-Experts構成で、総パラメータは30B、1トークンあたりのactive parameterは3.5Bとされています。
公式モデルカードではコンテキスト長262,144トークン、BF16 safetensors、推奨設定はtemperature=0、thinking disabled。
サービングはvLLMまたはSGLangが案内され、言語はEnglishと明記されています。
一般的なチャット用途より、低遅延のmulti-turn agentic workloadを意識したモデルです。
そのため評価するときも、知識量だけでなく初動、ツール呼び出し、会話継続、同時接続時の遅延を見る必要があります。
briefでは「32Bモデル」と表現されていますが、現行の公式モデルカードは30B total parametersとしています。
記事では一次情報に合わせて30Bとします。
MoEは複数のエキスパートから入力ごとに必要な一部を選ぶ方式です。
計算量はactive parameter数に近づけられる一方、通常は全エキスパートの重みをどこかに保持する必要があります。
したがって「3.5B activeだから3.5Bモデルと同じVRAM」という計算にはなりません。
この違いはGPU購入判断で特に重要です。
RTX 4090など24GB GPUで推論したい場合、BF16全重みをGPU 1枚へ載せる前提は成立しません。
量子化、CPUオフロード、複数GPUなど別の方法が必要になります。
PhoneLLM Alpha 1にはBF16版に加え、公式NVFP4チェックポイントが公開されています。
NVFP4は重みを大きく圧縮できるため、VRAM要求を下げる方向では有効ですが、対応ハードウェアとランタイムを確認しなければなりません。
公式NVFP4モデルカードはBlackwell GPU向けで、tested native vLLM recipeとしてNVIDIA B200 1基を示しています。
つまり「NVFP4ならRTX 4090の24GBで公式に動作保証」と読むことはできません。
RTX 5090もBlackwell世代ですが、データセンター向けB200と同じ条件とは限らず、vLLM側の対応と実測確認が必要です。
GPU容量別の判断では、断定より「どの精度・どのオフロード・どの同時接続を想定するか」を先に決めます。
ここで24GBの可否を「動く／動かない」の二択にしない理由は、CPUオフロードや量子化によって起動できる構成があり得る一方、PhoneLLMが狙う低遅延voice agentでは速度低下が致命的になり得るからです。
チャットで1リクエスト返せることと、電話で自然なターンテイキングを維持できることは別の合格条件です。
音声AIの構成は、ユーザー音声を文字へ変換するASR、応答を作るLLM、文章を音声へ変えるTTSの3層が基本です。
これらを同一GPUへ載せれば、PhoneLLM本体以外のVRAMも消費します。
PoCではASRやTTSをクラウドAPIへ逃がし、GPUをPhoneLLMへ集中させる方法があります。
逆にデータを外部へ出したくない場合は、ASR・TTSもセルフホストするため、GPUを分離するか、より大きなVRAMを用意する設計が必要です。
同時接続が増えるとKVキャッシュやバッチ処理の余裕も必要です。
1通話で動いた構成を、そのまま10通話へ比例させることはできません。
実運用ではP50だけでなくP95の初動遅延、通話中の割り込み、ツール呼び出し時の待ち時間まで測るべきです。
公式モデルカードにはvLLMとSGLangの起動方法が掲載されています。
vLLMではモデル名を指定してserveし、OpenAI互換APIとして呼び出せます。
SGLangも同様にサーバーを立ち上げ、HTTP経由で利用できます。
初回検証では、公式推奨どおりtemperature=0、thinking disabledから始めるのが妥当です。
電話AIは深い思考より応答速度と指示追従が優先される場面が多く、thinkingを有効にすると待ち時間が増える可能性があります。
検証項目は
①モデルロード時のVRAM
②1接続時の初動
③長い会話後のVRAM
④ツール呼び出し成功率
⑤同時2・4・8接続時のP95
⑥ASR/TTSを加えた総遅延
上記の順に増やすと原因を切り分けやすくなります。
24GB GPUで試す場合、まず「公式BF16をそのまま1枚へ全載せ」は除外し、対応する量子化とランタイムを確認してください。
NVFP4についてはGPU世代の対応を必ず確認し、B200向け公式レシピをGeForceへそのまま転用できると考えないことが重要です。
PhoneLLM Alpha 1の公式モデルカードはLanguageをEnglishとしています。
日本語テキストが偶然処理できる可能性と、日本語電話AIとして品質が保証されることは別です。
日本語用途では、固有名詞、数字、日時、敬語、割り込み、住所、電話番号などを独自に評価する必要があります。
ライセンス表示はBSD 2-Clauseですが、モデルはNVIDIA Nemotron 3 Nano 30B-A3Bの派生です。
リポジトリにはNVIDIA Nemotron Open Model Licenseの文書も同梱されています。
商用サービスへ組み込む際は、PhoneLLM側のライセンスだけでなく上流モデルの条件、再配布、表示義務、利用するASR/TTSの条件まで確認してください。
セルフホストはデータ管理を自社側へ寄せられる利点がありますが、それだけで安全になるわけではありません。
録音データ、文字起こし、ログ、個人情報、保持期間、アクセス権限を別途設計する必要があります。
PhoneLLM Alpha 1を24GB GPUで検討するとき、最初に見るべき数字は3.5B activeではありません。
30B総パラメータの重みをどの精度で保持し、KVキャッシュと音声スタックにどれだけ余白を残せるかが判断の中心です。
BF16版を24GB単体GPUへ全載せする構成は現実的ではありません。
公式NVFP4は軽量化の選択肢ですが、Blackwell向けで、公式テスト済みレシピはB200です。
GeForce 24〜32GBでの実用性は、対応ランタイムと実測を確認して初めて判断できます。
PoCではASR・TTSを別サービスへ分離し、まずPhoneLLM単体の遅延とVRAMを測る。
本番では同時接続、KVキャッシュ、ASR/TTS、ログ管理まで加えて再評価する。この二段階で考えると、必要GPUを過小評価しにくくなります。
.png){kind=logo}
