一个MCP服务器管理六个AWS推理后端实战

从终端脚本到MCP服务器：一个文件接管六个推理后端

在AWS上部署推理服务有多麻烦？六个后端、四五个区域、五种计费资源、两个AWS Neuron芯片实例，还有全部不可从公网访问的节点——这是很多团队做多后端推理对比时的真实处境。开发者xbill9在GitHub上开源了aws-inference-strands项目，把这一整套流程封装进一个MCP服务器文件，让一个聊天会话就能完成上线、健康检查、日志查看、推理请求和下线全流程。

这个服务器基于MCP Python SDK 2.1.1的MCPServer类构建，协议版本协商为2025-11-25，通过stdio启动。它在四个设计原则上做到了克制而彻底。

六个后端，一个聊天入口

这套演示背后实际运行的推理后端包括：Amazon Bedrock（托管服务）、一个SageMaker端点、EC2 g6实例上的vLLM、g5g实例上的推理服务，以及Inferentia2（inf2）和Trainium（trn1）上的Gemma 4模型。六个后端分散在最多四个区域，其中两个跑在AWS Neuron芯片上，意味着计费、可用区容量、健康状态都各不相同。

原来的做法是五个Shell脚本：stage/up.sh启动资源、stage/forward.sh建立端口转发、stage/check.py做健康检查、stage/ask.py发请求、stage/down.sh销毁资源。每个脚本都面向终端前的人输出信息。MCP服务器做的事情是：把这些操作暴露给Agent，用工具函数把“什么在运行、什么在计费”“inf2是否已经开始服务”“给我看g6上vLLM的日志”这类问题变成代码可验证的回答。

MCP（Model Context Protocol） 是由 Anthropic 于 2024 年底提出并开源的协议，目标是为大语言模型与外部工具、数据源之间建立统一的调用约定。它采用 JSON-RPC 2.0 作为消息格式，支持 stdio 和 Streamable HTTP 两种传输方式。MCP 的核心概念包括三部分：Tools（模型可主动调用的函数，如本文的 launch_backends）、Resources（模型可读取的上下文数据）和 Prompts（预设的提示模板）。服务器通过 tools/list 向客户端声明可用工具的名称、输入 Schema 和注解，客户端（如 Claude Desktop、Strands Agents、Cursor）再根据模型决策发起 tools/call。协议版本通过初始化握手协商，客户端和服务端各自宣告支持的版本号，取双方共同支持的较新版本。MCP 的价值在于把「每个 Agent 框架各写一套工具适配层」变成「一次实现、多端复用」，这也是本文能够用单个 Python 文件同时服务多个 Agent 场景的前提。

AWS Neuron 是 AWS 为其自研推理加速芯片 Inferentia 和 Trainium 提供的 SDK 与运行时栈，包含编译器（neuronx-cc）、运行时库和面向 PyTorch / TensorFlow 的集成层。与 GPU 不同，Neuron 芯片需要把模型先编译成针对特定芯片架构的 NEFF（Neuron Executable File Format）才能执行，这一步往往耗时数分钟到数十分钟，且编译产物会缓存。本文中 inf2 启动后 20.4 分钟才通过健康检查、日志里出现「READY in 473.8s」，正是模型编译和 NeuronCore 加载导致的。理解这一点有助于解释为什么 inf2 会出现「8080 端口已开但请求等待超时」的现象：服务进程先监听了端口，但底层 NeuronCore 还在装载编译好的模型，请求被排队而非拒绝。

四个设计原则撑起一个文件

服务器的核心设计不是堆功能，而是复用与封装。

复用已有的代码路径。ask_backend工具调用的就是backends.chat_once函数——stage/ask.py、stage/check.py、benchmark和第二个演示用的都是同一个函数。count_ids调用demo1_counting.count，也就是进程内工具调用的同一个函数。这意味着从MCP服务器拿到的数字和从脚本拿到的数字来自同一行代码，不会出现两套逻辑各说各话。

