이미지 한 장 뽑는 시간이 42.3% 줄었습니다

커널 코드를 다시 짠 쪽은 사람이 아닙니다. GPU 커널을 스스로 고치는 에이전트가 Qwen-Image 서빙에서 이미지 한 장 뽑는 시간을 42.3% 줄였습니다.

벤치마크 점수가 아니라 실제로 서비스가 응답하는 시간, 엔드투엔드 지연시간입니다.

공개한 사람은 브라이언 리입니다. Baseten에서 모델 성능을 맡고 있고, 워털루대 컴퓨터공학을 다닙니다. X에 올린 아티클 제목은 「The future of kernel engineering」, 소개 트윗은 조회 20만을 넘겼어요.

같은 프레임워크가 FLUX.2에서는 15.2%, MiniMax M3에서는 초당 토큰 5.5% 증가를 기록했습니다. 전부 B300 GPU 위에서 SGLang 서빙 엔진으로 돌린 결과예요.

벤치마크 1등 커널은 왜 서비스에서 죽을까요?

브라이언 리가 글 앞머리에 박아둔 문장이 이렇습니다.

"커널 벤치마크에서 이기는 일과 최적화를 프로덕션에 배송하는 일 사이에는 간극이 있다."

그가 꼽은 간극은 넷입니다.

첫째, 최적 설정이 워크로드마다 달라집니다. 같은 커널이라도 배치 크기와 해상도가 바뀌면 가장 빠른 구성이 따라 바뀌어요. 벤치마크는 한 조건에서만 겨루니까 그 조건 밖에서는 순위가 뒤집힙니다.

둘째, 마이크로벤치마크가 모델 속도를 대변하지 못합니다. 저자 표현을 그대로 옮기면 "더 빠른 마이크로벤치마크가 곧 더 빠른 모델은 아니다"예요. 커널 하나를 30% 당겨도 그 커널이 전체 시간에서 3%면 최종 이득은 1%입니다.

셋째, 커널을 하나씩 떼어놓고 보면 놓치는 게 생깁니다. 연산 두 개를 하나로 붙이는 융합, 같은 값을 두 번 계산하는 중복 제거. 둘 다 커널 경계를 넘어야 보이는 기회라, 낱개 최적화로는 손이 닿지 않아요.

넷째, 서빙 엔진에 배선하는 작업이 남습니다. 빠른 커널을 손에 쥐어도 SGLang 같은 엔진 안으로 넣어 굴러가게 만드는 건 별개 작업입니다.

이 넷을 합치면 결론이 하나로 모입니다. 커널 하나를 잘 짜는 능력만으로는 서비스가 빨라지지 않습니다.

에이전트는 어디부터 들여다볼까요?

프레임워크는 네 단계를 한 바퀴로 돕니다.

모델 전체를 프로파일링해서 시간이 어디로 새는지 봅니다. 그 프로파일을 근거로 최적화를 제안합니다. 제안대로 커널을 생성하고, 마지막에 실제 서빙 스택 위에 올려 검증합니다.

핵심은 시작점입니다. 커널 목록이 아니라 모델 전체 프로파일에서 출발해요. 사람이 "이 커널을 빠르게 해달라"고 지정하는 대신, 에이전트가 느린 자리를 스스로 고릅니다.

최적화 층은 둘로 나뉩니다.

모델 층에서는 연산을 붙이고 지웁니다. QKV 계산과 뒷단 처리를 하나로 묶고, 정규화와 양자화를 붙이고, 불필요한 연산을 아예 걷어냅니다. FP8 가중치를 미리 포장해두는 최적화 하나가 두 모델에서 각각 7.3%, 6.1%를 벌었어요.

커널 층에서는 병렬 구현을 탐색합니다. 같은 연산을 짜는 방법 여러 개를 동시에 만들어 겨루게 하고, 가장 빠른 쪽을 남깁니다. Qwen-Image에서 이 층만으로 7.6%와 13.4%를 더 줄였습니다.

실패한 커널은 어디로 갈까요?

여기가 이 프레임워크에서 가장 재미있는 대목입니다.

통과한 커널은 지식베이스에 저장됩니다. 여기까지는 예상 가능해요. 그런데 실패한 커널도 버리지 않습니다.

