LLM API 成本怎麼算：把 Token 帳算清楚
開發 LLM 應用時，最常被問到的一句話是「這個功能每天要花多少錢」。答案取決於一個變數：每次請求消耗多少 Token。這篇文章將這筆帳拆開來算一遍，順便講講哪幾個地方最容易算錯。
小火龍實驗室
AI科普
把複雜的AI知識講得讓人類能聽懂
大型語言模型呼叫如何拆解成本：談談模型串聯
許多團隊一提到降低成本，第一反應是換成小型模型，不然就是刪減預算。這兩種方法都過於粗糙。另一種更可控的做法稱為模型串聯（Model Cascade）：讓便宜的模型先處理，當便宜模型「信心不足」時，再交給昂貴的模型處理。
1 個 token ≈ 多少字：LLM 計費裡的隱形單位
如果你算過 AI API 的帳單，會發現計量單位不是「字」也不是「詞」，而是 token。工程師常見的第一個問題：一個 token 是不是等於一個字？不完全是。
它明明讀完了好幾萬字，為什麼關鍵資訊還是漏了：lost in the middle
你大概見過這種場景：把一份 30 頁的需求文件整個餵給大型語言模型，讓它總結並列出驗收標準。它洋洋灑灑回你一頁，結構漂亮，語料庫裡的術語一個不少——但恰好漏掉了第 14 頁那句「退款必須在訂單建立後 48 小時內發起」。
為 AI 系統進行回歸測試：LLM 評估的工程實踐
傳統系統修改了一個函式，執行一遍單元測試，全部通過就提交。在 LLM 應用中，這套方法失效了：輸出具有隨機性，同一個問題，這次回傳「好的」，下次可能回傳「好的沒錯」。修改了一版 prompt 後，如何確定沒有破壞其他功能？答案與軟體工程一致：建立一套回歸測試集。
請求不等齊才出發：推論服務裡的連續批次處理
上週有讀者問：為什麼同樣一張 GPU，別人跑的請求量是你們的三倍？模型一樣、量化方式一樣、顯示卡也一樣。差距往往不在模型，而在排程。
大模型的首字為什麼總是最慢？
下次把長文件發給大模型時，留意一個不算稀奇但很少被解釋的體驗：第一個字「打」出來要等好幾秒，等它出現之後，後面的字反而越吐越快。這不是網路抖了，是模型本身兩階段的分工造成的：prefill 和 decode。
結構化輸出不是「求模型聽話」，是推理器在解碼時的約束工程
很多生產團隊遇到同一個問題：模型答得挺流暢，但回傳的 JSON 偶爾會缺個括號、多個逗號、欄位名稱打錯，下游解析一報錯，整條流水線就斷。於是有人把鍋甩給「模型不穩定」，也有人試圖靠 prompt 反覆叮嚀「一定要輸出合法 JSON」。
同一個 Prompt，為什麼這次跑對上次跑錯：LLM 推論的非確定性與工程對策
在生產環境裡，最折磨人的 bug 往往不是報錯，而是「時靈時不靈」：同一個 prompt，連發五次，兩次答對，三次答錯。這背後不是玄學，而是 LLM 推論裡幾個可以量化的機制。