ファインチューニング済みモデルの API 指標：追跡すべきもの

ファインチューニング済みモデルは、ライブの API トラフィック下で十分に速く、十分に安定し、十分に安価であり続ける場合にのみ、保持する価値がある。

初日から数少ない項目だけ追跡するなら、私は レイテンシ、スループット、エラー率、タイムアウト率、成功率、フォールバック率、トークン使用量、リクエストあたりコスト、キュー深度、タスク完了率 を見ます。なぜか？ モデルは 200 OK を返してもなお、タスクに失敗したり、余分なトークンを消費したり、ユーザーを離脱させたりし得るからです。

要点は次の通りです。

• レイテンシ: 平均だけでなく TTFT と p95/p99 を見る。
• スループット: 1 リクエストずつではなく、本番の同時実行下で RPS/TPS をテストする。
• 信頼性: 4xx、5xx、429、503、504 を分けて、障害パターンを見つけやすくする。
• タイムアウト: 出力が長くなると、ファインチューニング済みモデルはリクエストの締め切りを超えがち。
• 成功 vs フォールバック: 動作する API レスポンスは、使える回答と同じではない。
• トークン: API の usage フィールドから 入力、出力、合計トークン を追跡する。
• コスト: 月次支出だけでなく、リクエストあたりコスト、1,000 トークンあたりコスト、p95 コスト を測る。
• キャパシティ: キュー深度と KV キャッシュの逼迫は、GPU のグラフより先に問題を示すことが多い。
• ユーザー成果: タスク完了率、人手レビュー、離脱を見る。
• ロールバックのリスク: p99 が急上昇、5xx + タイムアウトが 5% を超える、あるいは ベースモデルに対する勝率が 50%～55% を下回る 場合、それは強い警告として扱う。

カスタム計算指標を使ったファインチューニング

クイック比較

結論: 私はファインチューニング済みモデルをオフラインのスコアだけで判断しません。本番でベースモデルと比較し、ローンチ前にロールバックの閾値を設定し、速度、障害、支出、成果 を一画面で見せるダッシュボードを一つ保ちます。

ファインチューニング後に API 指標がより重要になる理由

ファインチューニングは、本番でのモデルの振る舞いを変えます。ライブトラフィック下では、レイテンシ、トークン使用、障害パターンがすべて動きうります。ある場合には、ファインチューニングは長いプロンプトを置き換えて入力トークンを削減します。別の場合には、補完を長くして出力コストを押し上げます ^[6]。だからこそ、オフラインでの勝ちはそれ単体では大した意味を持ちません。ライブの API 指標 と照らし合わせて確認する必要があります。

オフラインのテストと本番のギャップは現実のものです。研究によれば、ファインチューニング済みモデルはタスク特化のホールドアウトセットで 12 ポイント伸ばしても、GSM8K のような一般的推論のベンチマークで 6 ポイント落とすことがあります ^[2]。これは奇妙な例外ではありません。破滅的忘却 と呼ばれる既知の障害パターンで、あるスキルを向上させると別のスキルが弱まることがあります。

ここでの教訓はかなりシンプルです。ファインチューンは、あなたが気にするタスクに役立ちつつ、他の性能を損なうことがある。そして、そうしたベンチマークのドリフトは、オフラインのスコアだけを凝視していても明確には現れません。本番のシグナルを評価結果の隣に置いたときに見えてきます。

品質のドリフトだけが問題ではありません。ドメイン特化のファインチューニングは、ベースモデルの拒否挙動も弱め、モデルをジェイルブレイクやプロンプトインジェクションに対してより脆弱にすることがあります ^[2]。本番では、そうしたほころびは素早く現れます。成功率が落ち、フォールバック率が上がり、静的なテストセットでは捉えられない形でエラーの急増が現れ始めます。それらの変化は、後続の API 指標に現れます。

1. エンドツーエンドのレイテンシ

エンドツーエンドのレイテンシとは、クライアントがリクエストを送ってから完全なレスポンスが到着するまでの合計時間です。これにはネットワーク時間、キューイング、推論、レスポンス配信が含まれます ^[7][9]。ファインチューニング済みのエンドポイントでは、これは最初に見るべき本番シグナルの一つです。

レイテンシをシンプルに捉える方法はこうです。total time ≈ TTFT + output_tokens × TPOT ^[9]。