启动和销毁直接调用阶段脚本。launch_backends启动stage/up.sh，teardown启动stage/down.sh，MCP路径和文档描述的手动路径创建和销毁的是完全相同的资源。

**不开任何入站端口。**每个实例所在的安全组没有任何入站规则。需要访问实例的操作通过SSM Run Command在机器上执行Shell命令。

用标签作为唯一清单。stage/up.sh给每个实例打上ManagedBy=strands-demo-run标签，服务器在所有四个区域的查找都基于这个标签过滤。即使某个后端因为容量错误漂移到另一个区域，依然能被找到。

由于boto3是同步的，每个调用通过asyncio.to_thread在线程池中运行，这让一个工具可以同时向四个区域发起请求：

async def _instances() -> list[dict]:
    per_region = await asyncio.gather(*[_region_instances(r) for r in REGIONS])
    return [i for found in per_region for i in found]

SSM Run Command 是 AWS Systems Manager 的一项能力，允许在不开放任何入站端口、不需要 SSH 密钥的情况下，向 EC2 实例下发 Shell 命令并回收标准输出。其工作原理是实例上预装的 SSM Agent 主动向 SSM 服务端建立长连接（出站长轮询），命令由服务端推送到 Agent，再在实例本地执行。这一模式天然适配零入站安全组的场景，也是本文「不开任何入站端口」原则得以成立的技术基础。代价是：Agent 未注册时调用会立即返回 InvalidInstanceId（这正是文中用来判断实例是否就绪的信号之一），且命令输出有大小与超时限制，长输出需自行截断或落盘。

MCP 工具注解（Tool Annotations） 是协议为工具声明行为特征的机制，目前定义了 readOnlyHint、destructiveHint、idempotentHint 和 openWorldHint 四个布尔字段。客户端可据此在 UI 上做差异化提示——例如对 destructiveHint=true 的工具弹出二次确认，或对 readOnlyHint=true 的工具跳过审批。需要强调的是，注解属于自愿声明，协议不做强制校验，服务端完全可以标注错误。因此注解的可靠性取决于实现者的自觉，本文将其作为「安全信号」而非「安全边界」来使用，这种定位是务实且正确的。

八个工具的读写销毁分级

tools/list返回八个工具，每个都带有MCP工具注解，客户端在调用前就能区分清单查询、产生费用的操作和删除操作。注解分三类：READ_ONLY（只读且幂等）、WRITE（非破坏性写入）、DESTRUCTIVE（破坏性操作）。

工具	注解	触达范围
list_backends	只读	四区域的EC2、SSM、SageMaker查询
backend_health	只读	一次聊天请求，EC2走SSM
backend_logs	只读	服务日志，走SSM
ask_backend	只读	一次聊天请求，走端口转发
count_ids	只读	演示1的内存ID
launch_log	只读	stage/up.log或stage/down.log
launch_backends	写入	stage/up.sh，开始计费
teardown	破坏性	stage/down.sh，终止所有资源

list_backends一次调用在0.78秒内完成五个AWS查询（四个区域各一次EC2查询加一次SageMaker查询）。每个运行中的实例额外增加一次SSM查询。它返回的ask_backend_configured字段有个值得注意的细节：即使五个后端都已下线，它仍然列出全部六个后端名称——因为它读取的是demo.env文件中配置的URL，而这个文件在端口转发结束后仍然存在。工具描述中也明确说明了这一点。

启动、健康检查与日志的实际表现

launch_backends接受g6、inf2、trn1、g5g和sm这些名称，校验后以后台方式启动stage/up.sh。脚本会选择AMI、逐个尝试可用区、失败后转下一个区域，并把操作记录写入stage/up.log。

从启动到开始服务的时间实测数据：g6在启动调用后12.2分钟通过健康检查，inf2用了20.4分钟。inf2第一次通过后（后续请求0.27秒完成），g6的首次回答耗时1.21秒，之后三次在0.02到0.03秒之间。g6日志中的Triton kernel JIT编译警告解释了首次回答的延迟尖峰。

