▲

Fp8 커널 이름에 "cutlass"를 넣으면 약 100TFLOPS 빨라짐

 (github.com/triton-lang)
1P by GN⁺ 10일전 | ★ favorite | 댓글 1개
  • Attention 커널을 persistent 형태로 리팩토링하여 낮은 context 길이에서 성능 개선임
  • fp16에서 큰 context에서는 softmax 파티션의 ptxas 명령 스케줄링 이슈로 성능 저하 발생임
  • fp8은 커널 이름에 "cutlass" 가 포함되면 약 100TFLOPS 성능 향상 확인됨
  • 이 최적화는 커널 네이밍을 통한 하드코딩 최적화 트릭으로 분석됨
  • 성능 영향과 동작 원인은 NVIDIA ptxas 내부 구현에 의한 특이 현상임

요약: Persistent Attention 커널의 리팩토링 및 "cutlass" 네이밍 효과

개요

  • 이 Pull Request는 Triton의 attention 커널을 persistent attention 방식으로 리팩토링한 내용임
  • 주요 목적은 낮은 context 길이 구간에서 성능 최적화 효과를 얻기 위함임
  • 하지만, fp16 유형에서는 context 크기가 커질수록 softmax 부분의 ptxas 명령 스케줄 이슈로 인해 성능 저하 현상이 나타남

fp8에서 "cutlass" 이름 채택의 효과

  • fp8 모델을 사용할 때, 커널 이름에 "cutlass"를 포함시키면 약 100TFLOPS까지 성능 향상이 측정됨
  • 이는 NVIDIA의 ptxas(PTX 어셈블러) 가 내부적으로 커널 이름에 "cutlass"가 포함되어 있을 때 특수 최적화를 적용하기 때문임
  • 실제 코드에서 dtype이 float8e5이면 커널 이름을 "cutlass_gluon_attention" 등으로 할당함
  • ptxas 디스어셈블 분석 결과, 실제로 내부 코드에서 strstr(kernel_name, "cutlass") 조건문이 존재함

성능 벤치마크

  • 리팩토링 전후 benchmark 데이터에서, persistent attention 적용 전보다 D=64에서 상대적 성능 하락이 관측됨
    • 이는 softmax 파트의 명령 스케줄 문제에 기인함
  • 하지만 fp8 타입과 "cutlass" 네이밍을 조합할 경우, 특정 context와 크기에서는 현저히 높은 처리량 기록임
  • 대표적인 결과 요약:
    • Attention Z=4, H=32, D=64, causal=False:
      • persistent 적용 전: triton-fp16 약 383, triton-fp8 약 413, cudnn-fp16 약 565
      • persistent 적용 후: triton-fp16 약 360, triton-fp8 약 370
    • Attention Z=4, H=32, D=128, causal=True:
      • persistent 적용 전: triton-fp16 약 312, triton-fp8 약 345, cudnn-fp16 약 553
      • persistent 적용 후: triton-fp16 약 356, triton-fp8 약 351

네이밍 트릭의 발견과 분석

  • "cutlass"라는 문자열이 커널 이름에 포함될 경우, NVIDIA ptxas에서 실험적 최적화 루틴이 활성화됨이 커뮤니티 분석에서 확인됨
  • ptxas에 네이밍 매칭용 하드코딩 로직(strstr(kernel_name, "cutlass"))이 있음
  • 이 트릭은 aggressive, experimental 최적화로, 커널의 정확도 변화 여부는 하드웨어 및 상황에 따라 달라질 수 있음

커뮤니티 논의

  • 여러 리뷰어들이 성능 비교, 정확도 및 최적화 방식에 대해 질문 및 분석 진행
  • Deepseek technical report의 내용, Hopper GPU와 같은 특정 아키텍처에서의 차이 등도 논의됨
  • 네이밍 변경을 통한 최적화가 얼마나 광범위하게 적용되는지, 안정성 이슈 등도 제기됨

결론 및 시사점

  • 커널의 이름만으로도 하드웨어 레벨에서 실질적인 성능 변동이 발생하는 점이 매우 특이 현상임
  • NVIDIA 소프트웨어 스택(pxtas)에 숨은 최적화 trigger가 존재한다는 점에서, AI 프레임워크 개발 시 네이밍 규칙도 성능에 영향 줄 수 있음을 시사함
  • 실무적으로는 트릭 사용 시 재현성 및 안정성을 반드시 테스트해야 하며, 하드웨어 벤더의 최적화 정책을 예의주시할 필요가 있음
