函数计算 FC 选型与计费指南：CU 到底怎么算，哪些活该交给函数

函数计算是少数几个"账单上找不到机器"的计算产品。ECS 你能看到几核几 G、包月还是按量；ECI 至少还有容器实例数。到了 FC，账单上只有一个词：CU。很多人第一次看账单的反应是"我明明没跑多少请求，怎么还有钱"，第二次的反应是"这个 CU 到底等于多少 CPU"。

这篇把两件事讲清楚：CU 是怎么被算出来的，以及什么样的活该交给函数、什么样的活不该。所有价格以官方页面实时展示为准，文中数字是按公开单价做的算例，只用来判断量级。

一、先把三个"跑代码的地方"摆在一张表上

选型的第一步不是比较价格，是比较生命周期归谁管。

一句话边界：负载越"平"，越该用包月 ECS；负载越"尖"，越该用 FC。 FC 卖的不是算力，是"不用为闲置付费"。

二、CU 是唯一的计费单位

FC 把所有资源消耗折算成一个统一单位 CU，再乘单价。转换系数如下（CPU 实例）：

单价是按月阶梯累计的，而且按地域独立累计，不同地域的用量不会合并进同一档：

几个容易忽略的规则：

• CPU 实例按毫秒计量，GPU 实例按秒计量；
• 单小时费用低于 0.01 元时按 0.01 元收取，所以极低频任务的账单会被这个地板价托住；
• 公网出流量不在这张账单里，它走 CDT 统一计费，函数内发起的公网请求、响应流量、被 CDN 回源的流量都算；
• 新用户有 CU 试用额度（官方免费试用页给的是每月 15 万 CU、有效期 3 个月，具体以当期活动为准），额度内不产生费用。

三、决定账单的第三个变量：实例处于哪种状态

同样一个函数，实例状态不同，收费项完全不同。这是 FC 计费最容易误判的地方。

按量模式下，最小实例数为 0 时没有请求就不分配实例、不产生费用；一旦把最小实例数设成 1 以上，实例就常驻，无请求时进入浅休眠继续计费。这就是"我几乎没调用，为什么每天都有账单"的标准答案——不是计费错了，是为了消冷启动主动买了常驻。

深休眠还要注意一个反直觉的点：它的计费量是 内存 × 2 + 磁盘，而且不再享受 10 GB 磁盘免费额度。内存给得越大，深休眠越不划算。

四、算三笔账

以下用目录价 0.00011 元/CU 粗算，实际以官网实时价格和活动为准。

第一笔：每天跑一次的定时任务。 规格 0.5 vCPU / 1 GB，每次执行 30 秒。

每次 CU = 0.5×30 (vCPU) + 1×0.15×30 (内存) + 75/10000 (调用)
        = 15 + 4.5 + 0.0075 ≈ 19.5 CU
每月 30 次 ≈ 585 CU ≈ 0.06 元

再叠加"单小时不足 0.01 元按 0.01 元"的地板价，实际账单是几毛钱量级。同样的活放一台包月 ECS 上，光闲置就是几十上百元。这是 FC 最没有争议的战场。

第二笔：一个有波峰的 Web API。 日均 10 万次调用，每次 100 毫秒，规格 0.5 vCPU / 1 GB。

单次 = 0.5×0.1 + 1×0.15×0.1 + 75/10000 ≈ 0.0725 CU
每月 = 0.0725 × 10万 × 30 ≈ 21.75 万 CU ≈ 24 元

注意这里的假设：0.1 秒是真正的处理时间，不含冷启动。如果每次请求都要拉一个 200 MB 的依赖再初始化数据库连接，实际计费时长会翻几倍，账单跟着翻几倍。

第三笔：图片处理。 每张 2 秒，规格 1 vCPU / 2 GB，月处理 10 万张。

单张 = 2 + 2×0.15×2 + 0.0075 ≈ 2.61 CU
每月 = 2.61 × 10万 ≈ 26.1 万 CU ≈ 29 元

算力之外还有两笔：图片存 OSS 的存储与请求费、分发出去的 CDN 流量费。函数费往往不是这类方案里最贵的一项，别只盯着 CU。

