BackendBench — fixing the LLM kernel correctness problem

2024-2025 년의 큰 흐름 — Claude / GPT / DeepSeek 같은 LLM 이 Triton 커널을 직접 짠다. KernelBench, GPU-Bench 같은 leaderboard 가 등장하고, 가장 빠른 커널이 누구의 모델이 짰는지 경쟁하는 분위기가 생겼다. 그런데 그 커널들이 실제로 맞는가는 별개의 질문이고, 잘 측정되지 않고 있었다.

BackendBench 는 그 공백을 메운다. 강의의 두 줄 요약.

1. "빠른 커널" 의 leaderboard 는 correctness 를 너무 약하게 본다. 단일 input 에서 atol 1e-2 통과면 "정답" 으로 친다. 그러나 production 학습 / 추론에서는 numerical drift, edge case (NaN, inf, broadcasting), shape variation, dtype 조합이 모두 깨진다.
2. PyTorch 의 OpInfo 위에 LLM 커널을 검증하는 표준 harness 가 필요하다. PyTorch 의 aten op 들은 이미 잘 정의된 reference 가 있고 (eager mode), 그것에 대해 LLM 이 짠 커널을 입력 다양성 × tolerance × dtype 조합으로 측정.

LLM 이 만든 커널이 깨지는 자리는 보통 사람이 잘 안 보는 자리다 — production 에서만 등장하는 입력의 모양, drift 가 만들 수 있는 dtype 조합, 그리고 silent NaN.

왜 이게 KernelBench 같은 다른 도구와 다른가 — KernelBench 는 한 종류의 op (matmul, attention) 의 best-of-N 속도를 본다. BackendBench 는 PyTorch 의 op 전체를 cover 하는 평면적 harness 다. 한 LLM 의 커널이 attention 에서 빛난다 해도 dropout 에서 fail 하면 production 에서는 동일하게 사용 불가능.

PyTorch 의 testing 인프라는 이미 거의 모든 aten op 에 대해 OpInfo entry 를 가진다 — input sample generator, output dtype rule, autograd support 정보. BackendBench 는 그 위에 얹힌다.

이 설계의 진짜 미덕은 분산 가능하다는 점. op 단위로 독립이라 1000 개 op 를 1000 개 worker 에 뿌릴 수 있다. PyTorch 가 OpInfo 를 잘 관리해온 부산물이 LLM 커널 검증 인프라가 된다.

numerical kernel 의 correctness 는 binary 가 아니다. 어디까지를 "통과" 로 볼지 명확하지 않으면 같은 커널이 누구는 통과 누구는 실패가 된다. BackendBench 의 채점 기준 — 강의에서 Mark 가 의도적으로 conservative 하게 잡았다고 강조한 부분.

# BackendBench 의 비교 함수 (개념)
def compare(out_kernel, out_ref, dtype):
    # NaN 위치 일치
    if torch.isnan(out_ref).any():
        if not torch.equal(
            torch.isnan(out_kernel),
            torch.isnan(out_ref),
        ): return Fail("nan_mask")

    # Inf 위치 일치
    if torch.isinf(out_ref).any():
        if not torch.equal(
            torch.isinf(out_kernel),
            torch.isinf(out_ref),
        ): return Fail("inf_mask")

    atol, rtol = TOLERANCES[dtype]
    if not torch.allclose(
        out_kernel, out_ref,
        atol=atol, rtol=rtol,
        equal_nan=True,
    ): return Fail("value_mismatch")

    return Pass()

BackendBench 의 부산물 — LLM 이 짠 커널이 실패하는 패턴이 표로 정리된다. 강의에서 Mark 가 강조한 5 가지 failure mode.

강의에서 Mark 가 발표 시점의 leaderboard 한 장면을 공유한다. 정확한 수치는 변동 — 모든 수치는 확인 필요이고 시점에 따라 달라진다. 의미는 모든 모델이 비슷한 수준에서 깨진다 는 frame 자체.

강의에서 의외였던 관찰 두 가지.

• 모델 크기와 정확성이 단조 증가하지 않는다 — 작은 코딩 전용 모델이 큰 general 모델보다 특정 op 에서 더 잘하는 경우가 빈번. 학습 데이터 분포가 결정적.
• 같은 모델이 같은 종류의 실수를 반복한다 — § 05 의 taxonomy 에서, 한 모델은 promotion 에서 자주 깨지고 다른 모델은 broadcasting 에서 자주 깨진다. fingerprint 가 있다.