▲
GN⁺ 10일전  [-]
Hacker News 의견

  • ptxas를 분해해보면, "cutlass"라는 커널 이름을 감지하는 로직이 하드코딩되어 있음 확인함
    NVIDIA가 불안정하고 실험적이며 공격적인 최적화를 여기 적용했다고 봄, 항상 무조건 이 최적화를 켜면 교묘한 버그가 생길 수 있음 판단임

    • 실제로는 교묘한 버그보다 미묘한 성능 변화가 더 많이 나타남
      GPU 컴파일러는 굉장히 어렵고, 기본적인 최적화 이상을 하려고 하면 늘 문제와 혼합된 결과가 발생함
      어떤 커널은 빨라지고 어떤 커널은 느려지며, 전체적으로 성능이 상승하기를 바라는 건 매우 힘든 일임
      테스트 전체에서 단 하나의 최적화로 항상 속도가 증가하는 일은 거의 없음
      나의 경험은 Nvidia가 아닌 GPU 시스템에 있지만, 이 상황이 익숙하게 느껴짐
      Nvidia도 어떤 커널 집합에는 놀라운 결과를, 또 어떤 집합에는 형편없는 결과를 주는 최적화를 발견했고, 이를 자동으로 적용할 만한 신뢰할 수 있는 기준도 못 찾은 것 같음

  • 이런 맥락 설명 고마움
    이쪽 영역이 아니라서(이 프로젝트도 처음 들음) 제목과 PR 내용이 아무리 봐도 이해 안 됐었음

  • 25년 전 ATI(AMD)가 Quake III 벤치마크에서 실행파일 이름을 'quack'으로 바꾸자 성능이 달라진 걸로 드러나서 조작에 걸렸던 게 떠오름
    관련 링크도 남김: https://techreport.com/review/how-atis-drivers-optimize-quake-iii/">techreport.com 리뷰, https://hardocp.com/reviews/vidcards/ati/8500/index5.html">hardocp.com 리뷰, www.3dcenter.de/artikel/2001/10-24_a.php">3dcenter.de 기사

    • 혹시 나처럼 오해한 사람 있을까봐 정리함
      ATI가 'quake'라는 실행파일 이름을 감지해 텍스처 품질 등을 바꿔 벤치마크 점수를 올렸음
      사람들이 실행파일 이름을 'quack'으로 바꿨더니 이미지 품질이 올라가고 점수는 내려갔다는 걸로 드러남, ATI 드라이버가 품질을 일부러 낮춰 속도를 올린 것임
      그러니까 ATI가 직접 파일명을 바꾼 게 아니고, 사용자들이 바꾼 것임

    • 또는 Intel C++ Compiler가 출력값 속 "GenuineIntel" 문자열을 체크한 이슈도 있었음
      관련 위키 링크는 여기

    • 오늘날까지도 모든 벤더가 이런 짓을 함
      드라이버가 인기 게임의 렌더링 루프를 가로채서 버그를 고치거나, 셰이더를 더 최적화된 버전으로 바꾼다든가, 빠른 코드 경로를 여는 등 다양한 방식으로 개입함
      이런 변화는 결과물에 최소한의 영향만 주어야 하지만, 어떤 경우는 너무 공격적으로 개입해서 품질이 대폭 저하될 때도 있음
      그래서 게임이 자기들 하드웨어에서 더 빠르도록 만짐

    • 이 주제에 더 깊이 논의된 스레드가 있으니 여기 참고 추천함
      재미있게도 동일한 cutlass 최적화 관련 과거 글임

    • 이런 사례는 매우 흔함
      휴대폰 칩셋 제조사들이 벤치마크용으로 속임수를 썼고(VW는 배기가스, Nvidia는 3DMark 벤치마크, Intel은 Xeon용 SPEC 벤치마크 등등)
      컴퓨터 그래픽에서는 이제 거의 관습처럼 드라이버가 각 게임별로 트윅, 세팅, 워크어라운드 등을 집어넣음
      (아쉽게도 요즘은 제대로 된 출처 링크가 너무 자주 사라져서 archive.org를 써야 함. 이런 기억은 꼭 남겨야 한다고 생각함)
      참고 링크: https://anandtech.com/show/15703/…">Mediatek 벤치마크 조작, Volkswagen 배기가스 조작 스캔들, http://techreport.com/etc/2003q2/3dmurk03/index.x?pg=1">Nvidia 3DMark 논란, Intel compiler SPEC 벤치 영향

  • 컴파일러를 다루는 입장에서, 이런 식의 최적화가 이름(schema, substring 등)에 의존하는 경우가 있음
    마음에 들지 않더라도 현실적으로 그렇게 동작함
    반드시 악의적이진 않고, 자기 라이브러리에만 최적화가 적용되게 설계하는 쪽이 전체를 깨뜨릴 위험보다 안전한 선택이기도 함
    또는 프론트엔드가 더 신뢰할 만한 정보(구조적 정보 등)를 제공하지 못해서일 때도 있음

    • 아마 악의적이지는 않지만, 이런 최적화 방식은 결국 새로운 장벽을 만드는 면이 있음
    • 함수 타입이나 스키마에 의존하는 건 어느 정도 이해되지만, 단순한 이름만으로 적용한다면 좀 이상하게 느껴짐
    • “깨지는 것 방지용”이라고 해도, 누군가 우연히 같은 이름을 써버리면 예상치 못한 문제가 발생함
      이런 방식은 도움이 되지 않는다고 생각함

  • 별로 새로울 건 없다고 생각함

    • 인텔은 2024년 초, SPEC이 인텔 Xeon CPU 2,600건의 벤치마크 결과를 무효로 만들었는데, 이유는 인텔 컴파일러가 부정 최적화를 써서 점수를 올렸기 때문임 (Tom's Hardware 기사)
    • Microsoft도 Java/C 컴파일러 벤치 지표에서 비슷한 일을 하는 경우 있었음
    • 그리고 모두가 AI 벤치마크 속이기에 열을 올리고 있음 (AI 벤치마크 스캔들)

  • 약 10년 전 특정 버전 Webpack에서 add.svg라는 파일명을 쓰면 빌드가 깨졌던 일이 떠오름
    결국 파일명을 plus.svg로 바꿔서 해결했음

    • numpy도 비슷
      “secret.py”라는 파일을 써두면 본의 아니게 numpy를 망가뜨린 경험자도 있음

  • 커밋 메시지를 솔직히 쓰는 점이 인상적임

    • 어떤 커밋 diff 구성 방식에 대한 비판이 있었음
      누군가는 “뭔가를 대략 100 tflops만큼 빠르게 만들었다”고 썼을 때, 오히려 “커밋 메시지가 별로”라고 지적하는데… 그럼 John Carmack의 커밋 스타일도 싫어할 거라 생각함

    • 개인적으로는 이렇게 솔직한 메시지가 마음에 듦
      AI가 자동 생성한 커밋 메시지("refactored X" 이런 식의 반복)만 잔뜩 뜨는 것보다는 훨씬 낫다고 느껴짐

    • squash해서 커밋 내역을 묶는 게 좋다고 생각함
      왜 GitHub에 올릴 때 squash하지 않았는지 이해가 잘 안 됨

  • NVIDIA Jetson에서 사용법을 배웠을 때가 떠오름
    명령어 하나만 실행하면 모든 게 더 빨라진다는 걸 알게 됐었음 (관련 링크)

    • 전원 모드 얘기하는 건지 궁금함
      기사대로라면 5W, 10W 두 가지가 있고, 10W가 기본이라서 오히려 기본에서 5W로 바꿨을 때만 “더 빨리”가 적용되는 것으로 해석될 수도 있는데, 내가 뭔가 잘못 이해한 건지 질문함

  • 고수준 언어(C++ 등)로 심하게 튜닝된 코드를 쓰고, GPU 어셈블리로도 구체적인 결과를 기대하는데 컴파일러가 원하는 대로 나오지 않을 때가 있음
    컴퓨터팀에 문의하면 다양한 솔루션을 제시하겠지만, 오픈소스 코드라면 적용이 어려운 방법이 많음 (예를 들어, 독점적 #pragma, intrinsic 등)
    고성능 라이브러리를 만드는 입장에서는 성능이 안 나오면 출고 자체가 불가능함
    이럴 때 함수 이름 등으로 특정 코드 변환을 유도하는 트릭을 쓸 수밖에 없음
    이런 최적화는 현실 세계에서 흔히 사용되며, 벤치마크를 속이기 위해 이미지 품질을 낮추는 행위와 동급으로 볼 수 없다고 생각함

    • 이런 경우 왜 인라인 어셈블리를 안 쓰냐는 질문도 나옴

  • 이 PR이 처음 올라왔을 때 이미 논의가 됐었던 내용임
    새로운 게 없다고 느껴짐
    이전 토론

    • 눈에 익은 내용 같아서, 이미 봤던 것 같다고 느낌

  • 코드 공유가 쉬운 경제 구조가 있었으면 하는 바람임
    바이너리 블롭 드라이버, 베이스밴드 등 복잡한 구조 말고, 모두가 쉽게 정보를 얻어서 낭비되는 시간과 노력을 줄일 수 있었으면 함
    수많은 뛰어난 엔지니어와 연구자들이 이미 누군가 갖고 있는 문서와 회로도, 바이너리 코드를 리버스 엔지니어링하고 해독하는 데 몇 달, 몇 년을 소비함
    CUDA와 NVIDIA 같은 회사들은 답답하게 느껴짐

    • 문제의 본질은 소프트웨어 코드베이스를 개발하는데 드는 초기 고정비, 이후 유지관리 인건비, 그리고 소규모의 배포 비용(예: 다운로드 서버 등)임
      데스크톱 앱 기준, 사용자 1인당 추가 비용은 거의 0에 수렴함
      그래서 소프트웨어는 계속된 정기 수입 구조가 필요하지만, 사용자 수에 비례해 수입이 계속 증가하면 안 됨
      새로운 코드 개발에 투자한 사람들이 제품이 인기를 얻을 때 투자금을 회수해야 하는데, 기존 크라우드펀딩은 이런 구조를 만족시키지 못함
      사용자가 늘수록 1인당 기여액이 확 줄어들어, 모두가 100% 혹은 10%, 심지어 1%만 기여해도 투자금은 천문학적일 수 있음
      결국 경매 방식의 약정(pledge)이 필요하다고 생각함
      이 구조에도 문제는 있는데, 독점과 비독점 모드의 전환이 특히 골칫거리임
      대기업 몇 곳이 개발비를 다 부담해서 오픈소스로 공개된 경우, 나머지 모든 개인이나 기업들은 사실상 무임승차자가 됨
답변달기