亚马逊AWS官方博客

AI 驱动的 Graviton 迁移评估：Kiro Power 实战指南

摘要：本文将深入探讨如何利用 Kiro Power 加速 Graviton 迁移，从代码分析、依赖检查、容器适配的完整流程。

1. 引言

在云计算成本优化的浪潮中，AWS Graviton 处理器凭借卓越的性价比成为越来越多企业的首选。然而，将现有的 x86 工作负载迁移到 ARM64 架构并非易事。开发团队需要面对一系列挑战：识别 x86 特定的代码（如 SIMD intrinsics 和内联汇编），检查数百个依赖库的 ARM64 兼容性，适配容器镜像，以及进行全面的性能验证。这些任务通常需要数周甚至数月的手工分析和测试。

AWS 与 Arm 联合推出的 Kiro Graviton Migration Power 改变了这一局面。作为一个 AI 驱动的代码分析工具，它能够自动扫描你的代码库，识别兼容性问题，分析依赖关系，并提供可操作的迁移建议——所有这些都在几分钟内完成。

本文将深入探讨如何利用 Kiro Power 加速 Graviton 迁移，从代码分析、依赖检查、容器适配的完整流程。

2. Graviton 迁移的核心挑战

2.1 为什么选择 Graviton？

AWS Graviton 作为一款通用的 CPU 处理器，自 2019 年推出以来，已经成为云计算成本优化的重要选项。最新的 Graviton5（m9g 实例）在性能和成本方面都取得了显著进步：

  • 性能提升：相比 Graviton3，Graviton5 在视频编码（x264/x265）、数据库查询、流处理等多项基准测试中性能提升约 55%
  • 成本优势：性价比优势明显。以视频转码为例，处理 100 万帧的成本相比 Graviton3 下降 25%
  • 能效比：ARM64 架构的功耗更低，对于大规模部署的企业来说，电力成本节省可观

这些优势使得 Graviton 成为视频编码、数据分析、流处理等计算密集型工作负载的理想选择。然而，要充分利用这些优势，企业需要将现有的 x86 工作负载迁移到 ARM64 架构——这正是大多数团队面临的最大挑战。

您可以在 https://aws.amazon.com/cn/ec2/instance-types/m9g/ 看到更多 Graviton5 早期客户的证言。

2.2 企业迁移的三大痛点

2.2.1 痛点一：代码兼容性问题

许多高性能应用为了榨取 x86 处理器的最后一分性能，会使用架构特定的优化技术。这些优化在 ARM64 上无法直接运行。

SIMD 指令集差异

x86 和 ARM64 都支持 SIMD（单指令多数据）操作，但指令集完全不同：

x86-64 SSE 示例：

#include <immintrin.h>
void vector_add_x86(float* a, float* b, float* result, int n) {
for (int i = 0; i < n - 3; i += 4) {
__m128 va = _mm_loadu_ps(&a[i]);      // 加载 4 个浮点数
__m128 vb = _mm_loadu_ps(&b[i]);
__m128 vresult = _mm_add_ps(va, vb);  // SSE 加法指令
_mm_storeu_ps(&result[i], vresult);
}
}

ARM64 NEON 等价实现：

#include <arm_neon.h>
void vector_add_arm(float* a, float* b, float* result, int n) {
for (int i = 0; i < n - 3; i += 4) {
float32x4_t va = vld1q_f32(&a[i]);      // 加载 4 个浮点数
float32x4_t vb = vld1q_f32(&b[i]);
float32x4_t vresult = vaddq_f32(va, vb); // NEON 加法指令
vst1q_f32(&result[i], vresult);
}
}

虽然两者都能处理 4 个 32 位浮点数，但 intrinsics 函数名、寄存器类型、指令集都完全不同。

内联汇编的复杂性

一些性能关键的代码会直接使用内联汇编。x86 汇编代码在 ARM64 上根本无法编译：

