我要投稿

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

发布日期：2025-05-29 06:12:33 浏览次数： 1545 作者：阿里云云原生

函数计算( FC )是阿里云事件驱动的全托管计算服务，使用函数计算，您无需采购与管理服务器等基础设施，只需编写并上传代码或镜像。函数计算为您准备好计算资源，弹性地、可靠地运行任务，并提供日志查询、性能监控和报警等功能。面对 MCP Server 场景，函数计算不仅通过 MCP Runtime 支持了社区开源的 Stdio MCP Server 一键托管到函数计算；还通过亲和性调度解决了 MCP Server Session 会话保持的关键问题；同时函数计算针对 MCP Server 的场景特点，在函数计算已有的毫秒级计费基础上，实现了长连接闲置计费能力，支持部署到函数计算的 MCP Server 实现按用计费，在稀疏调用场景，最高可降低 87% 的 MCP Server 的托管成本。

为什么 MCP Server

可能存在资源闲置问题？

Cloud Native

在系列文章首篇 MCP Server 实践之旅第 1 站：MCP 协议解析与云上适配我们深入解析了 MCP 以及 SSE 协议，该协议通过定义标准化事件类型，实现了客户端-服务端的交互控制及会话保持机制，交互过程如下图所示：

1. Client 端发起一个 GET 请求，建立 SSE 长连接。（Connection1）

2. Server 端回复 event：endpoint 类型的事件，将 sessionId 信息放入 data 中返回。（Connection1）

3. Client 端使用第 2 步返回的 sessionId 信息发起首个 HTTP POST 请求。（Connection2）

4. Server 端迅速响应 202，但无内容。（Connection2）

5. Server 端返回第 3 步请求的实际消息。（Connection1）

6. Client 端使用第 2 步返回的 sessionId 发起 HTTP POST 请求 initialized 作为确认。（Connection3）

7. Server 端迅速响应 202，无内容。（Connection3）

8. Client 端使用第 2 步返回的 sessionId 发起 HTTP POST 请求 list tools。（Connection4）

9. Server 端迅速响应 202，无内容。（Connection4）

10. Server 端返回第 8 步请求的实际消息，即工具列表。（Connection1）

11. Client 端使用第 2 步返回的 sessionId 发起 HTTP POST 请求 call tool。（Connection5）

12. Server 端迅速响应 202，无内容。（Connection5）

13. 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 资源闲置成本

Cloud Native

按用计费，是函数计算为用户降本的宗旨，函数计算通过长期对技术的耕耘，已经建立起了三个核心能力：

高密度、多样化混部，实现了计算资源的错峰使用：函数计算有来自不同行业的活跃用户，产生了海量的负载类型，基于阿里云“沙箱容器”及“裸金属服务器”，函数计算实现了计算节点上高密度部署，使得多样化的场景类型可以错峰使用计算资源，提升了服务器整体的能效比；
基于函数级别的资源画像实现主动干预调度，减少资源挤占的隐患：函数计算基于历史数据，为活跃函数建立起精准的资源画像模型，可以识别函数在不同时间段的资源占用情况，基于画像模型，可以主动对占用大量计算资源的函数调度，减少由于计算节点资源挤占，影响请求延时的概率；
百毫秒级的快速弹性及平滑迁移能力，能快速兜底处理资源挤占问题：函数计算具备百毫秒级的弹性及平滑迁移用户负载的能力，在识别到有资源挤占的行为发生时，可以通过平滑迁移快速恢复；

正由于具备这些核心能力，函数计算实现了通过技术降本，所以选择了为用户让利，承担起了 MCP Server 的资源闲置成本。

闲置计费实现的技术内幕

Cloud Native

目前函数计算已实现按用计费的能力，如函数计算计费概述^【1】所示，按照请求计费的模式是按用计费的典型模式，只有请求执行期间，才会产生费用，无请求执行，实例处于“冻结”状态，冻结持续几分钟便会自动释放资源，不会产生额外的费用；即使您选择预留实例，由于有明确的“冻结”状态来判断闲置，预留实例在无请求执行时仅需要支付内存成本。但由于 MCP Server 的协议会话保持、异步提交及流式返回的特点，在会话持续期间，始终需要保持计算资源的活跃，故无法通过明确的“冻结”状态来减免资源闲置成本，所以函数计算面向 MCP Server 场景，引入了额外的判断闲置的方法，如下所示：

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

以上述稀疏调用场景为例：

4 次实际的动作，只有 8 秒算做活跃周期，剩余 3592 秒都处于闲置周期，闲置的周期，在计量上会减免 CPU 费用，只计算内存费用；内存费用参考函数计算计费概述^【1】，以 2 核 3GB 的配置为例，内存费用仅占 18%，整体费用节省：

（1- (8 + 3592 * 18%)/3600），约为 82%，如果以 2 核 2GB 最低内存比例配置为例，整体费用可降低 87%。为了简化对 MCP Server 场景闲置计费的理解，费用节省直接折算成减少 CU 计算时间，无条件的降低，在计量上表现为 CU 计算时间和活跃 vCPU 时间的降低。

如何开启 MCP Server

的闲置计费能力？

Cloud Native

MCP Server 闲置计费能力主要目标是解决会话亲和性保持造成闲置的问题，当开启会话亲和性后便默认开启闲置计费能力，开启方法参考 MCP 亲和性调度^【2】。

通过函数计算控制台^【3】 MCP 运行时开发 MCP 服务或通过 Function AI 创建 MCP 服务^【4】时，创建的函数自带 MCP Server 的闲置计费能力：

函数计算控制台：

Funciton AI 控制台：

其它场景需要在创建函数时通过参数指定开启：调用 API CreateFunction - 创建函数^【5】或 UpdateFunction - 更新函数^【6】，通过 SessionAffinity 字段指定调用请求的亲和策略为“MCP_SSE”，注意：由于 GPU 资源稀缺，对于配置了 GPU 的函数实例，不支持长连接的闲置计费。

另外，对于 Websocket 需要维持长请求的场景，也同步支持了闲置计费能力，无需参数设置默认开启，敬请体验，计费详情可到函数计算-资源用量明细^【7】查看。