생성 측 툴이 검증 측 툴보다 앞선다

출처: Dev.to

생성 측은 빠르게 배포되고 있다 (TileGym, AutoKernel, KernelEvolve). “런타임에서 커널이 실제로 수행한 일”을 검증하는 측면은 그 속도를 따라가지 못하고 있다.
지난 9개월 동안 CUDA 커널 자동 생성에 대한 세 가지 중요한 릴리스가 나왔다: NVIDIA TileGym, RightNow AutoKernel, 그리고 Meta의 KernelEvolve. 각각은 커널 생성을 위한 학습 인프라를 제공한다. 그러나 검증 인프라(생성된 커널이 실제 워크로드에서, 프로덕션 환경과 유사한 상황에서 런타임에 실제로 무엇을 했는지)는 같은 속도로 발전하지 못했다. eBPF 트레이스는 이 격차를 메우는 근거 레이어이다.

두 가지 구분된 검증 레이어:

• 출시 전: 생성된 CUDA C가 컴파일되고, PTX가 어셈블되며, 커널이 레퍼런스와 수치적으로 동등한지 테스트한다. 표준 컴파일러/단위 테스트 영역이다. 생성 프레임워크가 자체적으로 이 과정을 제공한다.
• 출시 후: 커널이 실행되고, 반환되며, N 마이크로초가 걸리고, 스레드당 M 레지스터를 사용하고, X 캐시 미스 비율을 기록하며, 스트림 뒤의 작업을 직렬화했는지 여부를 확인한다. 이 레이어는 eBPF 트레이스와 표준 CUDA 드라이버 카운터를 통해 어떤 커널이든(자동 생성이든 수작업이든) 답을 얻을 수 있다.

자동 생성 파이프라인은 기본적으로 출시 후 루프를 닫지 않는다. “우리 테스트 환경에서는 커널이 동작한다”는 것을 보여줄 뿐, “프로덕션 추론 트래픽에서 p99 레이턴스가 악화되지 않는다”는 것을 증명하지 않는다.

실제 워크로드에 생성된 커널이 배치되면, 모든 CUDA 커널에 적용되는 동일한 트레이스 레이어가 사용된다: cudaLaunchKernel에서의 런치 레이턴스, cudaStreamSynchronize에서의 동기화 스톨, 디스패처에서 발생하는 호스트 측 오버헤드, GPU가 바쁠 때 발생하는 호스트 스케줄링 프리엠션 등. 이러한 신호들은 커널을 격리된 상태에서 평가하는 생성 프레임워크에서는 보이지 않는다.

— 출시 후 검증: 새로 생성된 커널이 p99를 악화시켰는가?

SELECT kernel_name,
       COUNT(*)                  AS launches,
       AVG(duration_ns)/1e3      AS avg_us,
       quantile(duration_ns,0.99)/1e3 AS p99_us
  FROM cuda_events
 WHERE timestamp_ns BETWEEN :before AND :after
 GROUP BY kernel_name
 ORDER BY p99_us DESC
 LIMIT 20;

위 쿼리를 생성된 커널이 수작업 커널을 대체하기 전에 캡처한 트레이스와 대체 후에 캡처한 트레이스에 각각 실행한다. 차이가 바로 “이번 생성이 실제로 도움이 되었는가”에 대한 유일한 답이다.

커널 생성은 지난 1년간 가장 빠르게 개선된 분야인 LLM 코딩 능력의 하위 흐름이다. 검증 인프라는 관측성 도구의 하위 흐름이며, 구조적인 이유(프로덕션에 instrumentation이 필요하고, 에이전트는 낮은 오버헤드를 가져야 하며, 도구는 SRE에게 신뢰받아야 함) 때문에 더 느리게 움직인다. 생성 측은 매 분기마다 새로운 릴리스를 내놓지만, 검증 측은 2~3년에 한 번 정도이다.

이 격차는 GPU 커널에만 국한된 것이 아니다. 소프트웨어 엔지니어링 전반에서 “AI‑생성 코드”와 “AI‑검증 코드” 사이의 격차를 그대로 반영한다. GPU 커널 버전이 더 날카로운 이유는, 프로덕션에서 잘못된 커널이 초당 수십 달러(시간당 $30 GPU 호스트)라는 비용으로 바로 드러나기 때문이다.

더 나은 생성 도구만 있으면, 검증 도구가 부족해도 생산에 투입되는 커널 수는 늘어나지만, 실제 워크로드에 대해 측정된 적이 없는 채로 남는다. 해결책은 생성 속도를 늦추는 것이 아니라, 검증 레이어를 생성 레이어만큼 저렴하게 만드는 것이다. 새로운 생성 커널마다 트레이스 캡처와 SQL 쿼리를 수행하는 것이 한 가지 실현 가능한 형태다.

Ingero – GPU 디버깅을 위한 오픈소스 eBPF 에이전트. 하나의 바이너리, 의존성 제로, <2% 오버헤드. Apache 2.0 + GPL‑2.0. [GitHub ⭐] · 자동 생성된 CUDA 커널을 프로덕션에 배포하고 실제 워크로드에서 저렴하고 반복 가능한 검증 방법을 원한다면 이슈를 열어 주세요.

• 자동 생성된 CUDA 커널은 커널 수준 검증이 필요하다 – 이 격차를 설명하는 전제 프레임워크.
• 프로덕션에서의 파동‑레벨 GPU 인스펙션 – 동일한 생성/검증 분할의 게임‑사이드 대응.
• nvidia-smi가 97% 사용률을 보고하지만 GPU가 유휴 상태인 경우 – 대시보드 카운터가 생성된 커널을 검증하지 못하는 이유.