LLM 使用量ファイルの分析方法

すべての LLM 請求書の背後にはファイルがあります:プロバイダーが渡してくれる使用量エクスポートで、行ごと、モデルごと、日ごとです。ほとんどの人はそれを開きません。生のエクスポートは、合計も結論もないトークン数の壁だからです。このガイドは、そのファイルをどこで入手するか、その中に実際に何があるか、はっきり見えるようになったら探す価値のある 3 つのパターンを示します——このサイトの LLM 使用量分析ツールを使い、ファイルはあなたのブラウザ内でのみ読み取られ、他のどこでも読み取られません。

使用量をどこからエクスポートするか

プロバイダーが数値を保管している場所から始めてください。OpenAI は使用量を 2 か所で公開しています:プロバイダーコンソールの使用量ページは、現在の請求期間について日ごととモデルごとに活動を要約します。使用量 API は、同じデータを JSON として返します——時間バケットで、それぞれがコンテキストトークン、生成トークン、リクエスト数とともにモデルごとの結果を保持します。その JSON 形式は知っておく価値があります。スクリーンショットなしでアーカイブし、比較し、ツールに供給できる形式だからです。今日から始める価値のある習慣:月に一度 API レスポンスを取得して保存してください。プロバイダーはコンソールに限られた期間の履歴しか保持しません。あなた自身のアーカイブこそが、あなたが実際に費やしたものの、月ごとの唯一の完全な記録です。

Anthropic は、コンソールとレポート API を通じて、同じ精神で使用量とコストのレポートを公開しています:日ごととモデルごとに集計され、表形式データとしてエクスポートできます。他のプロバイダーは洗練度はさまざまですが種類は同じです——使用量または請求ページからの CSV ダウンロード、または日付付きの行を返す API エンドポイントです。一般的な形式こそが、どんな分析にも必要なすべてです:日付、モデル名、入力トークン、出力トークン、そして運が良ければキャッシュトークン、リクエスト数、コスト列。プロバイダーが複数のエクスポートを提供する場合は、最も粒度の細かいものを選んでください——日ごとのモデル別は月ごとのプロジェクト別に勝ります。自分で行った集計はいつでも元に戻せますが、プロバイダーが行った集計は戻せないからです。

ファイルに実際に含まれているもの

使用量の行は、小さくて密度の高い主張です:この日に、このモデルはこれだけのリクエストを処理し、これだけの入力トークンを読み——そのうちこれだけがキャッシュされ——これだけの出力トークンを書きました。それらの列を持つファイルを読むと、ワークロードの形状についてほぼすべてを再構築できます:プロンプトが長いか短いか、回答が冗長かどうか、トラフィックが安定しているかバースト的か、どのモデルが本当の仕事をしているか。ファイルが意図的に含まないものも同じくらい重要です:プロンプトテキストなし、補完なし、ユーザーコンテンツなし。それは数と名前であり、だからこそ、それが記述するトラフィックよりも自由に扱うことができます——ただし、最後のセクションが主張するように、「より自由に」とは「どこでも」という意味ではありません。

2 つの列は、どんな分析の前にも疑う価値があります。1 つ目はコスト:一部のエクスポートは請求されたコストを、一部はリスト価格の見積もりを、一部はまったく何も含まず、ファイルはめったにどちらかをラベル付けしません。コスト列はプロバイダーの数値として扱いますが、合計を信頼する前に日付範囲とスキップされた行や部分的な行を確認してください。2 つ目はキャッシュトークン列で、プロバイダーは少なくとも 5 通りの異なる名前を付け、時には分けて表示せずに入力数に折り込みます。入力トークンがそのモデルにしてはあり得ないほど安く、または高く見える場合、ヘッダーが最初に見るべき場所です——だからこそ分析ツールは、ヘッダーから検出した列の対応付けを表示し、何かが計算される前に修正できるようにします。

探すべきもの:3 つのパターン

1 つ目、キャッシュトークン比率。キャッシュされた入力を総入力で割り、モデルごとに計算します。繰り返し構造を持つワークロード——システムプロンプト、ドキュメントの接頭辞、固定したツールスキーマ——は、その接頭辞が呼び出しごとに同一であるため、入力の大部分をキャッシュするはずです。そうしたワークロードで比率がゼロに近い場合、キャッシュがオフになっているか、呼び出しの間にキャッシュが期限切れになっているか、接頭辞の中の何かがリクエストごとに変化している——タイムスタンプ、ランダムな id、並べ替えられたフィールド——そして静かにそれを打ち負かしていることを意味します。その 1 つの数値を修正することは、日常的にモデルを再交渉するよりも価値があります。主要なプロバイダーのすべてで、キャッシュされた入力は全額料金の何分の一かで請求されるからです。

2 つ目、モデルの構成。モデルをリクエスト数ではなくコストで並べ替えます:構成が健全なのは、高価な層のコストシェアが、それを本当に必要とする仕事のシェアとおおよそ一致する場合です。注意すべきドリフトは、フラッグシップモデルのコストシェアが月ごとに上昇するのに、そのリクエストシェアが横ばいであることです——より長いプロンプト、より長い出力、または誰も設定したことを覚えていないデフォルトによって大きなモデルへ静かにルーティングされる新しいトラフィック。3 つ目、集中と急増:1 つの API キー、プロジェクト、またはモデルがファイルを支配することは、コストの事実であると同時に爆発半径の事実であり、日ごとの急増——特に週末や夜間、誰も働いていなかった時間——は、リトライループ、暴走したエージェント、または行使されている漏洩したキーの兆候です。日別テーブルは、その急増を見逃せなくするために存在します。