BackendBench 의 두 번째 가치 — LLM 이 만든 커널을 자동으로 다시 짜게 만드는 loop의 base. failure mode 를 prompt 에 다시 넣으면 같은 모델이 두 번째 시도에서 더 많이 통과한다.

이 loop 가 시사하는 더 큰 그림 — LLM + evaluation harness 의 closed loop 가 새로운 컴파일러 형태가 된다. PyTorch op 의 reference 가 spec 이고, LLM 이 그 spec 을 만족하는 커널을 generate-and-test 로 찾는다. BackendBench 는 그 loop 의 testing 부분.

• PyTorch core CI — torch.compile 의 Triton 출력 검증의 일부로 BackendBench 의 sample 일부가 흘러들어간다 (확인 필요).
• KernelBench / GPU-Mode 대회 — 대회의 correctness gating 에 BackendBench 의 tolerance 정의를 차용.
• Anthropic / OpenAI — coder 모델의 GPU kernel 능력 측정 metric 의 하나로. 강의 시점에 이미 일부 모델 카드에 포함된 듯 (확인 필요).
• 학계 follow-up 논문 — KernelBench-Plus 같은 후속 도구들이 BackendBench 의 OpInfo-driven 설계를 따라간다.

채택의 큰 그림 — BackendBench 는 leaderboard 라기보다 standard test harness 로 자리잡는 길로 가고 있다. "어떤 모델이 1등" 이 아니라 "이 모델이 production-safe 한가" 의 답.

• fused op 의 spec — 단일 aten op 가 아니라 fused 패턴 (matmul + bias + relu) 의 spec 을 어떻게 정의할까. PyTorch 의 graph IR 위 pattern 으로 자동 추출.
• performance 와 correctness 의 결합 — 두 축을 동시에 보는 통합 leaderboard. correct 한 커널 중 가장 빠른 것.
• tolerance 의 contextual 적용 — fp16 학습의 reduction 에서는 tolerance 가 다르고, fp32 inference 에서는 또 다르다. context-aware tolerance.
• multi-GPU / collective — NCCL allreduce, AllGather 같은 collective op 의 LLM 생성 커널 검증. NCCL spec 의 mathematical reference 가 무엇인가가 별도 문제.
• backward 의 자동 검증 — forward 만 spec 이 명확. backward 는 같은 op 마다 다양한 정의 (autograd auto vs explicit). 자동 비교의 어려움.
• training loop level integration — 단일 op 가 통과해도 학습 루프 안에서 누적된 drift 가 깨질 수 있다. e2e 학습 1000 step 의 loss 일치까지 검증.

손에 새기기 — 실습 시퀀스

1. BackendBench 직접 돌리기 — repo 를 clone, 단일 op (예: aten::softmax) 만 target 으로 한 번 통과. fail 한 sample 의 input shape 을 직접 본다.
2. LLM 한 모델 평가 — Claude 또는 GPT-4o 에 같은 prompt 로 5 개 op 의 Triton 커널 짜게 한다. BackendBench 결과 표를 직접 만든다.
3. auto-fix loop 직접 돌려보기 — failure evidence 를 prompt 에 넣고 retry 3 회. pass rate 변화 그래프.
4. failure taxonomy 분류 — § 05 의 5 가지 mode 중 자기가 받은 fail 들이 어디로 분포되는지 직접 분류.
5. tolerance 변화 실험 — atol 를 1e-5 / 1e-3 / 1e-2 로 바꿔가며 같은 커널의 pass rate 변화. 어떤 op 가 tolerance 에 민감한지.
6. OpInfo 직접 읽기 — PyTorch repo 의 torch/testing/_internal/common_methods_invocations.py 를 열어서 한 op 의 sample generator 가 어떤 shape/dtype 을 만드는지 본다.

• repo 의 정확한 위치와 maintainer — meta-pytorch / pytorch / Mark personal 어디서 관리되는지. 강의 시점 이후 이전됐을 수 있음.
• op coverage 의 절대 숫자 — 몇 개 op 가 OpInfo 가 잘 정의되어 있는지. 전체 aten op 중 비율.
• backward 검증의 비중 — forward 만 검증하는지 backward 도 default on 인지.
• 모델 별 leaderboard 의 timestamp — § 06 의 수치는 시점 의존. 강의에서 발표된 정확한 시점의 표.
• fused op pattern — § 09 의 next step 이 강의 시점에 어디까지 진행됐는지.
• cost 분석 — LLM 호출 비용 + GPU eval 비용. 한 모델 전체 평가에 얼마.
• cuda kernel (vs Triton) 의 검증 가능성 — load_inline 으로 들어온 raw CUDA 코드도 sandbox 안에 build 가능한지.