用DeepSeek做多雲成本分析

簡而言之： 把每朵雲的帳單明細匯出來，歸一到同一種形狀——日期、帳號、服務、資源、標籤、用量、金額、幣別——然後讓DeepSeek去解釋兩個期間之間的差異，而不是讓它總結總額。它能原生讀懂中文的阿里雲匯出帳單，而這通常正是卡住的那一步。它修不了沒打標籤的資源，而沒打標籤的資源，正是多數這類分析失敗的原因。

財務每個季度都會拋來同一個問題：雲端成本漲了三成，為什麼？

在只用一朵雲的公司，這個問題用雲端業者自己的工具一個下午就能答完。而在本文說的這種資產規模裡——中國大陸業務跑在阿里雲上、區域其餘系統跑在AWS或Azure上、兩個法人實體、兩種幣別——沒有人答得上來，而誠實的原因不是能力不足。原因是：根本不存在一個地方，能讓這三份帳單以可比的單位並排放在一起。

於是答案變成了「雲端很貴」，預測數字變成了「上個季度加個百分比」，而真正的驅動因素又隱形了三個月。

這很適合交給語言模型，而且尤其適合DeepSeek，理由很平實：阿里雲的帳單匯出經常帶著中文的產品名和欄位名，而一個能原生讀懂這些的模型，直接砍掉了「財務團隊就此放棄」的那一步。

為什麼多雲帳單從設計上就不可讀

這不是陰謀——每一份帳單在自己內部都是自洽的。不自洽的是它們彼此之間。

分類體系對不上。 一家叫作一個「服務」的東西，另一家會拆成三個計量項，第三家又把它打包進執行個體費裡。沒有人先決定「運算」裡面到底裝什麼，「運算」在兩朵雲之間就不是一個可比的行項目。

顆粒度不一樣。 一份匯出給你按小時的資源級明細；另一份給你按天的計量項彙總。要比較，就得聚合到兩者中較粗的那個，並接受這份資訊損失。

稅和幣別的處理方式不同。 取決於簽約實體和地區，一份帳單可能是含當地稅呈現的，另一份是不含稅的。金額落在不同幣別裡，而你是按交易日、月底匯率、還是按財務系統已經入帳的匯率去換算，會讓比較結果的移動幅度超過你正在調查的那個差異本身。選定一種口徑，並把它寫下來。

法人實體不同。 一個中國實體付給一朵中國雲，一個香港或新加坡實體付給一朵全球雲，會產生關係人分攤，這意味著合併管理報表裡的那個數字，跟任何一份單獨帳單上的數字都不一樣。

這些事單看都不難。它們湊在一起，才是這個問題一直沒人回答的原因。

把帳單資料整理成同一種可比的形狀

匯出檔案，以及它們之間的差別

三家主要雲端業者都能產出明細帳單匯出，而不只是一份PDF發票。AWS的詳細成本與用量報告會把行項目級資料投遞到儲存；Azure的成本管理匯出用量明細的方式與之類似；阿里雲的費用中心可以匯出逐項帳單，而當帳號屬於中國大陸時，欄標題和產品名通常是中文的。具體的檔案結構、欄位名和匯出選項會隨時間變化——請查各家目前的官方文件，而不是相信你兩年前記下來的那套schema。

把所有東西歸一到一張扁平表，欄位都一樣：期間、雲端業者、帳號或訂閱、法人實體、服務、資源識別碼、標籤、用量、單位、原幣金額、幣別、以及換算成報告幣別的金額。整個訣竅就是這個，一點也不炫目。

DeepSeek的價值正是在這裡體現的。給它一份阿里雲匯出的樣本和你的目標schema，讓它產出欄位對應——包括一份中英文產品分類的對照，把比如「雲伺服器」和你給EC2、Azure虛擬機用的那個「運算」類別對上。讓它把對應產出成一張你保存下來反覆重用的表，而不是一次性的轉換。一份你能檢查、能修正的對應是資產；一個每季度重跑一遍的黑箱轉換是負債。

打標籤的紀律，決定了這套分析可不可能做

上面所有內容都是機械活。這一部分不是，而它決定了你最後拿到的是一份分析還是一個聳肩。

只有當資源身上帶著說明歸屬的標籤時，成本資料才可能歸到某個團隊、產品、環境或客戶頭上。沒打標籤的資源表現為「有成本、沒主人」，而在多數沒有被主動治理的資產規模裡，未打標籤的那一塊大到足以把整個答案吞掉。模型沒法推斷出某台執行個體屬於倉儲系統；它只能報告說你有三成八的支出無法歸屬——這件事本身值得知道，同時也極其令人不滿。

