【要約】LLMアプリのトークン・レイテンシ・コストをOpenTelemetryで可観測にする（Django実装） [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
LLMを組み込んだWebアプリケーションの開発者が、運用フェーズにおいて「内部挙動の不透明さ」という課題に直面する。従来のWeb監視では、LLM特有の動的な挙動を十分に捕捉できない。
- ・コストがトークン量に依存し、従量課金のため予測が困難。
- ・プロンプトによりレイテンシが大きく変動する。
- ・レート制限や内容フィルタなど、失敗のパターンが多様。
- ・「動いているか否か」の二値判定では、連続的な変化を追えない。
// Approach
開発者がOpenTelemetry（OTel）を導入し、生成AI向けのセマンティック規約に基づいた計装を行う手法を提示する。これにより、ベンダーに依存しない可観測性を確保する。
- ・OTelの3本柱（トレース、メトリクス、ログ）を適切に使い分ける。
- ・
gen_ai.*規約に従い、モデル名やトークン数を属性として記録する。 - ・Djangoの自動計装を併用し、HTTPリクエストとLLM呼び出しを紐付ける。
- ・OTLPプロトコルを用い、送信先をCollector経由で柔軟に変更可能にする。
// Result
開発者がLLMアプリの運用において、具体的な数値に基づいた迅速な意思決定を行える状態を実現する。
- ・モデル別・時間帯別のコスト推移やレイテンシの傾向を把握できる。
- ・トレースにより「API遅延の原因がLLM待ちであること」を即座に特定できる。
- ・予算超過や性能悪化に対する、メトリクスベースのアラート運用が可能になる。
- ・Jaeger等のツールを用い、リクエストごとの詳細な内訳を可視化できる。
Senior Engineer Insight
> 実戦的な観点から、この設計は極めて合理的である。特に、コストとレイテンシをメトリクスとして集計し、詳細調査のためにトレースへ繋ぐ設計は、大規模運用において必須のパターンだ。ただし、プロンプト内容の記録による機密情報漏洩や、ユーザーID等の高カーディナリティ属性による時系列データベースの破綻には細心の注意を払うべきである。まずはメトリクスで異常を検知し、トレースで深掘りするという運用フローを確立せよ。