TTFT は最初のトークンがどれだけ速く現れるかを測り、ストリーミングのアプリで非常に重要です ^[9][10]。TPOT は生成されるトークン間の平均時間です ^[9]。この分割は、ファインチューン後に何が変わったのかを見るのに役立ちます。応答速度が落ちたのか？ ストリーミングの開始が遅れたのか？ トークン生成が遅くなったのか？

ファインチューニング済みモデルは、ベースモデルより 10%～20% 遅い ことがよくあります。もしレイテンシが 50% 以上跳ね上がるなら、それは通常、マージされていない LoRA の重み、量子化の欠落、あるいは出力が長くなりすぎたことを示します ^[7][8]。有用な比較対象はベースモデルです。それが、ファインチューンが速度の犠牲を正当化するほどタスク品質を高めたかを教えてくれます。

テールレイテンシは、遅いターン、リトライ、キューの急増の際にユーザーが気づくものです。p95 TTFT が 3～4 秒を超える と、ユーザーにとって明確な遅さを生みます ^[3]。インタラクティブなチャットでは、p95 TTFT が 500ms 未満 なら瞬時に感じられます。3～4 秒 を超えると、体験は急速に悪化します ^[12]。だから SLA を平均だけで設定してはいけません。テールレイテンシで設定しましょう。

高いテールレイテンシは通常、素の GPU 速度ではなく、キュー深度の問題やコールドスタートのオーバーヘッドを示します ^[10]。だからこそ、パーセンタイルのレイテンシは平均応答時間そのものよりも重要なのです。

測定する前に、2～3 回のウォームアップリクエスト を実行しましょう。初回呼び出しのレイテンシは、しばしば 30%～50% 高く なります ^[8]。

2. p50、p90、p99 レイテンシ

平均レイテンシは、実態より良く見せてしまうことがあります。平均応答時間が 1.2 秒 なのを見てエンドポイントは順調だと思い込む一方で、p99 は 9 秒 かもしれません ^[15]。それは、ダッシュボードが正常に見えていても、1% のユーザーはなお 10 秒近く待っているということです。パーセンタイルは、ファインチューンが大半のリクエストを助けたのか、それとも遅さをテールに押し込んだだけなのかを見るのに役立ちます。

各パーセンタイルが、あなたのファインチューニング済みエンドポイントについて何を教えるかは次の通りです。

これらのパーセンタイルを使って、同じトラフィックミックス下でベースモデルとファインチューニング済みモデルを比較しましょう。

ファインチューニング後、p50 と p99 は別の方向に動くことがあります。ファインチューンがより短く構造化された出力をもたらすなら、典型的なリクエストが速く終わるため p50 は下がるかもしれません。しかしモデルが時々より冗長になる場合、p99 は上がるかもしれません ^[7][15]。その分岐が重要です。p50 が横ばいのまま p99 が上がるなら、それは平均応答時間ではなく、掘り下げるべきシグナルです。

p99 はあなたのロールバックリスクの数値です。 CI/CD パイプラインで p99 の閾値を軸に回帰ゲートを設定しましょう ^[15]。モデル更新がテールレイテンシを上限を超えて押し上げるなら、本番に届く前にビルドが失敗すべきです。

レイテンシはリクエストがどれだけ遅く感じるかを教えます。次は、エンドポイントがどれだけのリクエストをさばけるかを見ましょう。

3. スループットと秒間リクエスト数（RPS）

レイテンシは 1 リクエストがどう振る舞うかを教えます。スループットは、エンドポイントが時間あたりどれだけの仕事をさばけるかを教えます。

追跡すべき主な数値は、秒間リクエスト数（RPS）、秒間トークン数（TPS）、分間トークン数（TPM） です ^[17][18]。これらを合わせると、特に複数プロバイダーを管理するために 統合 LLM API を使う場合に、あなたのファインチューニング済みエンドポイントが実際のトラフィックに追随できるかがわかります。

ここに落とし穴があります。モデルは 1 回きりのテストでは速く見えても、トラフィックが積み上がると崩れることがあります。同時実行下では、並列リクエストを増やしても出力がもう増えず、レイテンシが激しく急上昇し始める スループットの崩壊 に陥ることがあります。スループットのスケールが止まるその変曲点が、あなたのキャパシティの天井です ^[15]。