有兩件事能幫上忙。讓模型按命名規律、建立時間、地域，以及與已打標籤資源的鄰近關係，去把未打標籤的資源分群，產出一份供人確認的候選歸屬——一份明確標註為「猜測」的短名單。以及，在下一次分析之前、而不是分析當中，把最小標籤集定下來——負責人、環境、成本中心、應用。另外要注意：在AWS裡，標籤還必須先被啟用為成本分配標籤，才會出現在帳單資料裡，而這是「我們明明都打了標籤」這句話一個常見且悄無聲息的來源。

一個實際例子——解釋一次30%的季增

一家180人的公司，面向中國的平台以大陸實體跑在阿里雲上，區域系統以新加坡實體跑在AWS上。合併口徑下，第二季雲端支出比第一季高了三成。CFO要的是原因，不是一張圖。

把兩份匯出歸一之後，要求做一次差異分解——而不是總結——得到的是一份能加總回那三成的拆解，而不是一堆觀察。

大約三分之一是匯率和日曆，不是消費量。 兩個季度之間的匯率變動，加上多出來的一個計費日，占了不小的一塊。這不是一個節省機會，它是一個解釋；而把它單獨拆出來，能避免有人派工程團隊去解決一個外匯問題。

將近一半是一份到期失效的承諾折扣。 一份預留容量的承諾在季度中間到期，負載回落到了按量付費費率，而這個過程沒有任何東西失敗、也沒有任何告警。沒有人在盯那個續訂日期。這是單項金額最大、同時也最容易修的一條。

其餘是真實成長，外加兩項本可避免的支出。 一是沒有生命週期原則、持續堆積的儲存快照；二是四月為了一次壓測擴容、之後再沒縮回去的預備環境。兩者之所以一直隱形，是因為相對總額它們都不大，而且在任何一張發票上都不會作為一個獨立行項出現。

最後這一項值得多說一句。它被找出來，不是因為模型聰明，而是因為被問的問題是「哪些資源第二季比第一季花得多、為什麼」——這是一次機械比對，只是從來沒有人跨著兩家雲同時跑過一遍。

AI輔助成本分析 vs 雲端業者自帶的成本工具 vs FinOps平台

跨業者、跨幣別、跨實體的比較 — AI輔助分析勝出。這是原生工具在結構上做不到的一件事，因為每一個都只看得見自己那份帳單。
讀懂中文帳單匯出並對齊分類體系 — AI輔助分析勝出，而這正是DeepSeek適合這項任務的具體原因。
底層數字的準確性 — 雲端業者自帶工具勝出。它們才是事實來源，它們正確反映折扣與抵用金，而任何由AI推導出來的數字，在進董事會資料之前都應該回到它們那裡對平。
持續監控、告警與異常偵測 — FinOps平台勝出。持續監控是一個產品問題，不是一個提示詞問題；你不會希望自己的偵測機制是「每季度手工過一遍」。
承諾折扣與預留執行個體的最佳化 — 原生工具和FinOps平台勝出。兩者都會用業者自己的價格，把業者特定的承諾選項對著你的真實用量建模。
把差異解釋給非技術的財務團隊聽 — AI輔助分析輕鬆勝出。產出一份點名原因、並且每個原因都掛著數字的書面解釋，正好就是這項任務的形狀。

對一家中小企業而言，現實的做法是：用模型做季度解釋和跨雲視圖，把原生主控台留作數字的仲裁者，等支出規模撐得起授權費用時再買FinOps工具——而對多數這個體量的公司來說，還撐不起。

誠實地做預測

在四個季度的多雲帳單上拉一條趨勢線，會產出一個自信、平滑、錯誤的數字。雲端成本不是平滑的，而且它在哪些地方不平滑，是可以知道的。

承諾折扣是階梯函數。 一份預留到期或續訂，會讓基線突然移動。任何沒有把續訂行事曆作為輸入的預測，都是在對這個序列裡最大的、本來可預測的那次移動瞎猜。

移轉和一次性事項會扭曲基數。 新舊環境並行跑六週，會把一個季度撐起來。用一個包含了已完成移轉的基數去預測，等於把那筆重複成本建進了未來每一期。

成長在各服務之間並不均勻。 儲存和資料傳輸往往隨累計資料量成長，而不是隨人頭或營收成長，所以「人均」這個比率會低估它們。

更該要的是：一份把假設單獨列出、並且每個組成部分都說明依據的預測——這一塊是已承諾且合約鎖定的，這一塊隨某個說明白的驅動因素伸縮，這一塊是已知專案，這一塊是無法解釋的波動。然後再要一個區間。一個沒有區間的單一數字，是一句關於未來的假話；而財務團隊處理區間的能力，通常遠好於技術團隊的預期。

