Rachel Lee Nabors / レイチェル・リー・ネイバーズ · 02:40 「トークン単価は最近下がってきた。 それなのに総推論コストは上がっている。 agentic と reasoning のワークロードが、 値下がりよりずっと速くトークンを食うからだ」
出発点は 「既定でフロンティアモデルに手を伸ばす」 という習慣への疑いだ。 GPT-5 や Claude のような foundation model を呼ぶたび、 セキュリティ・レイテンシ・費用・環境にコストがかかる。 Rachel Lee はこれを 「one-size-fits-all inference (万能一律の推論)」 と呼び、 4 つのコストに分解する。 セキュリティ (データをリモートサーバーに送る = 露出・傍受・保持のリスク)、 レイテンシ (VR チャットの研究で 「信じられる応答の限界は 4 秒」、 大型モデルはしばしばそれを超える)、 ビジネス (第三者の推論費は API 料金と違って制御できない)、 オフライン (接続が切れれば誰も使えない)。 そして冒頭の逆説 — トークン単価は下がっているのに総額は上がる。
処方箋は task-specific model 1 つのタスクに特化した小型モデル。 カメラ入力ならビジョン系 (MobileNet / YOLO / MediaPipe)、 マイク入力なら音声系 (Whisper 等)、 チャット・翻訳・分析なら小型言語モデルを充てる。 foundation model に比べサイズも消費電力もはるかに小さい と SLM Small (Smaller) Language Model。 数百万〜数十億パラメータの小型言語モデル。 LLM の数千億〜数兆に対して桁が小さく、 量子化すれば端末に載る。 Gemma や Qwen が代表例 だ。 大半の用途は 「チャットスレッドの要約」 や 「この人は今おこっているか判定」 程度で、 人類の知識を全部積んだ黒い箱は要らない。 歴史も哲学も Reddit の雑談も積んだ LLM をそこに走らせるのは、 近所へ買い物に行くのに大型トラックを出すようなものだ。 その代わりに Rachel Lee が掲げる合言葉が prototype big, deploy small Rachel Lee の設計指針。 試作は foundation model で大きくやってよいが、 本番はシステムの各部を SLM や特化モデルに置き換えて小さく出す。 「大きく試して、 小さく出荷する」 — 大きく試作して、 小さく出荷する。
着眼点
one-size-fits-all inference の 4 つのコスト — トークンが安くなっても総額は膨らむ (01:14 - 03:01)
この講演の土台は、 「安いから」 でフロンティアモデルを常用する判断への反証だ。 Rachel Lee は 4 つのコストを 1 行ずつ立てる。 セキュリティは信頼のコスト — クラウドの大型 LLM にデータを送ることは、 第三者による露出・傍受・保持のリスクを常に抱える。 レイテンシは体験のコスト — 応答が信じられる限界は 4 秒という研究があり、 大型モデルへの呼び出しはしばしばそれを超える。 エレベーターのボタンを押して 4 秒何も起きないと、 人はもう一度押したくなる、 あの間だ。 ビジネスは制御のコスト — 第三者の推論費は自前の API 費用と違って手綱を握れない。 オフラインは可用性のコスト — 接続が切れれば、 web につながっていないソフトは誰にも使えない。
そのうえで数字の逆説が効く。 トークン単価は下がってきたのに、 総推論コストは上がっている。 理由は、 agentic と reasoning のワークロードが値下がりよりずっと速くトークンを食うからだ。 だから問いはこうなる — 「これは本当に LLM が要る仕事なのか?」。 エネルギーの目安として、 同じタスクを LLM が消費する量を 100 とすると、 SLM は約 25、 特化モデルはさらにその半分ほどで済む、 という研究も引かれる。 NVIDIA は SLM を 「agentic AI の未来」 と呼んでいる、 と Rachel Lee は添える。
right-sizing の 4 ステップ — Mima の要約で Llama 3.2 3B が Claude Sonnet に肉薄する (08:52 - 16:16)
講演の背骨は 「モデルを right-size する」 4 ステップだ。 (1) 可能性を証明する — 最大のモデルで 「そもそもこのタスクは成立するか」 を確かめる。 (2) 成功を定義する — 入力と、 見たい出力の組を集めて golden dataset 人手でラベル付けした高品質な入力・出力ペアの集合。 モデルを評価・検証・ベンチマークするための ground truth (正解) として使う。 テストの模範解答を先に用意しておくイメージ にする。 これがテストの模範解答になる。 (3) 小さい方から大きい方へ試す — 各モデルの出力を模範解答と照らし、 十分な範囲に入る最小モデルを探す。 (4) その最小モデルを選ぶ。 Rachel Lee はこの最小で十分なモデルを SAGE model Rachel Lee の造語。 Small And Good Enough (小さくて十分) の頭字語。 用途に対して受容できる応答を返す、 最小のモデルを指す (small and good enough) と名付けようとしている。
実例が Mima のスレッド要約だ。 まず Claude で試作して 「十分に良い」 を証明し、 14 スレッド分の要約 (参照付きと無しの 2 種で 28 例) を golden dataset として書き出す。 測る軸は JSON の妥当性・参照の構造妥当性・事実整合性・長さ順守・レイテンシ (中央値 P50 と最悪値 P95)。 基準線の capability eval 「このモデルは何を上手くできるか」 を問う評価。 大型モデルの出力と、 複数の小型モデルの出力を同じ課題で突き合わせる。 Phoenix で実行する を Phoenix で回すと、 Claude Sonnet は精度は高いが少し遅く (レイテンシ約 3 秒)、 自分 1 人で 1 日およそ 1 ドルの推論費がかかる。 1 日 1 ドルは年 365 ドル (約 5.5 万円)、 それがユーザー数に比例して膨らむ。 一方 on-device の小型モデルの総費用はゼロ — 推論が消費者の端末に押し出され、 電気代は端末の持ち主が払うからだ。
候補は Qwen 2.5 Instruct (15 億パラメータ、 ディスク約 1GB)、 Qwen 3 (10 億)、 Llama 3.2 (30 億、 約 2GB)、 Gemma 4 E2B (50 億、 約 3GB)。 30 億パラメータは、 数千億〜数兆のフロンティア LLM に対して桁がいくつも小さく、 2GB でスマホに載る。 最速は Qwen 2.5 (P50 約 1 秒) だが精度が低い。 周りのエンジニアが口を揃えて 「Gemma 4 が一番」 と勧めたが、 実測では約 8 秒と遅かった。 助言のまま選んでいたら、 かなり悪い体験を出荷していた、 と Rachel Lee は振り返る。 精度まで入れた勝者は Llama 3.2 3B (精度およそ 90%、 速度も良好)。 Meta 製で、 SNS 上の人間の入力・要約に強い動機を持つ組織が作っている点が、 SNS クライアントの Mima と噛み合う。
ギャップの閉じ方 — few-shot と後処理、 そして 「judge が厳しすぎた」 (19:26 - 27:06)
90% という数字は 「取引を壊しかねない」 隙にも見える。 Rachel Lee はこの 10% をプロンプトと後処理で詰める。 原則は 「1 度に 1 変数」 — プロンプトの変種ごとに 1 つだけ条件を変え、 効いたかどうかを切り分ける。 5 つ試した (基準 / 番号付き入力 / few-shot / 厳格ルール / chain-of-thought)。 番号付き入力は差が出ず、 厳格ルール (「〜するな」 の否定命令の家) はモデルが不機嫌になり、 命令を嫌がる 「わがままな子ども」 のように振る舞った。 chain-of-thought は長さが少し改善したがレイテンシが 600 ミリ秒増えた。 勝ったのは few-shot — 数例を示す方式で、 長さも精度も改善し、 レイテンシ増は 200 ミリ秒だけだった。
仕上げは post-processing モデル出力の後段でハーネス側が行う整形・検証。 参照の本数が発言者数を超えていないかの検査、 長すぎる要約の切り詰めなど、 モデルに頼らず機械的に直せる部分を担う だ。 参照の本数がスレッドの発言者数を超えていれば誤り、 要約が長すぎれば切り詰める — モデルに頼らず機械的に直せる部分を後段で処理すると、 JSON 妥当性・構造妥当性が 100% になり、 P50 は約 1 秒、 P95 は 3.5 秒未満に収まった。 残った事実整合性のわずかな不一致は、 実は LLM-as-judge モデルの出力の良し悪しを別の LLM に採点させる方式。 人手より安く事実整合性などを判定できるが、 判定者 (judge) 自身の偏りや厳しさが結果に混じるため、 中身を開いて確認する必要がある (採点役の LLM) が厳しすぎたせいだった。 Claude に採点させると、 「angsty (いらついた) ではなく cross (むっとした) だ」 と細部で妹分の Llama をひいきするような判定が出た。 教訓は明快で、 eval は中を開けて生の応答を目で見よ。 出荷後は regression eval モデルやプロンプトを更新したときに、 過去に満たしていた品質を落としていないかを継続的に検査する評価。 CI/CD のテストと同じ要領で回し、 要約が突然長くなったり幻覚し始めるのを防ぐ を CI/CD のように回し、 更新で 「せっかく詰めた品質」 を取りこぼさないようにする。
動画の構成
- (00:00) 自己紹介、 Mozilla / W3C / Edge / React チームの経歴、 Arize 着任
- (00:42) Arize の観測プラットフォーム紹介、 OSS の Phoenix を今日使う
- (01:14) one-size-fits-all inference のコスト — セキュリティ (信頼)
- (01:40) レイテンシ (体験) — 「信じられる限界は 4 秒」 の研究
- (01:57) ビジネス (制御) — 第三者推論費の非制御性、 agentic の compounding
- (02:25) オフライン (可用性)、 トークン単価↓なのに総額↑の逆説
- (03:01) 「本当に LLM が要るのか?」、 task-specific model の早見表 (ビジョン / 音声 / 言語)
- (03:36) SLM とは、 パラメータ数の桁 (数百万〜数十億 vs 数千億〜数兆)
- (05:01) SLM の省エネ性、 量子化 (8bit / 4bit)、 端末搭載 (Pixel 10 Pro)
- (06:05) SLM は production ready、 NVIDIA 「agentic AI の未来」、 エネルギー比較
- (07:07) ローカル AI の実演 (Goose + Gemma)、 魚竜のエコロケーション質問
- (08:52) right-size の 4 ステップ、 「prototype big, deploy small」
- (09:51) Mima の要約機能、 Claude で試作して golden dataset を作る
- (11:02) 測る軸 (JSON / 参照構造 / 事実整合性 / 長さ / P50・P95 レイテンシ)
- (13:00) Phoenix で capability eval、 Claude Sonnet を基準線に
- (13:09) 基準線のレイテンシ約 3 秒、 1 日約 1 ドル、 on-device の総費用ゼロ
- (15:07) 候補モデル (Qwen 2.5 / Qwen 3 / Llama 3.2 / Gemma 4 E2B)、 SAGE model 命名
- (15:19) Qwen 2.5 は最速だが低精度、 Gemma 4 は約 8 秒と遅い
- (17:07) 精度込みの勝者は Llama 3.2 3B、 Meta 製で SNS と相性
- (19:26) ギャップの閉じ方、 プロンプトエンジニアリング、 「1 度に 1 変数」
- (21:33) 5 つのプロンプト変種 (番号付き / few-shot / 厳格ルール / CoT)
- (24:04) few-shot が勝ち (+200ms)、 厳格ルールは 「わがままな子ども」
- (25:51) post-processing で参照本数と長さを機械的に補正、 100% へ
- (25:56) 事実整合性の不一致は 「judge が厳しすぎた」、 eval は開いて見よ
- (28:18) regression eval を CI/CD のように回す
- (28:39) 「Claude 呼び出しのうち何個が Llama 呼び出しにできるか?」
- (29:02) Chrome の Prompt API から Gemini Nano、 端末に既にあるモデルを使う
- (29:31) まとめ — prototype big, deploy small、 prove / define / test / select
関連リソース
- Frontier results, on device — AI Engineer 公式 (講演動画)
- Phoenix — Arize の OSS 評価ツール (講演で使用)
- Arize 公式 (講演者の現職)
- Mima (mima.social) — 題材になった SNS クライアント
- nearestnabors.com — Rachel Lee 個人サイト
用語集
- one-size-fits-all inference
- どんなタスクにも既定でフロンティアモデルを充てる 「万能一律の推論」。 Rachel Lee はこれに 4 つのコスト (セキュリティ / レイテンシ / ビジネス / オフライン) を対置し、 大半の用途には過剰だと論じる。
- task-specific model
- 1 つのタスクに特化した小型モデル。 カメラ入力ならビジョン系 (MobileNet / YOLO / MediaPipe)、 マイク入力なら音声系 (Whisper 等)、 チャット・翻訳・分析なら小型言語モデルを充てる。 foundation model よりサイズも消費電力もはるかに小さい。
- SLM (Small / Smaller Language Model)
- 数百万〜数十億パラメータの小型言語モデル。 LLM の数千億〜数兆に対して桁が小さく、 量子化 (8bit / 4bit) すれば端末に載る。 30 億パラメータでディスク約 2GB。 Gemma や Qwen が代表例。
- prototype big, deploy small
- Rachel Lee の設計指針。 試作は foundation model で大きくやってよいが、 本番はシステムの各部を SLM や特化モデルに置き換えて小さく出荷する。 「大きく試して、 小さく出す」。
- right-sizing の 4 ステップ
- (1) 最大モデルで可能性を証明する、 (2) 入力・出力の組で成功を定義する (golden dataset)、 (3) 小さい方から大きい方へ試す、 (4) 十分な範囲に入る最小モデル (SAGE model) を選ぶ。
- SAGE model
- Rachel Lee の造語で Small And Good Enough (小さくて十分) の頭字語。 用途に対して受容できる応答を返す、 最小のモデルを指す。
- golden dataset
- 人手でラベル付けした高品質な入力・出力ペアの集合。 モデルを評価・検証・ベンチマークするための ground truth (正解) として使う。 テストの模範解答を先に用意しておくイメージ。
- capability eval
- 「このモデルは何を上手くできるか」 を問う評価。 大型モデルの出力と複数の小型モデルの出力を同じ課題で突き合わせる。 Phoenix で実行する。
- LLM-as-judge
- モデル出力の良し悪しを別の LLM に採点させる方式。 人手より安く事実整合性などを判定できるが、 判定者 (judge) 自身の偏り・厳しさが結果に混じる。 Claude が妹分の Llama をひいきした逸話が示すとおり、 中を開いて生の応答を確認する必要がある。
- regression eval
- モデルやプロンプトを更新したときに、 過去に満たしていた品質を落としていないかを継続的に検査する評価。 CI/CD のテストと同じ要領で回し、 要約が突然長くなったり幻覚し始めるのを防ぐ。
- Phoenix
- Arize が開発する OSS の LLM / agent 評価ツール。 capability eval を実行し、 生の応答・期待応答・レイテンシを開いて比較できる。 phoenix.arize.com で公開。
- Gemini Nano
- Chrome にネイティブ同梱される小型モデル。 Prompt API 経由で呼べるため、 ブラウザ利用者には別途モデルを配布せずに端末上の推論を使える。 「端末に既にあるモデルを使う」 例。