RPS を左右する最大の要因の一つは出力の長さです。ファインチューンがより長い回答を出し始めると、たとえ返答が良くなっても、スループットは下がりコストは上がります ^[6][8]。

素のスループットだけでなく グッドプット を見るのも有効です。グッドプットは、なおレイテンシ SLO を満たすリクエストの割合です。グッドプットが低ければ、エンドポイントは忙しくても的を外しているかもしれません。そうしたギャップはしばしば、弱いバッチ処理やサーバーの飽和を示します ^[17]。

だから RPS と TPS をベンチマークするときは、単一リクエストの実行ではなく 本番の同時実行 でテストしましょう。レート上限、キュー深度、VRAM に紐づく制限は、システムが負荷下に置かれるまで隠れたままであることが多いのです ^[7][9][15]。エンドポイントがそこでキャパシティを保てるなら、次はそれらのリクエストが成功しているかを確認する番です。

4. HTTP ステータスコード別のエラー率

負荷が制御下に入ったら、次に見るべきは信頼性です。エンドポイントがどれだけ失敗するか です。エラー率は、リクエストがあるべき形で完了しているかを教えます。実務では、これはクライアント側の失敗とサーバー側の失敗の 2 つのバケツに分かれます。

4xx エラーの増加は、しばしばプロンプトやスキーマの不一致、あるいはファインチューンが持ち込んだコンテキストウィンドウの問題を示します。503 や 504 エラーの増加は通常、サーバーの負荷やタイムアウトの圧力を示します。5xx エラーが急増したら、それは深刻なロールバックリスクとして扱いましょう。

ここにはお金の側面もあります。失敗したリクエストもトークンを消費します。無駄な支出を追跡するには、失敗したリクエスト、特に 429 以外の 4xx エラー と あらゆる 5xx エラー からトークン課金を積み上げましょう ^[22]。そしてリトライロジックが過度に積極的だと、それらの不適切なリトライが推論コストを 3 倍から 5 倍 に押し上げることがあります ^[21]。

最もよくあるステータスコード、その主な発生源、次に取るべき対応をシンプルに整理すると次の通りです。

すべてのエラーコードに同じリトライロジックを使ってはいけません。400 をリトライしても、リクエストが壊れたままなので計算資源を余分に消費するだけです。指数バックオフは 429 エラーに用いるものです ^[21]。503 や 504 が 3 回のチェックにわたって現れ続けるなら、サーキットブレーカーを作動させ、トラフィックをベースラインのモデルへ振り向けましょう。

次に、遅いレスポンスが完了前にタイムアウトしていないかを確認しましょう。

5. タイムアウト率

エラーが増えても明確な露骨な失敗の急増がないとき、次に確認すべきは タイムアウト率 です。タイムアウトも失敗したリクエストです。締め切り前にクライアントは何のレスポンスも受け取りません。タイムアウト率は、その締め切りを超えるリクエストの割合として追跡し、これはしばしばサーバー側のタイムアウトエラーとして現れます。

ファインチューニング済みモデルは、より長い出力を生成しがちなため、タイムアウトに陥りやすくなります。訓練データが冗長寄りだった場合、モデルはベースモデルよりリクエストあたり多くのトークンを生成するかもしれません。これは Alibaba Qwen モデル や、詳細な応答を優先するその他の高性能 LLM を使う際によく起こります。トークンが多いほど生成時間が長くなり、その余分な時間がリクエストを締め切り超えに押しやります ^[8]。

キュー深度がゼロを超えたままなら、システムはすでにキャパシティに達しています。そうなると通常、その直後にタイムアウト率が上がります ^[12]。タイムアウトが現れるのを待つのではなく、キュー深度を早期警告サインとして扱いましょう。キュー深度がタイムアウトと同時に上がるなら、それはキャパシティの問題で、即座の対応が必要です。タイムアウト率が落ち着いたら、真の成功をフォールバックのレスポンスから切り分けましょう。

6. 成功率とフォールバック率

タイムアウトがなくなっても、リクエストはなお仕事を外すことがあります。成功率は、モデルが実際にタスクを完了したかを教えます。単に HTTP 200 を返したかではありません。 それは、スキーマ準拠、正しいツール呼び出し、事実の正確さといったものを確認することを意味します。ファインチューニング済みモデルは、高いトークン精度を示しつつ、タスクレベルの回帰のせいでライブの本番クエリの 15%～30% に失敗することがあります ^[23]。

