HN 공개: TCP를 통한 가상 GPU 연결

• GPU는 CPU·스토리지·네트워킹·메모리와 달리 아직 풍부한 자원으로 가상화되지 못했고, Thunder Compute는 이를 시스템 계층에서 풀려 함
• 공급 확대의 초점은 칩을 더 많이 만드는 것뿐 아니라, 이미 배치된 GPU를 더 잘 쓰게 하는 소프트웨어 활용에 있음
• 기존 최적화가 추론 배치나 학습 작업 큐잉처럼 워크로드 계층에 머무른 반면, GPU 가상화는 상대적으로 덜 다뤄진 시스템 영역을 겨냥함
• NVIDIA H100을 시간당 $1.38부터 VS Code, CLI, 브라우저에서 사용할 수 있고, AWS 대비 80% 절감·계약 없음·egress 비용 없음·확장형 스토리지를 내세움
• 4년간 스텔스 상태에서 연구 프로토타입을 만들었으며, 자체 클라우드와 엔터프라이즈 파트너를 통해 데이터센터의 GPU 용량 개선을 배포하려 함

---

GPU 가상화로 낮은 활용률 개선

• Thunder Compute는 컴퓨팅의 여러 희소 자원이 결국 풍부해졌지만, GPU는 아직 같은 전환을 겪지 않았다고 봄
• GPU를 풍부하게 만드는 방법은 더 많은 칩 생산만이 아니라, 이미 배치된 칩을 더 잘 쓰는 소프트웨어에도 달려 있음
• 현재 GPU는 충분히 활용되지 않는 경우가 많고, 기존 해결책은 주로 워크로드 계층에 집중돼 있음
  • 추론 요청을 배치 처리함
  • 여러 서버 플릿에서 학습 작업을 큐잉함
• CPU, 스토리지, 네트워킹, 메모리는 가상화가 보편화됐지만, GPU에는 아직 같은 수준의 가상화가 자리 잡지 못함
• 이 빈 영역을 시스템 계층에서 다루는 것이 Thunder Compute의 핵심 접근임

제품 접근 방식과 배포 계획

• Thunder Compute는 상업적 초점을 가진 시스템 랩으로, 최신 GPU 가상화 연구를 프로덕션 환경에 적용하려 함
• 팀은 Citadel Securities, Aquatic, AWS 출신의 인프라 전문가와 시스템 연구자로 구성됐다고 소개함
• 4년간 스텔스 모드에서 연구 프로토타입을 만들었고, 현재는 자체 클라우드와 엔터프라이즈 파트너를 통해 결과물을 배포함
• 제품 설명상 NVIDIA H100은 시간당 $1.38부터 사용 가능함
  • VS Code, CLI, 브라우저에서 접근할 수 있음
  • AWS 대비 80% 절감을 내세움
  • 계약 없음, egress 비용 없음, 확장형 스토리지를 제공함
• 목표는 데이터센터 GPU 용량을 단계적으로 개선하는 것임

[GN⁺]

Hacker News 의견들

• 꽤 흥미로움. 예전에 비디오 트랜스코딩용으로만 GPU-over-IP가 필요했던 적이 있었음
  홈랩 서버에는 성능이 약한 AMD GPU가 있었는데, 비디오 인코딩을 시도할 때마다 커널을 크래시시키곤 했고, 게임용 PC에는 NVIDIA RTX 3080이 있었음. 그래서 https://github.com/steelbrain/ffmpeg-over-ip를 만들고 Windows 머신에서 서버를, 미디어 서버(Plex, Emby, Jellyfin 등)에서 클라이언트를 돌렸더니 완벽하게 동작했음

  • 아직 Show HN에 올린 적이 없다면 한번 고려해보면 좋겠음
    https://gist.github.com/tzmartin/88abb7ef63e41e27c2ec9a5ce5d...
    https://news.ycombinator.com/showhn.html
    https://news.ycombinator.com/item?id=22336638
  • 제목을 봤을 때 기대했던 건 대략 이런 것이었음. 실제 제출물이 유용한 범용 도구가 아니라 유료 클라우드 서비스라서 아쉬웠고, 역시 진짜 내용은 댓글에 있었음
    비디오 인코딩 말고 GPU-over-network를 쓸 만한 곳이 있는지도 궁금함. 지연 시간이 늘어나면 머신러닝이나 그래픽 집약 작업은 어렵지 않을까 싶음
  • 흥미로움. HLS처럼 여러 타임슬라이스 파일이 생기는 다중 파일 변환도 지원하는지 궁금함

