Stop hand-tuning kernels: How Neuron Agentic Development accelerates AWS Trainium optimizations
Quick Summary
Neuron Agentic Development는 NKI 커널 작성, 디버깅, 프로파일링, 분석을 에이전트와 스킬로 묶어 Trainium·Inferentia 기반 커널 최적화의 진입 장벽과 반복 비용을 낮추려는 도구 모음이다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
Neuron Agentic Development는 NKI 커널 작성, 디버깅, 프로파일링, 분석을 에이전트와 스킬로 묶어 Trainium·Inferentia 기반 커널 최적화의 진입 장벽과 반복 비용을 낮추려는 도구 모음이다.
📌 핵심 요약
- 글은 대규모 AI 모델이 복잡해질수록 하드웨어가 이론적으로 제공할 수 있는 성능과 실제 개발팀이 얻는 성능 사이의 격차가 커지고 있으며, 이를 줄이기 위한 기존 방식인 수작업 커널 최적화가 높은 전문성과 긴 반복 과정을 요구한다고 설명한다.
- Amazon은 이 문제를 해결하기 위해 Neuron Agentic Development 기능을 발표하며, Kiro와 Claude 같은 코딩 에이전트가 Neuron Kernel Interface 커널을 작성, 디버깅, 프로파일링하도록 돕는 스킬과 에이전트 구성을 제시한다.
- 핵심 스킬은 작성, 디버깅, 프로파일링, 프로파일 질의, 문서 탐색으로 나뉘며, 각각 NKI 코드 생성, 오류 해결, 하드웨어 실행 추적 수집, 병목 분석, API·오류·아키텍처 문서 조회를 담당한다.
- 실습에서는 scaled softmax 커널을 작성하고, 브로드캐스팅 오류를 수정한 뒤 실제 Trainium 하드웨어에서 PyTorch 기준값과 수치 일치성을 확인하는 과정을 보여준다.
- 이어 SwiGLU MLP 커널 프로파일링 사례를 통해 Tensor Engine의 비효율처럼 보이는 현상을 더 깊이 조사한 결과, 실제로는 DMA 전송 크기와 반복 로딩 문제가 핵심 개선 지점일 수 있음을 소스 라인 수준까지 추적한다.
🧩 주요 포인트
- 글은 대규모 AI 모델이 복잡해질수록 하드웨어가 이론적으로 제공할 수 있는 성능과 실제 개발팀이 얻는 성능 사이의 격차가 커지고 있으며, 이를 줄이기 위한 기존 방식인 수작업 커널 최적화가 높은 전문성과 긴 반복 과정을 요구한다고 설명한다.
- Amazon은 이 문제를 해결하기 위해 Neuron Agentic Development 기능을 발표하며, Kiro와 Claude 같은 코딩 에이전트가 Neuron Kernel Interface 커널을 작성, 디버깅, 프로파일링하도록 돕는 스킬과 에이전트 구성을 제시한다.
- 핵심 스킬은 작성, 디버깅, 프로파일링, 프로파일 질의, 문서 탐색으로 나뉘며, 각각 NKI 코드 생성, 오류 해결, 하드웨어 실행 추적 수집, 병목 분석, API·오류·아키텍처 문서 조회를 담당한다.
- 실습에서는 scaled softmax 커널을 작성하고, 브로드캐스팅 오류를 수정한 뒤 실제 Trainium 하드웨어에서 PyTorch 기준값과 수치 일치성을 확인하는 과정을 보여준다.
- 이어 SwiGLU MLP 커널 프로파일링 사례를 통해 Tensor Engine의 비효율처럼 보이는 현상을 더 깊이 조사한 결과, 실제로는 DMA 전송 크기와 반복 로딩 문제가 핵심 개선 지점일 수 있음을 소스 라인 수준까지 추적한다.
🧠 상세 정리
1. 하드웨어 성능 격차와 수작업 커널 최적화의 부담
글은 프런티어 AI 모델이 커지고 복잡해지면서 모든 하드웨어 플랫폼에서 공통적으로 나타나는 문제가 있다고 출발한다. 모델이 실행되는 실리콘에서 최대 성능과 효율을 끌어내는 일은 실시간 월드 모델 경험, 에이전트형 워크플로의 더 깊은 추론, 대규모 추론 비용 절감 같은 목표와 직접 연결된다. 그러나 하드웨어가 이론적으로 제공할 수 있는 성능과 대부분의 팀이 실제로 달성하는 성능 사이에는 여전히 큰 차이가 있다. 기존에는 이 차이를 줄이기 위해 커스텀 커널 개발이 사용됐지만, 이는 칩 구조에 대한 깊은 이해, 수동 프로파일링, 반복적인 최적화 사이클을 필요로 했다. 글은 이런 방식이 소수의 전문 인력에게만 가능한 일처럼 여겨졌다는 문제의식을 제시한다.
2. Neuron Agentic Development의 목표와 발표 내용
본문은 모든 머신러닝 엔지니어가 별도의 장기간 칩 수준 경험 없이도 성능 엔지니어처럼 일할 수 있다면 어떨지 묻는다. 즉 하드웨어를 의식한 커널을 작성하고, 병목을 진단하며, 최적화된 모델을 배포하는 과정을 에이전트 도구가 지원할 수 있다는 관점을 제시한다. Amazon은 이를 위해 AWS Trainium과 AWS Inferentia에서 개발하는 사용자를 위한 Neuron Agentic Development 기능을 발표한다. 첫 기능들은 Kiro와 Claude의 코딩 에이전트가 Neuron Kernel Interface, 즉 NKI 커널을 작성하고 디버깅하며 프로파일링하도록 돕는다. 이를 통해 다른 아키텍처에 익숙한 커널 개발자도 Trainium으로 더 빠르게 전환하고, 팀은 아이디어에서 하드웨어 최적화 구현까지 걸리는 시간을 줄일 수 있다고 설명한다.
3. 커널 개발 파이프라인을 따르는 다섯 가지 스킬
Neuron Agentic Development 패키지는 커널 개발의 자연스러운 흐름인 작성, 디버깅, 프로파일링, 분석을 따라 다섯 가지 전문 스킬을 제공한다. 사용자는 특정 작업을 위해 스킬을 개별적으로 호출할 수도 있고, neuron-nki-agent를 통해 요청에 맞는 워크플로를 자동 선택하도록 연결할 수도 있다. 이 스킬들은 에이전트형 IDE의 skills 디렉터리에 추가해 사용할 수 있으며, 예시로 VS Code, Cursor, Kiro에서 .kiro/skills 또는 .claude/skills 디렉터리에 배치하는 방식이 제시된다. 다만 스킬은 Trainium 기반 Amazon EC2 인스턴스에서 실행되어야 한다. 전체 구조는 개별 개발 단계의 도우미가 아니라, 커널 작성부터 성능 분석까지 이어지는 작업 체인을 에이전트가 보조하도록 설계되어 있다.
4. NKI 커널 작성, 디버깅, 문서 지원 기능
neuron-nki-writing 스킬은 PyTorch, NumPy 또는 자연어 설명을 올바른 NKI 코드로 변환하는 시작점으로 소개된다. 이 스킬은 128 파티션 차원, 512 또는 4096 PSUM free dimension 같은 하드웨어 제약을 고려한 타일링 전략, 메모리 접근 패턴, 명시적 dst 파라미터를 포함한 연산, DMA 크기와 SBUF 재사용 같은 효율 지침을 다룬다. neuron-nki-debugging 스킬은 Trainium과 Inferentia 하드웨어에서 발생하는 NKI 컴파일 및 실행 오류를 해결하기 위한 체계적 흐름을 제공한다. 여기에는 올바른 --target 플래그를 포함한 환경 설정, 28개 NCC 오류 코드의 분류된 색인을 활용한 컴파일러 오류 해결, CPU 기준값과의 수치 검증이 포함된다. neuron-nki-docs 스킬은 작성 중 API 시그니처와 튜토리얼을 제공하고, 디버깅 중 오류 코드를 설명하며, 프로파일링 중 하드웨어 아키텍처 세부 정보를 확인하는 데 쓰인다.
5. 프로파일링과 프로파일 질의를 통한 병목 분석
프로파일링 영역에서는 neuron-nki-profiling 스킬과 neuron-nki-profile-querying 스킬이 구분되어 설명된다. neuron-nki-profiling은 하드웨어에서 실행 프로파일을 캡처하기 위해 런타임 검사 환경 변수를 설정하고, 커널을 실행하며, 올바른 Neuron Execution File Format 파일을 식별한다. 이어 neuron-explorer를 통해 DMA Graph Engine 알림을 포함한 trace를 캡처하고, JSON 메트릭과 NEFF 파일을 생성한다. neuron-nki-profile-querying은 NEFF와 NTFF 파일을 받아 SQL 쿼리를 실행해 성능 한계를 계산하고, 병목 엔진을 식별하며, 비효율이 발생하는 위치를 NKI 소스 라인 수준으로 좁힌다. 분석 방법으로는 neuron-explorer API 서버, parquet에 대한 DuckDB 직접 질의, 사용자 정의 계산을 위한 pandas 방식이 제시된다.
6. 전문 에이전트들이 구성하는 자율 워크플로
스킬이 개별 작업의 빌딩 블록이라면, 에이전트는 여러 스킬을 묶어 다단계 개발 시나리오를 끝까지 처리하는 전문 페르소나로 설명된다. neuron-nki-agent는 NKI 개발의 통합 진입점이며, 사용자의 요청이 작성, 디버깅, 프로파일링, 문서 조회 중 어디에 해당하는지 판단해 적절한 스킬을 오케스트레이션한다. neuron-nki-writing-agent는 커널 작성에 집중해 PyTorch, NumPy, 자연어 설명을 NKI 코드로 변환하거나 기존 커널 수정을 처리한다. neuron-nki-debugging-agent는 컴파일러 오류를 분석하고 문서를 검색해 수정안을 적용하며, 최대 10회의 반복을 추적하고 막힐 경우 점진적으로 단순화한다. profile-analysis 에이전트는 프로파일 캡처와 질의 분석을 결합해 성능 한계, 병목 엔진, 특정 소스 라인의 비효율을 찾는 흐름을 담당한다.
7. scaled softmax 커널 작성과 실제 하드웨어 디버깅
실습의 첫 부분은 추론 파이프라인에서 PyTorch softmax 연산이 병목이라고 가정하고, 이를 앞선 scale 연산과 융합한 커스텀 NKI 커널로 작성하는 상황을 다룬다. 사용자는 Kiro CLI에서 마지막 차원에 대해 softmax(x * scale)을 계산하는 bfloat16 입력 형태의 커널을 작성해 달라고 요청한다. 에이전트는 row max, sum-of-exp, normalize로 구성된 3패스 커널을 생성하고, 하드웨어 가속 exp를 위해 nisa.activation(np.exp, ...)를 사용하며, 수치 안정성을 위해 float32 누산을 적용한다. 이후 커널을 실행하고 PyTorch 기준값과 비교하자 nisa.tensor_tensor가 reduction 결과를 자동 브로드캐스트하지 않는 문제가 드러난다. 에이전트는 NKI 참조 패턴을 확인해 .ap()를 통한 stride-0 access view 방식으로 커널을 고치고, 네 가지 shape 테스트에서 모두 bfloat16 허용 오차 내 결과를 얻는다.
8. SwiGLU 커널 프로파일링에서 드러난 실제 최적화 지점
커널이 컴파일되고 수치적으로 올바른 결과를 낸 뒤에는 하드웨어 실행을 프로파일링해 병목을 찾는 단계가 이어진다. 본문은 실제 워크로드 예시로 대형 언어 모델에서 흔히 쓰이는 SwiGLU MLP 커널을 사용한다. 에이전트는 먼저 커널을 NEFF로 컴파일하고 neuron-explorer로 NTFF trace를 캡처한 다음, 커널 수준 통계와 성능 한계를 살펴보고 instruction 실행 수준에서 세부 비효율을 질의한다. 분석 결과 Tensor Engine이 실행 시간을 지배하고 비효율적이며 큰 idle gap을 가진 것으로 나타나지만, 추가 조사에서는 NKI matmul 명령 자체는 거의 최대 효율에 가깝다는 점이 확인된다. 대신 DMA 명령이 목표 크기보다 작고 입력을 여덟 번 다시 로드하는 중복이 있으며, 이 문제를 만드는 NKI 코드 세 줄까지 찾아내는 것이 핵심 결론으로 제시된다.
🧾 핵심 주장 / 시사점
- 글의 핵심은 커널 최적화 자체를 자동화한다기보다, 작성·오류 수정·측정·원인 추적의 반복 루프를 에이전트가 구조화해 더 많은 개발자가 접근할 수 있게 만드는 데 있다.
- softmax 예시는 에이전트가 처음부터 완벽한 코드를 내는 사례가 아니라, 실제 하드웨어 실행에서 드러난 오류를 문서와 패턴을 바탕으로 수정하는 반복형 워크플로를 보여준다.
- SwiGLU 프로파일링 사례는 겉으로 보이는 병목 엔진만 보고 최적화 대상을 정하면 오판할 수 있으며, 소스 라인 수준의 데이터 이동 분석이 실제 개선 우선순위를 바꿀 수 있음을 보여준다.
✅ 액션 아이템
- internal coding agents와 AWS가 바꾸는 업무·제품 흐름을 internal coding agents 같은 원문 근거로 분해해 실제 적용 범위를 점검한다.
- AWS와 internal coding agents의 연결 지점을 기준으로 사용자 경험, 운영 비용, 보안·책임 경계를 나눠 검토한다.
- 후속 발표나 운영 데이터가 나오면 internal coding agents의 AWS 실행 성과를 원문에서 제시한 지표와 다시 비교한다.
❓ 열린 질문
- internal coding agents의 AWS 변화가 실제 사용자 워크플로에 자리 잡으려면 internal coding agents 중 어떤 지표가 먼저 개선되어야 할까?
- AWS와 internal coding agents 조합은 다른 조직이나 제품 환경에서도 같은 효과를 낼 수 있을까?
- internal coding agents가 AWS의 신뢰성을 증명하려면 어떤 후속 데이터나 운영 사례를 공개해야 할까?