- 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 사례도 그러한 과정 중 하나였음