フォールバック率は、ファインチューニング済みエンドポイントが失敗、タイムアウト、あるいは安全フィルターでブロックされた後に、トラフィックをどれだけ別の場所へ送る必要があったかを教えます ^[4][5]。だから成功率のすぐ隣で追跡すべきです。あなたが測っているのは補完だけではありません。使える出力を測っているのです。

この 2 つの指標を、完了品質の主要シグナルとして一緒に使いましょう。どちらかが落ちたら、それはファインチューンがなおベースモデルに耐えられるかを確認する瞬間です。ベースモデルに対する勝率が 50%～55% を下回るなら、それはよくあるロールバックの閾値です ^[2][4]。

成功率が高いままコストが上がり始めたら、次はトークン使用量を確認しましょう。

すべてのリクエストの提供コストが高すぎるなら、成功率が高くても大した意味はありません。

7. リクエストあたりトークン使用量

信頼性の次に、トークン使用量は、モデルがスケールで動かせるほど無駄がないかを教えます。また、プロンプトのオーバーヘッドを学習済みの振る舞いに置き換えることで、ファインチューニングが仕事をしているかも示します。トークン使用量が少ないほど、通常はコストが下がり、返答が速くなります。

入力、出力、合計 のトークンを別々の数値として追跡しましょう。そうすれば、緩やかな増加がコスト問題になる前に見つけやすくなります。入力トークンが多い場合は、しばしばプロンプトの肥大化やコンテキストの超過を示します。出力トークンが多い場合は通常、冗長な補完、弱いストップルール、あるいは出力上限の欠如を意味します。そして出力トークンは入力トークンより高くつくため、冗長さが最大のコストリスクです ^[15]。

トークン数は、ローカルのトークナイザーの推定値ではなく、すべてのレスポンスの API の usage オブジェクトから取得しましょう ^[15][25]。ローカルの推定は請求上の数とずれることがあります。3 倍のトークン急増を見たら、原因が見つかるまではプロンプトの肥大化かコンテキストの超過だと想定しましょう ^[3]。CI/CD で出力トークンの上限を設定しておくと、冗長さの回帰を出荷前に捉えられるので有効です ^[15]。

トークン数はそのまま支出に対応します。だからこそ次の指標はリクエストあたりコストです。

8. リクエストあたりコストと 1,000 トークンあたりコスト

トークンはドルになります。しかし月次の請求書だけでは、なぜ支出が上がったのかは わかりません。何が支出を押し上げているかを見るには、リクエストあたりコスト と 1,000 トークンあたりコスト を追跡しましょう。それが本番分析の次の層を与えてくれます。

リクエストあたりコスト は、単一のユーザー操作にいくらかかるかを示します。そのリクエストの請求対象の入力、出力、キャッシュトークンの課金から計算します ^[26][28]。次に、1,000 トークンあたりの請求レートを単独で追跡します。両方の数値を一緒に見れば、支出が上がっているのはトラフィックが増えたからか、それともプロンプトと補完が長くなっているからかを見分けられます。そのパターンはしばしば トークンクリープ と呼ばれます ^[15][26]。

ファインチューニング済みの推論は トークンあたり 2～5 倍高く つくことがありますが、プロンプトの長さを削るなら、なおリクエストあたりコストを下げられます ^[29][30]。なぜか？ ファインチューニング済みモデルは、役割定義、ガードレール、few-shot の例を重みに焼き込みます。だから呼び出しのたびに各プロンプトが短くなります。あるベンチマークでは、ベースモデルが 85 トークン を必要としたところで、ファインチューニング済みモデルはわずか 42 補完トークン で済み、リクエストあたり推論コストが 50.6% 削減 されました ^[19]。平たく言えば、単価が高くても、トークン数の少なさに負けることがあるのです。それがライブの API トラフィックで測りたい利得です。

すべての API 呼び出しに feature_name と user_tier のタグを付けて、支出を製品の利用に結びつけられるようにしましょう ^[27][28]。それによって、コストがドリフトし始めたときにデータがはるかに有用になります。

いくつかのチェックが特に重要です。