コストを持たないファイルの価格付け

多くのエクスポートにはコスト列がまったくなく、その場合、分析はファイル自体に価格を付けなければなりません。分析ツールは透明な方法でそれを行います:各行は、このサイトの LLM 料金表から価格付けされます——コスト計算ツールも使う検証済みのリスト料金で、プロバイダー自身の式を使います:キャッシュされていない入力は入力料金、キャッシュされた入力は存在する場合はキャッシュ料金、出力は出力料金。モデル名は厳密に照合されます:正確に、プロバイダー接頭辞を取り除いた後、または末尾の日付や「latest」サフィックスを取り除いた後。その厳密さこそが要点です。より緩い曖昧な照合は、最終的にファインチューンをそのベースモデルとして、またはプレビューをリリースとして価格付けし、合計は得ていない自信を得ることになります。

だからこそ、何にも一致しないモデルは一覧化され、推測されません。それらのトークンとリクエストは依然として数えられます——そのボリュームを見て、欠落が重要かどうかを判断できます——が、そのコストは空欄のままとされ、結果にはそのお金がどこから来たかがラベル付けされます:ファイル自体、表から計算、混合、またはなし。計算された合計を読むときは、その基準で保持してください:それは、あなたの割引、クレジット、バッチ料金、階層化された長コンテキスト価格を知らないリスト価格の算術であり、請求書とセント単位で一致することはありません。それが確実に行うのは順位付けです:どのモデル、どの日、どのパターンが請求書を支配しているか。コストの仕事では、順位付けが通常、意思決定に関連する部分です。

プライバシー、そして月次ルーチン

使用量ファイルにはプロンプトテキストは含まれませんが、運用上は依然として機密です:あなたが実行するすべてのモデル、日ごとのボリューム、成長曲線、支出を名指しします——システムがどのように構築されているかを示す、競争上およびセキュリティ上関連する指紋です。だからこそ、LLM 使用量分析ツールはファイルをあなたのブラウザ内でローカルに解析し、決してアップロードしません。一般的なルールは、この 1 つのツールをはるかに超えて通用します:ファイルがあなたのインフラを要約すればするほど、それをホストされたチャットや未知のコンバーターに貼り付けることは悪い考えになります。ファイルが文字通りの意味で秘密を含まない場合でもです。集計も漏洩します。ただ、より静かにです。

実際に起こるほど小さなルーチンで締めくくります。月に一度:ファイルをエクスポートし、分析し、4 つの数値を書き留めます——総コストとその出所、トップモデルのコストシェア、キャッシュトークン比率、そして最大の単一日。前月の 4 つの数値と比較します。その 5 分間の差分は、ドリフト、急増、打ち負かされたキャッシュを、それらがまだ安いうちに捕らえ、1 年かけて、どのプロバイダーコンソールもあなたのために保持してくれないアーカイブを構築します。請求書は、請求書しか読まない人を驚かせます。使用量を読む人を驚かせることはめったにありません。

よくある質問

どちらのエクスポートを使うべきですか——コンソール CSV ですか、使用量 API JSON ですか?

どちらでも。それらは同じ活動を記述しています。コンソール CSV は最も早く入手でき、一度だけ見るには十分です。API JSON はより良い習慣です:完全で、スクリプト可能で、アーカイブ可能で、モデルごとのトークンフィールド(コンテキスト、生成、存在する場合はキャッシュ、リクエスト数)を安定した形式で保持します。2 つが一致しない場合は、まず日付範囲とタイムゾーンを確認してください——コンソールのビューは多くの場合ローカル時間で表示されますが、API のバケットは UTC であり、それが日の境界をずらし、合計を変えることなく隣接する日の間で支出を移動させます。

キャッシュトークン比率がゼロに近いです。何がプロンプトキャッシュを壊しますか?

通常の原因は順に:トラフィックが通るルートでキャッシュが有効でない、または提供されていないこと。呼び出し間の間隔がキャッシュの寿命を超え、すべてのエントリが再利用前に期限切れになること。またはプロンプトの接頭辞が呼び出し間で実際には同一でないこと——注入されたタイムスタンプ、リクエストごとの id、シャッフルされたツールリスト、ユーザー固有の最初のメッセージはすべて接頭辞を変え、キャッシュを外します。冒頭で 2 つの生のリクエストをバイトごとに比較してください:最初に異なるものが、キャッシュが一致を止める場所です。修正は、可変なものをすべて安定した共有接頭辞の後に移動することです。

なぜツールは私の一部のモデルに価格を見積もりませんか?

その名前について、その表に正直な価格が存在しないからです。ファインチューンはベースモデルのエンジンを継承しますが、その価格を必ずしも継承せず、プレビューはリリースとは異なる請求をされることが多く、サードパーティの展開は独自の契約に従います——それらのいずれかを推測すると、合計は完全に見えるようになりますが、間違ったものになります。代わりにツールは、それらのモデルをボリュームとともに一覧化します。そうすれば、その部分を契約や請求書から自分で価格付けし、各数値の出所を明確に保ちながら計算された合計に加えることができます。