函数计算( 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 需要维持长请求的场景，也同步支持了闲置计费能力，无需参数设置默认开启，敬请体验，计费详情可到函数计算-资源用量明细查看。