• 出力トークン を注意深く見ましょう。フラッグシップモデルの価格では、入力トークンより 5 倍 高くつくことがあるため、冗長な回答を削るほうが、同じ数のプロンプトトークンを削るより多く節約できます ^[15]。
• CI/CD パイプラインで平均出力トークンに上限を設定しましょう。これは冗長さの回帰が本番に届く前に捉えるのに役立ちます ^[15]。
• コストは合算だけでなく、機能別・ユーザー階層別に見直しましょう。さもないと、高コストな利用が健全に見える合計の中に隠れてしまいます。

コストの次は、支出が実需に見合っているのか、それとも遊休キャパシティに対するものかを見ましょう。

次に、これらのコストをインフラの稼働率とキュー長と比較しましょう。

9. インフラの稼働率とキュー長

レイテンシとタイムアウトが上がったなら、次はサービング層を見ましょう。キュー、メモリ、キャッシュの逼迫です。ここではキュー深度が最も重要です。 GPU 使用率は需要に遅れて追随しがちで、遅行指標です。だからオートスケーリングは、計算資源の割合ではなく、レプリカあたりのキュー深度を軸にすべきです ^[10][32]。

KV キャッシュ使用量 は、チームが見落としがちなもう一つの指標です。KV キャッシュはトークンのコンテキストを GPU メモリに保存し、そのメモリが逼迫すると、GPU の計算資源にまだ余裕があるように見えても、エンジンは新しいリクエストをキューに入れ始めることがあります ^[31][32]。目安として、40%～50% の KV キャッシュ使用を早期警告、90% 以上 を飽和として扱いましょう ^[31][32]。

ファインチューニング済みモデルには、もう一つひねりが加わります。LoRA アダプターはベースモデルの重みに加えてメモリを必要とし、スケールアップ後の最初のリクエストでそれらを読み込むとコールドスタートの遅延が生じます。ほとんどの場合、それは TTFT に数百ミリ秒を加えます ^[10]。起動時にアダプターをプリロードすれば、その打撃の大半を避けられます。トークン化と前処理が見逃しやすいレイテンシを加え得るため、CPU を単独で見るのも有効です ^[10]。

これらのキャパシティのシグナルがなお健全に見えるなら、出力の品質へ進みましょう。

10. ユーザー満足度とタスク完了率

レイテンシ、コスト、信頼性の次に、最後のチェックはシンプルです。モデルは仕事を最後までやり遂げるか？ ファインチューニング済みのエンドポイントは、速くて安くて安定していても、なお的を外すことがあります。

タスク完了率（TCR） は、人手を借りずに解決されたリクエストの割合です。人手レビュー率 は、なお手作業の修正を要する出力の割合です。その違いが重要です。モデルは HTTP 200 を返しつつ、誰かが使える前に人が手を入れて整える必要のあるものを返すことがあります。だから TCR は、API が答えたかどうかではなく、ビジネス成果を追跡します。

構造化出力の作業では、500 件の高品質な例 がフォーマット準拠を 68%～74% から 97%～99% へ押し上げることがあります ^[33]。そうした跳躍は、スタッフが介入する頻度を減らします。フォーマットが正しくなったら、ファインチューニング済みモデルをベースモデルと直接比較しましょう。

ここでも速度は重要です。p99 レイテンシが 5 秒を超えると、約 45% の離脱を招きます ^[33]。だからファインチューンが体験を遅くすれば、ユーザーは素早くそれを示します。離脱によって。

直接的な品質チェックには、ペア型のアリーナテスト を使いましょう。200～500 件の本番サンプル をベースモデルとファインチューニング済みモデルの両方に通し、LLM-as-a-judge で出力を並べて採点します。その後、判定モデルとルーブリックを固定 して、今後のテストが一貫するようにします。ベースモデルに対する勝率が 50%～55% を下回るなら、それはよくあるロールバックの閾値です ^[2][4]。

これらのシグナルを一緒に見るのも有効です。

• TCR
• アリーナ勝率
• 凍結したベンチマークスイート

モデルが 一般ベンチマークで 5 ポイントを超えて落ちる なら、たとえタスク特化のスコアが上がっても、それは決定的な失格として扱いましょう ^[2]。

これらの品質チェックを、前のセクションの API 指標の隣で使い、ファインチューンが本番の準備ができているかを判断しましょう。

レイテンシとスループットの比較表

ファインチューニング済みエンドポイントについて、全体像を語れる単一の指標はありません。たとえば平均レイテンシは、特にプロバイダー側のキューイングやバッチ処理が絡むと、リクエストごとの揺れをならしてしまうことがあります ^[9]。

