本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。
大規模モデルのリソース消費に関する洞察
王成（Wang Cheng）
大規模モデルアプリケーションをデプロイする場合、必ずCEOに事前に通知してください。大規模モデルアプリケーションは、Webアプリケーションと比べてリソースコストがはるかに制御しにくいものです。古典的なWebアプリケーション（eコマース、ゲーム、旅行、再生可能エネルギー、教育、医療など）では、CPU消費量がオンラインユーザー数やログイン時間と正の相関を持ちます。急な計算リソースのスパイクが発生した場合、それは通常、運営活動や予期せぬトラフィックの増加によるものです。サーバーの弾性スケーリング後、システムはしばらく安定し、その後通常の状態に戻ります。バックエンドでのリソース消費は追跡可能で管理可能です。しかし、大規模モデルにおけるトークン消費はそうではありません。
目次
- 大規模モデルにおけるトークン消費に影響を与える要因
- 大規模モデルにおける隠れたトークン消費源
- エージェントにおけるより複雑なリソース消費台帳
- 異常なトークン消費を制御するための初期的アプローチ
- まとめ
1. 大規模モデルにおけるリソース消費に影響を与える要因
Quantum Bit [1] の記事によると、「木の2つの道の間の距離」を入力すると、DeepSeekは無限の思考プロセスに陥り、625秒もの思考時間を消費し（下図参照）、20,000語の出力を生成します。このフレーズは複雑でも意味不明でもなく、完全に普通の質問に見えます。細かく見れば、表現が不十分である可能性はありますが、このような無限の繰り返し思考はモデル自体の精神的バーンアウトであり、計算リソースの浪費につながります。ハッカーに悪用されれば、これは推論モデルに対するDDoS攻撃のようなものです。では、オンラインユーザー数や使用時間以外に、大規模モデルにおけるトークン消費に影響を与える他の要因は何でしょうか？ここではDeepSeekを例として取り上げますが、他の大規模モデルAPI呼び出しの課金ルールや影響要因も類似しています。DeepSeekの公式サイト[2]に掲載されている課金ドキュメントによると、API呼び出しのコストは以下のパラメータに関連しています：
- モデルタイプ：V3とR1では百万トークンあたりの価格が異なり、R1の方が推論能力が高いため価格が高い。
- 入力トークン数：百万トークン単位で課金され、使用量が多いほどコストが高くなる。
- 出力トークン数：百万トークン単位で課金され、使用量が多いほどコストが高くなり、出力価格は入力価格を上回る。
- キャッシュヒット：キャッシュヒット時の単価はミス時よりも低い。
- ピーク・オフピーク：オフピーク時の単価は低い。
- 思考チェーン：出力時に消費されるトークン数。
さらに、オンライン検索プロセス中の検索リクエストや返されたデータの処理（コンテンツ生成前のステップ）もトークン使用量に含まれます。大規模モデルの意識を覚醒させるすべてのアクションはトークンを消費します。この課金ルールに基づくと、大規模モデルのリソース消費は以下の要因に関連します：
- ユーザー入力テキストの長さ：ユーザーの入力テキストが長いほど、消費されるトークンが増えます。一般的に、1中国語の単語、1英単語、1数字、または1記号は1トークンとカウントされます。
- モデル出力テキストの長さ：出力テキストが長いほど、消費されるトークンが増えます。例えば、DeepSeekの出力トークン消費価格は入力の4倍です。
- ユーザー入力コンテキストのサイズ：対話の文脈では、モデルが以前の対話を読み込む必要があるため、入力が大幅に増加し、トークンが増える。
- タスクの複雑さ：より複雑なタスクはより多くのトークンを必要とする。例えば、長いテキストの生成（論文の翻訳や解釈）や複雑な推論（数学や科学関連の質問）には多くのトークンが必要。
- 特殊文字、フォーマット、マークアップ：これらはトークン消費を増加させる。例えば、HTMLタグ、Markdownフォーマット、または特殊記号は複数のトークンに分割される可能性がある。
- 異なる言語とエンコーディング方式：これらはトークン消費に影響を与える。例えば、中国語は通常英語よりも多くのトークンを消費する。
- モデル自体に関連する要因：同じモデルでも、パラメータが大きいほど詳細な内容が出力されやすく、トークン消費が容易になる。
- 深層思考機能の使用：出力トークン数には思考チェーンと最終回答のすべてのトークンが含まれるため、深層思考機能を有効にするとトークン消費が増加。
- オンライン機能の使用：外部知識ベースやウェブサイトから情報を検索する際、モデルがトークンを消費する。
- セマンティックキャッシング機能の使用：キャッシュヒットとミスでは価格が異なるため、セマンティックキャッシングを使用することでリソース消費を削減できる。
2. 大規模モデルにおける隠れたリソース消費要因
前述の要因に加えて、大規模モデルアプリケーションにおいて異常なリソース消費を引き起こす多くの隠れた要因があります。
コードロジックの脆弱性
- 制御されていないループ呼び出し：再試行メカニズムの設定ミスにより、個々のユーザーセッションで重複呼び出しが発生する可能性がある。
- キャッシュメカニズムの欠如：キャッシュを利用しない高頻度の繰り返し質問は、類似の回答を繰り返し生成するためにトークンを消費する。
プロンプトエンジニアリングの欠点
- 冗長なコンテキストの持ち込み：完全な会話履歴を持ち込むと、単一リクエストでのトークン数が大幅に増加する。
- 非効率的な指示設計：構造化されていないプロンプトはモデル生成の効率を低下させる。
生態系依存リスク
- プラグイン呼び出しのブラックホール：プラグイン呼び出しの深さに制限がないと、単一クエリで繰り返しのチェーン呼び出しが発生する。
- サードパーティサービスの変動：ベクトルデータベースの応答遅延はタイムアウト再試行を引き起こし、間接的にトークン消費を増加させる。
データパイプラインの欠点
データ前処理中に生じる問題：データクリーニング、前処理、および正規化は、入力品質を向上させる標準的な方法です。ただし、修正や補完が新しい入力不足を引き起こす可能性もあり、これにより異常なリソース消費が発生する場合があります。
3. エージェントのリソース消費台帳はさらに複雑
エージェントについて話すとき、最近人気のMCP（Model Context Protocol）を見逃すことはできません。1月には、MCP十の質問 | モデルコンテキストプロトコルを迅速に理解する を紹介しました。また、MCPの収益化に関する概要も近日公開予定ですので、Higressの公式アカウントをフォローしてください。MCPは、大規模モデルとサ
以下は、知乎（Zhihu）の著者 @tgt が作成した図で、入力段階からエージェントの計画、メモリ、外部システムへの呼び出し、および出力実行がすべて大規模モデルを活性化させ、その結果トークンを消費することを示しています。さらに、出力を生成する前に自己修正プロセスを含めることで結果を向上させる場合、トークンのコストはさらに増加します。最近人気のある Manus は、多くのユーザー事例を展示し、印象的な実行結果を提供していますが、その背後には大きな計算コストがかかっています。一般的に、エージェントの成熟度が高まると、基盤モデルの呼び出し消費が大幅に増加します。
4. 異常なトークン消費を制御する方法に関する初期的探索
モデルリソース消費につながる要因が多岐にわたり複雑であるため、単一の製品やソリューションだけでこの問題を解決することはできません。完全なエンジニアリングシステムを、事前準備、プロセス中、事後対応の各段階で確立する必要があります。私たちはまだトークン消費の初期段階にいるため、以下は予備的な議論であり、今後より多くの実践を通じて、大規模モデルのコスト削減について理解が深まるでしょう。
（1）異常な呼び出しが発生する前：予防措置
a. リアルタイム監視と閾値アラートシステム
監視システム: リソース監視ダッシュボードを展開して、メトリクス、ログ、トレース、およびトークンをリアルタイムで追跡します。異常な呼び出しが発生した場合、迅速に障害を追跡し、レート制限を適用できます。[4]
アクセス制御: ユーザーID（APIキーなど）に対する権限レベルとアクセス制御を実装し、消費者認証機能を提供します。例えば、高頻度の呼び出しを制限することで、悪意のあるまたは意図しない操作による突然のリソース占有を防ぎます。[5]
b. データ前処理
フォーマットチェック: モデルを呼び出す前に、ユーザー入力をフォーマット、長さ、センシティブワードなどでチェックし、無効または異常なリクエスト（例：過度に長いテキスト、特殊文字攻撃など）をフィルタリングして、無駄なトークン消費を削減します。
RAG効果最適化技術: ベクトル検索を行う前にメタデータを使用して構造化検索を行い、ターゲット文書を正確に特定し関連情報を抽出することで、入力長を短縮し、トークン使用量を削減します。
セマンティックキャッシュ: 大規模モデルのレスポンスをインメモリデータベースにキャッシュし、それをゲートウェイプラグインとして実装することで、推論レイテンシとコストを改善します。ゲートウェイ層は各ユーザーの過去のダイアログを自動的にキャッシュし、それを以降の会話のコンテキストに適用することで、大規模モデルの文脈意味理解を向上させ、キャッシュミスによるトークン消費を削減します。[6]
c. パラメータ調整
温度パラメータ調整: モデルの出力動作を制御するためにパラメータを調整します。例えば、温度を変更するとモデルの出力のランダム性に影響を与えます。温度を下げると、モデルの出力はより決定論的になり、不必要なトークン生成を削減できます。たとえば、DeepSeekは公式にコード生成や数学問題解決では温度を0.0に設定することを推奨しており、一般的な対話では1.3に設定することを推奨しています。
出力長の事前設定: モデルを呼び出す際に、出力の最大長を事前に設定します。具体的なタスクの要件に基づき、モデルに約どの範囲で出力するかを明確に指示します。例えば、要約を生成する際には出力長を4kを超えないように設定し、過度に長いテキストを生成しないようにします。DeepSeekは最大8Kの出力長をサポートしています。
（2）異常な呼び出しが発生したとき：リアルタイム処理
a. アラートとレート制限メカニズム
アラート: トークン消費、呼び出し頻度、失敗率などの主要指標に対して動的なベースライン閾値を設定します。これらの閾値を超えた場合、アラートがトリガーされます。
レート制限とサーキットブレーカー: URLパラメータ、HTTPリクエストヘッダー、クライアントIPアドレス、消費者名、またはクッキー内のキー名などに基づいて、トークン消費の急増や異常な失敗率が検出された場合、自動的にレート制限がトリガーされ、必要に応じてブロッキングアクションが取られ、コア機能を保護し影響範囲を制御します。[7]
b. 異常な呼び出しのトレースと隔離
一時的なブロック: ログを分析して異常な呼び出しの原因（特定のユーザー、IP、またはAPIインターフェースなど）を特定し、それらの異常なリクエスタを一時的にブロックして、さらなるリソースの浪費を防ぎます。
（3）異常な呼び出しが発生した後：復旧と最適化
a. データ補正とコード修正
統計エラーの削減: オフライン計算タスクを通じて、データ更新の遅延によるエラー（トークン消費記録の欠落など）を追跡し再調整し、課金および監視システムの正確性を確保します。
コードレビューと修復: 大規模モデルを呼び出すコードを監査し、潜在的な論理エラーや脆弱性を修正します。例えば、モデルへのループ呼び出しがないか確認し、無限ループによる異常なトークン消費を防ぎます。
b. 攻撃のトレースと防御戦略のアップデート
異常な呼び出しログの分析: 呼び出しが敵対的攻撃（ポイズニング攻撃や悪意のある生成リクエストなど）によるものかどうかを特定し、ブラックリストルールを更新し、入力フィルタリングモデルを導入します。
身元認証メカニズムの強化: APIキー漏洩によるリソースの不正利用を防ぐために、二要素認証を実施します。
自動化アラートおよび処理メカニズムの改善: 自動化アラートおよび処理システムを強化し、異常なトークン消費への対応能力を向上させます。例えば、アラートルールを最適化してアラートをより正確かつ迅速にし、例外処理ワークフローを改善して効率を向上させます。
c. 長期的な最適化策
トークンの階層管理: 異なるビジネスに対して異なる権限を持つトークンを割り当て、コアサービストークンへの露出リスクを低減します。
自動テストと訓練: 定期的にトークン異常シナリオ（有効期限切れや故障など）をシミュレーションし、フォールトトレランスメカニズムの有効性を検証します。
5. まとめ
これまで、インフラストラクチャリソースの利用効率を向上させるために多大な時間と努力を投資してきました。現在、AIインフラストラクチャに関与しているすべての企業が、ハードウェア層からモデル層、推論最適化層、さらにはゲートウェイエントリ層まで、リソース利用の最適化に焦点を当てています。これは、エンジニアリングとアルゴリズムが協力して進む長い競争になるでしょう。