芯片上了轨道、本地超算加到 64GB：创作者该重新算的算力账

做 AI 内容的团队，最难受的往往不是模型不够强，而是每个月的算力账单说不清花在哪。一个五人小工作室，跑图、跑视频、跑微调，月底云厂商扣款一万多，问每个人这个月哪个任务最费钱，没人答得上来。更麻烦的是，账单是被动的——你只能等它出来，然后凭直觉决定下个月要不要少跑一点，而不是按结构去调。

最近关于算力供给有两条动静，一条看起来离得很远，一条看起来很近。一条是训练用的加速芯片被送上了近地轨道，先在真实太空环境里验证辐射和温差下的稳定性，真正瞄的是轨道上远高于地面的太阳能供给；另一条是本地小型超算设备新增了更大内存的配置档位，开售时间和价格都已经公布。

这两条单独看都不影响你明天的工作，但放在一起看，它们指向同一件事：算力的供给端正在用新的方式扩张。对普通创作者来说，值得关心的不是新闻本身，而是它会在未来六到十二个月里怎么改变你的成本结构。这篇就把这件事拆开算一遍。

你手里的算力预算，其实只被三件事决定

绝大多数团队在讨论算力时，讨论的都是单价：这张卡一小时多少钱，那家平台有没有折扣。但真正决定你月支出的，是另外三个变量。

• 单次任务的显存下限：你的任务能不能在一张卡上跑完，直接决定了你租的是单卡还是多卡，价格往往差三到五倍。
• 任务的并发密度：同一时段有多少任务在排队，决定了你的卡是满负荷还是空转，而空转的时间你照样付钱。
• 失败重试的比例：跑崩一次重跑一次，成本翻倍。很多团队账单一半的钱花在了没人统计的重试上。

单价只是这三个变量的乘数。把这三个变量压下去一档，通常比换一家便宜两毛钱的云厂商有用得多。

在轨的那批芯片，短期跟你没关系，中期跟价格有关

把加速芯片送上轨道，听起来像科幻。但从成本角度看，它的逻辑很朴素：地面数据中心的瓶颈不只是芯片，还有电力、散热和土地。轨道上有持续且强度更高的太阳能，散热靠辐射，理论上能绕开地面最难压下去的那部分成本。

但这件事短期内不会体现在你的账单上。在轨验证要解决的是辐射损伤、温差循环、发射成本和维护不可达这些工程问题，任何一条都可能让商业化推迟好几年。所以对创作者来说，正确的态度是：知道供给端在往这个方向走，但不要把明年的预算建立在它上面。

真正值得你留意的，是这条消息释放的信号——头部厂商认为长期算力需求还会继续涨，而且地面供给迟早不够用。这意味着中期内算力价格更可能是波动而不是单边下跌，你的成本模型应该按波动来设计，而不是按越来越便宜来设计。

本地超算加内存档位，改变的是能不能跑，不是跑得多快

新增大内存配置这件事，比听起来重要。因为对本地设备来说，内存容量决定的是模型能不能完整加载，而不是加载之后跑多快。

过去很多人的本地设备卡在一个尴尬的位置：小模型跑得很爽，稍微大一点的模型不是跑不动，就是要做各种量化和切分，效果打折、流程变复杂。内存上限抬高之后，这个尴尬区间会明显收窄——原本必须上云的任务，有一部分可以在本地完成。

对创作者来说，这带来三个直接变化。

• 试错成本下降：本地跑不计费，你可以把最费次数的探索阶段留在本地，把只有一次机会的成品渲染放到云上。
• 数据合规更好谈：涉及客户素材、未发布产品、个人肖像的内容，留在本地不用走一遍数据传输的审批流程。
• 交付节奏更可控：不依赖云厂商的排队和限流，紧急改稿不用等资源。

哪些活儿该上云，哪些该留本地

判断标准不是任务重不重，而是任务的形态。下面这个分法在多数团队里都成立。

• 适合留本地的：高频、小批量、需要反复调参的探索性任务；涉及敏感素材的任务；对延迟敏感、要即时看到结果的交互式任务。
• 适合上云的：一次性大批量渲染；需要短时间内堆大量并发的交付期任务；本地设备根本装不下的超大模型；以及你还没确定要不要长期做的试验性项目。
• 两种都不该做的：没有明确验收标准的跑量任务。这类任务最容易吃掉预算，因为你会一直跑下去，永远觉得再跑一次可能更好。

一个真实月账单可以这样拆

假设一个做 AI 视频的小团队，月支出一万二。拆开之后通常是这个结构。

• 约四成花在成品渲染上，这部分是有效成本，钱花得明白。
• 约三成花在探索阶段的反复试跑上，其中相当一部分可以在本地完成。
• 约两成花在失败重试上，原因通常是脚本没做断点、参数没记录、任务中途被中断。
• 剩下的一成是纯粹的闲置——卡开着没人用，或者任务排队时资源空转。

按这个结构，压成本的顺序就很清楚了：先消灭闲置，再管住重试，然后把探索阶段搬到本地，最后才是去谈单价。多数团队的顺序正好相反，一上来就换厂商，结果省了五个点，剩下四十个点的浪费原封不动。

还有一个没人记账的成本：排队等待的时间

账单上看不到，但真实存在的成本是等待。交付期的时候，云端资源紧张，任务排队两小时，人就在旁边干等，或者干脆去做别的事，等结果出来再回过头接上，注意力被切碎。

这类成本之所以没人管，是因为它不出现在发票上。但你可以用两个指标把它量化。

• 任务等待时长占比：从提交到开始执行的等待时间，占整个任务周期的比例。超过三成，说明你的资源安排已经出问题了。
• 上下文切换次数：一个人一天里在等待中被打断的次数。次数越多，有效产出越低，而且这种损失是隐性的。

改善的办法很直接：把需要即时反馈的任务留本地，把可以离线跑的任务放到云端的低谷时段，用队列而不是手动提交。这三件事都不需要额外花钱，但能明显改善团队的实际产出。

常见误区：把显存当成唯一指标

显存确实是最硬的约束，但它不是唯一的。有三个指标经常被忽略，却同样决定体验。

• 内存带宽：同样是能加载，带宽差一倍，生成速度就差一倍，而很多人只看了容量。
• 存储读写速度：大模型权重加载、素材预处理，瓶颈常常在磁盘而不是算力。
• 散热与持续性能：短时间跑分很好看，连续跑两小时降频一半，等于你实际买到的是降频后的性能。

买设备或者租卡之前，把这三个指标和显存一起看，判断会准很多。

接下来三十天可以做的三件事

算力这件事，最忌讳的是一次性做大决定。买设备、签年框、换架构，任何一步做错，纠偏成本都很高。给你一个低风险的推进顺序。

• 第一周，记账：给每个任务打标签，记录起止时间、使用的资源规格和是否成功。不改造任何流程，只把事实记录下来。
• 第二周，分类：按上一周的数据，把任务分成留本地、上云、不该做三类，先停掉不该做的那部分。
• 第三到四周，迁移：把探索性任务迁到本地，给云端任务加上断点和参数记录，只保留需要并发和超大模型的部分。

做完这三步，多数团队能把月度算力支出压下来三到五成，而且交付速度不会变慢。真正省钱的从来不是更便宜的卡，是更少的无效运行。