だからこそ、SLO を設定する前に、まずレイテンシとスループットを別々に測り、それから並べて比較するのが有効です。

結果を、エンドポイント種別、モデルバージョン、リージョン、時間帯で切り分けましょう。ピーク時のトラフィックは、オフピークのテストでは捉えられないレイテンシの問題を表面化させることがよくあります。

そうした切り分けによって、ファインチューニング済みエンドポイントがライブトラフィック下でどこから苦しみ始めるかがずっと見やすくなります。

ロールバックリスクを示す信頼性指標

ロールバックが必要かもしれない最も明確なサインは、ベースモデルに対する勝率 です。ペア型のカナリアとシャドールーティングを実行して、ファインチューニング済みモデルをベースモデルと並べて比較できるようにしましょう。勝率が 50% を下回るなら、ファインチューンは本番でもう価値を加えていません。ルーティング層は、カナリアのコホートが いずれかのルーブリック別品質スコアで 2 ポイントの低下 を 30～60 分間保つときに、自動ロールバックもすべきです ^[2][4]。それらの比較がマイナスに転じたら、次の一手はシンプルです。壊れているプロンプトのグループを見つけることです。

いくつかの他のシグナルもロールバックのトリガーとして機能すべきです。5xx + タイムアウト率、拒否率、無効出力率、429 の急増、フォールバックの挙動 です。これらは、ファインチューンを稼働させ続けるべきか判断するときに重要な数値です。429 の急増は単独で追跡しましょう。それはしばしば、より高い計算コストやより深いキューを示します ^[24][5]。

拒否率 と 無効出力率 をひとまとめにせず、切り分けるのも有効です。2% を超える拒否は、しばしば安全性の回帰、あるいはプロバイダーのフィルターがあなたのカスタムプロンプトと衝突していることを示します ^[5][35]。無効出力率は通常、スキーマのドリフトや弱い指示追従を示します ^[2][24]。

各指標を プロンプト種別、ワークフローのルート、モデルバージョン で分解しましょう。モデルは一般的なリクエストでは問題なく見えても、構造化出力の経路やドメイン特化のプロンプトでなお苦しむことがあります。その切り分けにより、モデルを稼働させ続けて安全か、そしてコストプロファイルがなお成立するかがずっと判断しやすくなります。

コスト、トークン、リソースの指標をドル建てで

レイテンシ、スループット、信頼性の次に、次のステップはシンプルです。エンドポイントはその金額に見合うか？ 安定したトラフィックも、リクエストごとのコストが高すぎれば大して役立ちません。信頼性が制御下に入ったら、トークン使用量をドルに変換する必要があります。

GPT-4o では、ファインチューニング済みの推論価格はベースレートに対して 1.5 倍の上乗せ が付きます。それは 100 万入力トークンあたり $3.75、100 万出力トークンあたり $15 に相当します ^[36]。その追加コストは、ファインチューンが成功した結果を得るためのコストを下げる場合にのみ理にかないます。支出を削る一般的な方法の一つが、AI API の集約割引 と モデルカスケーディング です。単純なクエリはより小さく低コストのモデルへ送り、より大きなモデルは難しいタスクのために取っておきます ^[37]。

支出を、控えめ、想定、高負荷のケースにわたって予測するのも有効です。そこにリトライ、フォールバックの利用、評価の実行を上乗せします ^[26]。チームの 40% は利用開始の最初の四半期で AI API の予算を超過する ため、この工程は多くのチームが思う以上に重要です ^[37]。さらに、平均だけでなく リクエストあたり p95 コスト も追跡しましょう。さもないと、長いコンテキストのプロンプトや繰り返しのリトライが、平均では見えない形で予測を歪めます ^[24]。素の支出は、成功した成果に結びつけて初めて有用になります。

その結びつきが 成功成果あたりコスト です。実務では、解決した問い合わせチケットあたりコストや、受理された回答あたりコストを意味するかもしれません。ファインチューニング済みモデルが成功成果の割合を引き上げれば、リクエストあたりの価格が上がっても、解決あたりコストは下がり得ます ^[26][37]。

セルフホストのデプロイでは、GPU 使用率 が主なコスト要因です。固定の GPU 支出は、利用が一定の閾値を超えて初めて元が取れます。言い換えれば、高い使用率はそれがコスト効率を改善するときに重要になります。使用率の隣でキュー長も見るべきです。キュー深度が上がり続けるなら、それは通常、飽和、コスト増、そしてより多くのスケーリング圧力のサインです ^[11][15]。