왜 틀렸는지, 어디서 어긋났는지를 교훈으로 적어 같이 쌓아둡니다. 다음 최적화는 그 기록을 읽고 출발합니다. 같은 벽에 두 번 부딪히지 않는 구조예요.

브라이언 리가 여기서 그린 그림이 이렇습니다.

"배포마다 실제 트래픽에 가장 잘 맞는 구현으로 계속 진화할 수 있다."

한 번 튜닝하고 끝나는 게 아니라, 서비스가 굴러가는 동안 커널이 계속 다시 태어난다는 말입니다. 트래픽 모양이 바뀌면 최적 구성도 바뀐다는 첫째 간극에 대한 답이기도 하고요.

42.3%는 어떤 항목을 더한 값일까요?

Qwen-Image 쪽부터 봅니다.

바이어스를 곱셈 안으로 흡수하는 최적화가 5.2%를 줄였습니다. 이 항목 하나가 FP8 연산 단계에서 차지하던 몫이 약 11%였어요.

CFG 캐시는 FP8에서 2.1%, NVFP4에서 3.1%를 줄였습니다. 여기에 앞서 본 커널 층 탐색 몫이 더해집니다.

FLUX.2 쪽 항목은 결이 조금 다릅니다.

QK 계산과 RoPE를 합친 커널이 2배 빨라졌습니다. 이어붙이기 호출이 60번에서 12번으로 줄어든 덕입니다. 전체 지연시간 기준으로는 2.3%와 4.0%를 벌었어요.

SwiGLU와 양자화를 붙여 2.3%, 3.8%. 게이트 잔차 처리로 1.2%, 2.3%. 커널 층 탐색으로 1.9%, 2.8%.

숫자를 늘어놓고 보면 성격이 드러납니다. 한 방에 42%를 당긴 최적화는 없어요. 2%, 5%, 7%짜리 항목을 열 몇 개 쌓아 만든 값입니다.

사람이 이걸 하려면 항목마다 며칠씩 붙어야 합니다. 개별 이득이 작으니 우선순위에서 밀리고, 밀린 항목은 영영 안 됩니다. 에이전트가 잘하는 자리가 정확히 여기예요.

이 방식은 이미지 모델 밖으로도 갈까요?

이미 나가는 중입니다.

MiniMax M3에서 초당 토큰 처리량이 5.5% 늘었고, GLM-5.2도 대상에 올라 있습니다. 언어 모델 쪽 확장은 vLLM을 겨냥합니다.

이미지 모델과 언어 모델은 병목 위치가 다릅니다. 확산 모델은 같은 계산을 수십 번 반복하고, 언어 모델은 토큰을 한 개씩 뽑으며 메모리 대역폭에 먼저 막혀요. 그래서 언어 모델 쪽 이득 폭이 훨씬 작습니다.

이미지 모델 쪽 두 자릿수와 언어 모델 쪽 한 자릿수를 나란히 두면 이 프레임워크가 어디서 힘을 쓰는지 보입니다. 연산이 무겁고 반복이 많은 워크로드일수록 붙일 자리가 많습니다.

남는 생각

저는 실패 기록이 진짜 자산이라고 봅니다.

커널을 짜는 능력 자체는 이제 흔합니다. KernelBench에서 좋은 점수를 내는 모델은 여럿이고, 브라이언 리도 그 사실을 인정하고 글을 시작해요. 갈리는 지점은 안 되는 구현을 기억하느냐입니다.

통과한 답만 모으면 그냥 코드 창고입니다. 실패까지 이유와 함께 모으면 그 배포에만 있는 지도가 됩니다. 두 자릿수 단축은 그 지도가 쌓인 뒤에 나온 값이에요.

저는 이 구조가 커널 밖에서도 같은 모양으로 반복될 거라고 봅니다. 사람이 손으로 튜닝하던 자리, 이득이 작아서 아무도 안 건드리던 자리. 그 자리가 서비스마다 알아서 굳는 자리로 바뀝니다.

제가 이 글에서 가장 오래 붙들린 문장은 마지막 인용문이었습니다. "배포마다 실제 트래픽에 가장 잘 맞는 구현으로." 최적화가 출시 전에 끝내는 일에서, 서비스가 사는 동안 계속되는 일로 넘어간다는 뜻이거든요.

---

원문·소스

• 브라이언 리 원문 트윗 (@BrianLi23): https://x.com/BrianLi23/status/2093487934448214351 (조회 20만)