MCP Server On FC 之旅第四站: 长连接闲置计费最高降低87%成本的技术内幕

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