LYR Performance
そのAI、もっと安く・速くできる
「遅い・高い・品質が出ない」の多くは、モデルを乗り換えなくても動きます。AI翻訳プロダクト LYR を一人で作りながら学んだ、レイテンシ・コスト・品質の意思決定の記録。まず方法論を、続けて実際のケーススタディを。
#000 マニフェスト — まずここから
AIの性能は、意思決定の順序で決まる
LYRを一人で作って辿り着いた、AIプロダクトの性能を決める4つの原則
4つの原則を読む →
以下は、その4原則を実際のケースで実践した記録です。数字と、失敗も含めた過程で。
計測が導いた旅
- #001 10 min 一つの設定で生成トークン数1/27・レイテンシ1/4・コスト1/5を実現した 1行の翻訳に数百トークンの"思考"。生成の96%は訳ではなく、モデルが答える前に考えていた分だった。設定ひとつで思考を止めると、生成トークンは1/27、レイテンシは1/4、コストは1/5に。モデルは変えていない。
- #002 6 min 去年の正解が、今年の間違いになる 出力を削って速くしたはずの翻訳を、数か月後に測り直すと内訳が真逆に。生成は1割、待ちと距離が9割。エッジ推論で往復を消そうとして、逆に遅くなった話。
- #003 8 min 品質を測る前に、失格になるAIがある モデル選定には、品質を測る前の"足切り"がある。賢いモデルほど答える前に「考えて」しまい、リアルタイム用途では失格になる。足切りを揃えて測り直すと、「軽量＝速い」という常識のほうが崩れた。
- #004 6 min 借り物のAIは、ある日突然消える 選んで最適化したモデルが、ある日プロバイダに退役させられる。安い階層が丸ごと消え、残ったのは最高値の1つ。レイテンシもコストも自分で握れるのに、土台だけは握れなかった。
- #005 16 min 自前でAIを持って、E2Eを約500ms→120ms・コストを1/3〜1/10にした セルフホストは主権のためだけじゃない。専有で待ち行列を、近接で距離を同時に消せる。だが安いGPUで素にやると、今度はcomputeが新しいボトルネックになる。コスト試算とレイテンシ従来比。
- #006 7 min あなたがボトルネックです 4か月で122個の計測器を作って気づいた——計測ファーストの正体は精度でなく速度で、最初のボトルネックは自分だった。
インフラ — 速さの締め切りと、動かせない床
- #007 9 min 「十分速い」を、ベンチマークで決めてはいけない 「何msなら速いのか」をベンチマークで決めると必ず外す。字幕翻訳の目標は、字幕が画面に映っている時間から逆算した"締め切り"だった。速さは連続値でなく、崖だ。
- #008 5 min 地理は、レイテンシの"動かせない床"だ モデルを速くしても、量子化しても、距離だけは縮まらない。東京から各地のデータセンターへの往復時間を測ると、東京5ms〜ケープタウン373msの"動かせない床"が見えた。レイテンシ最大のレバーは、性能ではなく置き場所だった。
- #009 10 min 状態を持つ部品を1つ動かして、体感を469ms→252msにした 推論をユーザーに近づけてレイテンシを削ったつもりが、間に挟んだ状態管理部品（Cloudflare Durable Object）が太平洋を往復していた。区間分解してみると、往復は消えたのに別の区間が175msに跳ねていた。部分最適が、分散システムでは別の場所で相殺される。全体で測るまで、誰も気づけなかった。
- #010 13 min AIアプリは、CPUとRAMで考えるとうまくいく 基盤LLMを「借り物のCPU」、context・データを「自社設計のRAM階層」と見なすと、キャッシュ設計も文脈設計も自前化の判断も、1つの語彙で組織化できる。CPUは退役するが、RAMは資産として積み上がる。
モデル — 小さく、速く、賢く
- #011 7 min モデルを4分の1に圧縮しても、賢さはほぼ落ちない AIモデルを「軽く詰め直す」と、なぜ生成が1.8倍速く・さばける量とコストが4倍になり、しかも精度はほぼ落ちないのか。メモリ帯域という本当のボトルネックと、量子化がそれをどう解くかを、経営の言葉で。
- #012 9 min 小さなAIの正答率を42%→84%へ。一部タスクは巨大モデルと同点 素の小型モデルは、翻訳の正答率が42%しかなかった。それを、退役した本家モデルと同じ84%まで、さらに一部タスクでは現役の巨大モデルと同点まで引き上げた。汎用の賢さは要らない。1つの仕事だけ仕込む方法と、その限界を、経営の言葉で。
- #013 7 min ベンチで賢かったAIが、本番で急に間違え始めた 微調整したAIモデルが、ベンチマークでは優等生なのに、本番に載せた途端に主語や否定を取り違え始めた。原因は性能でも学習でもなく、「テストした環境」と「デプロイした環境」の精度の不一致だった。同じ条件で測り直し、同じ条件で仕込むまでの発見の記録。
- #014 9 min その「97%改善」を、私は捨てた 自動計測が「97%改善」という朗報を返してきた。数字が良すぎるとき、経営はそれをどう扱うべきか——採用する前に生の出力を一枚ずつ見た、ある偽の勝利の解剖記録。
- #015 10 min 「文脈を足せば賢くなる」は、半分ウソだった 前後のセリフを渡せば、小さいモデルも文脈を読んで賢くなる——そう思って測ったら、半分は本当で、半分はウソだった。文脈で埋まるのは話者・固有名・主語のような「調べれば分かる穴」だけ。深い読解は、答えが目の前にあっても容量が足りず使えない。本番同型・temp0の総当たり実験で、文脈をどう入れても品質差は動かなかった話。
- #016 11 min 最下位率を64%→24%に下げ、最上位率の低下は12ptに抑えた 強く圧縮したモデルは、最高の訳も出すが、大事故も出す。平均で見ると差はほとんど無い。だが字幕製品でユーザー体験を壊すのは、平均でも最高でもなく、たった一度の最悪だった。天井でなく床を上げる、という選び方。
- #017 15 min スワヒリ語を0%→30%に。だが価値は点数でなく、失敗の中身が変わったこと AIがもっとも苦手な言語のひとつ、スワヒリ語。素のモデルの正答率は0%だった。基礎を仕込んでも30%。合格には遠い。だが、伸びた30%より価値があったのは「失敗の中身が変わったこと」だ。スコアの絶対値でなく失敗の分布を見る——低資源言語で何が本当の律速かを見抜いた話。
- #018 12 min AIに「正解より良い訳」を選ばせる 「正しいお手本を1つ用意して真似させる」——AI学習の常識だ。だが、候補をN個出させて品質推定器（QE）に一番良いものを選ばせれば、教師の一発目を超えるお手本が作れる——LYRで最も有望と見込む"次の一手"だ。そして確かなのは、その裏返しのほうだった：選ぶ物差しが的外れなら、綺麗な1つの手本にあっさり負ける（実測82%→73〜77%）。正解信仰を壊し、その効き目と限界を正直に測った話。
- #019 10 min 小さな専門家が、現役最強と肩を並べた 汎用の巨大モデルに真っ向勝負しなくても、Live字幕という1つのタスクに絞って磨けば、約3分の1のモデルが現役最強クラスと引き分けにできる。Live字幕の成功率を90→96へ、現役27Bモデルと同点にした話。ただし代償があった——1モードに特化すると別モード(Page/Manga)が−4崩れる。特化とは配分の選択であって、無料ランチではない。
- #020 13 min 教師AIを、別のAIに作らせる 小さな専門AIを育てるには「正解データ」が要る。それは人間が作るもの、と皆思う。だがLYRでは正解を、別の大きなAIに作らせた——苦手だった日本語→英語の正答率は、素直な写経だけで42%から84%へ跳ねた。そこから先の天井は、生徒（4B）の理解容量に由来するhallucination。押し上げの次の一手は、教師にN個書かせて良い訳を選ぶbest-of-N。教師データを自動で作る方法論の話。
- #030 11 min 生成の速さはパラメータ数でなく、重みのバイト数で決まる 同じGPUで測ると、パラメータが2倍違う 4B-INT8 と 8B-INT4 がほぼ同速だった（1トークンあたり5.98ms 対 6.50ms）。1トークン生成するたびに重みを全部読み出すから、速さを決めるのは計算量でもパラメータ数でもなくバイト数。ただし前提を外すと法則は壊れ、測り方を間違えると2.35倍の差が消えたり逆転したりする。
- #032 25 min 汎用モデルという器は、字幕には無駄が多すぎる 圧縮を一切かけない素のままの8Bでも、致命的な誤訳は97件中15件残った。3倍以上大きい27Bは4件（p=0.015）。圧縮の強さを変えても、この差は動かない。ならば次は器そのものを疑う——字幕は短文・制約・有界文脈なのに、任意長の自由生成のために設計された器を丸ごと使っている。特化に期待するのは速さだけではない。感情の語り口と、映像を見て訳す精度。設計仮説と、その反証条件を正直に置く。
計測・調整 — 正しく測り、設定を合わせ込む
- #021 5 min その設定値、勘で決めていませんか 閾値も解像度もバッチサイズも、たいてい勘で決められている。検証が安くなると、1点を選ぶのをやめて、範囲を掃いて曲線の形を見るようになる。sweet spotは、全体を測って初めて見える。
- #022 6 min 「どっちが速い？」が、そもそも愚問になるとき 速さ vs 精度、品質 vs コスト。目的が対立するとき「どっちが良い」に答えはない。あるのはフロンティア（前線）だけ。勝者を探すのをやめて、操作点を選ぶ。安いパラメータ変更が高価な改善を"支配"したら、その改善は無だ。
- #023 7 min AIに採点させるなら、その採点を疑うところから 品質をAIに採点させると、同じものを2回測っただけで6点も揺れた。その揺れが生んだ「+7点の改善」は、直接対決させたら互角だった。採点者そのものを先に校正しないと、改善は幻を追う。
- #024 9 min 複製したベンチマークは、静かに嘘をつく 主要ロジックだけ真似て複製したベンチは、本番がとっくに捨てた設定を測り続けていた。本番関数をそのまま呼ぶ形に直すと数値が+26〜31pp回復。さらに、A/Bの前に「同じコードを2回流して一致するか」を確かめると、悪名高い「±20ppのノイズ」の正体が見えた。
- #025 7 min その「精度」、あなたが選んだ定義ですよね 「精度を上げる」と言うとき、その"精度"は誰かが選んだ定義でしかない。合否だけを返す採点に最適化すると、その定義が拾わない価値だけが平板に取り残される。改善の天井はモデルではなく、貧しい定義のほうにある。
- #026 6 min 対照を取るまで、「なぜ」を語らない 数字が動いた、良くなった、機構はこうだ——語りたくなる。だがその前に対照（検証したい要因だけが treatment と異なり、それ以外はすべて揃った比較対象）を一本取れ。安い対照が高価な変更を全軸で上回ったら、その変更は何も足していない。改善に見えたものは交絡だ。
- #027 7 min 一つのモードで測って満足しない Live翻訳の数字を90から96へ押し上げて「改善だ」と宣言しかけた。だが全モードで測り直すと、PageとMangaが静かに4ポイントずつ落ちていた。製品が複数のモードで使われるなら、1つのモードの数字だけで勝利を宣言してはいけない。regime shiftのトレードオフは、全モードを測って初めて見える。
- #031 9 min 5回作り直しても当てずっぽうだった原因は、モデルではなくラベルだった 入力を変え、構造を変え、5回作り直しても精度が当てずっぽうと変わらない。原因はモデルではなく、正解ラベルが約1秒ずれていたことだった。しかも壊れたラベルは二重に損をさせる——悪いモデルを作るだけでなく、既にあった良い実装を「取りこぼし25%」と過小評価していた。
OCR — 端末の上で、処理を減らす
- #028 12 min OCRの電力予算を1桁下げた——速くするのではなく、呼ぶ回数を減らして 端末の上で字幕を読むOCRは、電池を食う。最初は「OCRを速くする」に投資した。実際 -51% 速くなった。だが桁は変わらなかった。桁を変えたのは、1回0.5msの常時レイヤーに「そもそも呼ぶかどうか」を判定させたことだった。ただし、ゲートを安くしただけでは電力は1ミリも動かない——過剰発火6.9倍という逆説の話。
- #029 8 min UIへの誤発火を44%→22%に。外側のifを1本も足さずに 字幕を見張るはずの判定器が、動画アプリの操作UIやブラウザのURLバーに反応する。外側にフィルタを足せば消える。実際に消えたし、電力も落ちた。だがそれは、モデルが弱いことを隠す保険を毎フレーム買い続ける契約だった。ラベル定義を直してモデル側に解かせた話と、それでも外側のロジックが正しい唯一の条件。