【要約】DeepSeekのFilesAPIを実測：帯域は92%減っても、トークンは1つも減らなかった [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が画像入力を繰り返すエージェントを構築する際、通信量とコストの増大に直面する。具体的には以下の課題が存在する。
- ・通信帯域の無駄：base64形式では画像データが約1.33倍に膨らみ、毎ターン再送される。
- ・コスト削減への誤解：Files APIを使えば画像トークン料金も安くなると誤認しやすい。
- ・コスト構造の不透明さ：画像入力コストとモデルの思考コストのどちらが支配的なのか不明である。
// Approach
検証者がDeepSeekの実験的モデルを用い、通信量と課金への影響を定量的に測定した。以下の手法で比較検証を行っている。
- ・比較手法：base64方式とFiles API方式による、10ターンのエージェントループ比較。
- ・計測指標：リクエストボディのバイト数、レイテンシ、使用トークン数（入力・出力・思考）。
- ・環境制御：
user_idパラメータを使い、キャッシュの影響を分離して計測。
// Result
実測の結果、Files APIの役割は通信の最適化に限定されることが明らかになった。得られた成果は以下の通りである。
- ・帯域削減：Files APIにより、繰り返し参照時の送信バイト数を約92%削減した。
- ・トークン不変：画像トークン数はFiles APIを利用しても、base64方式と完全に一致した。
- ・コストの真因：画像コストよりも、Thinking Modeによる出力トークンがコストの大部分を占める。
Senior Engineer Insight
> 技術責任者として、ネットワーク帯域と計算コストの分離を強く推奨する。Files APIは通信の最適化手段であり、課金の最適化手段ではない。帯域が細い環境では有効だが、コスト削減を狙うならまずThinking Modeの制御とキャッシュ活用を検討せよ。最適化の優先順位を誤ると、画像対策に工数を割いてもコストは下がらない。常に「バイト数」と「トークン数」を別軸で監視すべきである。