Na istniejącym hoście Proxmox jest jeszcze miejsce na usługę AI. Czy wystarczy dołożyć kartę graficzną i utworzyć maszynę wirtualną? Może to być sensowne rozwiązanie, jeśli przypisanie GPU, zasoby hosta i utrzymanie zostaną zaplanowane wspólnie.
Przy passthrough fizyczna GPU należy do jednej VM
PCIe passthrough przekazuje maszynie wirtualnej kontrolę nad fizycznym urządzeniem. VM AI korzysta z GPU przez własny sterownik w systemie gościa. W czasie tego przypisania host i inne VM nie mogą jednocześnie używać tej samej karty do własnych obliczeń.
Wewnątrz VM AI wspólna usługa modeli może obsługiwać wiele zapytań. To co innego niż podział karty pomiędzy kilka VM. Przydatność odrębnego rozwiązania vGPU zależy dodatkowo od GPU, hiperwizora, sterowników, wspieranych konfiguracji i licencji.
Zaletą VM jest jasno przypisane środowisko systemowe: system operacyjny, serwer modeli i potrzebne dane można obsługiwać razem. GPU pozostaje fizycznym urządzeniem z własnymi wymaganiami.
Przed montażem sprawdzić cały łańcuch sprzętowy
Dokumentacja Proxmox wymaga obsługi IOMMU, w tym mapowania przerwań. Procesor, płyta główna, firmware i obsługa w Linuksie muszą być zgodne. Sama nazwa VT-d lub AMD-Vi nie zastępuje tej weryfikacji.
Ważna jest również grupa IOMMU wybranego gniazda. GPU i powiązane funkcje powinny być odpowiednio oddzielone od pozostałych potrzebnych urządzeń. Dokumentacja Linux VFIO wyjaśnia, dlaczego grupa stanowi granicę przypisania i izolacji. Inne gniazdo może oznaczać inne grupowanie.
Sprawdza się także miejsce, elektryczne połączenie PCIe, zasilanie i chłodzenie. W systemie gościa potrzebne są odpowiedni sterownik GPU i wsparcie usługi modeli. Dla GPU passthrough Proxmox zwykle zaleca q35 z OVMF/UEFI i PCIe; odpowiedni musi być również firmware karty. Konkretne ustawienia zależą od używanego sprzętu.
Dostępna wydajność to wspólny budżet
Przykład planowania zakłada istniejący host wirtualizacji z aplikacjami firmowymi i dodatkową VM AI. Czas CPU, RAM, pamięć masowa i sieć pozostają wspólnymi zasobami. Nieograniczony import dokumentów lub uruchomienie modelu nie powinny niespodziewanie spowalniać pozostałych aplikacji.
VM otrzymuje więc jasno opisaną konfigurację i limity obciążenia. Pamięć graficzną, długość kontekstu i równoległe zapytania do modelu testuje się łącznie. Więcej RAM przydzielonego VM nie zwiększa fizycznej VRAM karty. Przeniesienie części pracy na CPU może zmienić zachowanie i wymaga osobnego pomiaru.
Dla uczciwego porównania zapisuje się wersję modelu, dane wejściowe, kontekst i współbieżność. Ocenia się jakość, pierwszą odpowiedź, dalszy wynik, oczekiwanie i wpływ na inne VM. Ogólny procent narzutu wirtualizacji byłby mało przydatny bez takiego konkretnego testu.
VM czy dedykowana maszyna: co zmienia się w utrzymaniu?
| Pytanie | VM AI z GPU passthrough | Dedykowany serwer AI |
|---|---|---|
| Zasoby | GPU przypisana na stałe; pozostałe zasoby hosta uzgodnić z istniejącymi VM. | Zasoby obliczeniowe i pamięciowe są dostępne dla własnego systemu. |
| Utrzymanie | Wspólnie planować sterowniki gościa, obsługę modeli i aktualizacje Proxmox/hosta. | System operacyjny i modele w osobnym zakresie utrzymania. |
| Zmiana hosta | Bezpośrednio przekazane urządzenia PCI uniemożliwiają zwykłą migrację na żywo. Przy przenoszeniu zatrzymanej VM sprawdzić odpowiedni sprzęt docelowy i przypisanie. | Przeniesienie lub zastąpienie przez przygotowane odtworzenie pracy na innym sprzęcie. |
| Kopia zapasowa | Łącznie rozpatrzyć dyski VM, spójność aplikacji, konfigurację i przypisanie urządzeń. | Osobno zorganizować dane systemowe/aplikacyjne i ich odtworzenie. |
| Nakład pracy | Można wykorzystać istniejącą infrastrukturę; uwzględnić integrację i dodatkowe zależności od hosta. | Zaplanować własny sprzęt i zasoby lokalizacji, z wyraźniej wydzielonym utrzymaniem. |
Istniejący klaster nie sprawia automatycznie, że VM AI związana z fizycznym sprzętem da się przenosić bez przerwy. Restart na innym węźle wymaga zgodnych zasobów GPU, prawidłowego przypisania i rzeczywiście przetestowanej procedury. Wymagania usługi decydują, czy to przygotowanie wystarczy, czy potrzebny jest kolejny węzeł usługi.
Odtworzenie ma wykazać więcej niż samo uruchomienie VM
Kopia wirtualnego dysku nie zawiera działającego stanu fizycznej karty graficznej. Przy odtwarzaniu sprawdza się więc również wersje modeli, konfigurację, prawa do danych i ponowne przypisanie urządzenia. Migawka na tym samym hoście nie zastępuje osobnej kopii zapasowej.
Odbiór obejmuje zwykły restart VM, restart hosta, zmianę sterownika/jądra w planowanym oknie utrzymania i zaplanowane odtworzenie. Następnie sprawdza się rzeczywiste zapytanie do modelu oraz pozostałe aplikacje. Pokazuje to, czy urządzenie po restarcie znów jest poprawnie dostępne.
Akcelerator używany wyłącznie do obliczeń nie potrzebuje monitora podłączonego do GPU. Konsola Proxmox nie wyświetla po prostu obrazu z przekazanej GPU. Z usługi AI korzysta się przez przewidziany interfejs lub API.
Oprzeć decyzję na ograniczonym pilotażu
DAXS najpierw ustala zadanie, istniejący host, zakres użycia i dopuszczalną przerwę. Ograniczony pilotaż sprawdza następnie przypisanie urządzenia, jakość merytoryczną i wpływ na działanie. W zależności od wyniku odpowiednia może być VM, własna maszyna albo usługa zewnętrzna.
Nasze omówienie Proxmox dla firm wyjaśnia ogólny wybór platformy. Nasza strona o lokalnej infrastrukturze LLM i pilotaż testów obciążenia rozwijają temat doboru zasobów. Dla wspólnej usługi artykuł o Ollama i Open WebUI uzupełnia architekturę.
Omówić model działania AI i istniejącą infrastrukturę.
Źródła: Proxmox: PCIe passthrough (link zewnętrzny) · Proxmox: migracja maszyn wirtualnych (link zewnętrzny) · Linux: VFIO i grupy IOMMU (link zewnętrzny) · NVIDIA: macierz wsparcia vGPU (link zewnętrzny) · Ollama: obsługa sprzętu (link zewnętrzny).
