客户问“我没在用，为什么云账单还在涨”——每个在线用户，都是一台没关机的云主机

你以为账单涨是因为 AI 太聪明、算得太多其实大半是在为一台没人用的显示器付电费。先说一句可能会让你有点意外的话一个 Agent 产品最烧钱的时刻往往不是用户拼命在用的时候而是用户压根没在用、把屏幕开着挂在那儿的时候。这听起来不合常理。按道理用得多才该贵用得少就该便宜。可真到了做 Agent 的中小厂手里账单偏偏不按这个道理走。更让人憋屈的是这不是个例。几乎每一个刚把 Agent 产品跑起来、准备大干一场的中小团队都会在某个月底撞上同一张让人发懵的账单然后开始怀疑人生是不是我哪里配错了是不是被云厂商坑了还是这门生意本身就不该做这一篇咱们就把这件没在用也涨的怪事从头到尾摊开讲清楚。不讲怎么解决——解决办法留到下篇卷起袖子干活——这一篇只干一件事把为什么贵、贵在哪、痛在哪讲到你心里去。一、一张让老板发懵的账单先讲个故事。有个做 AI 工具的小团队咱们就叫它某 AI 工具团队老板叫小 A。产品上线小半年用户不多不少活跃度平平——白天有人零零星星地用晚上基本没人周末更冷清。按小 A 的估算就这么点用量云账单不至于吓人。结果月底账单一出来小 A 盯着屏幕愣了半天。不是数字大得离谱而是那条一直往上爬的曲线——用户活跃度明明没怎么涨账单却一个月比一个月高。他一行一行往下扒最后目光钉死在其中一行上实例常驻费。这一行占了大头而且雷打不动跟用户用没用、用多少几乎没关系。小 A 想不通。他反复念叨一句话“我的用户大半时间根本没在用啊没人用这钱是烧在哪儿了”这个困惑说出了几乎所有做 Agent 的中小厂老板共同的心声。你能感觉到钱在往外流却抓不住它到底流去了哪。你甚至会怀疑是不是被云厂商多收了翻明细、去比价翻半天发现——云厂商没多收一分是你自己的账本来就是这么算的。问题不在云厂商问题在你根本没搞清楚一件事你以为你在为用量付费其实你在为占用付费。这俩差着十万八千里。想把这事讲透得先请出这一篇会一直陪着咱们的一个比喻——住酒店的全职管家。你雇了一个全职管家。他不住你家住在你家隔壁的酒店房间里24 小时待命随叫随到。听起来很爽——你想使唤他的时候喊一声人就来了。但有一个前提你可能没细想只要这个房间给你开着房费就一直在走跟你今天有没有使唤他一点关系都没有。你今天出差了、忙别的了、压根没找他房费照收。你睡了一整天房费照收。房间空着灯还亮着房费还是照收。小 A 账单上那行实例常驻费就是这笔房费。而且你越琢磨越不对劲小 A 请这个管家本来是想让他关键时刻能上。可现实是关键时刻一个月也没几回房费却是一天不落地在走。他为能上这件事付的钱远远超过了管家真上那几次创造的价值。说到底账单涨不是因为你的 AI 干了多少活是因为你替每一个用户都在酒店常年包了一间房。这句话就是这一篇要给你讲透的全部。二、把账单摊开看为什么没在用也涨要理解这笔房费得先理解一个技术事实不过我保证用大白话讲清楚。你产品里的那个 AI它不是凭空飘在云里的一段聪明。它得有个落脚的地方——一个能读文件、能跑程序、能连各种工具、能记住你们聊到哪儿的身体。业界给这个身体起了个名字叫容器也常被叫做 pod。你就把它理解成一台专门伺候这个用户的云主机。那么问题来了这台云主机什么时候是开着的在最常见、也最省事的架构里答案是——用户一登录就给他开一台这台机器就一直常驻在那儿直到用户走人。这就是所谓的一人一 pod一个在线用户配一台专属云主机。这么做隔离性极好用户 A 的东西和用户 B 的东西物理上分得清清楚楚绝不会串。做产品的人爱它因为它安全、干净、不容易出乱子。上线初期你也很难想到别的更稳妥的做法——毕竟每个用户一台独立机器出了问题也炸不到别人谁都睡得踏实。可代价呢代价就藏在那个词里——常驻。这台机器不是用的时候才开、用完就关。它是只要用户还挂在线上哪怕在发呆、哪怕切出去刷手机、哪怕对着屏幕一个字没敲机器都开着、内存都占着、钱都在烧。这里就得说说云计算收钱的门道了。云上的机器怎么计价据 AWS Lambda 官方的定价说明它的计费锚点是按分配的内存乘以运行时长——说白了你占了多大的内存、占了多长时间就付多少钱。内存越大、占的时间越长钱烧得越猛。这里有个特别反直觉的点值得多说一句这个公式里压根没有用了几次算了多少这一项。它只关心两个变量——你占了多大的内存、占了多久。换句话说云不是按你用了多少收钱是按你占了多少、占了多久收钱。这跟你交房租一个道理房东不会问你这个月在家住了几晚他只看你这间房租了多少天。你看这两件事一撞——一边是一人一 pod、只要在线就常驻一边是云按内存乘时长收钱——结论就冷冰冰地摆在那儿了用户在不在用压根不进入这个账单公式。进入公式的只有这台机器开着没有“开了多久”。这就是小 A 想不通那件事的答案。不是他被坑了而是他一开始就把账算错了。他以为账单跟着用量走实际上账单跟着占用走。用户没在用机器却没关——账单当然照涨。回到那个管家的比喻你现在就全懂了“没在用还涨账单”不是管家偷懒了也不是酒店乱收费而是酒店房间只要给你开着房就计费这件事跟你有没有使唤管家从头到尾没有半点关系。再说一句可能更扎心的这种架构下一个特别安静、特别乖的用户——登录进来挂着一整天没敲几个字——他给你烧的钱跟一个拼命用的用户几乎一样多。因为他俩的房间都开了一整天。所以真相是这样的贵的不是 AI 在思考而是每个用户都在云端常年占着一间房。你为聪明付的钱其实没多少你为开着付的钱才是大头。三、贵在哪三笔藏在暗处的账光知道占用要花钱还不够得知道这笔占用费具体贵在哪几个地方。摊开看是三笔藏在暗处的账一笔比一笔隐蔽。第一笔内存钱。那台伺候用户的云主机里塞着一大堆东西编辑器的服务端、AI 的内核、各种工具进程……它们全都常驻在内存里。这里有个公开的参照能给你个直观感觉——像 code-server 这类把整个编辑器跑在服务端、浏览器只当显示器的产品官方给出的单实例最低配置是1GB 内存加 2 个 CPU 核。注意这是最低、是地板价是能勉强跑起来的最寒酸配置。一个用户就摊上这么一份地板价还常驻着。用户在发呆这 1GB 也在那儿占着用户去吃饭了这 1GB 还在那儿占着。内存不认你用没用它只认你占没占。在管家的比喻里这就是那间酒店房——房子空着房费一分不少。而且请注意地板价这三个字真实产品里为了让体验别太卡很多团队给单个用户配的远不止这个最低档。也就是说1GB 只是最省的那种算法实际烧的往往比这更多。这笔内存钱是三笔账里最直白、也最躲不掉的一笔——只要机器开着它就在走。第二笔镜像和磁盘钱。每开一台这样的云主机都得先给它装一套操作系统 编辑器 一堆预装环境这套打包好的东西叫镜像。这镜像可不轻动辄一两个 G。据某中小厂内部的测算量级示意他们那套运行环境的镜像压一压也在 1.5GB 以上——请注意这是他们内部测算出来的量级不是什么已经验证过的通用生产数据我只是拿它给你个有多重的直观感受。镜像越重存起来越占磁盘、传起来越占带宽、机器开起来越慢。一台两台看不出名堂成百上千台一起开这笔磁盘和带宽的账就悄悄堆起来了。第三笔也是最隐蔽的一笔——冷启动的连锁代价。这笔账得绕个弯才能看明白可它恰恰是最要命的。因为每台机器都这么重1GB 内存起步、镜像一两个 G带来一个直接后果一台物理服务器上塞不下几台。据某中小厂内部测算的量级示意一台 8GB 内存的服务器扛这么重的配置大概只能塞下 8 台左右。塞得少行话叫密度低。密度低又逼出下一个麻烦。你肯定希望用户点开产品的一瞬间AI 就能用别让他干等。要做到这点行业里的常规做法是养一个预热池——提前开好一批空机器在旁边待命用户一来直接从池子里拿一台给他省掉现场开机器的那段等待。可问题是预热池里那些空机器是在空烧钱——没人用可它们开着内存照占、房费照走。你的单台机器越重1GB 起步养这么一个池子的成本就高到离谱。养不起你就只能不养。不养预热池会怎样用户点开产品的那一刻就得从头现开一台机器拉那一两个 G 的镜像、把服务一个个启动起来、把上下文加载进来……这一套下来据某中小厂内部测算的量级示意能到 30 秒以上。用户就在屏幕这头干等半天。而这半天的干等代价可不只是体验差。你想想一个用户满心期待点开你的产品结果转了三十秒圈还没进去他大概率就走了、就流失了。你花大价钱把他引进来却因为一台机器起得太慢把他挡在了门外。冷启动慢不是慢一点点的问题是你辛苦拉来的用户还没用上就跑了。你现在看清这条连锁反应了吗——机器重一台服务器塞不下几台密度低预热池太贵养不起冷启动只能硬扛用户点开要等半天。一环扣一环全被第一环机器太重死死拽住。所以这第三笔账最阴险的地方在于它不是一笔孤立的开销而是从内存到镜像再到冷启动一整条被机器太重拖着走的连锁账。贵的不是某一处是被重字串起来的一整串。四、为什么用户量一涨就崩前面讲的都还是一个用户贵在哪。真正让中小厂夜里睡不着的是把这笔账乘以用户量之后的样子。回到管家的比喻。一个客户你在酒店给他包一间房一年房费你还扛得住。那 100 个客户呢100 个客户就是 100 个全职管家就是 100 间酒店房一年 100 份房费。500 个客户呢500 间房。1000 个客户呢1000 间房1000 份房费全年无休地烧。你可以把这个账再往前推一步这 1000 间房就算每间只按最省的地板价算加在一起也是一笔让中小厂肉疼的固定开销。而它是每个月、雷打不动地扣跟你这个月赚没赚到钱、用户活不活跃一点关系都没有。你生意好的月份它这么多生意差的月份它还是这么多。你看出这里最要命的地方了吗——成本是跟着客户数线性往上涨的一个客户一间房多一个客户多一间房一分都省不掉。而且别忘了前面说的这些房间里大半时间是空的、没人使唤管家的。也就是说你花的这笔线性上涨的钱大部分买的是待命不是干活。这时候有人会说那大厂不也一堆用户吗人家怎么就扛得住问得好。差别恰恰就在这儿而且这个差别是理解中小厂困境的钥匙。大厂扛得住靠的是四个字——规模摊薄。同样是养一大片酒店房大厂用户基数极大、账号极多它可以把很多用户的活儿在底层揉在一起精打细算把每一台服务器的空隙都填满把闲置的房间尽量退掉再重开把冷启动用海量的预热池吃掉。它有本钱做这些填空的功夫因为它的量足够大大到每一分优化摊到单个用户头上都值得。前面几篇咱们也聊过大厂做这类东西的动机——它们做 Agent很多时候图的根本不是这个产品本身赚钱而是别的算盘。所以哪怕运行环境这块贵一点它也认了、也摊得起。中小厂不一样。你的量本来就不大你既没有海量用户去摊薄固定成本也没有那个资本和人力去做那些精细的填空优化。你能做的就是老老实实一个用户开一间房。于是同样一套一人一 pod的架构在大厂那儿是能被规模消化掉的成本到你这儿就是一根勒在脖子上、随用户增长越勒越紧的绳子。说得再直白一点——不是大厂比你会省钱而是同样这笔账大厂能摊进海里你只能一个人扛在肩上。这就是为什么中小厂做 C 端 Agent验证期几十个用户的时候一切都好账单可爱、体验流畅、老板开心可一旦真要放开了运营、用户往上冲成本模型立刻反过来把商业模式压垮。不是你的产品不行是这套一人一 pod、全跑云端的地基本来就不是给中小厂设计的。你搭在上面盖房子用户越多地基陷得越深。五、管家的活儿一大半是门面聊到这儿你可能已经憋着一个问题了既然这么贵那这台常驻的云主机到底在忙什么它值不值这个钱咱们把管家一天的活儿掰开看看。管家 24 小时待命可他真正动脑子的时间有多少所谓动脑子是指那些真的需要这个专业管家、别人替不了的活儿——帮你出主意、帮你安排复杂的事、帮你判断怎么处理才妥当。放到 Agent 身上就是 AI 真正在决策、在调用大模型思考、在编排各种工具把一件事干成。这部分才是你雇它的核心价值。可你仔细想想管家一天里这种动脑子的活儿占多大比例其实只是一小部分。他绝大部分时间在干什么在端茶递水、摆盘、报菜名——站在你面前把菜单念给你听把东西摆整齐问你要不要加点什么等着你开口。这些活儿要不要做要。但它们需要一个专业管家吗不需要。你家的智能音箱、你自己顺手就能干。放到 Agent 身上这些门面活儿就是界面怎么渲染、菜单怎么排布、你点哪个按钮有什么反应、内容怎么显示在屏幕上——也就是那一整套界面交互和画面渲染。你可以对照自己每天用的软件感受一下你刷网页、看视频、用各种 App那些画面、那些按钮、那些动效是谁在画是你手里的手机、你面前的电脑在画。这些活儿从来就是终端设备该干的也一直干得挺好压根用不着一台云端的专业机器伺候。这里有个特别值得点破的认知在那台常驻云主机烧的钱里真正花在动脑子上的是一小部分一大半烧在了端茶递水报菜名这些门面活儿上。界面渲染这种活儿本来就是可以在用户自己的浏览器里跑的——你打开任何一个网页画面不都是你自己电脑在渲染吗可在全跑云端的架构里连这份本该用户设备自己扛的门面活儿也被塞进了那台按内存收费的云主机里占着最贵的房间烧着最贵的电。说到这里我得停一下因为这里藏着一个绝大多数人没意识到的荒诞你花大价钱在酒店包了间房、请了个专业管家结果这间房大半的开销是在为报菜名这种智能音箱就能干的活儿买单。门面活儿凭什么要占着酒店房间的钱这就是整件事最不合理的地方也是下篇要动刀子的地方。但本篇先把这个认知钉死——不是 AI 太能干才贵而是一堆本该由用户设备自己扛的门面活儿被硬塞进了云端最贵的房间里。六、几句可能会颠覆你的话把前面这些摊开的账收一收我想用几句反着说的话帮你把这件事真正刻进脑子里。这几句你可以慢慢品——不是 AI 太贵而是每个在线用户都被当成了一台没关机的云主机。你以为你在为算力付费其实你在为开着付费。机器一开就烧钱跟它算没算、算了多少没关系。不是用户用得多才贵而是用户只要在线就贵。这套架构里衡量成本的从来不是用量是占用时长。一个挂着不动的用户跟一个拼命用的用户烧的钱几乎一样多。不是你在为 AI 的智商付费而是你大半在为一台没人用的显示器付电费。那台云主机里真正动脑子的开销是小头一大半烧在了本该由浏览器自己干的界面渲染上——那就是一台被架在云端、还没人看的显示器电费你全掏。不是你的商业模式不行而是你的地基是按大厂的身板浇的。一人一 pod、全跑云端这套地基能被大厂的规模摊平却会被中小厂的用户增长压垮。同样一套账大厂摊进海里你一个人扛在肩上。不是 agent 会思考才让你烧钱而是每个用户的门面活儿都在云端占着一间房。这句话是这一整篇的核心。你把它记住就等于把这一篇读明白了。金句听着痛快但你要真信这几句才算真看懂了那张让小 A 发懵的账单——它涨的从来不是聪明的钱是占着的钱。七、写在最后咱们把这一整篇收一收。小 A 盯着那行实例常驻费发懵的时候他其实撞上了中小厂做 Agent 的第一根钉子——运行环境全压在云端一人一台常驻云主机用户没在用账单照涨。这根钉子扎得深是因为它不是某一处贵而是一整条连锁账内存常驻烧钱、镜像沉重占磁盘、机器太重导致密度低、密度低导致预热池养不起、预热池养不起导致冷启动只能硬扛、冷启动硬扛导致用户干等。一环扣一环全被机器太重、全跑云端这个地基拽着往下沉。而这套地基能被大厂的规模摊平却把中小厂的商业模式压垮。更扎心的是这台贵得要命的常驻云主机大半的钱还不是花在 AI 真正动脑子上是花在了一堆本该由用户浏览器自己扛的门面活儿上——那间酒店房里管家动脑子是小头端茶递水报菜名才是大头。所以问题其实已经浮出水面了。你顺着这条思路往下想一个念头肯定冒了出来——管家的门面活儿既然智能音箱就能干那能不能把它从酒店房间里搬出来、交回你自己家让管家只留在酒店里动脑子那间房是不是就能退个小档、省下一大笔房费这个念头就是解开整个困局的第一根线头。而这恰恰是下篇要卷起袖子干的活儿——运行环境下沉到底怎么做。怎么把门面活儿搬回用户自己的设备怎么让云端那台机器瘦下来怎么让退了档的房间既省钱、又不耽误管家动脑子。这一篇咱们把痛点摊透了下篇咱们就动手拆解这套给管家的房间减负到底怎么落地。先记住这一篇最要紧的一句你为 Agent 烧的钱大头不在它有多聪明而在于你替每个用户都在云端常年包了一间没人用的房。关于 ArchAIHarness这篇文章是「看懂 AI 与智能体」专栏的一部分由ArchAIHarness持续输出。ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产主张架构师定义秩序AI 在秩序中生长。人立法AI 执行体系审计。如果你也希望 AI 在明确的架构边界内协作而不是在混沌中碰运气欢迎到 GitHub 上看看我们在做什么组织主页github.com/ArchAIHarness — 了解完整理念与资产全景本专栏zhuanlan-ai-and-agents— 所有文章的源码与发布记录实践指南docs— 架构哲学、工程方法和落地指南开源工具agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools工程样例framework— DDD AI 协作的工程底座展示如何在开发中融合 AIEngineered by Architects · Empowered by AI · Audited by Discipline