健康检查在实例上通过SSM执行curl，请求不离开实例，因此不需要端口转发也不需要入站规则。失败回复能精确反映不同阶段的问题：InvalidInstanceId表示SSM Agent尚未注册；毫秒级返回000表示端口关闭；90秒后返回000表示端口已开但请求等待超时——这个现象只出现在inf2上，因为它的服务器在NeuronCores仍在加载编译模型时就打开了8080端口。

backend_logs根据后端类型选择正确的日志命令：g6的vLLM容器和inf2、trn1的Neuron容器用docker logs，g5g用journalctl -u vllm.service。容器尚不存在时回退到cloud-init日志。inf2的日志显示“READY in 473.8s”，模型花了将近8分钟才真正就绪。

Triton kernel JIT 编译延迟：vLLM 等推理框架底层依赖 OpenAI Triton 编写的高性能 kernel，这些 kernel 通常以源码形式分发，首次在目标 GPU 架构上执行时才由 Triton 即时编译（JIT）并缓存到本地。编译过程涉及 PTX 生成、ptxas 汇编和 cubin 加载，单个 kernel 可能耗时数十毫秒到数秒，一个模型前向传播涉及的 kernel 数量可达数十个，因此首次推理出现秒级延迟尖峰是正常现象。本文中 g6 首次回答耗时 1.21 秒、后续三次降至 0.02–0.03 秒，正是这一机制的直接体现。如果希望消除冷启动尖峰，可在部署阶段做一次「预热推理」把 kernel 全部编译进 TRITON_CACHE_DIR，后续请求即可直接命中缓存。

Demo 1跨MCP与进程内的对比

演示1的问题是统计十一个ID中有多少个大于等于10，正确答案是8。count_ids接受一个谓词操作符和值，返回精确的数量、最小值和最大值，并回显执行的谓词。比如>= 10返回8，> 10返回7。

demo1_counting.py --tools mcp通过MCP协议把这个工具提供给Strands Agent。Strands的MCPClient以stdio方式启动服务器，工具过滤器只暴露count_ids。由于工具在服务器进程中运行，演示无法实时记录调用，转而从Agent的对话消息中读取工具调用记录，再用同一个函数评分。

在Bedrock上各跑20次的结果：进程内工具和MCP工具都是20/20正确、20/20使用了正确的过滤器、零错误、中位数都是1.07秒。启动服务器的成本只在每次演示运行时发生一次，不计入计时的Agent调用。

值得关注的工程细节

每个工具都捕获异常并返回以❌开头的一行文本，包含AWS错误码和消息、无效后端名的ValueError、或命名了搜索的四个区域的RuntimeError。但有个需要注意的地方：协议层的isError标志在所有失败回复中都是false，如果客户端根据这个标志判断成败，会把失败的健康检查当作成功。原文建议在使用客户端真正依赖这个标志时应该设置它。

数字钳制也做得很到位：tail被限制在1到2000行，max_tokens限制在1到1024，backend在任何AWS调用前对照固定列表校验。一个要求一百万行日志的模型请求只会得到两千行。

长时间运行的任务以后台分离方式执行，start_new_session=True确保脚本在MCP会话关闭后仍然存活，输出写入日志文件供launch_log读取。

一个尚未解决的缺口

服务器不打开任何端口转发，所以ask_backend和各个演示仍然需要从终端运行stage/forward.sh。此外，demo.env文件的生命周期超出了端口转发的生命周期，导致ask_backend会列出实际已下线的后端，直到端口转发重新运行。这是复用已有文件设计带来的副作用。

从整体上看，这个项目展示了一种把复杂多后端基础设施操作暴露给AI Agent的务实模式：不是重新实现一套逻辑，而是包装已有的、经过验证的代码路径，用工具注解传递安全信号，用标签而非状态文件维护资源清单。这些设计选择对于需要在生产环境中让Agent操作云资源的团队有直接的参考价值。