函数计算的云上计费演进：从请求驱动到价值驱动，助力企业走向 AI 时代

在云计算的发展过程中，计费方式往往是开发者最直观的感知。最初，用户需要直接购买资源，按小时计费；后来，函数计算将粒度细化到按请求执行的毫秒级。很多开发者第一次接触一款云产品时，关注的往往不是架构，而是账单。因为账单背后映射的，正是云厂商在 资源抽象、调度方式、安全隔离与开发体验 上的关键选择。
函数计算的演进史，其实也是一部计费方式的演化史。透过计费这一窗口，我们可以一管窥全豹，清晰地看到背后产品形态在技术与体验上的深刻变化，以及技术架构随应用场景不断演化的能力。
阶段一：从资源租用到按请求计费

在函数计算发展的最初阶段，最大突破点在于计费方式的根本转变：用户不再像租用虚拟机一样，为实例的持续运行付费，而是只在函数被真正调用、执行时支付费用。换句话说，在没有请求执行的时间段，用户无需承担任何闲置成本，这一阶段的创新，让“只为代码运行时刻付费”成为 Serverless 的立身之本，也迅速降低了开发者的使用门槛。如下图所示。

支撑这种计费模式的关键技术包括：

• 精准识别请求边界
  
  
  
  • 请求的生命周期就是计费的生命周期，平台必须在微秒/毫秒级准确地识别“开始”和“结束”，保证账单公平与精确。
    
  
  
• 按请求分配独占资源
  
  
  
  • 每个请求都获得确定的 CPU/内存资源，避免资源竞争导致性能抖动，从而保障账单的可控性。
    
  
  
• 低延时大并发的冷启动能力
  
  
  
  • 实例不常驻，而是按需启动。平台必须优化冷启动延时，在大规模并发场景下快速分配资源，同时在空闲时立即回收，避免浪费。
    
  
  
• 1ms完成活跃/闲置状态转化
  
  
  
  • 在无请求时通过冻结函数实例的 CPU 调度，转成闲置状态，确保不再消耗时间片，请求来到时候，实时转成活跃状态，允许CPU调度，这是实现毫秒级精确计费和公平性的保障。
    
  
  

这一阶段让函数计算真正区别于虚拟机和容器租用模式，奠定了“按请求计费”的核心心智模型。
阶段二：多并发 + 毫秒级计费 —— 面向 Web 应用的优化

随着函数计算逐渐普及，除了事件触发外，Web Server 等 I/O 型场景也开始被采用。如果继续采用单请求独占计费，对比传统多并发的服务模型，成本很难接受，因此进入了第二阶段的演化。
核心变化是：突破单并发限制，按函数实例的活跃时间段计费，并将粒度精细化到 1ms，从而支撑 Web 应用、API 服务等主流场景，如下图所示。

支撑这一演化的关键技术包括：

• 识别活跃时间段作为计费边界
  
  
  
  • 从“单请求时长”转变为“活跃区间”，只要实例内有请求在执行，即视为活跃计费，不管并发多少请求。
    
  
  
• 引入 Custom Runtime / Container Runtime
  
  
  
  • 支持用户平滑迁移主流 Web 框架（如 Express、Flask、Spring Boot），这些框架天然支持多并发，能够降低成本并收敛数据库连接数，减少连接暴涨带来的风险。
    
  
  
• 缩短计费粒度：从 100ms 到 1ms
  
  
  
  • 大多数 Web 请求延时低于 100ms，如果仍按 100ms 粒度计费，用户成本过高。精细化到 1ms，使账单更公平。
    
  
  
• 极致优化平台全链路延迟
  
  
  
  • Web 应用对端到端延迟极其敏感，平台必须在鉴权、路由、调度、转发等环节做性能优化，避免平台开销成为主要瓶颈。
    
  
  

这一阶段的价值在于：从“为单个请求买单”转变为“为活跃区间买单”，辅以更精细的粒度和运行时灵活性，让函数计算从事件驱动扩展到主流 Web/API 服务场景。
阶段三：按实际资源消耗计费 —— AI 时代的价值计费

AI 应用具有长会话、强交互、低延迟的特点：

• 模型对话需要保持上下文；
  
• 语音/流式生成需要实时响应；
  
• 会话中可能包含多种工具调用与后台任务。
  

这类应用往往是 稀疏型负载：大多数时间处于低负载，仅维持长连接和上下文。传统“请求边界=活跃，闲置时冻结 CPU”的机制不再适配：如果一律计为活跃，用户在“低价值”的保活状态下将付出过高成本。
因此，第三阶段的核心转变是：在识别请求边界的基础上，引入按实际资源消耗动态区分“活跃/闲置”的计费模型。低负载状态下减免 CPU 费用，同时仍然允许 AI 应用运行后台任务。

支撑这种演化的关键技术包括：

• 支持会话亲和性
  
  
  
  • 引入会话亲和性机制，使得同一会话的请求路由到同一个实例，避免上下文丢失。
    
  • 用户可通过配置IdleTimeout主动控制会话保留时间（即将发布）。
    
  
  
• 按实际资源消耗判断活跃/闲置
  
  
  
  • 在过去“有请求=活跃”的基础上，引入根据资源利用率感知活跃/闲置的机制。
    
  • 如果 CPU 使用超过阈值，则记为“活跃”并计算CPU费用；如果只是心跳/轻量保活，CPU使用极低，则记为闲置，免去CPU费用，仅收内存/磁盘/网络成本。
    
  
  
• 执行期间低负载的减免机制
  
  
  
  • 在有请求执行时，函数计算以秒为周期采样，如果 CPU 使用低于阈值，自动减免该周期的 CPU 费用。
    
  • 在 MCP、WebSocket 等典型低负载场景默认启用，平台主动让利，避免“在线=计费”的粗暴逻辑。
    
  
  
• 支持不冻结，允许后台任务持续运行
  
  
  
  • 在 AI 场景中，冻结会导致长连接中断、缓存失效，恢复代价高。
    
  • 函数计算支持不冻结模式，允许请求结束后继续运行后台任务，如缓存预热、索引更新、回调处理。
    
  • 这类任务的费用仍然根据实际资源消耗判定为活跃或闲置，差异化计费。
    
  
  

第三阶段的价值在于：从“为活跃区间买单”进一步演化为“按资源消耗分层计费”，账单更好地对齐到有效计算，避免因长连接或低负载保活而产生额外成本，让 Serverless 真正适配 AI 时代的长会话与强交互负载。（由于GPU等异构资源的稀缺性，暂不纳入支持范围）
函数计算的演化方向是把产品形态与用户价值更紧密地对齐

函数计算的计费方式经历了三个阶段：

• 阶段一：按请求计费 —— 降低门槛，让用户只为调用付费；
  
• 阶段二：活跃区间计费 —— 扩展场景，让 Web/API 应用也能高效低成本运行；阶段三：
  
• 按资源消耗计费 —— 贴近价值，让 AI 应用在长会话与低负载下也能公平付费。
  

在 AI 时代，函数计算一直坚持走向“让开发者只关心业务逻辑，云厂商自动完成一切资源管理与调度”的愿景，最终让计算像水、电一样随时可得、按实际使用价值付费。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！