把这三笔放在一起看，会得到一个粗略的换算：百元级的包月实例，大约相当于每月 90 万 CU 的按量消耗。月用量稳定超过这个量级，就该认真考虑包月或常驻资源池，而不是继续按量。

五、反转：五个不该用 FC 的场景

选型文章如果只讲优点就是广告。以下五类活，交出去大概率要返工。

1. 长连接与常驻进程。 WebSocket 长会话、MQTT broker、需要维持心跳的后台任务，都不适合。实例会被冻结、被回收，连接跟着断。函数里若确实要跑后台异步逻辑，得关掉浅休眠，成本随即变成常驻。
2. 依赖本地状态的服务。 临时磁盘上限 10 GB，实例随时可能被替换。会话、上传的临时文件、本地缓存目录都不能当持久层用。
3. 7×24 恒定高负载。 峰值和谷值差不多的业务，按量单价一定打不过包月。这种负载用 FC 是把省钱的前提（有闲置）主动放弃掉了。
4. 强依赖固定公网 IP 或需要 SSH 进去排查的。 FC 支持配置固定公网 IP，但要求关闭默认网卡的公网访问，配置错了表现为"函数能跑但访问不了外网"。也没有 SSH，排障只能靠日志和本地复现。
5. 超长批处理。 单次执行上限是 86400 秒，看似够长，但长任务一旦中途失败重试成本很高。几小时以上的离线计算，用 ECI 或大数据产品更稳。

六、上线前必须确定的七个参数

FC 的坑八成不在代码里，在配置里。这张表建议照着过一遍。

另外两个配额值得提前知道：单账号单地域按量模式实例总数默认 100，实例交付速度约 300 个/分钟。突发流量打进来时，扩容不是无限的。

七、从零到跑起来：四步

用 Serverless Devs 走一遍最小闭环。

# s.yaml
edition: 3.0.0
name: demo-fc
access: default
resources:
  web:
    component: fc3
    props:
      region: cn-hangzhou
      functionName: demo-web
      runtime: python3.10
      code: ./code
      handler: index.handler
      memorySize: 512
      cpu: 0.35
      timeout: 60
      instanceConcurrency: 10
      triggers:
        - triggerName: httpTrigger
          triggerType: http
          qualifier: LATEST
          triggerConfig:
            authType: anonymous
            methods: [GET, POST]

# 部署（首次会引导配置 AccessKey）
s deploy -y

# 本地触发一次，先验证业务逻辑
s invoke -e '{"queryStringParameters": {"name": "fc"}}'

# 查看线上日志
s logs --tail

部署完在控制台拿到公网访问地址，再用 curl 验收：

curl -i "https://<your-endpoint>/<path>?name=fc"
# 记下响应头里的 X-Fc-Request-Id，查日志时用它精确定位一次调用

验收清单三件事：响应头有 X-Fc-Request-Id；日志里能看到本次调用的完整耗时；用 s info 确认 instanceConcurrency 和 timeout 是你要的值而不是默认值。

八、避坑清单

1. 把默认 60 秒超时当成"够用"，批量任务跑到一半被截断。
2. 最小实例数设了 5 却以为"没请求就不收费"，月底账单不对。
3. 为了消冷启动把内存拉满，结果冷启动没消掉，浅休眠的内存费翻倍。
4. 在函数里初始化数据库连接池、加载大模型，每次调用都重新付一遍初始化时间的钱。
5. 用临时磁盘存用户上传的文件，实例回收后文件消失。
6. 忘了配 VPC，连不上 RDS 内网地址，误判为"函数不能访问数据库"。
7. 函数挂在 OSS 触发器上做全量处理，一次误传几万个对象直接把月度 CU 打穿——上线前先确认触发范围与幂等。
8. 只看 CU 单价做对比，漏算公网出流量和下游存储、CDN 的费用。

最后

FC 的价值不在"便宜"，在于把闲置成本转移到平台。判断标准其实只有一条：这段代码是不是"有事才跑、跑完就没事"。是，就交给函数；不是，老老实实包一台机器。

产品页和当前计费规则在这里，价格随活动和地域变化，动手前建议自己核一遍：函数计算 FC 产品页与计费说明。