// x86-64 内联汇编（ARM64 上无法编译）
void vector_add_asm_x86(float* a, float* b, float* result, int n) {
for (int i = 0; i < n - 3; i += 4) {
asm volatile(
"movups (%1), %%xmm0"      // x86 指令
"movups (%2), %%xmm1"      // xmm 寄存器
"addps %%xmm1, %%xmm0"
"movups %%xmm0, (%0)"
: : "r"(result + i), "r"(a + i), "r"(b + i)
: "%xmm0", "%xmm1"
);
}
}

ARM64 的等价实现需要使用完全不同的指令和寄存器（v0-v31）。

手工修复的成本

  • 需要深入理解两个架构的差异
  • 每个 SIMD 函数都需要单独改写
  • 修改后需要充分测试以确保正确性
  • 一个中等规模项目可能有数十个这样的函数

2.2.2 痛点二：依赖库的兼容性分析

现代应用通常依赖数百个第三方库。这些库中的许多可能包含 x86 特定的代码或预编译的二进制文件，无法在 ARM64 上运行。

常见的兼容性问题

  1. 预编译二进制：某些库只提供 x86 二进制，没有 ARM64 版本
  2. 架构特定的依赖：例如某些 Python 包依赖于 x86 特定的 NumPy 版本
  3. 版本不匹配：ARM64 支持可能只在较新的库版本中才有
  4. 构建工具链：某些库的构建脚本可能不支持 ARM64 交叉编译
  5. 间接依赖：一个库可能依赖另一个不兼容的库，形成依赖链

依赖分析的复杂性

一个中等规模的 Python 项目可能有 50-100 个直接依赖，而这些依赖又有数百个间接依赖。手工检查每一个库的 ARM64 兼容性是一项繁琐且容易出错的工作：

  • 需要逐个查询每个库的发布历史
  • 需要检查库的 GitHub 仓库或官方文档
  • 需要理解版本之间的兼容性关系
  • 需要跟踪依赖链中的每一个环节

容器镜像的多架构支持

如果应用运行在容器中，迁移变得更加复杂。Dockerfile 中的基础镜像、安装的系统包、编译的二进制文件都需要支持 ARM64。

典型的迁移问题：

# 原始 Dockerfile（仅支持 x86）
FROM ubuntu:22.04
RUN apt-get install -y some-x86-only-package
COPY app-x86-binary /app/

迁移到 ARM64 需要：

  1. 选择支持多架构的基础镜像
  2. 检查所有系统包的 ARM64 可用性
  3. 重新编译应用二进制文件
  4. 测试容器在 ARM64 上的运行

2.2.3 痛点三：性能验证与基准测试

即使代码成功迁移到 ARM64，也不能假设性能会自动达到预期。需要进行全面的基准测试来验证：

性能验证的多个维度

  • 单线程性能：是否符合预期
  • 多线程扩展性：是否能充分利用多核
  • 内存访问模式：是否优化了缓存利用率
  • 功耗效率：是否达到了能效目标
  • 成本效益：是否真正实现了成本节省

基准测试的挑战

  • 需要在 ARM64 实例上运行多轮测试
  • 需要对比 x86 和 ARM64 的性能差异
  • 需要识别性能瓶颈并进行优化
  • 需要验证不同工作负载下的表现

时间成本统计

根据我们的经验，一个中等规模的应用（10-50 万行代码）的手工迁移通常需要：

  • 代码审查和分析：2-4 周（识别 x86 特定代码）
  • 依赖库检查：1-3 周（检查每个库的兼容性）
  • 代码修改和测试：3-6 周（修改 SIMD 代码、处理兼容性问题）
  • 性能优化和验证：2-4 周（基准测试和调优）

总计：8-17 周的开发时间

这还不包括回归测试、文档更新和团队培训的时间。

面对上述三大痛点，传统的手工迁移方法效率低下且容易出错。AWS 与 Arm 联合推出的 Kiro Graviton Migration Power 通过 AI 驱动的自动化分析，彻底改变了迁移的方式。

