ngrok 這篇在講 prompt caching 的文章很值得看,以前做產品只會在那邊算一萬 token 要多少錢,看完才意識到,真正花錢的是一樣的開頭 prompt 你每天幾百次在重算。 它把 Transformer 裡面在 cache 的東西解釋的很清楚,不是什麼神祕黑科技,就是把 attention 的 K/V 結果存起來,下次同一段開頭 prompt 就不用重跑一遍 attention。 對有長系統 prompt、長規則、長說明書的應用來說,其實只要肯花時間重構一次 prompt,把可重用省下來,那你的 token 成本跟延遲就可以顯著下降。 做產品的人應該都有類似的經驗,模型好像可以可是雲端帳單就是很高的無力感,之前我們有用過類似的做法,所以滿推薦大家可以試試,把這種底層機制當成產品設計的一部分,而不是交給雲端廠商自動幫你通靈。 https://ngrok.com/blog/prompt-caching
位置圖Vibe Coding河谷一帶
2 週
全圖
電子報
下一篇寫好時,寄給你。
新文章上站時寄一封信,不寄別的。隨時一鍵退訂。
← 上一篇 · 2025.12.20Professional Software Developers Don't Vibe, They Control 下一篇 · 約 2026.01 →繼續當個Giver
附近的石堆 · 地圖上離這篇最近的文章
Vibe Coding河谷相距 10 天 可觀測性那篇寫完之後,我覺得下一步就是 eval 我上次寫 LLM observability 變成標配,核心是讓系統行為「看得見」,但看得見之後,下一個問題馬上浮上來。你看見一堆 trace 了,所以呢?你要怎麼確定你改了 pr… Vibe Coding河谷相距 8 天 Professional Software Developers Don't Vibe, They Control Professional Software Developers Don’t Vibe, They Control: AI Agent Use for Coding in 2025… Vibe Coding河谷相距 23 天 Google 怎麼回來的 大多數人都記得 2022~2023 是 OpenAI + ChatGPT 定義整個生成式 AI 的年代;而 Google,一度因為 創新者的兩難 看起來像是要不行了 但從 2025…