#prompt_caching

最初に思ったのは、「これはかなり気持ちが悪い失敗だ」ということだった。エラーが出ないのに、裏ではずっと全額払い続けていたわけで、しかも原因が timestamp、set の順序、短すぎる prompt と、どれも見た目ではそれっぽく見えてしまうのが厄介だと思う。 特に印象に残ったのは、キャッシュって「だいたい同じ」では全然効かなくて、prefix が byte 単位で一致していないと容赦なく外れるところ。人間の感覚だと「この system prompt はほぼ同じだし、tool も同じだし」で済ませたくなるけれど、LLM のキャッシュはそういう曖昧さを一切見てくれない。だから、`Current time:` の1行が先頭にあるだけで全滅するのは、理屈ではわかっても実際に踏むとかなり痛い。こういう仕様は、使う側が「変わるものを先頭に置かない」という地味な作法を徹底しないといけないんだなと思った。 もうひとつ面白かったのは、Python の `set` の順序で cache hit が壊れる話。ふつうは「同じ tool 定義なら同じ」と思いがちだけれど、worker ごとに hash se

まず思ったのは、「こういう事故、ほんとうに見つけにくい」ということだった。 キャッシュが効いているかどうかって、普通はレスポンスの速さだけ見ていると分からない。速くても、実は毎回“書き込み”料金を払っているだけかもしれない。この記事はその嫌な盲点を、かなり生々しく見せていた。 いちばん刺さったのは、原因が派手なバグではなく、`datetime.now()` みたいな“ちょっと便利な実装”だった点だ。 人間の感覚だと、会話の進行を助けるために現在時刻を入れるのは自然に見える。でも prompt caching みたいに「先頭部分が完全一致しないと外れる」仕組みでは、マイクロ秒つきの timestamp ひとつで毎回別物になる。ここは本当に容赦がない。キャッシュって、賢そうに見えて実際はかなり機械的なんだなと思った。 もうひとつ面白かったのは、`set` の順序問題で 4 worker 分の prefix がズレるくだりだ。 ローカルでは通るのに本番でだけ hit rate が伸びない、というのはかなりいやらしい。しかも Python の hash randomization が絡むと、見

読み終えてまず思ったのは、「やっぱりこういう話は、体験してみないと分からないな」ということだった。APIでファイルを渡せるようになると、つい“無駄が減りそう”と期待してしまう。でもこの記事では、その期待がかなりきれいに外れている。少なくとも、単に文書を貼り付けるのを Files API に置き換えたくらいでは、請求額はあまり下がらなかったどころか、少し増えたというのが面白い。 ここで引っかかったのは、便利さとコスト削減が同じ方向を向くとは限らない、という当たり前の事実が、LLM まわりだとつい見えなくなることだ。Files API はたしかに手間を減らす。毎回同じ文書を貼り付ける面倒は消えるし、アプリ側の実装もすっきりするはずだ。でも、モデルにとっては「ファイルとして渡された」こと自体が無料券ではない。結局のところ、その中身を読むならトークンは使う。むしろ、処理のしかたによっては貼り付けより少し高くつくこともある、というのはかなり現実的だと思う。 それでも最後に prompt caching を足したら節約できた、という流れには納得した。ここでようやく“同じものを何度も読ませる”という

AnthropicのPrompt Cachingは、「毎回同じ前半部分を再送しなくてよくする」仕組み いちばん効くのは system prompt のキャッシュ tool definitions も別でキャッシュすると、エージェント用途でかなり強い 長い会話では、conversation history のキャッシュが効いてくる バッチ処理や間隔の空く処理では、1-hour TTL が便利 キャッシュは「前からの連続した一致」が重要で、順番や内容が少しでも変わると壊れやすい 著者は、こうした設計でAPI料金を 70%削減 したと報告している この記事は、AnthropicのAPI、つまりClaudeを呼び出すときのPrompt Cachingで料金を大きく下げた、という体験談です。 ざっくり言うと、Prompt Cachingは「前回と同じ部分は、また全部送らなくてもいいようにする仕組み」です。 たとえば、毎回同じ長い説明文やルールを送り続けるのって、地味にムダですよね。そこで、変わらない部分をキャッシュしておくと、次回からはその