# GPU에 대한 오해

> Clean Markdown view of GeekNews topic #19241. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=19241](https://news.hada.io/topic?id=19241)
- GeekNews Markdown: [https://news.hada.io/topic/19241.md](https://news.hada.io/topic/19241.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-02-15T11:33:08+09:00
- Updated: 2025-02-15T11:33:08+09:00
- Original source: [fly.io](https://fly.io/blog/wrong-about-gpu/)
- Points: 7
- Comments: 1

## Summary

Fly.io는 GPU를 활용한 AI/ML 추론을 목표로 Fly GPU Machines를 개발했으나, 기술적 어려움과 보안 문제로 인해 기대만큼의 성과를 내지 못했습니다. 일반 개발자들은 GPU보다는 LLM을 선호하며, 대규모 AI 작업을 수행하는 기업들은 더 강력한 GPU 클러스터를 원해 Fly.io의 GPU 비즈니스 모델은 실패로 이어졌습니다. Fly.io는 이러한 경험을 통해 시장의 필요에 맞는 제품을 개발하는 것이 중요하다는 교훈을 얻었으며, GPU 지원을 축소하면서 보안성과 개발자 경험을 유지하는 방향으로 조정하고 있습니다.

## Topic Body

- Fly.io는 자체 하드웨어를 사용하는 퍼블릭 클라우드를 구축 중이며, GPU를 활용한 AI/ML 추론을 제공하는 것을 목표로 Fly GPU Machines를 개발함  
- Fly GPU Machines는 Docker/OCI 컨테이너를 실행하는 VM으로, NVIDIA GPU를 직접 매핑하여 빠른 CUDA 연산이 가능하도록 설계됨  
- AI/ML의 중요성은 예상보다 컸지만, GPU 제품은 시장의 니즈를 제대로 반영하지 못한 것으로 보임  
  
### GPU 도입의 기술적 어려움  
- Fly GPU Machines는 Firecracker 대신 Intel의 Cloud Hypervisor를 사용하여 PCI 패스스루를 지원하도록 설계됨  
- NVIDIA의 생태계는 마이크로 VM 하이퍼바이저를 지원하지 않아, GPU 보안 및 성능 최적화가 어려움  
- GPU는 보안팀의 우려 대상이었으며, 다방향 DMA(Direct Memory Access) 전송과 사용자 제어 연산이 가능하여 높은 보안 리스크를 초래함  
- GPU와 비GPU 워크로드를 분리하기 위해 별도 서버 하드웨어를 사용, 비용 비효율적 구조가 발생함  
- 보안 검증을 위해 Atredis 및 Tetrel과의 대규모 보안 평가 진행, 높은 비용과 시간 소모  
  
### 기술적 시행착오  
- NVIDIA가 권장한 방식(K8s 클러스터 구축 또는 QEMU 사용)을 따르지 않고, Fly Machines의 빠른 시작 속도를 유지하려고 시도함  
- NVIDIA의 가상 GPU(vGPU) 드라이버를 Intel Cloud Hypervisor에서 사용하려다 실패  
- NVIDIA의 폐쇄적인 드라이버 환경으로 인해 GPU를 효율적으로 활용할 수 있는 구조를 만들기 어려웠음  
- GPU를 활용한 모델 가중치 로딩 최적화가 필요했으나, 개발자 경험(DX)을 유지하면서 해결하기 어려웠음  
- 많은 GPU를 구매했지만, 기대만큼의 성과를 내지 못함  
  
### GPU 비즈니스 모델의 실패 원인  
- 일반 개발자들은 GPU보다는 LLM을 원함  
  - AI/ML 모델 최적화보다 OpenAI, Anthropic 등의 LLM API를 활용하는 것이 더 간편하고 성능 차이도 크지 않음  
  - 대부분의 개발자들은 "초당 토큰(tokens per second)" 단위의 성능을 중요시하며, GPU가 제공하는 밀리초 단위의 최적화에는 큰 관심이 없음  
- 대규모 AI 작업을 수행하는 기업들은 엄청난 GPU 연산 능력을 필요로 하며, 단일 A100 GPU도 부족함  
  - 대규모 AI 연구소 및 기업들은 SXM 기반 H100 클러스터를 원함  
- 경량 ML 작업을 위한 소형 GPU 시장이 존재할 가능성은 있으나, NVIDIA MIG를 완전 가상화된 환경에서 활용하기 어려움  
- L40S GPU는 유용하게 사용되고 있지만, Fly.io의 핵심 비즈니스 성장 요인이 되지 못함  
  
### 얻은 교훈  
- 초기(2022년)에는 다양한 AI 모델이 등장할 것이라 예상했으나, 현재는 OpenAI, Anthropic 등의 소수 LLM 모델로 수렴됨  
- Fly.io는 "10,000명의 개발자를 위한 기능을 설계한다"는 원칙을 따름  
  - GPU는 10,001번째 개발자를 위한 기능에 불과하여 주요 제품으로 자리 잡기 어려웠음  
- 스타트업은 여러 번의 도전을 통해 배우는 과정이며, GPU 도입은 하나의 실패한 베팅이었음  
- GPU 관련 투자는 전부 손실이 아니며, 일부 하드웨어는 나중에 매각 가능함  
- Fly Machines의 보안성과 개발자 경험을 유지하면서 GPU 지원을 축소하는 방향으로 조정 가능  
- Fly.io의 초기 제품이었던 JavaScript 엣지 컴퓨팅 런타임도 시장에서 원하지 않았으며, 결국 컨테이너 지원으로 전환한 것처럼, GPU도 시장의 필요에 맞지 않았던 선택이었음  
- 스타트업은 종종 잘못된 가정을 통해 올바른 답을 찾아가며, 이번 GPU 사례도 그러한 과정 중 하나였음

## Comments



### Comment 34597

- Author: neo
- Created: 2025-02-15T11:33:09+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43053844) 
- 개발자들은 GPU나 AI/ML 모델보다 LLMs를 원함. 시스템 엔지니어들은 CUDA와 GPU에 대해 신경 쓰지만, 소프트웨어 개발자들은 그렇지 않음
  - 소프트웨어 개발자들 사이에 큰 분열이 있음. 일부는 코드의 실행 위치와 작동 방식을 이해하고 싶어함
  - 다른 그룹은 `git push`만으로 끝내고 싶어하며, DNS나 리눅스 같은 것을 이해하고 싶어하지 않음
  - fly.io 같은 회사는 후자에게 매력적임. GPU 인스턴스는 전자에게 매력적임
  - 두 시장을 다르게 접근해야 함. 후자에게는 추상화와 자동화를 많이 판매할 수 있음

- 2012년부터 무어의 법칙이 사실상 끝남. 단일 스레드 실행은 2GHz에서 멈춤
  - 2012-2022년 동안 클라우드로 이동하면서 단일 스레드의 정체를 눈치채지 못함
  - 2022년 데이터 센터는 더 많은 코어를 가진 차세대 칩을 구매할 필요가 없음을 깨달음
  - LLMs는 100% 병렬 처리 가능하므로 다시 자본을 투자할 수 있음
  - 2024년 웨이퍼 스케일 실리콘이 등장할 것임. Llama 모델을 A100보다 10배 빠르게 실행할 수 있음
  - 소프트웨어는 이 성능을 활용할 방법을 찾아야 함

- fly GPU 머신은 매우 빠르고 신뢰할 수 있으며, 대안에 비해 가격이 비싸지 않음
  - DX가 훌륭함. 새로운 명령어를 배울 필요가 없음
  - 가격이 더 저렴하고 더 많은 지역에서 사용할 수 있기를 바람

- 4090을 구매했지만, 24GB VRAM으로는 충분하지 않음
  - 2개 이상의 3090과 맞춤형 전원 공급 장치가 더 나았을 것임
  - 성능과 품질이 아직 부족함

- Fly를 선택하는 고객은 전용 GPU 서버를 장기간 사용하는 마지막 사람일 것임
  - 서버리스 솔루션을 사용할 가능성이 높음

- GPU 슬라이스가 없는 것이 아쉬움. 월 $1,000의 비용은 정당화하기 어려움
  - AMD 소비자 GPU를 Raspberry Pi에 연결하는 것이 경제적일 수 있음

- "우리가 틀렸다"는 말은 영어에서 가장 고귀하고 아름다운 말 중 하나임

- Fly.io는 Cloudflare의 Workers 플랫폼과 유사한 개발자를 끌어들임
  - PaaS 환경의 개발 속도를 원함
  - Cloudflare는 GPU와 함께 PaaS 접근 방식을 유지하며 Workers AI를 구축함

- Runpod에서 서버리스 엔드포인트를 설정하는 데 한 달이 걸렸고, 비싸고 신뢰할 수 없었음
  - Google Cloud 크레딧을 사용하여 제품을 고객에게 제공할 수 있었음
  - GPU 제공자에 대한 수요가 있음. Fly가 이 시장에 진입할 수 있을지는 확실하지 않음