가상머신 안에서 GPU 쓰기, 왜 이렇게 어려울까요
리눅스에서 KVM으로 가상머신(VM)을 돌려 보신 분이라면 한 번쯤 부딪히는 벽이 있어요. 'VM 안에서 GPU 좀 쓰고 싶은데' 하는 순간부터 일이 갑자기 어려워지거든요. CPU나 메모리, 디스크는 하이퍼바이저가 잘게 나눠서 여러 VM에 나눠 주는 게 자연스러운데, GPU는 이상하게 그게 잘 안 돼요.
오픈소스 클라우드 게이밍 프로젝트 Nestri를 만드는 팀이 이 문제를 겨냥한 virtio-nvgpu라는 프로젝트를 공개했어요. 목표는 이름 그대로 KVM 게스트 안에서 엔비디아 GPU를 '거의 네이티브' 성능으로 쓰게 하는 건데요. 무엇이 새로운 건지 이해하려면 먼저 기존 방법들이 왜 아쉬운지 알아야 해요.
지금까지의 세 가지 방법과 각각의 한계
첫 번째는 VFIO PCI 패스스루예요. 이게 뭐냐면, GPU라는 PCI 장치를 호스트에서 떼어내 VM 하나에 통째로 넘겨주는 방식이에요. VM 입장에선 진짜 GPU가 꽂힌 것과 똑같아서 성능도 거의 100% 나오고, 드라이버도 그냥 일반 드라이버를 쓰면 돼요. 그런데 GPU 하나를 VM 하나가 독점해요. GPU가 4개면 VM도 4개까지만 GPU를 쓸 수 있는 거죠. 게이밍 스트리밍이나 GPU 서버를 여러 사용자가 나눠 써야 하는 환경에서는 너무 비효율적이에요.
두 번째는 엔비디아 vGPU(옛 이름 GRID)예요. GPU 하나를 시간 단위로 잘라 여러 VM에 나눠 주는 엔비디아 공식 솔루션인데, 데이터센터용 GPU(A 시리즈, L 시리즈 등)에서만 되고 별도 라이선스 비용이 들어요. 집에 있는 RTX 4090으로는 못 써요. 소비자용 GPU에서 억지로 되게 하는 우회 방법들이 있긴 한데, 드라이버 버전에 묶이고 안정성이 보장되지 않아요.
세 번째는 API 전달 방식이에요. virtio-gpu 장치에 VirGL이나 Venus 같은 프로토콜을 얹어서, 게스트의 OpenGL이나 Vulkan 호출을 하나하나 호스트로 넘겨 대신 실행하는 방식이죠. 이건 GPU를 여러 VM이 나눠 쓸 수 있고 소비자용 GPU에서도 되지만, API 호출마다 번역과 직렬화가 일어나서 오버헤드가 커요. 그리고 결정적으로 CUDA나 NVENC(하드웨어 영상 인코더) 같은 엔비디아 전용 기능은 아예 안 돼요.
정리하면 '성능은 좋은데 나눠 못 쓰거나', '나눠 쓸 수 있는데 비싸거나', '싸고 나눠 쓰는데 느리고 기능이 빠지거나' 셋 중 하나였던 거예요.
virtio-nvgpu의 접근: 드라이버를 나눠서 심는다
virtio-nvgpu의 핵심 아이디어는 '네이티브 컨텍스트'라고 부르는 방식과 맥이 닿아 있어요. 이게 뭐냐면, API 수준에서 번역하는 게 아니라 커널 드라이버와 유저스페이스 드라이버 사이의 경계에서 전달하는 거예요.
엔비디아 드라이버는 두 층으로 나뉘어요. 커널 안에서 하드웨어를 직접 만지는 커널 모듈이 있고, 그 위에 CUDA 라이브러리나 OpenGL, Vulkan 드라이버 같은 유저스페이스 라이브러리가 있죠. 유저스페이스 라이브러리는 커널 모듈에게 ioctl이라는 시스템 호출로 '메모리 할당해 줘', '이 명령 큐 실행해 줘' 하고 부탁해요.
virtio-nvgpu는 게스트 VM 안에서 유저스페이스 드라이버는 원래 것을 그대로 쓰고, 커널 모듈 자리에 요청을 대신 전달하는 얇은 드라이버를 넣는 구조예요. 이 드라이버는 ioctl 요청을 받으면 virtio 채널(VM과 호스트 사이의 표준 통신 통로)로 호스트에 넘기고, 호스트의 진짜 엔비디아 드라이버가 처리한 뒤 결과를 돌려줘요. GPU 메모리는 호스트가 매핑해서 게스트와 공유하기 때문에, 진짜 무거운 데이터인 명령 버퍼(GPU가 실행할 명령들이 담긴 메모리)는 복사 없이 게스트가 직접 써넣을 수 있어요.
왜 이게 빠르냐면, GPU 작업에서 ioctl 호출은 사실 빈도가 낮아요. 명령을 준비하는 건 메모리에 직접 쓰는 일이고, ioctl은 '준비됐으니 실행해' 하고 신호 보내는 정도거든요. 그러니 빈도 낮은 신호만 VM 경계를 넘고, 대량 데이터는 공유 메모리로 흐르니까 네이티브에 가까운 성능이 나오는 거예요. 게다가 유저스페이스 드라이버가 원본이니까 CUDA, NVENC, Vulkan, OpenGL 전부 이론상 그대로 동작하고요. 엔비디아가 커널 모듈을 오픈소스로 공개하면서(open-gpu-kernel-modules) 이 경계의 인터페이스를 들여다볼 수 있게 된 것도 이런 시도가 가능해진 배경이에요.
물론 주의할 점도 있어요. 아직 초기 단계 프로젝트라 지원되는 드라이버 버전이나 GPU 세대가 제한적일 가능성이 높고, 게스트와 호스트의 드라이버 버전을 맞춰야 해요. 그리고 호스트 커널 드라이버의 ioctl 인터페이스가 게스트에 그대로 노출되는 셈이라, 격리 수준은 패스스루보다 약해요. 신뢰할 수 없는 사용자에게 VM을 내주는 멀티테넌트 환경이라면 이 부분을 꼭 따져 봐야 해요.
업계 흐름에서 보면
오픈소스 그래픽 드라이버 진영에서는 이미 비슷한 흐름이 있었어요. Mesa 프로젝트에서 AMD, 인텔, 퀄컴 GPU용으로 virtio-gpu 네이티브 컨텍스트를 구현해 왔고, 크롬OS나 안드로이드의 VM에서 쓰이고 있거든요. virtio-nvgpu는 그 개념을 엔비디아 독점 드라이버 스택에 적용하려는 시도라고 보면 돼요.
컨테이너 쪽은 사정이 훨씬 나아요. nvidia-container-toolkit 하나면 도커 컨테이너 여러 개가 GPU를 나눠 쓸 수 있죠. 그런데 컨테이너는 커널을 공유하니까 보안 격리가 VM보다 약해요. 그래서 Firecracker나 Kata Containers 같은 마이크로VM에 GPU를 붙이려는 수요가 계속 있었고, virtio-nvgpu 같은 접근이 그 빈틈을 노리는 거예요. 클라우드 게이밍, GPU 샌드박스, AI 에이전트가 코드를 실행하는 격리 환경 같은 곳이 다 여기에 해당해요.
한국 개발자에게 주는 시사점
Proxmox로 홈랩 운영하면서 게이밍 VM과 AI 실험용 VM에 GPU 하나를 나눠 쓰고 싶었던 분들에게는 특히 반가운 소식이에요. 지금은 패스스루로 한 VM에 몰아주거나 소비자용 GPU에서 vGPU를 억지로 되게 하는 우회로를 쓰셨을 텐데, 성숙해지면 훨씬 깔끔한 선택지가 생기는 거죠.
회사에서 GPU 서버를 팀별로 나눠 쓰는 경우에도 마찬가지예요. 다만 아직 프로덕션에 바로 넣기보다는, 저장소를 클론해서 어떤 드라이버 버전에 어떻게 얹는지 구조를 뜯어 보는 정도가 현실적이에요. virtio 장치가 어떻게 만들어지는지, 커널 드라이버와 유저스페이스 드라이버의 경계가 어디인지 배우기에 아주 좋은 교재거든요.
정리하며
한 줄로 정리하면, virtio-nvgpu는 엔비디아 드라이버의 커널/유저스페이스 경계에서 요청을 VM 밖으로 넘기는 방식으로, 라이선스 없이 소비자용 GPU도 여러 VM이 거의 네이티브 속도로 나눠 쓰게 하려는 시도예요.
여러분은 GPU 가상화 때문에 고생하신 적 있으세요? 이런 반가상화(paravirtual) 방식이 격리 수준의 약점을 감수할 만큼 매력적이라고 보시나요, 아니면 프로덕션에서는 여전히 패스스루나 공식 vGPU가 답이라고 보시나요?
🔗 출처: Hacker News