用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辅助分析轻松胜出。产出一份点名原因、并且每个原因都挂着数字的书面解释，正好就是这项任务的形状。

对一家中小企业而言，现实的做法是：用模型做季度解释和跨云视图，把原生控制台留作数字的仲裁者，等支出规模撑得起license费用时再买FinOps工具——而对多数这个体量的公司来说，还撑不起。

诚实地做预测

在四个季度的多云账单上拉一条趋势线，会产出一个自信、平滑、错误的数字。云成本不是平滑的，而且它在哪些地方不平滑，是可以知道的。

承诺折扣是阶跃函数。 一份预留到期或续订，会让基线突然移动。任何没有把续订日历作为输入的预测，都是在对这个序列里最大的、本来可预测的那次移动瞎猜。

迁移和一次性事项会扭曲基数。 新旧环境并行跑六周，会把一个季度撑起来。用一个包含了已完成迁移的基数去预测，等于把那笔重复成本建进了未来每一期。

增长在各服务之间并不均匀。 存储和数据传输往往随累计数据量增长，而不是随人头或收入增长，所以"人均"这个比率会低估它们。

更该要的是：一份把假设单独列出、并且每个组成部分都说明依据的预测——这一块是已承诺且合同锁定的，这一块随某个说明白的驱动因素伸缩，这一块是已知项目，这一块是无法解释的波动。然后再要一个区间。一个没有区间的单一数字，是一句关于未来的假话；而财务团队处理区间的能力，通常远好于技术团队的预期。

把这件事做对——账单数据的敏感性、账号权限，以及什么时候该让IT介入

在你导出任何东西之前，有三点实务问题。

一份云账单是关于你公司的商业情报。 资源数量、地域布局、服务组合、增长速度以及内部系统的名字，都可以从一份明细导出里推断出来，而它们合在一起就描述了你的架构和你的走势。请把它当作商业机密对待：把会暴露客户或产品身份的资源名去掉、使用那个你真的读过其数据处理与留存条款的档位，而对于负有中国内地数据驻留义务的组织——把"处理发生在哪里"当成一个刻意的决定，而不是一个默认值。当约束是真实存在的时候，自建部署开放权重模型是一个正当选项。

只读的账单权限就够了，而且这也是正确的权限上限。 做成本分析不需要任何写权限。各家云厂商都设计了对应的账单角色，而"因为方便就多给了权限"，恰恰是把一次财务工作变成一条安全审计发现的经典路径。

解释账单和改变账单不是一回事。 依据这些发现去行动，意味着调整实例规格、设置存储生命周期策略、买对承诺折扣，以及搞清楚哪些负载能迁、哪些不能——包括那些因为ICP备案或数据驻留约束而让"搬走就是了"根本不成立的负载。这是托管IT云服务的工作范围，它涵盖跨阿里云、AWS与Azure的多云架构设计，包括在中国内地的合规托管。我们的AI+支持与托管IT支持分列它的两侧。自2007年在北京创立以来，Brocent一直在亚洲各地做跨境IT，总部设于新加坡，2016年起在香港设有办公室——也就是说，针对这种形状的资产盘子，这场对话我们已经谈过很多次。同样的"先归一、再追问"套路，也适用于治理阿里云安全组规则。

常见问题

云账单里有敏感的业务信息吗？

有，而且比多数人以为的要多。一份明细导出会暴露你跑着多少资源、在哪些地域、以什么速度增长，并且——通过资源名和标签——常常还暴露你的内部系统和客户叫什么。请把它当作商业机密对待，尽可能去掉带身份信息的资源名，并有意识地选择处理环境。

怎样公平地比较阿里云和AWS的行项目？

在各家的产品分类和你自己的一套通用类别之间建立一份显式映射，并把这份映射作为可复用文档保存下来。聚合到两者中较粗的那个颗粒度。定死一种货币折算口径，并写明。没有把这三个决定写下来就做出的比较是不可复现的，这意味着每个季度都要重吵一遍。

这能找出闲置或配置过剩的资源吗？

仅凭账单数据，它能找出很强的候选——持续计费但用量模式不像生产负载的资源、只涨存储却没有对应计算的情况、名字带着测试字样却全天候在跑的环境。而要确认某个东西真的闲置，需要的是利用率指标而不是成本数据，所以请把产出当成一份待核查的短名单，而不是一份删除清单。

币种和关联方分摊怎么处理？

先定下折算口径——交易日、期间平均、还是期末——并一致地应用，因为这个选择造成的影响可能比你正在调查的差异还大。至于关联方分摊，请在"实际付给每家云厂商的那份账单"这个层级上做分析，把分摊当作一个独立的会计步骤。把两者混在一起，正是成本分析对不上管理报表的原因。

我们需要只读账单权限，还是每月一份导出就够？

一份导出足以起步，而且是阻力更小的路径。当你希望把这件事从每季度变成每月做、或者希望不用等人产文件就能查一下的时候，常设的只读账单权限就值得了。无论哪种情况，只读都是正确的权限上限。

DeepSeek在这件事上确实更好，还是随便哪个模型都行？

任何有能力的模型都能做这里的算术和推理。它的具体优势在于：无需先做一次有损的翻译，就能处理中国内地账单导出里的中文产品名、字段标题和发票术语——而对一个"中国加全球"的资产盘子来说，这正是这类项目通常卡住的那一步。如果你的账单全是英文的，那么工具的选择远不如归一化的纪律重要。

从哪里开始

只拿一朵云，取上个季度和上上个季度，单独为这一家做一次差异分解。这个任务小到一个下午能做完，而它会立刻告诉你：你的支出里有多大比例是没打标签的——这将决定这件事的多云版本现在值不值得尝试，还是说打标签才是真正的第一个项目。如果答案最后指向架构而不是分析，那就是另一场对话了，而这场对话我们很乐意谈：联系我们。