• 이게 CPU/GPU 경계에서 동작한다면, VRAM에 들어가지 않는 데이터셋에서는 엄청난 입출력 병목이 생기지 않나 헷갈림
  동작 방식을 잘못 이해한 것일 수도 있지만, GPU 입출력을 가로챈다면 매 에폭마다 전체 데이터셋을 원격 머신으로 스트리밍해야 하는 셈이라 낭비처럼 들림

  • 그 시스템 이해가 맞음. 실용적으로 만들기 위해 입출력 비용을 줄이는 최적화를 여러 가지 구현했음
    BERT 추론 성능은 여기서 볼 수 있음: https://youtu.be/qsOBFQZtsFM?t=69
    학습은 추론보다 오버헤드가 더 크고, 네이티브 성능에 가까워지도록 추가 최적화를 구현 중임

• 실제로 어떻게 동작하는지 궁금한 사람들을 위해 보면, 프로세스에 라이브러리를 주입해서 이 함수들[1]을 후킹한 뒤 서비스로 전달하는 구조처럼 보임
  [1] https://pastebin.com/raw/kCYmXr5A

  • 이 함수들이 후킹된 걸 어떻게 알아냈는지 궁금함. 어떤 심볼이 다시 바인딩되는지 알려주는 ld/ldd 플래그가 있는 걸로 추정함
    또 심볼이 다시 바인딩되려면 약한 심볼이어야 한다고 생각했는데, NVIDIA가 약한 심볼을 노출할 리는 없으니 결국 이건 사실상 LD_PRELOAD 방식이라는 뜻인가 싶음
  • PCIe 장치 전체를 전달하는 마법 같은 방식이 있기를 기대했음

• 흥미롭지만, 더 관심 있는 건 셀프 호스팅임. 이미 GPU가 많이 있고 일부는 돌고 일부는 놀고 있음
  기존에 가진 GPU를 쓸 수 있도록 셀프 호스팅 옵션이 있는지 궁금함

  • 아직 셀프 호스팅은 지원하지 않지만, 같은 기술이 잘 맞을 것으로 보임
    효율적인 작업 스케줄링, GPU 공유, 사용 편의성 같은 장점이 셀프 호스팅 환경에도 그대로 적용됨. 앞으로 이 가능성에 충분히 열려 있음
  • 자체 GPU, 고정 장비든 클라우드든, 위에서 PyTorch와 비슷한 사용감을 원한다면 https://github.com/run-house/runhouse를 보면 됨
  • 자체 GPU나 클라우드 계정을 쓰면서도 좋은 개발 경험을 원한다면 SkyPilot을 보면 됨
  • Akash Network 같은 서비스로 자신의 GPU를 클라우드에서 빌려줄 수 있고, thundercompute.com에서 GPU를 빌릴 수도 있음. 거의 셀프 호스팅처럼 운영하는 관리자 경로에 가까움

