はじめに
2年前に AWS LambdaにおけるARM64とx86_64の性能比較 を書きました。「ARM64のほうが速い」という結論自体は今回測り直しても変わりませんでしたが、倍率が実態より大きく出ていたので訂正させてください。
あわせて、2026年9月時点で測り直して分かった新しい話も載せます。
測定は東京リージョン / Python 3.13.15 / 2026-09-28、各セル18サンプル（総計約860、失敗0件）。
訂正1: 「I/Oバウンド処理」がCPUテストその2になっていた
前回のI/Oテストは f.write(f"{i}\n") を10^6回。ディスクI/Oではなく、Pythonの文字列生成が支配的でした。**前回の表は実質「CPUテスト×3本」**で、I/O性能には到達していません。
根拠（前回の表からそのまま読み取れます）
Lambdaはメモリに比例してCPUを割り当てるので、CPU律速なら「メモリ2倍で時間半分」になります。前回のARM64のI/O列は 3.999 → 1.973 → 0.997 → 0.479 で、きれいに反比例している。ストレージ律速ならこうはなりません。
訂正2: 測定条件にいくつか誤りがあった
- 並列処理のテストが並列になっていなかった
- 本文と表が食い違っていた
- 「34%」の内訳の理解が逆だった
- 試行回数がn=1、リージョンとランタイムバージョンが未記載だった
それぞれの中身
- Lambdaは 1,769MBで1 vCPU相当。前回測った128〜1024MBは全て1 vCPU未満なので、原理的に並列実行できません（加えてGILがあります）。
- 「いずれにおいてもARM64が優れた」と書きましたが、並列処理の512MB/1024MBはx86_64が勝っています（0.099 vs 0.112、0.053 vs 0.056）。
- AWS公称の「最大34%の料金パフォーマンス」は 性能+19% × 価格−20%。性能向上は最初から織り込まれています。前回「実行効率は落ちる前提」と書いたのは誤りでした。
- 試行回数は n=1 でした。今回は各セル18サンプルの中央値を取っています。
訂正後の表
設計を直して測り直しました。1実行1ワークロード、I/Oはペイロードを事前生成して write + fsync + 読み戻しのみを計測、CPUは libm依存(sqrt/sin)と非依存(整数演算)に分離、並列は同じ総仕事量を直列 / threading / multiprocessing の3通りで実行しています。
各セルは ARM64 / x86_64（実行時間の中央値・秒）と、ARM64が何倍速いか。1.33x ならARM64が1.33倍速い、という読み方です。
| workload | 128MB | 512MB | 1769MB (1 vCPU) |
|---|---|---|---|
| I/O (32MB write+fsync+read) | 0.282 / 0.375 (1.33x) | 0.078 / 0.099 (1.28x) | 0.035 / 0.042 (1.20x) |
| CPU float (libm依存) | 0.943 / 1.256 (1.33x) | 0.223 / 0.302 (1.36x) | 0.061 / 0.090 (1.47x) |
| CPU int (libm非依存) | 1.379 / 1.720 (1.25x) | 0.346 / 0.430 (1.24x) | 0.101 / 0.124 (1.23x) |
| 並列ベースライン(直列) | 1.089 / 1.199 (1.10x) | 0.268 / 0.300 (1.12x) | 0.076 / 0.088 (1.15x) |
| 並列 threading | 1.154 / 1.223 (1.06x) | 0.281 / 0.299 (1.07x) | 0.062 / 0.089 (1.44x) |
| 並列 multiprocessing | 1.313 / 1.380 (1.05x) | 0.314 / 0.340 (1.08x) | 0.077 / 0.093 (1.21x) |
全18セルでARM64が勝ちます。ただし倍率は1.05〜1.47倍で、前回の1.5〜1.7倍ではありません。
なお cpu_float の比が cpu_int より一貫して大きい。ARMの優位の一部はコアの速さではなく sqrt/sin の実装差に由来します。前回「浮動小数点演算が多いためARM64が効率的」と書きましたが、分離しないとそこまでは言えませんでした。
新情報: 「arm64」は実は３種類？
毎回 /proc/cpuinfo を記録したところ、arm64の15実行環境にGraviton2/3/4が混在していました。同じ関数を再デプロイするだけで乗る世代が変わり、世代は選べません。
全部置き換わるんじゃないんですね。
| CPU | 実行環境数 | x86_64より何倍速いか |
|---|---|---|
Graviton2 (Neoverse-N1 / 0xd0c) |
8 | 1.01〜1.35x |
Graviton3 (Neoverse-V1 / 0xd40) |
6 | 1.23〜1.69x |
Graviton4 (Neoverse-V2 / 0xd4f) |
1 | —（1環境のみ） |
Graviton2はAWS公称の「最大19%」とほぼ整合。Graviton3はそれを大きく超えます。
まとめ
- ARM64を選ぶ、という結論は変わりません。速度1.05〜1.47倍、コスト22.3〜42.4%減（中央値30.7%）。
- ただし前回の1.5〜1.7倍は出ません。あれは「I/OテストがCPUテストだった」「並列テストが並列でなかった」ことによる数字です。
- 効いているのは主に価格。GB秒単価がちょうど20%安いので実行時間が同じでも2割弱は減り、そこに速度差が4〜24ポイント上乗せされます。
-
arm64フリートはGraviton2/3/4混在。ベンチマークするなら
/proc/cpuinfoを記録すること。
ARMで動かない依存があるかだけ確認して、動くなら切り替える。そこは2年前と同じ結論です。