用 Runtime Instances 构建多智能体音乐流水线，能跑两周？

使用 Runtime Instances 可以让三个智能体共享 GPU 和存储，完成一个跨天的音乐制作流程，而无需每隔几小时重新启动会话。

什么时候需要 Runtime Instances

单个处理客户咨询的 agent 可以跑在 MicroVM 上，冷启动快、按使用付费，但会话只能维持到 8 小时。当你想让几个 agent 合作写歌、互相传递 .wav 文件、并在几天内不断迭代时，短暂的会话显然不够用。这时候 Runtime Instances 提供了更长的会话窗口、GPU 访问以及持久存储，使得多智能体工作流可以在同一台 EC2 实例上驻留。

Runtime Instances 与 MicroVM 的主要区别

• 计算基础：MicroVM 是纯 serverless；Runtime Instances 是 AWS 管理的 EC2 实例。
• 会话时长：MicroVM 最多 8 小时；Runtime Instances 可维持长达 14 天。
• 智能体密度：MicroVM 一对一（一个微VM只能跑一个 agent）；Runtime Instances 允许一个实例上运行多个 agent（1:N）。
• GPU 支持：MicroVM 不能挂载 GPU；Runtime Instances 在支持的实例族上可以直接使用 GPU。
• 存储方式：MicroVM 的存储仅限于会话生命周期；Runtime Instances 通过 Amazon EBS 提供持久卷，文件可以在会话间保留。
• 计费模式：MicroVM 按实际消耗付费；Runtime Instances 按 EC2 实例计费，可以结合 Savings Plans 或按需容量预留来降低成本。
• 伸缩方式：MicroVM 按需自动伸缩；Runtime Instances 由 capacity provider 负责管理实例池的扩容与回收。

这些差异直接影响到你能否把几个长时间协作的 agent 放在同一机器上，以及是否需要自己处理状态持久化。

音乐制作流水线的实际做法

在原文中描述的示例里，三个 agent 被部署在同一个 Runtime Instance 上：

• 第一个 agent 负责调用生成式音频模型，把原始乐想写入 .wav 文件并存到共享卷。
• 第二个 agent 打开该 .wav，进行混音或加效处理。
• 第三个 agent 负责最终母带制作并输出可播放的曲目。

因为所有 agent 共享同一个文件系统和 GPU，它们可以在不复制大量数据的前提下，快速读取彼此的输出。整个流程可以持续几天，只要实例不被终止，之前生成的中间文件仍然存在，后续的 agent 可以直接接着上一步的结果继续工作。

需要准备的条件

1. 创建 capacity provider：在 AWS 控制台或 CLI 中定义一个 provider，指定想要的实例类型（比如 g5.xlarge 以获得 GPU）和期望的实例数量。
2. 准备 agent 镜像或 S3 源：每个 agent 都可以打包成容器镜像，或者直接从 S3 拉取代码包；Runtime Instances 两种制式都支持。
3. 启动会话并获取 runtimeSessionId：创建会话时使用同一个 capacity provider，这样后续调用都会落到同一 EC2 实例上。
4. 挂载共享卷：在会话初始化时指定一个 EBS 卷作为根目录或自定义挂载点，所有 agent 通过这个路径访问 .wav 和中间产物。
5. 调用 agent：使用相同的 runtimeSessionId 调用每个 agent 的入口点，它们会在同一实例上依次或并行执行，文件系统保证了数据可见性。

个人体验与注意事项

• 会话长度不是无上限：虽然官方给出 14 天的上限，但实际使用中仍建议定期检查实例健康状况，避免因底层主机维护导致的突掉。
• GPU 驱动要匹配：选择的实例族必须预装合适的 NVIDIA 驱动，否则容器里的 CUDA 程序会报错。可以在创建启动模板时确认 AMI 已经包含驱动。
• 存储成本：EBS 卷会持续计费，即便实例暂停使用也会产生存储费用，若流水线间歇运行可以考虑在不需要时快照并删除卷，以节省开支。
• 调试日志：因为多个 agent 共享同一日志目录，建议为每个 agent 加上前缀或使用不同的日志流，以免信息混淆难以定位问题。

总之，如果你的创作任务需要几天时间、需要 GPU 加速且涉及多个模型或处理步骤，Runtime Instances 比传统的 MicroVM 更合适。它把原本需要自己拼凑的长会话、持久存储和多实例共享都托管到了 AWS 层面，让你可以专注于音乐本身而不是基础设施的琐事。