基于 Arm MCP Server 的 Graviton 迁移分析：Kiro Power 架构与实测

最近在做 x86 到 ARM64 的迁移评估。发现亚马逊云科技和 Arm 联合推出了 Kiro Graviton Migration Power——一个基于 MCP 协议的 AI 迁移分析工具。

拿两个项目实测了一下，记录技术细节。

为什么迁移评估这么耗时

x86→ARM64 迁移的三个核心痛点：

1. SIMD 指令重写 — SSE/AVX 和 NEON 完全不同的 API。AVX 256 位寄存器，NEON 128 位，一条 AVX 指令可能要拆成两条 NEON 指令。手动排查极其耗时。

2. 依赖链检查 — 一个中等项目几百个依赖包，每个都要确认 ARM64 支持。纯语言包没问题，C 扩展包就不好说了。

3. 容器和 CI/CD — Dockerfile 写死架构、构建脚本假设 x86、runner 默认 amd64，处处都是坑。

传统评估方式：安排高级工程师手动审查，一个项目 2-3 周，服务多了直接劝退。

Kiro Power 技术架构

核心组件是 Arm MCP Server。

MCP（Model Context Protocol）是 AI 代理调用外部工具的协议标准。Arm 把指令集映射规则（SSE/AVX → NEON）、依赖兼容性矩阵、容器适配模式封装成了 MCP Server。

Kiro IDE 中的 AI 代理通过这个协议获取专业知识，而不是靠通用模型去猜。

架构简图：

开发者 → Kiro IDE → AI 代理 ←→ Arm MCP Server
                                      ↓
                                迁移知识库
                        (指令映射 / 依赖矩阵 / 镜像规则)

配置方式：

{
  "mcpServers": {
    "arm-migration": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-server-arm"],
      "env": {
        "ARM_ANALYSIS_MODE": "full"
      }
    }
  }
}

实测 1：Java Chatbot

Spring Boot 项目，有 JNI 调用。

分析结果：

• ✅ JVM 字节码无 x86 依赖，天然跨架构
• ⚠️ 2 个 JNI 本地库需要 ARM64 环境下重新编译
• ⚠️ Dockerfile 基础镜像要换多架构版本
• ✅ 47 个 Maven 依赖全部兼容

JNI 库的处理方式：在 Graviton 实例上起编译环境，找到 C 源码重新 make。不复杂，但需要一个 ARM64 环境。

实测 2：Python FastAPI

Poetry 管理依赖。numpy、pandas、cryptography、pillow 等核心包全部有 ARM64 预编译 wheel。全绿通过。

Python 生态的 ARM64 支持已经很成熟了。除非用了冷门的 C 扩展包，否则基本无障碍。

SIMD 转换要点

x86 AVX 256 位，NEON 128 位。同样的 8-float 向量加法：

// x86 AVX
__m256 vr = _mm256_add_ps(va, vb);  // 一条指令，8 个 float

// ARM64 NEON：拆成两组
float32x4_t vr_lo = vaddq_f32(va_lo, vb_lo);  // 前 4 个
float32x4_t vr_hi = vaddq_f32(va_hi, vb_hi);  // 后 4 个

Kiro Power 能自动识别这类代码并给出转换建议，但复杂场景（嵌套在模板/宏里的 intrinsics）仍建议人工复核。

Graviton5 (m9g)

• 比 Graviton3 性能提升约 55%
• 视频转码成本下降约 25%

迭代速度很快。

总结

Kiro Power 的定位是迁移评估辅助工具，不是自动修复方案。它把评估时间从"周"压到"分钟"，让团队能快速做出迁移决策。

对于 Java/Python 项目，Graviton 迁移门槛已经很低。C/C++ 项目如果 SIMD 使用量大，工作量不小，但问题定位速度大幅提升。

参考链接：

• Kiro IDE
• 亚马逊云科技 Graviton
• 原文指南