3. Kiro Graviton Migration Power：AI 驱动的解决方案

3.1 什么是 Arm MCP Server 和 Kiro Powers？

要理解 Kiro Graviton Migration Power，首先需要了解它的基础架构。

3.1.1 Arm MCP Server 的核心理念

Arm MCP Server（Model Context Protocol Server）是 Arm 与 AWS 联合开发的一个创新框架，它将 Arm 的专业知识、工具和结构化提示直接暴露给 AI 编码代理。关键特点包括：

  • 本地运行：在企业防火墙后运行，确保安全性
  • 专家工作流：嵌入 Arm 架构专家的知识和最佳实践
  • 结构化指导：不依赖开发者的提示工程能力，而是由 AI 代理调用专家级的工作流

3.1.2 传统 AI 助手的局限

通用的 AI 助手可以生成代码，但没有结构化的领域特定工具和知识访问权限。这导致一个”鸡生蛋、蛋生鸡”的困境：

  • 要获得专家级的输出，开发者必须已经知道如何将专家级的架构意图编码到提示中
  • 这对大多数开发团队来说是不现实的

3.1.3 Arm MCP Server 的解决方案

通过将 Arm 架构知识直接嵌入代理的工作流中，Arm MCP Server 实现了：

  • 降低对提示工程的依赖
  • 让每个团队都能获得 Arm 专家的指导
  • 将迁移从”黑盒”过程转变为”透明、可控”的工程流程

3.2 Kiro Graviton Migration Power：Graviton 迁移的专家团队

Kiro Powers 是 AWS 的 AI 原生 IDE（Kiro）中的专用工具包。Arm MCP Server 现在通过新的 Kiro Powers 支持云基础设施现代化的完整工作流。

Graviton Migration Power 帮助开发者将工作负载迁移到 AWS Graviton 处理器（Arm64 架构），它通过分析源代码中的已知代码模式和依赖库来识别与 Graviton 处理器的兼容性，生成报告突出显示检测到的兼容性问题（建议手动审查），并为语言运行时和依赖库提供最小必需版本和推荐版本的可操作建议。

Power 页面：https://kiropower.dev/power/graviton-migration-power

Github 仓库：https://github.com/kirodotdev/powers/tree/main/aws-graviton-migration

3.2.1 适用场景：AWS Graviton 云迁移

目标是将代码库从 x86 迁移到 Arm。使用 MCP 服务器工具来帮助您完成此任务。检查 x86 特定的依赖项（构建标志、内联函数、库等），并将它们更改为 Arm 架构的等效项，帮助识别兼容性问题，并为 Arm 架构提出优化建议。查看 Dockerfile、版本文件和其他依赖项的兼容性，并优化性能。

3.2.2 核心能力

1.x86 代码库 Arm 就绪性评估

    • 自动扫描代码库中的 x86 特定依赖
    • 识别指令集依赖和性能假设
    • 生成详细的兼容性报告

2.指令集依赖识别

    • 检测 SIMD intrinsics（SSE、AVX 等）
    • 识别内联汇编代码
    • 标记架构特定的编译标志

3.容器化工作负载重构

    • 分析 Dockerfile 的多架构兼容性
    • 检查基础镜像和系统包的 ARM64 支持
    • 提供多架构构建的最佳实践

4.CI/CD 管道 Arm 原生对齐

    • 审查构建脚本和测试流程
    • 建议 ARM64 特定的优化
    • 确保自动化流程支持多架构

