过去十几年，国内云计算主要解决资源问题。开发者不用自己买机房和服务器，需要多少算力就取多少，价格也比自建便宜。这件事已经做成了。阿里云重新思考的，是云厂商到底该卖什么给客户。
答案正在变化。客户现在更常问的是：系统能不能扛住大促流量，大模型能不能接入自己积累的业务知识，敏感数据能不能留在境内。单价当然仍然重要，但已经不是唯一的判断标准。
大促流量怎么接得住
某中型服装品牌每年大促前都会遇到同一个问题。平时每天订单不到两万单，活动当天的峰值可能是平时的几十倍。过去的做法是提前采购足够多的服务器，活动一结束，大部分机器就闲着，成本压力很大。
后来这个品牌把订单系统拆成几个可以单独伸缩的服务，并设置了扩容规则：流量超过阈值，实例自动增加；流量回落，实例自动释放。资源费用因此下降。故障排查也变快了，因为各个服务的日志和指标都汇总在同一个监控面板里，出了问题不必逐台登录机器去查。
如果你想借鉴这种做法，有两点要提前想清楚。扩容阈值最好结合订单量或排队长度来设，只看服务器负载不够。CPU 不高但接口已经超时，系统可能不会触发扩容。另外，要在压测中确认新实例启动需要多长时间。启动要几分钟的话，阈值就得设得更早一些。
把设备手册接进大模型
一家地方制造企业积累了大量设备手册和维修记录。一线员工遇到故障时，常常要在多份文档里来回翻找，新人尤其吃力。企业想要的是一个能直接回答问题的工具，同时不希望内部资料被送到公共模型里。
常见的做法分三步。先把文档切分成小段并转成向量，存进企业自己的数据库。员工提问时，系统先检索相关段落，再交给大模型生成回答，并标明引用的手册章节。员工看到的是操作步骤加出处，可以点回原文核对。
落地时，很多问题并不出在模型本身。扫描版 PDF 识别出错，同一设备的新旧版手册混在一起，维修记录里的口语描述和标准术语对不上，这些都会让回答变得不可靠。所以前期的数据清洗，往往比挑选参数更大的模型更有用。权限也要按部门划分。车间员工可以查维修步骤，但不应该看到采购或财务文件。
数据不出境：先问存在哪、谁能看
金融、医疗和政务类客户对数据位置要求很严。一家区域性医疗机构在搭建影像分析平台时，第一件事是确认数据存在哪里，以及谁在什么时候访问过这些数据。上层分析功能再好，底层的存储和审计达不到要求，项目也走不下去。
这对云厂商提出的要求很具体：地域隔离，数据加密存储，关键操作留痕。客户选型时可以直接问这三件事，并要求对方说明日志保留多久、由谁审计。如果对方只能给宣传材料，拿不出可以核查的配置说明，就要多追问一句。
这也说明，厂商还得让客户在合规框架里放心用，高级功能才有机会被真正用起来。
难处在哪里
重新定位并不轻松。云服务是重资产、回报周期长的生意，而大模型训练和推理的成本波动很大，一次模型升级就可能让算力预算重新排期。厂商需要在自研模型、开放生态和服务已有客户之间找平衡。把钱大量投进通用能力，行业解决方案的预算可能被挤压；只盯着一两个行业做，平台的通用性又会变弱。
竞争也更激烈。国内外云厂商和大模型公司都在争同一批企业客户，价格战和功能战同时进行。客户比价时容易只看首年报价，真正的成本往往在后面：扩容是否可控，数据迁出是否收费，模型调用量上涨后单价怎么变。判断一家厂商是否靠谱，可以看它愿不愿意把长期成本讲清楚，而不只是抢下一个订单。
选云服务时可以看哪几点
如果你正在评估云服务，下面几项可以作为对照清单，每一项都拿到自己的业务场景里去问。
- 弹性能力：用自己的历史流量曲线做一次模拟，看扩容和释放是否自动完成，而不是靠人工提前预估。
- 数据边界：要求对方说明数据存放的地域、加密方式，以及访问审计的保存周期。
- 模型接入：确认自有知识能否在私有环境中接入大模型，权限能否细化到部门或角色。
- 迁移成本：提前问清数据导出的格式、时限和费用，免得将来换平台时被动。
阿里云重新出发，是把云服务从提供资源推向提供能力。对企业来说，选择标准也要随之调整。过去比的是单价表，现在更该比的是：这家服务商能否在你的具体问题上给出可以验证的方案。