これらの指標を一緒に使って、健全な負荷と高くつく無駄を見分けましょう。

API を通じて観測できる品質シグナル

レイテンシ、スループット、コストが良好になったら、次のステップはシンプルです。モデルが 実際にユーザーの仕事を進める助けになっているか を確認することです。速度はもちろん重要です。しかし、問題を解決しない速い回答は、やはり的外れです。

まず タスク完了率、エスカレーション率、人手引き継ぎ率 に注目しましょう。これらが主な成果シグナルです。ファインチューニング済みモデルが単独でリクエストをさばいたのか、それとも誰かが介入する必要があったのかを教えてくれます。そしてそれは、実際のリクエストとセッションのログから得られるため、ベンチマークのスコアより重要です。

高評価／低評価のレーティング と 離脱率 も、API トラフィックに紐づくセッションレベルの補助的シグナルとして追跡できます。フィードバックがまばらでも、繰り返される痛点を示すことがあります。離脱は特に有用です。モデルがどこでドリフトし始め、コンテキストを失い、会話の途中で役に立たなくなるかを示すからです。

ライブトラフィックを LLM-as-judge でサンプリングして、ハルシネーションや安全性の問題を推定するのも有効です。多くの場合、5% のサンプル で、評価コストをあまり押し上げずに異常を捉えるのに十分です ^[39]。ガードレールの発動頻度 にも目を配りましょう。リクエストの 20% 超がブロックされる なら、それは危険な出力の急増、あるいはユーザーが望むものとシステムが期待するもののミスマッチを示すことがあります ^{[38] [1] [2]}。拒否率 の急な増加は、しばしばフィルターが敏感になりすぎたか、スタックのどこかでプロンプトテンプレートが壊れたことを意味します ^{[39] [2]}。

すべてのライブの失敗は、恒久的なケースとしてオフラインのテストセットに戻すべきです。それが、同じ問題が後でこっそり戻ってくるのを防ぐ方法です。

下の表を使って、主要な品質シグナルと補助的なものを切り分けましょう。

これらのシグナルを、オブザーバビリティのダッシュボードでレイテンシやコストと並べて使いましょう。

ファインチューニング済みエンドポイントのためのオブザーバビリティダッシュボード

単一の指標を追跡することは役立ちます。しかし、すべてを一か所で見られるようになったときに、その見返りが得られます。

ファインチューニング済みエンドポイントの堅実なオブザーバビリティ構成は、4 つの柱に支えられます。レイテンシやエラー率のような集約シグナルのための メトリクス、1 リクエストの全経路のための トレース、何が起きたかの構造化された記録のための ログ、そして非同期の品質チェックのための 評価 です ^[40][42]。

これはファインチューニング済みモデルではさらに重要になります。リクエストは、AI チャット インターフェースを使う場合でも、システムレベルで成功しつつ意味レベルで失敗することがあります。だからダッシュボードは、単なる転送の成功ではなく、意味的な失敗を示す必要があります。旧来の APM は、レスポンスが健全だったことは示せます。答えが間違っていたかは教えられません。200 OK も、悪い結果を隠していることがあるのです。

ダッシュボードを 5 つのビューを軸に構築しましょう。レイテンシ、信頼性、コスト、品質、キャパシティ です。GenAI のセマンティック規約とともに OpenTelemetry を使い、トレースをテールサンプリングして、通常トラフィックのごく一部だけをサンプリングしつつ、すべての遅いリクエストと失敗したリクエストを保持しましょう ^[40][41]。その構成はインシデント時にも報われます。トレーシングは平均復旧時間を 3 倍 短縮できます ^[42]。

それらのシグナルを使って、5 つの中核パネルを持つダッシュボードを一つ作りましょう。レイテンシ、信頼性、コスト、品質、キャパシティです。

こう捉えると分かりやすいでしょう。レイテンシはシステムが どれだけ速く 動いたかを、信頼性はそれが稼働し続けたかを、コストは各回答にいくらかかっているかを、品質は回答が良かったかを、そしてキャパシティはシステムが過熱し始めるタイミングを教えてくれます。

ダッシュボード設計の表

