把重試預算算清楚：LLM 呼叫的「一次失敗」到底成本多少
上週一個朋友的線上服務半夜發出警報。模型服務商那邊一切正常，是我們這邊 23% 的流量在重試。更值錢的證據在帳單上：一個多月的 API 消耗裡，有相當一部分 429 重試其實是在重複一個註定會失敗的呼叫——那段時間服務商在降級，重試永遠救不回來，錢照燒。
小火龍實驗室
AI科普
把複雜的AI知識講得讓人類能聽懂
為什麼 LLM 會「一本正經地胡說八道」：幻覺的工程視角
做 AI 系統最常被問的一個問題：模型為什麼會犯錯？「幻覺」這個詞聽起來玄乎，拆開看其實是幾件很具體的事。
慢不是模型慢：AI 服務延遲裡藏著四個可量化的成分
上週幫一個團隊看線上問題：客服機器人回答太慢，用戶投訴，老闆一句「換更快的模型」。換完之後，P95 延遲降了大概 400 毫秒，投訴還是沒少。問題出在哪？他們只測量了「模型推論」這一段，但用戶感知到的等待時間裡，模型推論只佔一小塊。
為什麼「換更大的模型」常常不是答案：AI 系統的選型與降級鏈
上次一個朋友被線上故障逼到牆角，第一反應是「把 GPT-4 換成更大、更貴的模型」。結果故障沒好，帳單倒是翻了一倍。這個反應本身沒錯——大型語言模型確實更強。但大多數真實的線上問題，並不是「模型不夠聰明」，而是工程面沒把冗餘、成本、延遲這幾件事理順。先把這個區分清楚，後面所有選型決策才不至於跑偏。
推論超時不是玄學：給 LLM 呼叫設三個數
LLM 呼叫的超時糾結常常是這樣的：20 秒太短，長 prompt 偶發被掐斷；120 秒太長，上游掛了你的佇列先堵死。多數團隊最後是拍腦袋定一個值，然後每次故障復盤都要重新吵一遍。
把種子釘死：LLM 複現問題的最小修
複現是工程裡最便宜的品質訊號：同一份輸入、同一段程式碼、同一天跑兩遍，結果一致，你才能判斷這次改動是讓系統變好了，還是運氣好了。
15 分鐘手工打造一套 LLM 評估集：不用 MLflow，不用平台
每次更換模型、修改提示詞（Prompt）、調整 temperature，你想知道結果會變好還是變壞，但只能把剛生成的那幾段讀一遍，憑感覺說「感覺差不多」。這套流程撐得過 Demo，卻撐不過正式上線：感覺不穩定，不同人員之間標準不一致，過了兩週你自己也記不清上次到底是什麼水準。
為大型語言模型加上流量控制：為什麼 QPS 並非越高越安全
許多團隊將「QPS 限額」視為一個可以不斷調降的大數值，直到業務發出警報時再稍微調低。然而，閘道器上的速率限制其實扮演著更微妙的角色：它是您與模型推論叢集之間唯一的緩衝區。今天的主題就是該如何設定這個緩衝區，而許多人的直覺答案往往是錯誤的。
LLM API 呼叫重試怎麼寫：哪些錯誤該重試，哪些別碰
做過 LLM 服務的人都寫過這段程式碼：呼叫失敗，for 迴圈重試三次。看起來很穩，但生產環境的事故裡有一半跟這三行迴圈有關。LLM API 的失敗行為與傳統 HTTP API 不一樣，重試策略得按它的特性來設計。