3.2.3 执行步骤

  • 检查所有 Dockerfile，使用 check_image 和/或 skopeo 工具验证 Arm 兼容性，如有必要则更改基础镜像。
  • 查看Dockerfile安装的软件包，将每个软件包发送到 knowledge_base_search 工具以检查每个软件包的 Arm 兼容性。如果软件包不兼容，则更改为兼容的版本。调用工具时，明确询问“[软件包] 兼容 Arm 架构吗？”其中 [软件包] 是软件包的名称。
  • 查看任何 requirements.txt 文件的内容，逐行发送到 knowledge_base_search 工具以检查每个软件包的 Arm 兼容性。如果软件包不兼容，则更改为兼容的版本。
  • 查看你可访问的代码库，确定使用的语言。
  • 使用基于代码库使用的语言选择适当的语言扫描器，在代码库上运行 migrate_ease_scan 工具。
  • 提供包含完整依赖分析、迁移建议和 AWS Graviton 处理器优化的分析报告。
  • 在进行代码更改前，获取用户的确认。

3.2.4 为什么这很重要

对于考虑迁移到 AWS Graviton 以优化成本的开发团队来说，这个 Power 消除了迁移决策中的不确定性。对于现代化云基础设施的组织来说，Graviton 通常是成本优化的关键转折点。Graviton Migration Power 用结构化、逐步的工作流（由智能代理指导）替代了猜测。

3.2.5 Kiro Powers 的关键优势总结

方面 传统方法 Kiro Powers
知识获取 需要 Arm 专家 AI 代理内置专家知识
工作流结构 非结构化、易出错 规范驱动、可重复
决策支持 基于经验 基于数据和最佳实践
学习曲线 陡峭 平缓，有 AI 指导
可扩展性 受专家数量限制 可扩展到整个团队
文档生成 手工编写 自动生成详细报告

3.3 实际工作流示例

场景：一个团队想要将视频编码应用从 x86 迁移到 Graviton5，并最终部署在 AWS EC2。

使用 Graviton Migration Power 进行应用的迁移评估

Plain Text
1. 上传代码库到 Kiro
2. Graviton Migration Power 自动扫描
├─ 发现 15 个 x86 SIMD 函数
├─ 识别 8 个不兼容的依赖库
└─ 检查 Dockerfile 的多架构支持
3. AI 代理生成迁移计划
├─ 代码修改建议（带代码示例）
├─ 依赖升级路径
└─ 容器镜像优化方案
4. 开发者按照指导进行修改
5. 自动验证和性能基准测试

Kiro Graviton Migration Power 不仅仅是一个工具，它代表了一种新的开发范式——将 Arm 专家知识嵌入 AI 代理，使每个团队都能获得企业级的迁移指导。下一章我们将深入探讨如何在实际项目中使用这个 Power。

4. 准备 Kiro Powers 环境

在本章节中，将在 AWS EC2 Graviton4 实例(c8g.xlarge) 上安装  Docker 运行环境，用于Arm MCP Server 的执行环境；并使用该服务器作为Kiro Workspace，通过本地笔记本电脑的 Kiro IDE 进行远程连接该工作空间；安装 Kiro Graviton Migration Power。

4.1 准备 Arm MCP Server 运行环境

1.您可以参考 使用控制台中的启动实例向导来启动 EC2 实例 创建一个实例类型为 c7g.xlarge 的 EC2 实例，本文中使用 Ubuntu 22.04 作为操作系统。

2.可通过 SSH 登录到该实例

3.安装 Docker

sudo apt update
sudo apt install -y docker.io
sudo systemctl start docker
sudo systemctl enable docker
sudo usermod -aG docker $USER
newgrp docker

4.拉取 Arm MCP Server 的容器镜像

docker pull armlimited/arm-mcp:latest
docker image ls

5.创建一个Kiro Workspace

mkdir -p ~/kiro_workspace

4.2 Kiro IDE 连接到 Workspace

在本地的 Kiro IDE，通过 Remote Explorer 连接到 Arm MCP Server 所在的 EC2 实例

[图1]

在出现登录界面时，您可以通过常用方式进行登录：

[图2]

在连接成功后，可使用 Explorer 中的 Open Folder 定位到 workspace：

[图3]

4.3 激活 Kiro 中的 MCP 功能

[图4]

4.4  安装 Kiro Graviton Migration Power

在 Kiro Powers 界面，找到 Plan and Migrate to Graviton 并进行安装：

[图5]