この表は、各ダッシュボードのウィジェットを、最も適したチャート種別と、インシデントやコストレビューの際に有用にするフィルターに結びつけます。

それらのフィルターを初日から機能させるには、計装の際にトレースへモデル ID、プロンプトバージョン、環境のタグを付けましょう。OpenTelemetry の GenAI セマンティック規約には、gen_ai.request.model や gen_ai.usage.input_tokens といった属性が含まれます ^[40]。

障害パターンを一目で見つけやすくするチャートを選びましょう。

コスト帰属 は、どのモデルバージョンが支出を牽引しているかを示します。トレースエクスプローラー は、検索、ツール呼び出し、推論にまたがるレイテンシとエラーを示すため、RAG やエージェントのワークフローで最も重要です ^[43][40]。

各ウィジェットを定義したら、保持とサンプリングのルールを設定しましょう。高レイテンシ、エラー、低品質スコアのリクエストはすべて トレースエクスプローラー に保存します。そして通常の成功リクエストは 5%～20% でサンプリングして、ストレージコストを抑えましょう ^[40]。

結論

ファインチューンの評価は、単なる変化ではなく 改善 を証明しなければなりません。だからこそ、最終的なスコアカードは速度、信頼性、コスト、成果の指標を 一緒に 見る必要があります。

ある指標を単独でチューニングすると、本番の問題が素早く忍び込むことがあります。モデルは速くなっても安定性が下がるかもしれません。あるいはレビュー時間を削りつつエラーを押し上げるかもしれません。要点は、一部の断面ではなく全体像を追跡することです。

ベースモデルから始めましょう。そのベースラインがなければ、ファインチューンが何かをより良くしたことを示せません。5%～10% のカナリア を実行し、それらの結果をシャドールーティングを通じてベースモデルと比較しましょう。レイテンシが ベースラインの 2 倍 を超えたとき、あるいはエラー率が 5 分間 5% を超えたときにアラートを設定します。それらのガードレールを設定したら、数値を運用上の節約に結びつけましょう。

すべての指標は、ビジネス成果に対応づけられるべきです。人手レビュー率は、運用上の節約の直接的な代理指標です。その数値が動いていないなら、ファインチューンは本番価値を生み出していません。

ダッシュボードとアラートは任意ではありません。ローンチ前にオブザーバビリティを構築し、ユーザーが気づく前に回帰が表面化するようにしましょう。

よくある質問

まずどの API 指標を監視すべきですか？

システムが安定しているかを確認するため、インフラと信頼性 の指標から始めましょう。95 パーセンタイルの TTFT、エンドツーエンドのレイテンシ、ハードなエラー率、拒否率、リクエストあたりコスト に注目します。

それらのベースラインを得たら、LLM-as-judge のスコア と 能力のドリフト で出力品質を見ましょう。それが、モデルが中核スキルで滑り始めていないかを見つける助けになります。

ファインチューニング済みモデルをベースモデルとどう比較すればよいですか？

両方のモデルを同じホールドアウトのテストセット——訓練で一度も使っていないデータ——で実行して、ギャップをクリーンに測れるようにしましょう。まずベースモデルで強力なプロンプティングのベースラインから始めます。それが、都合よく仕込むのではなく、公平な比較点を与えてくれます。

モデルを 品質、レイテンシ、コスト にわたって比較しましょう。

品質には、仕事に合う指標を使いましょう。例えば次のようなものです。

• 分類や抽出タスクには F1
• 正解が一つのタスクには 完全一致
• 構造化出力には JSON パース率

レイテンシには、素のモデル実行時間だけでなく、エンドツーエンドの応答時間 を測りましょう。それは、プロンプト送信から最終出力までのリクエスト全経路の時間を計ることを意味します。

コストには、各モデルの 100 万トークンあたりの価格 を使い、テストセットでの実際の入力・出力トークン使用量に基づいて支払額を計算しましょう。

ファインチューニング済みモデルをいつロールバックすべきですか？

本番の監視が 品質が明確に低下した ことを示したときにロールバックしましょう。それはモデルのドリフトや、ライブ入力での失敗を示すことがあります。

モデルが拒否セットで滑る、新たなプロンプトインジェクションの弱点を開く、あるいは本番のカナリアテストで現行バージョンより劣る場合も、ロールバックすべきです。

p95 レイテンシ とユーザー報告の品質問題を注意深く見て、トラブルを早期に発見できるようにしましょう。