云计算一直是一门关于"生存"的学问。当你在大规模构建系统时，必须考虑资源规划、容量规划以及需求突增时的适应性。云架构中的"生存主义者"思维，就是构建能够扛住突发风暴的系统——无论是瞬时的流量激增，还是要把AI推理扩展到全球用户群。过去十年间，无服务器计算（Serverless）一直是这种弹性架构的首选，它把底层基础设施抽象掉，让你能专注应用本身。如今，AI带着它的服务器无形态来了，正在改写我们关于"大规模部署智能"的思考。

思路直白：把推理当API

核心思路其实非常直白：你不必再预置GPU实例、管理模型部署、给推理基础设施做容量规划——你只需调用一个API、把数据发过去、等响应回来。提供方处理其余一切：模型跑在他们云里的某个地方，自动扩缩容，按Token或按请求计费。Amazon Bedrock、Azure OpenAI服务、Google Cloud Vertex AI等服务，已经让这种方式从例外变成了常态。通过托管API，你可以访问Anthropic、OpenAI、Meta和Google的基础模型，所有底层工作——从硬件选型到自动扩缩容——都被屏蔽掉。这种简洁非常优雅，对许多用例来说也确实是刚需。

弹性的优势

这种架构带来的好处相当可观，值得认真审视。最明显的一点是：你不必花时间给基础设施做容量规划。AI基础设施的容量规划是出了名的难——GPU实例很贵，要拿到刚好够用的数量来应对峰值、又不会在低峰期过度配置，这需要大多数组织并不具备的专业能力。无服务器AI把这个问题完全外包出去：你描述需求，服务在背后做容量预置，按用量计费。系统在你需要时扩起来，不需要时缩下去。没有闲置容量，没有等待实例启动的烦恼，也不会有"模型流量突然暴涨、凌晨被运维电话叫醒"的痛苦。

如果做对了，对那些一直在扩缩之间波动的应用来说，这堪称天降甘霖。零售业是教科书般的例子：节假日季，零售商部署的AI推荐引擎可能要扛住10倍于平时的负载；进入一月，需求又会断崖式回落。无服务器架构意味着，你不必在淡季为闲置的GPU基础设施买单。同样的逻辑适用于季节性业务、事件驱动应用，或任何流量模式难以预测的工作负载——你拿到弹性，却不必承担复杂度。

按量付费的隐藏成本

缺点也同样需要纳入考量，而这也是不少架构师栽跟头的地方。由于你对扩缩容过程和存储资源没有直接控制权，成本会随基础设施需求上下浮动。对很多高度波动的扩缩系统来说，这反而是好事——既不会过度配置也不会配置不足，没有闲置服务、不必为从不使用的资源买单。账单随实际用量变化，听起来很理想——但你要意识到，按使用量计费并不总是等于更便宜。

如果你的AI应用长期占用相对固定的资源，无服务器服务通常会让你花更多钱。当你需要全天候以稳定速率跑推理时，自行预置专有基础设施并谈一个固定费率，往往更划算。让无服务器看起来很美的"按Token计价"模式，在这种场景下会变成你为一项用不上的灵活性所付的溢价。更要紧的是，你永远不会真正发挥出无服务器技术的优势——AI流程的基础设施会长期保持相对静态。冷启动、扩缩容延迟、无法控制实例类型——这些缺点永远得不到对冲，因为你压根用不上它的优点。

让架构匹配用例

这是一个"看菜吃饭"的场景，你得仔细琢磨要不要动用这项技术。尽管无服务器在云端世界已经存在多年，我仍不确定大多数企业架构师和AI架构师是否真正掌握了如何部署基于无服务器的AI。这项技术还足够新，模式尚未完全成型；云厂商的文档通常强调易用性，却没有充分覆盖它"力不从心"的场景。结果是，组织出于"无服务器永远更好"的同样思维，把每一种AI用例都默认上了无服务器AI——这种思维误区也曾困扰早期云计算的采纳。

无服务器AI和其他架构选项一样，只是一种架构选项。你必须谨慎地使用它，让正确的业务问题匹配到对应的技术。波动性强、不可预测、且具有显著季节性模式的工作负载，是理想的适配场景。稳定、稳态的推理工作负载则多半不是。决策应当立足于你对流量模式、成本约束、运维需求的理解，而不是建立在"无服务器天然比自建基础设施更好"的假设之上。"生存主义者"的思维方式在此处和云架构的每个角落一样适用：最好的工具是恰好契合工作的那一个，而不是听起来最炫的那一个。