安装后如下图所示：

[图6]

同时，在 Kiro MCP SERVERS 界面可以看到 Arm MCP Server 也已处于激活状态，并连接有 6 个 Tools 工具：

[图7]

其中几个关键的 Tool 和作用：

  • migrate-ease_scan: 扫描Arm兼容性问题的代码库（C++、Python、Go、JS和Java等）
  • knowledge base search: 搜索Arm文档以获取迁移指导
  • skopeo: 远程检查容器镜像以获得架构支持
  • check image: 快速Docker镜像架构验证
  • mca (Machine Code Analyzer): 分析汇编代码进行性能预测

5. 演示一：将基于 Java 语言开发的 Chatbot 应用迁移到 Graviton

本章节演示将一个基于 Java 语言开发的聊天机器人应用，借助 Kiro Graviton Migration Power 进行迁移评估的过程。

5.1 将演示代码下载到 Arm MCP Server 所在 EC2 实例

cd ~/kiro_workspace
wget https://ws-assets-prod-iad-r-iad-ed304a55c2ca1aee.s3.us-east-1.amazonaws.com/1e6403ba-debf-4816-a773-806d1acc1ecc/java-demo.zip
sudo apt install unzip
unzip java-demo.zip

该演示应用包含如下主要部分：

Java 应用

  • Main.java：源代码
  • pom.xml：Java 应用的依赖组件
  • libchatbot-amd64.so： 聊天机器人动态库（x86 架构）
  • Dockerfile：构架容器镜像文件

C/C++ 库文件

  • chatbot.cpp: 聊天机器人库文件源代码
  • CMakeLists.txt：构建文件

[图8]

5.2 对代码工程进行 Graviton 迁移分析

在 Kiro IDE 中，输入如下提示词：

提示词
对项目 /home/ubuntu/kiro_workspace/java-demo 进行 Graviton Migration 分析，其中：
java 子目录是 Java 主程序代码；
gdd-chatbot-main 子目录是聊天机器人动态库的源代码。

你在 Kiro IDE 中将看到使用了 Graviton Migration Power 进行分析：

[图9]

在完成分析后，将提供一份评估报告：

[图10]

在分析报告中已经包含了 需要修改的地方 等内容。

基于 Kiro Graviton Migration Power 生成的详细迁移分析报告，开发团队可以有针对性地进行代码适配工作。报告中包含的具体修改建议、代码示例和最佳实践为团队提供了清晰的执行路径。

如需进一步利用 Kiro 的 AI 能力进行代码重构和优化，开发者可以通过自然语言提示的方式与 Kiro 交互，指导其完成具体的代码修改任务。需要注意的是，这种交互式代码编辑属于 Kiro IDE 的核心功能，而非 Graviton Migration Power 的专属能力。两者的结合使用能够实现从分析到实施的完整迁移工作流。

6. 演示二：评估 Portry 管理的 Python 应用的依赖包

Poetry 是 Python 生态中一个流行的依赖管理和打包工具，它用 pyproject.toml 作为唯一的项目配置文件，替代了传统的 setup.py + requirements.txt 组合。 Poetry 主要做三件事：

  • 依赖管理（安装、更新、锁定版本）
  • 虚拟环境管理（自动创建和管理 venv）
  • 打包发布（构建 wheel/sdist，发布到 PyPI）

你可以通过如下 URL 下载并查看一个 pyproject.toml 的样例：

https://raw.githubusercontent.com/eric-yq/ec2-test-suite/refs/heads/main/misc/demo-code-for-graviton-migration/poetry/pyproject.toml

下面将同样借助 Kiro Graviton Migration Power 进行迁移评估。

提示词
python-demo 目录有一个 x86 架构下使用 poetry 管理的 python 工程文件 pyproject.toml。请进行 Graviton 迁移评估，如果部署在 Graviton4 上，需要哪些改动？

同样，可以看到 Kiro 激活了 Graviton Migration Power 进行评估：

[图11]

