나는 이 글과 여러 문서들이 다소 불분명하다고 느꼈음, 특히 GPU에 대해 설명하면서 용어가 애매하게 사용되는 경우가 많음, 예를 들어 첫 번째 이미지에 ‘Warp Scheduler’가 TPU의 VPU와 비슷한 SIMD 벡터 유닛이라고 설명하면서 32개의 ‘CUDA Core’가 있다고 하는데, 여기서 ‘CUDA core’가 무엇인지 명확하게 설명하지 않아 설명의 핵심 사물을 제대로 전달하지 못함, 이런 복합적인 오류로 인해 초심자나 개념을 익히려는 독자들은 여전히 이해가 어렵고 반면 어느 정도 개념을 이해하고 있는 사람들에게는 이미 아는 내용임, 초안이던 내용이라도 공개할 땐 용어 하나하나를 외과 수술처럼 정확하게 다뤄야 하고, 용어를 혼동하거나 섞어서 쓰지 않아야 함, 아날로지를 쓸 땐 신중해야 한다는 조언임, 그리고 MXU(매트릭스 연산 유닛) 같은 용어는 부연설명이나 하이퍼링크를 통해 쉽게 찾을 수 있도록 해야 한다고 생각함, 요즘은 AI에게 이 역할을 시킬 수도 있는데, 이는 다소 슬픈 일임
저자로서 직접 답변함, 지적에 대체로 동의함, 설명에서 정확성을 확보하려 할수록 ‘도덕적 진실’과의 균형에 늘 고민이 있음, 예를 들어 “NVIDIA가 CUDA Core라 부르는 SIMD(단일 명령-다중 데이터) 벡터 유닛 32개(ALU)로 구성된 TPU VPU와 유사한 유닛"이라고 쓸 수도 있지만, 이러면 문장이 길어지고 벡터 유닛 등 용어 정의는 또 빠질 수 있음, 각주를 많이 쓰려 노력하지만, 독자가 일일이 클릭할 거라 기대하기도 어렵고, 사이드노트는 HTML에서 구현 난이도가 있음, MXU 같은 용어는 전장(前章)에서 이미 정의했지만, 독자가 모든 장을 꼭 읽으리라 가정하는 건 무리라 생각함, "Warp Scheduler"도 실제로는 여러 역할(스케줄러, 디스패치 유닛, SIMD ALU)을 모두 뜻하는 등 용어 자체의 모호함이 있지만, NVIDIA가 복합 유닛에 별도 명칭을 붙이지 않아 생기는 일임, 앞으로 더 개선하려힘, 쉽지 않은 타협의 연속임
LLM은 이런 용어 연결의 난관을 풀기 꽤 좋은 도구임, 한 용어를 찾아도 연쇄적으로 모르는 용어가 나올 때 어디서부터 공부하면 되는지 잘 안내해 줌
진지하게 묻고 싶은데, 컴퓨터 아키텍처에 대한 적정 수준의 배경지식은 어느 정도가 적합한지 궁금함, SIMD 개념 자체가 이미 50년이 넘었음, 해당 자료 서두에선 LLM과 Transformer 아키텍처에 대한 이해는 기본으로 보고 있지만, 컴퓨터 작동 원리에 대한 이해는 없어도 된다고 하면서도, CPU 기본 동작 원리는 알아야 하는 게 아닌가란 생각임
해당 콘텐츠는 머신러닝 분야에 종사하는 사람을 대상으로 쓰인 책의 한 챕터임
나는 오픈 소스가 아니거나 여러 공급업체가 교차 사용 가능한 기술이 아니면 투자한 시간을 정당화하기 매우 어렵다고 느낌, Nvidia 칩 활용을 잘 하는 일이 예전의 SAP ABAP 컨설턴트 같은 것이라 여겨짐, 물론 이 분야에서 돈이 많이 벌리긴 하지만, 역사적으로 이런 전문성은 그리 득이 아니었다고 생각함
나도 10년 전 대학 때 CUDA 수업을 일부러 건너뛰며 같은 생각을 했었음
CUDA는 하드웨어 아키텍처와 이를 위한 소프트웨어 스택 두 가지가 있음, 소프트웨어 스택은 폐쇄적이어서 직접 저수준 최적화를 할 계획이 아니면 굳이 신경 쓸 필요 없음, 하지만 하드웨어 구조는 배울 가치가 충분함, 모든 GPU들은 기본적으로 비슷한 방식으로 동작하고(CUDA 구조는 2007년부터 기본 철학은 그대로임), 이러한 아키텍처가 셰이더 언어나 GPU 추상화 방식에 큰 영향을 미침, 쓰레드 스케줄링, 워프, 사설/공유 메모리 구조 등 자세한 특성을 이해하면, 알고리즘을 하드웨어 실행 모델에 더 잘 맞춰 막대한 연산 성능을 활용할 수 있음
병렬 컴퓨팅의 원리와 하드웨어, 드라이버 레벨에서의 작동 방식은 상당 부분에 일반성이 있음을 강조하고 싶음, 일부는 특정 플랫폼 특화 내용이지만 상당수는 폭넓게 응용 가능함, 일반성만 맹신하다 보면 오히려 손해 보기도 함, 오픈 소스 여부와 범용/특화성은 별개로도 볼 수 있으니, 더 넓은 탐구가 필요함
전환이 그리 어렵지 않음, 이미 OpenMP나 MPI 코드를 짰던 사람이라면 CUDA 입문 자체는 쉬웠음, CUDA에서 성능 최적화 방법을 배우면 CPU 병렬 코드도 빨라지므로 본질적으로 기존 컴퓨팅 모델의 진화형임
나도 어릴 때 IBM PC/MS-DOS로 프로그래밍 배웠는데 둘 다 오픈 소스가 아니었지만, 지금도 크게 도움이 되고 있음
“Quiz 2: GPU nodes” 부분의 계산이 부정확하다고 생각함, 실제로는 GPU나 스위치마다 포트가 제한돼 있어서 이론상 가능한 450GB/s가 확실히 제공되지 않으며, 그래서 주요 클라우드나 레퍼런스 시스템에서 3.2TB/s이 제공되는 것임, 만약 3.6TB/s가 가능하다면 분산 링 워크로드에서 병목이 발생함, 한편 구직 중임
나도 이 부분 오랜만에 생각해 봤는데, 클라우드 업체들이 3.2Tbps만을 광고하는 이유는 노드의 IB(InfiniBand) 네트워크 연결 한계 때문임, DGX 기준으로 H100 한 개당 Connect-X 7 NIC 1개씩이 400Gbps까지 제공함, 8개의 GPU x 400Gbps = 3.2Tbps임, Quiz 2는 표현이 헷갈리게 되어 있는데 내 생각엔 노드 내 GPU 간 연결을 의미하는 것 같고, 노드 간 네트워크는 아님
이 시리즈 전체가 정말 좋았음, 현대 AI 워크로드의 이론적 한계를 설명하면서 아키텍처와 병렬화 등 기술적 원리를 쉽게 풀어줌, TPU 중심이긴 하지만 대체로 다른 분야에도 적용할 수 있어 활용성이 높음
타입이 확실한 언어로 수치 집약적인 코드를 최대한 최적화하고, 그럼에도 빨라야 한다면 GPU 옵션을 검토하는 게 순서임, 내 경험상 GPU로 대략 8배는 빨라짐, 웹 응답 4초를 0.5초로 줄일 수 있으면 어마어마한 변화임, 하지만 사실상 웹소켓으로 지연 표시(스피너)하거나 백그라운드 캐시를 쓰는 편이 더 쉽기도 함, 그리고 클라우드에서 GPU 돌리는 건 비용이 많이 드는 점도 고려해야 함
nvshmem이 ML 분야에서 이렇게 각광받는 것이 흥미로움, 반면 동일 기능의 MPI는 예전 과학 시뮬레이션 세계에선 그리 만족스럽지 않았음, 참고로 나는 여러 노드에 걸친 장거리 힘 계산처럼 난도가 높은 작업을 주로 했었음
왜 Nvidia는 TPU를 자체 개발하지 않았는지 궁금함
그럴 필요가 없음, 이미 하드웨어와 프로그래밍 모델 시장 지배적 위치에 있고, TPU는 오히려 프로그래밍 난이도가 더 높음
사실상 이 기사에서 설명하듯, Nvidia GPU 성능의 90%가 행렬 연산 유닛에서 나오기 때문에 거의 TPU와 유사한 구조임, 약간의 성능은 포기하지만 훨씬 더 유연한 컴파일러 생태계를 확보함
아직까지 Nvidia에서 이런 수준의 리소스를 공식 제공하지 않은 게 놀라움, 결국 3rd party들이 하드웨어를 역공학해서 실제로 쓸 만한 개념도로까지 정리하는 상황이 됨, Nvidia의 진짜 동기가 궁금함, 만약 단순 마케팅만 생각한다면 성공한 셈이지만, 나는 엔지니어링 컬처엔 의문이 남음
실시간 렌더링 엔지니어 입장에서 항상 그랬음, NV는 세대간 변화 포착을 경쟁사들이 못하게 하려고 대부분 정보를 꽁꽁 숨김, 다른 벤더들도 다르지 않음, 게임에서는 NDA 맺고 세부 아키텍처 정보를 더 자세히 제공하긴 하는데 그 외엔 Intel 빼고 완전한 공개 사례는 못 봤음
Nvidia는 실제로 타사 대비 정말 우수한 공식 문서가 많음
왜 그렇게 느꼈는지 궁금함, 사실 이 기사에 있는 내용 대부분은 Nvidia 공식 문서를 거의 그대로 가져온 것으로 보임, 예를 들어 H100 다이어그램도 실제로는 H100 whitepaper에서 출처 표시 없이 복사된 것임, 연산량, 대역폭 정보도 전부 공식 whitepaper와 CUDA C++ 가이드 5,6,7장이 이미 다 다루고 있음, 외부에서 더 간략하게 정리하고 해석 덧붙이는 건 가치 있지만, Nvidia 공식 자료 없었으면 이런 기사 자체가 힘들었을 것이니 근거 없는 추측·의심은 좀 과함
Nvidia가 평범한 수준의 문서만 공개함으로써 cuBLAS, cuDNN 같은 폐쇄형 라이브러리만 빠르고, 이로 인해 벤더 종속이 심해지는 구조임, 덕분에 다른 업체가 역공학으로 쫓아오기도 어렵게 만듦
여러 정황을 볼 때 Nvidia는 NDA 서명자와 VIP에게만 맞춤형 자료를 제공하고 공공용 공식 매뉴얼 공개는 일부러 소홀히 하는 경향이 있음, 그게 상업적으로 자신들에게 유리하니까 그렇게 하는 것 같음, API 공식 문서조차 장벽을 치면 평범한 개발자들은 접근 어려워도 AI, GPU 자체, 소프트웨어, VIP용 문서 등 전체 생태계 판매에 집중하고 있어서 아예 일반 개발자에겐 신경을 덜 쓰는 셈임
우리가 구조 다이어그램을 볼 때 실제 하드웨어를 완벽히 반영한 것이 아니란 점을 반드시 유념해야 함, Nvidia는 다이어그램의 블록이나 구성 요소가 실제로 존재함을 보장하지 않고, 어디까지나 GPU와 SM 구조를 생각할 때 참고용 멘탈 모델로만 제공함, 예를 들어 실제 SM에 기능 유닛이 몇 개나 있는지, ‘tensor core’ 자체가 독립된 하드웨어인지 아니면 여러 유닛의 조합 결과인지, warp 이하 단위의 세부 동작도 공식적으로는 알 수 없음
흥미로운 의견임, 그런데 실제로는 SM이 tensor core 연산 중에는 블로킹되어 있다는 점이 동일한 FPU가 tensor 연산까지 모두 처리한다고 해석할 수 있지 않을까란 생각임
Hacker News 의견
나는 이 글과 여러 문서들이 다소 불분명하다고 느꼈음, 특히 GPU에 대해 설명하면서 용어가 애매하게 사용되는 경우가 많음, 예를 들어 첫 번째 이미지에 ‘Warp Scheduler’가 TPU의 VPU와 비슷한 SIMD 벡터 유닛이라고 설명하면서 32개의 ‘CUDA Core’가 있다고 하는데, 여기서 ‘CUDA core’가 무엇인지 명확하게 설명하지 않아 설명의 핵심 사물을 제대로 전달하지 못함, 이런 복합적인 오류로 인해 초심자나 개념을 익히려는 독자들은 여전히 이해가 어렵고 반면 어느 정도 개념을 이해하고 있는 사람들에게는 이미 아는 내용임, 초안이던 내용이라도 공개할 땐 용어 하나하나를 외과 수술처럼 정확하게 다뤄야 하고, 용어를 혼동하거나 섞어서 쓰지 않아야 함, 아날로지를 쓸 땐 신중해야 한다는 조언임, 그리고 MXU(매트릭스 연산 유닛) 같은 용어는 부연설명이나 하이퍼링크를 통해 쉽게 찾을 수 있도록 해야 한다고 생각함, 요즘은 AI에게 이 역할을 시킬 수도 있는데, 이는 다소 슬픈 일임
저자로서 직접 답변함, 지적에 대체로 동의함, 설명에서 정확성을 확보하려 할수록 ‘도덕적 진실’과의 균형에 늘 고민이 있음, 예를 들어 “NVIDIA가 CUDA Core라 부르는 SIMD(단일 명령-다중 데이터) 벡터 유닛 32개(ALU)로 구성된 TPU VPU와 유사한 유닛"이라고 쓸 수도 있지만, 이러면 문장이 길어지고 벡터 유닛 등 용어 정의는 또 빠질 수 있음, 각주를 많이 쓰려 노력하지만, 독자가 일일이 클릭할 거라 기대하기도 어렵고, 사이드노트는 HTML에서 구현 난이도가 있음, MXU 같은 용어는 전장(前章)에서 이미 정의했지만, 독자가 모든 장을 꼭 읽으리라 가정하는 건 무리라 생각함, "Warp Scheduler"도 실제로는 여러 역할(스케줄러, 디스패치 유닛, SIMD ALU)을 모두 뜻하는 등 용어 자체의 모호함이 있지만, NVIDIA가 복합 유닛에 별도 명칭을 붙이지 않아 생기는 일임, 앞으로 더 개선하려힘, 쉽지 않은 타협의 연속임
LLM은 이런 용어 연결의 난관을 풀기 꽤 좋은 도구임, 한 용어를 찾아도 연쇄적으로 모르는 용어가 나올 때 어디서부터 공부하면 되는지 잘 안내해 줌
구글 TPU 시스템 아키텍처 문서에 거의 다 나와있음
진지하게 묻고 싶은데, 컴퓨터 아키텍처에 대한 적정 수준의 배경지식은 어느 정도가 적합한지 궁금함, SIMD 개념 자체가 이미 50년이 넘었음, 해당 자료 서두에선 LLM과 Transformer 아키텍처에 대한 이해는 기본으로 보고 있지만, 컴퓨터 작동 원리에 대한 이해는 없어도 된다고 하면서도, CPU 기본 동작 원리는 알아야 하는 게 아닌가란 생각임
해당 콘텐츠는 머신러닝 분야에 종사하는 사람을 대상으로 쓰인 책의 한 챕터임
나는 오픈 소스가 아니거나 여러 공급업체가 교차 사용 가능한 기술이 아니면 투자한 시간을 정당화하기 매우 어렵다고 느낌, Nvidia 칩 활용을 잘 하는 일이 예전의 SAP ABAP 컨설턴트 같은 것이라 여겨짐, 물론 이 분야에서 돈이 많이 벌리긴 하지만, 역사적으로 이런 전문성은 그리 득이 아니었다고 생각함
나도 10년 전 대학 때 CUDA 수업을 일부러 건너뛰며 같은 생각을 했었음
CUDA는 하드웨어 아키텍처와 이를 위한 소프트웨어 스택 두 가지가 있음, 소프트웨어 스택은 폐쇄적이어서 직접 저수준 최적화를 할 계획이 아니면 굳이 신경 쓸 필요 없음, 하지만 하드웨어 구조는 배울 가치가 충분함, 모든 GPU들은 기본적으로 비슷한 방식으로 동작하고(CUDA 구조는 2007년부터 기본 철학은 그대로임), 이러한 아키텍처가 셰이더 언어나 GPU 추상화 방식에 큰 영향을 미침, 쓰레드 스케줄링, 워프, 사설/공유 메모리 구조 등 자세한 특성을 이해하면, 알고리즘을 하드웨어 실행 모델에 더 잘 맞춰 막대한 연산 성능을 활용할 수 있음
병렬 컴퓨팅의 원리와 하드웨어, 드라이버 레벨에서의 작동 방식은 상당 부분에 일반성이 있음을 강조하고 싶음, 일부는 특정 플랫폼 특화 내용이지만 상당수는 폭넓게 응용 가능함, 일반성만 맹신하다 보면 오히려 손해 보기도 함, 오픈 소스 여부와 범용/특화성은 별개로도 볼 수 있으니, 더 넓은 탐구가 필요함
전환이 그리 어렵지 않음, 이미 OpenMP나 MPI 코드를 짰던 사람이라면 CUDA 입문 자체는 쉬웠음, CUDA에서 성능 최적화 방법을 배우면 CPU 병렬 코드도 빨라지므로 본질적으로 기존 컴퓨팅 모델의 진화형임
나도 어릴 때 IBM PC/MS-DOS로 프로그래밍 배웠는데 둘 다 오픈 소스가 아니었지만, 지금도 크게 도움이 되고 있음
“Quiz 2: GPU nodes” 부분의 계산이 부정확하다고 생각함, 실제로는 GPU나 스위치마다 포트가 제한돼 있어서 이론상 가능한 450GB/s가 확실히 제공되지 않으며, 그래서 주요 클라우드나 레퍼런스 시스템에서 3.2TB/s이 제공되는 것임, 만약 3.6TB/s가 가능하다면 분산 링 워크로드에서 병목이 발생함, 한편 구직 중임
이 시리즈 전체가 정말 좋았음, 현대 AI 워크로드의 이론적 한계를 설명하면서 아키텍처와 병렬화 등 기술적 원리를 쉽게 풀어줌, TPU 중심이긴 하지만 대체로 다른 분야에도 적용할 수 있어 활용성이 높음
타입이 확실한 언어로 수치 집약적인 코드를 최대한 최적화하고, 그럼에도 빨라야 한다면 GPU 옵션을 검토하는 게 순서임, 내 경험상 GPU로 대략 8배는 빨라짐, 웹 응답 4초를 0.5초로 줄일 수 있으면 어마어마한 변화임, 하지만 사실상 웹소켓으로 지연 표시(스피너)하거나 백그라운드 캐시를 쓰는 편이 더 쉽기도 함, 그리고 클라우드에서 GPU 돌리는 건 비용이 많이 드는 점도 고려해야 함
nvshmem이 ML 분야에서 이렇게 각광받는 것이 흥미로움, 반면 동일 기능의 MPI는 예전 과학 시뮬레이션 세계에선 그리 만족스럽지 않았음, 참고로 나는 여러 노드에 걸친 장거리 힘 계산처럼 난도가 높은 작업을 주로 했었음
왜 Nvidia는 TPU를 자체 개발하지 않았는지 궁금함
그럴 필요가 없음, 이미 하드웨어와 프로그래밍 모델 시장 지배적 위치에 있고, TPU는 오히려 프로그래밍 난이도가 더 높음
사실상 이 기사에서 설명하듯, Nvidia GPU 성능의 90%가 행렬 연산 유닛에서 나오기 때문에 거의 TPU와 유사한 구조임, 약간의 성능은 포기하지만 훨씬 더 유연한 컴파일러 생태계를 확보함
아직까지 Nvidia에서 이런 수준의 리소스를 공식 제공하지 않은 게 놀라움, 결국 3rd party들이 하드웨어를 역공학해서 실제로 쓸 만한 개념도로까지 정리하는 상황이 됨, Nvidia의 진짜 동기가 궁금함, 만약 단순 마케팅만 생각한다면 성공한 셈이지만, 나는 엔지니어링 컬처엔 의문이 남음
실시간 렌더링 엔지니어 입장에서 항상 그랬음, NV는 세대간 변화 포착을 경쟁사들이 못하게 하려고 대부분 정보를 꽁꽁 숨김, 다른 벤더들도 다르지 않음, 게임에서는 NDA 맺고 세부 아키텍처 정보를 더 자세히 제공하긴 하는데 그 외엔 Intel 빼고 완전한 공개 사례는 못 봤음
Nvidia는 실제로 타사 대비 정말 우수한 공식 문서가 많음
왜 그렇게 느꼈는지 궁금함, 사실 이 기사에 있는 내용 대부분은 Nvidia 공식 문서를 거의 그대로 가져온 것으로 보임, 예를 들어 H100 다이어그램도 실제로는 H100 whitepaper에서 출처 표시 없이 복사된 것임, 연산량, 대역폭 정보도 전부 공식 whitepaper와 CUDA C++ 가이드 5,6,7장이 이미 다 다루고 있음, 외부에서 더 간략하게 정리하고 해석 덧붙이는 건 가치 있지만, Nvidia 공식 자료 없었으면 이런 기사 자체가 힘들었을 것이니 근거 없는 추측·의심은 좀 과함
Nvidia가 평범한 수준의 문서만 공개함으로써 cuBLAS, cuDNN 같은 폐쇄형 라이브러리만 빠르고, 이로 인해 벤더 종속이 심해지는 구조임, 덕분에 다른 업체가 역공학으로 쫓아오기도 어렵게 만듦
여러 정황을 볼 때 Nvidia는 NDA 서명자와 VIP에게만 맞춤형 자료를 제공하고 공공용 공식 매뉴얼 공개는 일부러 소홀히 하는 경향이 있음, 그게 상업적으로 자신들에게 유리하니까 그렇게 하는 것 같음, API 공식 문서조차 장벽을 치면 평범한 개발자들은 접근 어려워도 AI, GPU 자체, 소프트웨어, VIP용 문서 등 전체 생태계 판매에 집중하고 있어서 아예 일반 개발자에겐 신경을 덜 쓰는 셈임
우리가 구조 다이어그램을 볼 때 실제 하드웨어를 완벽히 반영한 것이 아니란 점을 반드시 유념해야 함, Nvidia는 다이어그램의 블록이나 구성 요소가 실제로 존재함을 보장하지 않고, 어디까지나 GPU와 SM 구조를 생각할 때 참고용 멘탈 모델로만 제공함, 예를 들어 실제 SM에 기능 유닛이 몇 개나 있는지, ‘tensor core’ 자체가 독립된 하드웨어인지 아니면 여러 유닛의 조합 결과인지, warp 이하 단위의 세부 동작도 공식적으로는 알 수 없음
정말 환상적인 리소스임, 덕분에 좋은 내용 얻게 됨