How Lambda Memory Really Affects ONNX Runtime Performance

Lambda 메모리와 CPU의 숨은 상관관계

메모리=CPU 배수 레버다. 대략 1,769 MB에서 ~1 vCPU, 최댓값 10,240 MB에서 최대 ~6 vCPU까지 붙는다. 즉, ONNX Runtime처럼 CPU‑bound 함수면 메모리를 올리면 지연시간이 꽤 선형에 가깝게 줄어든다.

왜 이런가?

• Lambda는 “메모리 단위 요금제”지만, 같은 레버로 CPU/네트워크 대역폭도 비례 증설한다.

• 그러니 I/O가 아닌 연산 위주(추론, 디코더, 보코더, 토큰화) 작업은 메모리 슬라이더를 올리는 게 곧 vCPU 수 증가로 이어진다.

실전 튜닝 절차(ONNX Runtime 기준)

1. 기본 설정
• intra_op(스레드 풀)와 inter_op(그래프 간 병렬) 스레드를 **기본값(자동)**으로 두고 시작. Lambda가 주는 vCPU가 늘어날수록 ORT가 자연히 더 쓰게 된다.

2. 메모리 스윗 스팟 찾기
• 메모리 단계를 1024→1536→1769→3072→5120→10240 MB 식으로 올리며 p50/p95 지연을 측정.
• 1,769 MB 지점에서 “~1 vCPU” 체감이 오고, 3–5 GB 근처에서 추론 시간이 뚝 떨어지는 구간이 자주 보인다.

3. 동시성·비용 밸런스
• 단일 호출이 충분히 빨라졌다면 **동시성(Reserved/Provisioned)**과 메모리의 곱으로 총 처리량/원가를 맞춘다. 빠른 함수는 실행 시간이 짧아져 GB‑초 요금이 상쇄되어 오히려 더 저렴해지는 경우가 많다.

4. 콜드스타트 고려
• SnapStart/프로비저닝을 쓰면 고메모리에서 늘어나는 초기화 비용을 회피 가능. 모델 로드가 무겁다면 메모리↑ + SnapStart/PC 조합이 체감이 크다.

체크리스트

• 모델이 CPU‑bound인지 먼저 확인(CloudWatch Logs로 단계별 타임라인 분해: 모델 로드/전처리/추론/후처리).

• ARM(Graviton)과 x86_64 모두에서 테스트. 동일 메모리라도 vCPU/IPC 특성이 달라 최적점이 다를 수 있다.

• ORT 빌드가 OpenMP/NEON/AVX2 등 대상 아키텍처 최적화가 켜져 있는지 확인. (Lambda AL2023용 빌드는 mtune=neoverse-n1(ARM) 또는 해당 x86 플래그 권장)

• 스레드 고정값을 줬다면(예: SetIntraOpNumThreads(1)), 자동 스케일의 이점이 사라짐. 먼저 해제하고 측정 후 필요시 미세조정.