在所有分析完成之后，会生成Graviton 迁移分析总结：

[图12]

7. 其他使用说明

7.1 安全性考量

Kiro Graviton Migration Power 实际上是一个 MCP Server（Model Context Protocol），MCP Server 本身在本地运行和读取代码，整个 Power 的工作方式：

Kiro (AI 助手) ←→ MCP 协议 (stdio) ←→ Docker 容器 (armlimited/arm-mcp:latest)

其中 Power 集成的主要工具的运行方式：

1. migrate_ease_scan：代码扫描

运行位置：本地 Docker 容器内

数据访问：通过卷挂载直接读取 /workspace 下的源文件

网络通信：无（容器没有暴露端口，没有配置外部 API endpoint）

因此源代码不离开本地机器

2. knowledge_base_search：知识库搜索

发送内容：自然语言查询字符串（如 “Is grpcio compatible with ARM?”）

这个工具的后端实现在容器内部，没有配置外部 API key 或 endpoint。知识库数据（Arm intrinsics、生态兼容性信息）是打包在容器镜像内的（镜像 /app 目录 1.43GB，/opt/arm-migration-tools 371MB）

查询在本地容器内完成，不发送源代码

3. check_image / skopeo：镜像检查

发送内容：Docker 镜像名称（如 nginx:latest）

skopeo 二进制文件直接打包在容器内，它会访问公开的 Docker Registry API 查询镜像 manifest

只有镜像名称会发送到公开 registry，不涉及源代码

4. mca：汇编分析

运行位置：本地 Docker 容器内，基于 LLVM 工具链

纯本地分析

因此，Graviton Migration Power 的 MCP 工具本身在本地 Docker 容器中运行，不会直接将源代码发送到 Bedrock 处理。

但 Kiro 作为 AI 助手，在分析过程中读取的文件内容和工具返回的结果，会作为对话上下文发送到 Bedrock 上的模型进行推理，这是 Kiro 正常工作的方式，与是否使用 Graviton Power 无关。如果你对源代码的隐私有顾虑，关键变量不在于 Graviton Power，而在于 Kiro/Bedrock 本身的数据处理策略。Kiro 在数据保护方面的说明，您可以通过查看 https://kiro.dev/docs/privacy-and-security/data-protection/ 获取详细信息。

如果您或您的组织有安全方面的考量，建议您在全面评估后审慎使用。

7.2 使用建议

在使用 Kiro Graviton Migration Power 进行迁移评估时，建议采用分阶段、有针对性的扫描策略，而非一次性处理大规模代码库。这主要基于以下技术考量：

技术限制：

  • 大量文件内容扫描可能导致 MCP 或 LLM 上下文窗口溢出，进而引发扫描超时、响应延迟或系统无响应等问题。

推荐的预筛选策略：

  • 人工预筛选：优先识别包含架构特定代码的核心模块，如性能关键路径、SIMD 优化代码段等。
  • 工具辅助筛选：先使用 AWS Porting Advisor for Graviton 进行初步扫描，获得问题概览报告，然后基于该报告确定需要深度分析的代码范围。
  • 分模块评估：将大型项目按功能模块或依赖关系分解，逐个使用 Graviton Migration Power 进行精准评估。

这种分层筛选的方法不仅能够规避技术限制，还能提高分析的精确度和可操作性，确保迁移评估的效率和质量。

8. 结语

➡️ 下一步行动：

相关产品：

  • Amazon Kiro — AI 驱动的 IDE
  • Amazon EC2 — 安全且可调整大小的计算容量
  • Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台

相关文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

袁泉

亚马逊云科技弹性计算解决方案架构师，专注于 Graviton 和 Arm64生态的发展和应用，致力于为企业客户提供 EC2 实例家族、Auto Scaling、Spot 实例等核心计算产品的深度技术咨询。凭借丰富的云原生架构经验，帮助客户设计兼具成本效益与卓越性能的创新计算解决方案，实现业务的可扩展性与技术转型目标。

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用