把這件事做對——帳單資料的敏感性、帳號權限，以及什麼時候該讓IT介入

在你匯出任何東西之前，有三點實務問題。

一份雲端帳單是關於你公司的商業情報。 資源數量、地域布局、服務組合、成長速度以及內部系統的名字，都可以從一份明細匯出裡推斷出來，而它們合在一起就描述了你的架構和你的走勢。請把它當作商業機密對待：把會暴露客戶或產品身分的資源名去掉、使用那個你真的讀過其資料處理與保留條款的方案，而對於負有中國大陸資料落地義務的組織——把「處理發生在哪裡」當成一個刻意的決定，而不是一個預設值。當限制是真實存在的時候，自建部署開放權重模型是一個正當選項。

唯讀的帳單權限就夠了，而且這也是正確的權限上限。 做成本分析不需要任何寫入權限。各家雲端業者都設計了對應的帳單角色，而「因為方便就多給了權限」，恰恰是把一次財務工作變成一條資安稽核發現的經典路徑。

解釋帳單和改變帳單不是一回事。 依據這些發現去行動，意味著調整執行個體規格、設定儲存生命週期原則、買對承諾折扣，以及搞清楚哪些負載能遷、哪些不能——包括那些因為ICP備案或資料落地限制而讓「搬走就是了」根本不成立的負載。這是委外IT雲端服務的工作範圍，它涵蓋跨阿里雲、AWS與Azure的多雲架構設計，包括在中國大陸的合規託管。我們的AI+支援與委外IT支援分列它的兩側。自2007年在北京創立以來，Brocent一直在亞洲各地做跨境IT，總部設於新加坡，2016年起在香港設有辦公室——也就是說，針對這種形狀的資產規模，這場對話我們已經談過很多次。同樣的「先歸一、再追問」套路，也適用於治理阿里雲安全群組規則。

常見問題

雲端帳單裡有敏感的業務資訊嗎？

有，而且比多數人以為的要多。一份明細匯出會暴露你跑著多少資源、在哪些地域、以什麼速度成長，並且——透過資源名和標籤——常常還暴露你的內部系統和客戶叫什麼。請把它當作商業機密對待，盡可能去掉帶身分資訊的資源名，並有意識地選擇處理環境。

怎樣公平地比較阿里雲和AWS的行項目？

在各家的產品分類和你自己的一套通用類別之間建立一份明確對應，並把這份對應作為可重用文件保存下來。聚合到兩者中較粗的那個顆粒度。定死一種貨幣換算口徑，並寫明。沒有把這三個決定寫下來就做出的比較是不可重現的，這意味著每個季度都要重吵一遍。

這能找出閒置或配置過剩的資源嗎？

僅憑帳單資料，它能找出很強的候選——持續計費但用量模式不像生產負載的資源、只漲儲存卻沒有對應運算的情況、名字帶著測試字樣卻全天候在跑的環境。而要確認某個東西真的閒置，需要的是使用率指標而不是成本資料，所以請把產出當成一份待查核的短名單，而不是一份刪除清單。

幣別和關係人分攤怎麼處理？

先定下換算口徑——交易日、期間平均、還是期末——並一致地套用，因為這個選擇造成的影響可能比你正在調查的差異還大。至於關係人分攤，請在「實際付給每家雲端業者的那份帳單」這個層級上做分析，把分攤當作一個獨立的會計步驟。把兩者混在一起，正是成本分析對不上管理報表的原因。

我們需要唯讀帳單權限，還是每月一份匯出就夠？

一份匯出足以起步，而且是阻力更小的路徑。當你希望把這件事從每季度變成每月做、或者希望不用等人產檔案就能查一下的時候，常設的唯讀帳單權限就值得了。無論哪種情況，唯讀都是正確的權限上限。

DeepSeek在這件事上確實更好，還是隨便哪個模型都行？

任何有能力的模型都能做這裡的算術和推理。它的具體優勢在於：無需先做一次有損的翻譯，就能處理中國大陸帳單匯出裡的中文產品名、欄位標題和發票術語——而對一個「中國加全球」的資產規模來說，這正是這類專案通常卡住的那一步。如果你的帳單全是英文的，那麼工具的選擇遠不如歸一化的紀律重要。

從哪裡開始

只拿一朵雲，取上個季度和上上個季度，單獨為這一家做一次差異分解。這個任務小到一個下午能做完，而它會立刻告訴你：你的支出裡有多大比例是沒打標籤的——這將決定這件事的多雲版本現在值不值得嘗試，還是說打標籤才是真正的第一個專案。如果答案最後指向架構而不是分析，那就是另一場對話了，而這場對話我們很樂意談：聯絡我們。