
每天 20 點發文,卻有兩個「今天」:流水線時區邊界怎麼咬出重複一天
這條內容流水線每天 20:00(SGT)發一篇文章,slug 前綴是 article-YYYYMMDD-,發之前要查一遍 CMS:今天這個前綴已經有行沒有,有就跳過,沒有才寫新的。聽起來是個兩行的邏輯。
深度內容,技術探索,設計思考

這條內容流水線每天 20:00(SGT)發一篇文章,slug 前綴是 article-YYYYMMDD-,發之前要查一遍 CMS:今天這個前綴已經有行沒有,有就跳過,沒有才寫新的。聽起來是個兩行的邏輯。

上個月對帳,批次匯出流水線一天的成本從三毛漲到快一塊錢。沒人收到警報,因為沒掛任何跟成本有關的警報。它不 crash、不超時、不降質,就是每一刀都比昨天厚一點。這種「故障」比 crash 難發現多了:crash 會喊疼,成本漂移只會安安靜靜地按月結帳。

凌晨三點,自動化任務跑了一整夜,儀表板上的解析成功率從 99% 掉到 71%。第一反應是資料來源出了問題,翻了兩小時的日誌才發現,情況相當尷尬:幾天前路由器進行了一次上游資源池遷移,我們一直使用的 qwen-cloud-plus 這個別名,被悄悄指向了另一個模型。提示詞(prompt)一個字都沒動,但它背後的權重已經換

上週我們的一條批次管線掛了。凌晨三點開始跑,十一點我去看儀表板,進度卡在 61%,任務狀態還是 running,日誌最後一行停在 03:42,行程還在,CPU 0%。

上個月,我給推理服務做的值班機器人開始大受歡迎:客戶報障,它就拉生產環境日誌的相關行餵給模型,讓模型給出診斷。直到有一天,一份診斷 Markdown 裡原樣出現了一串 32 位元的 token——那是同事啟動時 dump 環境變數列印的 API key,一直躺在日誌裡。

這個月初,我們的自主交付任務連續跑了三個通宵。早上查看帳單時發現,本月日均 Token 消耗量幾乎是上個月的兩倍。

上個月我們在本地推論機器上執行一個批次任務:對兩萬四千筆去識別化後的客服訊息進行分類,每筆都要經過一次本地模型,一趟跑滿四小時。

上週給一家客戶的內部問答系統做交付,最狼狽的不是模型答錯,而是熔斷器把整個服務切崩了。三次。三次都是同一個設定,三次都怪我沒想到。

上週我們做了件很常規的事:把本地推理閘道器後面掛載的主模型從 32B 換成 70B,推理框架小版本也順手升了一個號。按慣例,我們只跑了「冒煙測試」——三條典型問答,答案看起來都對,就合上了 PR,把閘道器切到了生產環境。