函数计算( FC )是阿里云事件驱动的全托管计算服务, 使用函数计算,您无需采购与管理服务器等基础设施,只需编写并上传代码或镜像。函数计算为您准备好计算资源,弹性地、可靠地运行任务,并提供日志查询、性能监控和报警等功能。面对 MCP Server 场景,函数计算不仅通过 MCP Runtime 支持了社区开源的 Stdio MCP Server 一键托管到函数计算;还通过亲和性调度解决了 MCP Server Session 会话保持的关键问题;同时函数计算针对 MCP Server 的场景特点,在函数计算已有的毫秒级计费基础上,实现了长连接闲置计费能力,支持部署到函数计算的 MCP Server 实现按用计费,在稀疏调用场景,最高可降低 87% 的 MCP Server 的托管成本。
为什么 MCP Server 可能存在资源闲置问题?
在系列文章首篇 MCP Server 实践之旅第 1 站:MCP 协议解析与云上适配 我们深入解析了 MCP 以及 SSE 协议,该协议通过定义标准化事件类型,实现了客户端-服务端的交互控制及会话保持机制,交互过程如下图所示:

- Client端发起一个 GET 请求,建立SSE长连接。(Connection1)
- Server端回复
event:endpoint
类型的事件,将sessionId信息放入data 中返回。(Connection1) - Client端使用第2步返回的sessionId信息发起首个HTTP POST 请求。(Connection2)
- Server端迅速响应202,但无内容。(Connection2)
- Server端返回第3步请求的实际消息。(Connection1)
- Client端使用第2步返回的sessionId发起HTTP POST请求
initialized
作为确认。(Connection3) - Server端迅速响应202,无内容。(Connection3)
- Client端使用第2步返回的sessionId发起HTTP POST请求
list tools
。(Connection4) - Server端迅速响应202,无内容。(Connection4)
- Server端返回第8步请求的实际消息,即工具列表。(Connection1)
- Client端使用第2步返回的sessionId发起HTTP POST请求
call tool
。(Connection5) - Server端迅速响应202,无内容。(Connection5)
- Server端返回第11步请求的实际消息,即工具调用结果。(Connection1)
所以,由于 MCP Server 通信协议需要会话保持的特点,一旦初始化,就会建立长连接绑定固定的服务器资源。但绝大多数 MCP Server 的业务流量呈现典型的稀疏性(Sparse Access)与突发性(Burstiness)特征------请求分布高度离散且流量峰谷波动显著,导致服务器资源的实际资源利用率很低,典型场景下图所示:

某用户通过大模型初始化了一个 MCP Server,实现对某文档库的检索能力,大模型会话持续了1小时才关闭,期间总共检索了2次, 资源保持时间是1小时,实际初始化与检索的时间为7.1s,资源闲置比例高达99.8%。在一些复杂的 AI agent 场景, 可能一个会话要连接多个不同用途的 MCP Server,可能产生大量的资源闲置,谁来承担这个闲置成本呢?
函数计算为用户让利,承担了 MCP Server 资源闲置成本
按用计费,是函数计算为用户降本的宗旨,函数计算通过长期对技术的耕耘,已经建立起了三个核心能力:
- 高密度、多样化混部,实现了计算资源的错峰使用:函数计算有来自不同行业的活跃用户,产生了海量的负载类型,基于阿里云"沙箱容器"及"裸金属服务器",函数计算实现了计算节点上高密度部署,使得多样化的场景类型可以错峰使用计算资源,提升了服务器整体的能效比;
- 基于函数级别的资源画像实现主动干预调度,减少资源挤占的隐患:函数计算基于历史数据,为活跃函数建立起精准的资源画像模型,可以识别函数在不同时间段的资源占用情况,基于画像模型,可以主动对占用大量计算资源的函数调度,减少由于计算节点资源挤占,影响请求延时的概率;
- 百毫秒级的快速弹性及平滑迁移能力,能快速兜底处理资源挤占问题:函数计算具备百毫秒级的弹性及平滑迁移用户负载的能力,在识别到有资源挤占的行为发生时,可以通过平滑迁移快速恢复;
正由于具备这些核心能力,函数计算实现了通过技术降本,所以选择了为用户让利,承担起了 MCP Server 的资源闲置成本。
闲置计费实现的技术内幕
目前函数计算已实现按用计费的能力,如函数计算计费概述所示,按照请求计费的模式是按用计费的典型模式,只有请求执行期间,才会产生费用,无请求执行,实例处于"冻结"状态,冻结持续几分钟便会自动释放资源,不会产生额外的费用;即使您选择预留实例,由于有明确的"冻结"状态来判断闲置,预留实例在无请求执行时仅需要支付内存成本。但由于 MCP Server 的协议会话保持、异步提交及流式返回的特点,在会话持续期间,始终需要保持计算资源的活跃,故无法通过明确的"冻结"状态来减免资源闲置成本,所以函数计算面向 MCP Server 场景,引入了额外的判断闲置的方法,如下所示:

函数计算将 MCP Server 长连接时间划分成多个闲置判断周期,如果某周期实际消耗的 CPU Time 低于某个阈值,则该周期算作闲置,这个阈值的设定,确保了只有发生 Initialize/List Tools/Call Tools 等实际调用时,函数实例才会判断为活跃。
以上述稀疏调用场景为例:

4次实际的动作,只有8秒算做活跃周期,剩余3592秒都处于闲置周期,闲置的周期,在计量上会减免 CPU 费用,只计算内存费用;内存费用参考函数计算计费概述,以2核3GB的配置为例,内存费用仅占18%,整体费用节省:
(1- (8 + 3592 × 18%)/3600),约为82%,如果以2核2GB最低内存比例配置为例,整体费用可降低87%。为了简化对 MCP Server 场景闲置计费的理解,费用节省直接折算成减少 CU 计算时间,无条件的降低,在计量上表现为 CU 计算时间和活跃 vCPU 时间的降低。
如何开启 MCP Server 的闲置计费能力?
MCP Server 闲置计费能力主要目标是解决会话亲和性保持造成闲置的问题,当开启会话亲和性后便默认开启闲置计费能力,开启方法参考 MCP亲和性调度。
通过函数计算控制台 MCP 运行时开发 MCP 服务或通过 Function AI 创建 MCP 服务时,创建的函数自带 MCP Server 的闲置计费能力:
- 函数计算控制台:

- Funciton AI 控制台:

其它场景需要在创建函数时通过参数指定开启:调用 API CreateFunction - 创建函数或 UpdateFunction - 更新函数,通过 SessionAffinity 字段指定调用请求的亲和策略为"MCP_SSE",注意:由于 GPU 资源稀缺,对于配置了 GPU 的函数实例,不支持长连接的闲置计费。
另外,对于 Websocket 需要维持长请求的场景,也同步支持了闲置计费能力,无需参数设置默认开启,敬请体验,计费详情可到函数计算-资源用量明细查看。