cost-aware-llm-pipeline

Topics in the source

• コスト認識LLMパイプライン
• 起動条件
• コアコンセプト
• 1. タスクの複雑さによるモデルルーティング
• 2. 不変のコスト追跡
• 3. 狭いリトライロジック
• 4. プロンプトキャッシング
• 合成

品質を維持しながらLLM APIのコストをコントロールするためのパターン。モデルルーティング、予算追跡、リトライロジック、プロンプトキャッシングを組み合わせた合成可能なパイプライン。 LLM APIを呼び出すアプリケーションの構築（Claude、GPTなど） 複雑さが異なるアイテムのバッチ処理 API支出の予算内に収める必要がある場合 複雑なタスクの品質を犠牲にせずにコストを最適化する場合 シンプルなタスクには自動的に安価なモデルを選択し、複雑なタスクのために高価なモデルを予約します。 凍結データクラスで累積支出を追跡します。各API呼び出しは新しいトラッカーを返します — 状態を変更しません。 一時的なエラーのみリトライします。認証やリクエストエラーでは素早く失敗します。 長いシステムプロンプトをキャッシュして、リクエストごとに再送信しないようにします。 4つのテクニックすべてを単一のパイプライン関数に組み合わせます： | モデル | 入力（$/1Mトークン） | 出力（$/1Mトークン） | 相対コスト | |-------|---------------------|----------------------|---------------| | Haiku 3.5 (legacy) | $0.80 | $4.00 | 0.8x | | Haiku 4.5 | $1.00 | $5.00 | 1x | | Sonnet 5 | $2.00 | $10.00 | 2x | | Sonnet 4.6 | $3.00 | $15.00 | 3x | | Opus 4.8 | $5.00 | $25.00 | 5x | | Fable 5 / Mythos 5 | $10.00 | $50.00 | 10x | | Opus 4.0 / 4.1 (legacy) | $15.00 | $75.00 | 15x | 最も安価なモデルから始める、複雑さの閾値が満たされた場合にのみ高価なモデルにルーティングする バッチ処理の前に明示的な予算制限を設定する — 過剰支出より早期に失敗する モデル選択の決定をログに記録する、実際のデータに基づいて閾値を調整できるように 1024トークンを超えるシステムプロンプトにはプロンプトキャッシングを使用する — コストとレイテンシーの両方を節約 認証またはバリデーションエラーではリトライしない — 一時的な失敗のみ（ネットワーク、レート制限、サーバーエラー） 複雑さに関わらずすべてのリクエストに最も高価なモデルを使用すること すべてのエラーでリトライすること（永続的な失敗で予算を無駄にする） コスト追跡の状態を変更すること（デバッグと監査が困難になる） コードベース全体にモデル名をハードコードすること（定数または設定を使用する）

This is an excerpt. Refer to the complete source and its current requirements.