Meta는 추천 모델 1,500개 이상을 NVIDIA GPU, AMD GPU, 자체 MTIA에서 운영한다고 설명합니다. 필요한 커널이 없거나 느리면 CPU 계층을 따로 두어 네트워크 지연을 감수하거나 모델 출시를 미뤄야 합니다. KernelEvolve는 이 조합 문제를 한 번의 코드 생성이 아니라 측정이 포함된 탐색으로 다룹니다[1].
만들고 실행하고 선택하고 기억하는 방식
시스템은 최적화 후보를 그래프 상태로 표현합니다. 에이전트가 문서와 운영 코드를 검색해 Triton·CuTe DSL·저수준 코드를 만들고, 컴파일·정확성 검사·성능 측정을 거쳐 좋은 가지를 확장합니다. 일반 모델이 학습하지 못한 자체 가속기 규칙은 지속 지식 저장소에서 가져옵니다.
KernelBench 250개와 ATen 연산자-플랫폼 조합 480개를 모두 통과했습니다. 운영 작업의 PyTorch 기준 대비 속도 향상은 1.25~17×이고 개발 기간은 수주에서 수시간으로 줄었다고 보고합니다. 입력 모양에 따라 성능이 나빠지는 후보도 있으므로 배포 판정에는 한 입력이 아니라 운영 분포를 사용합니다.
커널 수는 연산자 목록보다 빠르게 늘어나는 조건
연산자 이름 하나가 구현 문제 하나를 뜻하지 않습니다. 입력 모양, 레이아웃, 데이터 형식, 희소성, 융합 경계, 정확도 허용치, 가속기 세대, 컴파일러 버전, 주변 그래프가 최적 커널을 바꿉니다. NVIDIA·AMD GPU와 MTIA, PyTorch 분해, Triton, CuTe DSL, 저수준 코드를 곱하면 수백 연산자가 수천 개 성능 구간으로 늘어납니다[1].
전문가 팀은 비용이 큰 조합부터 최적화하고 나머지에는 범용 경로를 둡니다. 새로운 모양이 대량 작업에 들어오거나 새 칩에서 순위가 바뀌면 이 경로가 CPU 이동, 여러 작은 커널, 비효율적인 레이아웃을 만들 수 있습니다. 비용은 한 연산자의 지연을 넘어 그래프 융합과 메모리 상주까지 바꿉니다.
KernelEvolve는 입력 하나가 아니라 운영 분포를 대상으로 삼습니다. 큰 행렬 하나에서 이기지만 자주 나타나는 작은 입력에서 느린 후보는 기존 구현을 대체하지 않습니다. 이것이 벤치마크 점수만 높이고 실제 서비스를 늦추는 일을 막는 첫 조건입니다.
긴 프롬프트보다 탐색 상태가 중요한 이유
시스템은 후보를 그래프로 구성합니다. 노드는 구현과 측정 상태를 담고, 간선은 변환·수정·대안 전략을 나타냅니다. 하나의 프로그램을 계속 고치는 대신 여러 갈래를 확장합니다. 현재는 느린 후보라도 새로운 레이아웃이나 동기화 방식을 제공해 다음 변환에서 유용할 수 있으므로 다양성을 보존합니다.
생성 과정은 문서, 운영 커널, 컴파일러 제약, 가속기별 메모를 검색합니다. 모델이 비공개 명령어나 최신 컴파일러 동작을 기억한다고 가정하지 않습니다. 플랫폼이 바뀌면 검색 지식의 규칙을 갱신하고 성공과 실패를 함께 저장해 다음 작업이 같은 오류를 반복하지 않게 합니다.
수천 후보를 컴파일하고 측정하면 시험 인프라 비용도 큽니다. 어느 시점에 개선이 멈췄는지, 어떤 갈래에 실험을 더 줄지, 다른 입력까지 검증할 만큼 결과가 안정적인지 결정해야 합니다. 가장 빠른 한 번보다 실험 비용과 신뢰도가 중요합니다.
정확성은 여러 검사를 통과해야 할 이유
생성 코드는 실행 전에는 안전하지 않습니다. 편한 입력에서 정답을 내더라도 타일 경계에서 범위를 벗어나 읽거나, 다른 크기에서 경합이 생기거나, 누산기가 넘치거나, 정렬 조건을 어길 수 있습니다. KernelEvolve는 컴파일, 실행, 수치 비교, 성능 측정을 탐색 안에 넣어 검사를 통과한 코드만 다음 후보의 기반으로 씁니다.
정답 판정도 하나로 충분하지 않습니다. 정확 연산은 비트 단위 일치가 필요하고 저정밀 연산은 운영 계약에 맞춘 절대·상대 오차가 필요합니다. 빈 차원, 타일을 채우지 못하는 끝부분, 비연속 레이아웃, 극단값, 메모리 별칭, 실제 입력 분포를 시험해야 합니다. 반복 실행은 한 번에 드러나지 않는 경합을 찾습니다.
보고된 730개 시험의 통과는 평가 범위가 넓다는 증거이지 모든 입력, 드라이버, 미래 컴파일러의 정확성을 증명하지 않습니다. 생성 모델, 도구 체인, 하드웨어가 바뀔 때 같은 검사를 다시 수행해야 합니다.
성능은 운영 문맥에서 다시 재야 할 이유
마이크로벤치마크는 따뜻한 캐시, 순간 부스트 클록, 비동기 실행 시점, 측정 잡음의 영향을 받습니다. 준비 실행과 반복 측정이 필요하고 비동기 작업이 실제로 끝난 경계에서 시간을 재야 합니다. 짧은 커널은 호출 비용이 지배할 수 있고 융합한 후보는 한 연산의 일을 다른 측정 영역으로 옮길 수 있습니다.
개별 커널이 빨라도 전체 모델에서 다시 확인해야 합니다. 임시 메모리가 늘거나 통신과의 겹침이 줄고, 그래프 융합을 막거나 동시 스트림의 자원을 독점할 수 있습니다. 입력 모양별 성능 저하가 보고된 것은 이런 상호작용이 실제임을 보여 줍니다. 최대 속도보다 운영 빈도로 가중한 지연이 중요합니다.
1.25~17×는 하나의 보편적 배수가 아니라 여러 커널의 범위입니다. 큰 배수는 느린 범용 경로를 대체한 경우일 수 있으며 모델 전체가 17배 빨라진다는 뜻이 아닙니다. 전체 효과는 해당 연산자가 기존 실행 시간에서 차지한 비율로 제한됩니다.
축적된 지식이 다음 세대의 자산
탐색은 최종 코드 외에도 어느 타일 크기가 메모리 계층에 맞는지, 어떤 동기화가 잘 컴파일되는지, 어떤 형식 변환이 비용을 만드는지 학습합니다. 이 결과를 버전이 있는 검색 지식으로 남기면 다음 에이전트는 일반적인 GPU 조언이 아니라 검증된 제약에서 시작합니다.
각 기록에는 장치, 드라이버, 컴파일러, 라이브러리, 입력 범위를 붙여야 합니다. 큰 타일이 빠르다는 규칙도 새 칩에서 레지스터가 넘치면 반대로 바뀔 수 있습니다. 오래된 지식은 우선순위를 낮추거나 재검증해야 하며, 비공개 가속기 정보는 접근 권한을 분리해야 합니다.
실패도 보존할 가치가 있습니다. 드문 수치 오류나 특정 레이아웃의 성능 저하를 기록하면 여러 에이전트가 같은 위험한 변환을 되풀이하지 않습니다. 공유 기억이 없으면 병렬 탐색의 상당 부분이 같은 막힌 경로를 다시 찾는 데 쓰입니다.
이식성은 같은 코드가 아닌 같은 절차
세 플랫폼은 하나의 커널 언어로 실행되지 않습니다. Triton은 여러 GPU 패턴을 다루고, CuTe는 다른 기본 요소를 노출하며, MTIA에는 공개 모델이 알 수 없는 내부 제약이 있습니다. KernelEvolve가 공유하는 것은 생성 언어가 아니라 탐색·검증 절차이며 대상별 생성기와 규칙은 달라집니다.
모든 가속기를 한 추상화에 맞추면 메모리 엔진, 행렬 명령, 동기화 특성이 가려집니다. 반대로 칩마다 별도 시스템을 만들면 시험, 실험 추적, 배포 제어가 중복됩니다. 공통 제어 계층과 플랫폼별 백엔드를 나누면 안전 절차는 재사용하면서 네이티브 경로를 살릴 수 있습니다.
플랫폼 비교도 같은 작업 조건을 써야 합니다. 연산자 이름이 같아도 레이아웃, 정밀도, 융합 범위가 다르면 같은 시험이 아닙니다. 가속기 구매에는 전체 모델, 전력 경계, 품질 조건을 다시 맞춰야 합니다.
배포는 되돌릴 수 있어야 할 이유
채택한 후보는 지원 입력과 환경 정보를 붙인 레지스트리에 먼저 들어갑니다. 일부 호출에서 기존 커널과 함께 실행해 결과만 비교하면 생성 결과를 서비스에 쓰지 않고 실제 입력을 검증할 수 있습니다. 이후 소수 장비에서 동시 실행과 열 조건을 확인하고 문제가 없을 때 기본 경로로 승격합니다. 이전 구현은 즉시 되돌릴 수 있게 유지해야 합니다.
모니터링에는 정확성 경보, 지연 분포, 컴파일 실패, 메모리 사용량, 최적화 범위 밖 호출 비율이 필요합니다. 새 모델이 입력 분포를 바꾸면 최적 커널 자체는 빨라도 대부분 트래픽이 범용 경로로 돌아갈 수 있습니다. 커버리지를 운영 지표로 다뤄야 합니다.
생성 커널은 가속기 메모리에 직접 접근합니다. 격리된 컴파일, 서명한 산출물, 제한된 도구 권한, 의존성 검사, 검색 코드의 출처 관리가 필요합니다. 시험 입력에서 정답을 냈다는 사실만으로 범위 밖 접근이나 데이터 유출이 없다고 볼 수 없습니다.
마지막 병목은 명세
KernelEvolve는 사람이 정한 목적 함수와 정확성 계약 안에서만 탐색합니다. 오차 허용치가 느슨하면 품질이 낮은 코드를 고르고, 벤치마크가 운영의 긴 꼬리 입력을 빼면 잘못된 구간을 최적화합니다. 지연, 처리량, 전력, 메모리, 결정성 사이의 우선순위를 명시해야 합니다.
최적화 여지가 작아 탐색 비용이 전문가 구현보다 큰 연산도 있습니다. 측정 잡음을 개선으로 오인하지 않고 안전한 향상이 없다고 멈출 수 있어야 합니다. 새로운 알고리즘, 정답 판정, 배포 범위, 연산자 경계를 넘는 예외는 전문가가 책임집니다.
조직이 결정할 대상은 모델에게 코드를 쓰게 할지 여부가 아니라 측정 기반 커널 생산 체계를 만들지 여부입니다. 검색 지식, 실행 자원, 엄격한 판정, 산출물 관리, 운영 피드백을 갖춰야 생성이 더 넓은 하드웨어 영역으로 전문가 판단을 확장할 수 있습니다.
개발 기간이 수주에서 수시간으로 줄었다는 결과에는 코드 생성, 자동 컴파일, 병렬 실험, 미리 만든 시험 체계, 축적된 지식의 효과가 함께 들어 있습니다. 비교할 전문가에게도 같은 정답 시험, 하드웨어 시간, 문서, 기준 코드를 제공해야 자동화 자체의 기여를 구분할 수 있습니다. 후보 수와 장치 사용 시간, 컴파일 실패, 정확성 탈락, 반복 측정의 변동도 함께 보고해야 합니다.
생성한 소스가 실제 실행 코드와 같지도 않습니다. 컴파일러가 명령 선택, 레지스터 배치, 메모리 스케줄을 바꾸며 버전에 따라 우연한 이득이 사라질 수 있습니다. 소스와 중간 표현, 최종 바이너리, 도구 체인 해시, 장치 대상을 함께 보존하면 새 컴파일러에서 기준과 후보를 다시 비교하고, 반복해서 유용한 변환을 라이브러리나 컴파일러 규칙으로 올릴 수 있습니다.
커널 탐색은 검증 가능한 운영 절차가 되는 과정
에이전트 코딩은 실행 결과가 다음 후보 선택에 직접 반영될 때 운영 인프라가 됩니다. 검색은 비공개 하드웨어 지식을 공급하고, 시험은 틀린 코드를 제거하며, 성능 측정은 직관 대신 근거를 제공합니다. 최고 속도보다 중요한 결과는 생성 코드를 실행 전에는 신뢰하지 않으면서 변화하는 칩의 커널 범위를 유지하는 절차입니다.
생성보다 승인 절차가 탐색의 경제성을 결정하는 기준
KernelEvolve가 후보를 많이 만드는 것만으로 운영 가치는 생기지 않습니다. 대표 연산 형태와 데이터 형식(dtype)에 대한 수치 검증, 반복 실행 시 성능 분산, 컴파일 및 실행 안정성, 메모리 안전성, 모델과 컴파일러 버전에 연결된 되돌림 절차를 통과해야 실제 배포 후보가 됩니다. 한 벤치마크에서 빠르더라도 드문 연산 형태에서 실패하거나 누산 오차를 바꾸는 커널은 장비군 전체에 적용할 수 있는 최적화가 아닙니다.
탐색 비용은 생성한 후보 수가 아니라 최종 승인한 커널에 배분해야 합니다. 후보 생성, 컴파일, 시험, 탈락에 사용한 가속기 시간을 기록하고, 승격한 커널이 처리할 호출 횟수에 걸쳐 비용을 나누면 전문가 튜닝과 비교할 수 있습니다. 호출량이 많고 오래 유지되는 연산자는 큰 탐색 비용을 감당할 수 있지만, 모델이 자주 바뀌거나 사용량이 적은 연산자는 그렇지 않습니다. 구매 기준은 조직의 실제 배포 주기에서 검증된 성능 향상을 탐색 비용으로 나눈 값이어야 합니다.
출처와 저작권 안내
이 글은 독립적인 문장과 두 새 도판으로 작성했습니다. 원문의 문장·코드·도판·표를 복제하지 않았습니다. Meta가 전문 기술 보고서를 공개했으며 ISCA 판본은 (c) IEEE 2026입니다.