• 이해가 잘 안 됨. ECS에서 원하는 GPU 인스턴스를 직접 띄우면 되는데, 왜 ECS에서 인스턴스를 띄워서 당신들 GPU를 ECS에서 써야 하는지 모르겠음
  별도로, 진짜 Nitro 대신 반쪽짜리 Nitro를 쓰고 싶을 이유도 모르겠음

  • 좋은 지점임. 장점이 몇 가지 있음
    GPU가 필요한 개발을 계속하고 있다면 보통 인스턴스가 켜져 있는 전체 시간 동안 비용을 내야 함. Thunder를 쓰면 GPU를 실제로 쓰는 동안에만 비용을 냄. CPU 코드만 실행할 때는 GPU 시간 비용이 발생하지 않는 셈임. 대안은 인스턴스를 수동으로 켜고 끄는 것인데 번거로울 수 있음
    또 사용하는 GPU의 종류와 수를 쉽게 확장할 수 있음. 예를 들어 저렴한 T4 인스턴스에서 개발하다가 8개 A100으로 전체 딥러닝 학습 작업을 돌리고 싶다면, 인스턴스를 바꾸고 환경을 다시 설정할 필요 없이 명령 하나를 실행한 뒤 더 강한 GPU에서 바로 돌릴 수 있음
  • 시스템 입장에서는 더 투명하게 보임. 예를 들어 얇은 클라이언트에서 GPU 가속이 필요한 GUI 애플리케이션(Matlab, SolidWorks, Blender)을 쓴다면 ECS를 설정하지 않고도 가능함
    GPU 없이 개발하다가 시뮬레이션을 돌릴 때 갑자기 GPU를 붙일 수 있고, AWS보다 훨씬 저렴할 것 같음. 본질적으로는 Ray(https://www.ray.io/)가 푸는 문제를 더 범용적인 방식으로 푸는 것처럼 보임. 반쪽 GPU 같은 더 세밀한 GPU 공유도 가능할 수 있어 매우 기대됨

• 여기 관심이 많아서 T4 인스턴스를 무료로 열기로 했음. 직접 써보고 생각을 알려주면 좋겠음

  • A100과 H100 가격은 어떻게 되는지 궁금함

• 멋짐. MIG나 vGPU로도 동작하게 만들 수 있었는지 궁금함

  • MIG나 vGPU로는 테스트해보지 않았지만, 본질적으로 GPU를 물리적으로 파티셔닝하는 방식이라 동작할 것 같음
    가까운 미래의 주요 목표 중 하나는 GPU 공유를 허용하는 것임. 사용자를 일부 메모리로 제한하지 않고 전체 GPU 메모리를 쓸 수 있게 할 것이기 때문에 MIG나 vGPU보다 나을 수 있음

• 의미 있는 처리량으로 실제 사용하면 어떤 느낌인지 궁금함. 해시 크래킹에도 쓸 수 있나?
  네트워크 너머의 가상 GPU를 생각할 때마다 봇넷이 떠오름. 특히 https://www.hpcwire.com/2012/12/06/gpu_monster_shreds_passwo...의 “Gosney는 먼저 Mosix 공동 창립자인 Amnon Barak 교수에게 자신이 ‘세상을 거대한 봇넷으로 바꾸려는 게 아니다’라고 설득해야 했다”는 대목이 생각남

  • 흥미로운 사고 실험이긴 하지만, 실제로 우리 시스템은 GPU가 분산되어 있지 않기 때문에 봇넷보다는 AWS에 더 가까움
    이 기술은 데이터센터 안에서 매우 유연한 클러스터를 만드는 쪽으로 흥미로운 응용이 가능하고, 그 부분을 탐색 중임

• glx를 개발한 원래 SGI 엔지니어들은 GPU 전송에 X11 메커니즘을 쓰도록 매우 신중하게 설계했는데, 그래서 GL 스트림을 네트워크로 보내 내 그래픽 카드에서 렌더링하는 일이 꽤 간단했음
  “복도 끝 슈퍼컴퓨터에서 실행하고, 워크스테이션에서 렌더링한다”는 식이었음. 최근 드라이버 개발은 그런 배려를 보이지 않아 보통은 더 이상 불가능함. 실제로 얼마나 유용했는지는 모르겠음. 보통 좋은 그래픽 카드가 있으면 CPU도 좋았으니까. 그래도 가지고 놀기에는 재미있었고, 머신룸에서 실행 중인 프로그램이 가속 그래픽을 얻는 게 묘하게 매력적이었음. 한 번은 이런 식으로 glquake를 돌리는 데 성공했음

• 이게 가능하다는 것 자체는 인상적이지만, 네트워크 연결이 끊기거나 100% 안정적이지 않을 때 무슨 일이 생길지 궁금함
  경험상 드라이버는 로컬 GPU가 조금만 이상하게 동작해도 좋지 않게 반응함