Ein Rechenzentrums-GPU für 200 £ in einen Gaming-PC einbauen

 (blog.tymscar.com)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Um eine lokale LLM-Umgebung zu erweitern, für die eine RTX 4080 16GB allein nicht ausreichte, wurde für rund 200 £ zusätzlich eine gebrauchte Tesla V100 SXM2 16GB samt Adapter eingebaut, womit insgesamt 32 GB VRAM zur Verfügung stehen
  • Die V100 SXM2 ist eine Server-GPU ohne PCIe-Steckplatz, Display-Ausgang oder gewöhnlichen Stromanschluss, ließ sich aber mit einem SXM2-zu-PCIe-Adapter in einen Gaming-PC einbauen
  • Der Server-Lüfter war standardmäßig mit 82 dB für den Einsatz in Innenräumen unbrauchbar, konnte aber über ein PH2.0-2.54-mm-Jumper-Kabel an einen Mainboard-Lüfteranschluss angeschlossen werden, wodurch PWM-Steuerung und leiser Betrieb möglich wurden
  • Mit tensor splitting in llama.cpp wurde Qwen3.6-27B-MTP Q5_K_M auf RTX 4080 und V100 verteilt, wodurch 128k Kontext und etwa 32 tok/s Inferenzgeschwindigkeit erreicht wurden
  • Es ist nicht so elegant wie eine einzelne 32-GB-GPU, und Probleme mit Treibern, CUDA und warmen Neustarts bleiben bestehen, aber gebrauchte Server-GPUs können eine günstige Alternative zur lokalen LLM-VRAM-Erweiterung sein

Eine 32-GB-lokale-LLM-Umgebung für 200 £

  • Die RTX 4080 mit 16 GB VRAM reichte nicht aus, um die gewünschten lokalen Modelle auszuführen, daher wurde per Adapter eine gebrauchte Rechenzentrums-GPU in den Gaming-PC eingebaut
  • Eine Tesla V100 SXM2 16GB samt SXM2-zu-PCIe-Adapter wurde für zusammen etwa 200 £ gekauft, wodurch eine Umgebung mit insgesamt 32 GB VRAM über zwei GPUs entstand
  • Ein Modell mit 27 Milliarden Parametern wurde auf die zwei GPUs verteilt und mit rund 32 Tokens/s ausgeführt; sowohl das gesamte Modell als auch der Kontext passten in den VRAM
  • Es ist zwar nicht dasselbe Erlebnis wie mit einer einzelnen Consumer-GPU mit 32 GB, aber die VRAM-Kapazität wurde zu deutlich geringeren Kosten als bei einer RTX 5090 32GB erreicht

Tesla V100 SXM2 und Adapter

  • Die Tesla V100 SXM2 16GB ist eine GPU für NVIDIA-DGX-Server und Hyperscaler-Racks
    • Es gibt keinen normalen PCIe-Steckplatz, keinen Display-Ausgang und keinen gewöhnlichen Stromanschluss
    • Sie wird auf proprietären Boards im Server montiert und kommuniziert über NVLink
    • Für den direkten Einsatz auf einem Mainboard ist ein separater Adapter nötig
  • Die V100 ist eine Volta-GPU mit 16 GB HBM2-Speicher und 5120 CUDA-Kernen
    • Der eBay-Kaufpreis lag bei etwa 150 £
    • Obwohl sie von 2017 stammt, sind Rechenleistung und VRAM für lokale LLMs noch immer brauchbar
  • HBM2-Speicherbandbreite ist ihr großer Vorteil
    • Die V100 bietet mit einem 4096-Bit-Speicherbus 900 GB/s Bandbreite
    • Das sind 22 % mehr als die 736 GB/s GDDR6X-Bandbreite der RTX 4080
    • Auch mehr als Apple M3 Max mit 400 GB/s, M4 Max mit 546 GB/s und M5 Max mit 614 GB/s
  • Die AMD RX 7900 XTX liegt mit 24 GB GDDR6 und 960 GB/s Bandbreite leicht vor der V100, kostet aber über 700 £
    • Die LLM-Inferenzunterstützung von ROCm wird im Vergleich zu CUDA noch als unausgereift bewertet
    • Die V100 liefert 94 % der Bandbreite einer RX 7900 XTX für weniger als ein Viertel des Preises und funktioniert mit llama.cpp
  • Die RTX 5090 liegt mit 1.792 GB/s klar vor der V100, kostet aber über 2.000 £
    • Bei LLM-Inferenz ist Speicherbandbreite ein wichtiger Engpass, der die Tokens/s bestimmt
  • Der SXM2-zu-PCIe-Adapter ist kein offizielles NVIDIA-Produkt und wird nicht offiziell unterstützt
    • Es handelt sich um eine nackte Platine mit SXM2-Sockel auf der einen und PCIe-Edge-Connector auf der anderen Seite
    • Der Preis lag bei rund 50 £, womit die Gesamtkonfiguration auf etwa 200 £ kam
    • Dank des Adapters konnte die V100 16GB zusammen mit der RTX 4080 ins Mainboard gesteckt werden

Problem und Lösung bei der Server-Kühlung

  • Die V100 SXM2 wurde für industrielle Kühlung in 2U-Servern ausgelegt
    • Der Lüfter des Adapters ist für einen normalen Raum viel zu laut
    • Die mit der Apple Watch gemessene Lautstärke betrug 82 dB und wurde zwischen Küchenabfallzerkleinerer und Rasenmäher eingeordnet
  • Im Auslieferungszustand ließ sich der Lüfter nicht steuern
    • Versuche mit nvidia-smi, Linux-Geräteerkennung und Windows Afterburner schlugen alle fehl
    • Der Lüfter des Adapters scheint davon auszugehen, in einem Server-Rack dauerhaft mit 100 % zu laufen
  • Mit einem 9V-Batterietest wurde die Pin-Belegung des Lüfters geprüft
    • Als Jumper auf VCC und Ground gesetzt und eine 9V-Batterie angelegt wurde, drehte sich der Lüfter
    • Gegenüber dem Betrieb mit 12 V war er deutlich leiser, was auf Regelbarkeit hindeutete
  • Der Lüfter verhielt sich ähnlich wie ein Standard-PC-Gehäuselüfter
    • Jumper wurden in den Lüfterstecker gesteckt und die andere Seite an einen freien Lüfteranschluss des Mainboards geführt
    • Das Mainboard konnte die RPM auslesen und auch PWM steuern
    • Selbst bei 10 % Drehzahl blieb die Temperatur unter Volllast unter 50 °C und war nahezu unhörbar
  • Das endgültige Kabel bestand aus einem 2.54mm male zu PH2.0 female Jumper-Kabel
    • Der Lüfteranschluss des Adapters ist ein 4-poliger JST-PH2.0-Stecker
    • Der Lüfteranschluss des Mainboards nutzt den Standard mit 0.1 inch bzw. 2,54 mm Raster
    • Die PH2.0-female-Seite wurde mit Tachometer- und PWM-Pins des Lüfters verbunden, die 2.54mm-male-Seite mit dem Lüfteranschluss des Mainboards
    • Mit einem etwa 2 £ teuren Jumper-Kabel und etwas Pin-Prüfung wurde das 82-dB-Problem gelöst

VRAM mit zwei GPUs erweitern

  • Die finale GPU-Konfiguration sah so aus
    • RTX 4080: 16 GB VRAM, Ada-Architektur
    • Tesla V100: 16 GB VRAM, Volta-Architektur
    • Gesamt: 32 GB VRAM über beide GPUs
  • llama.cpp kann per tensor splitting ein Modell auf zwei GPUs verteilen
    • Dabei werden Layer über den PCIe-Bus gepipelined
    • Die RTX 4080 verarbeitet einen Teil der Layer, die V100 den Rest
    • Es ist nicht schneller als eine einzelne 32-GB-GPU, funktioniert aber und kostet nur etwa 10 % einer 32-GB-GPU
  • Der Stromverbrauch der V100 wurde bei maximal etwa 150 W beobachtet
    • Für eine GPU zur lokalen LLM-Inferenz ist das nicht klein, aber auch nicht außergewöhnlich hoch
  • Eine V100 mit 32 GB bleibt ebenfalls eine Option
    • Sie kostet mehr als doppelt so viel wie das gekaufte Modell, bietet aber 32 GB HBM2 auf einer einzelnen Karte für einige hundert Pfund
    • Zwei V100 mit 32 GB würden 64 GB VRAM ergeben und lägen laut Darstellung bei etwa 20 % des aktuellen RTX-5090-Preises
  • Das SXM2-Format unterstützt standardmäßig NVLink
    • In einer korrekt aufgebauten Multi-GPU-Konfiguration könnten die GPUs mit hoher Bandbreite direkt kommunizieren
    • Auch über den PCIe-Adapter war die tensor-split-Leistung ausreichend robust

Treiber und CUDA unter NixOS passend machen

  • Die Software-Konfiguration verlief dank NixOS vergleichsweise reibungslos
  • Die V100 nutzt einen Volta-Chip, und NVIDIA hat den Volta-Support ab Treiberzweig 560 eingestellt
    • Der letzte Treiber, der sowohl RTX 4080 Ada als auch V100 Volta unterstützt, ist der Zweig 550.x
    • Unter NixOS entspricht das nvidiaPackages.legacy_535
  • Dieser Treiber unterstützt nur bis CUDA 12.2
    • Das aktuelle nixpkgs liefert CUDA 12.6 oder neuer
    • Daher musste CUDA 12.2 aus nixpkgs 24.05 übernommen werden
  • Der Treiber verlangt einen Linux-Kernel 6.6
    • Der Legacy-Treiber unterstützt neuere Kernel nicht
  • Obwohl es sich um einen Headless-Inferenzserver handelt, war services.xserver.enable = true nötig
    • Ohne diese Einstellung wurde das NVIDIA-Kernelmodul nicht geladen
  • Die zentrale NixOS-Konfiguration bestand aus Kernel, NVIDIA-Legacy-Treiber und der Angabe des NVIDIA-X-Server-Treibers
boot.kernelPackages = pkgs.linuxPackages_6_6;
hardware.nvidia.package = config.boot.kernelPackages.nvidiaPackages.legacy_535;
services.xserver.enable = true;
services.xserver.videoDrivers = [ "nvidia" ];
  • CUDA 12.2 wurde per Overlay aus älteren nixpkgs eingebunden
nixpkgs.overlays = [
  (final: prev: {
    cudaPackages_12_2 = nixpkgs-cuda.legacyPackages.${prev.system}.cudaPackages_12_2;
  })
];
  • Beide GPUs wurden korrekt erkannt, und CUDA funktionierte ebenfalls
  • Die vollständige Maschinenkonfiguration ist in diesem Commit im dotfiles-Repo enthalten
    • Dort sind auch die llama.cpp-Service-Definition und ein auf die richtige Version fixierter Custom-Build enthalten

Verwendetes Modell und Leistung

  • Das verwendete Modell war die quantisierte Version Qwen3.6-27B-MTP Q5_K_M
    • Die Modellgröße beträgt rund 19 GB
    • Mit zwei GPUs passt das gesamte Modell in den VRAM, und es bleibt noch Platz für den Kontext
  • Die wichtigsten Laufparameter waren wie folgt
    • Model: Qwen3.6-27B-MTP Q5_K_M, 19GB
    • Context size: 128k tokens
    • GPU layers: 99, vollständig offloaded
    • Tensor split: -ts 1.0,1.0, gleichmäßige Verteilung auf beide GPUs
  • Die Leistung war wie folgt
    • Inference speed: etwa 32 tok/s
    • Prompt processing: etwa 133–160 tok/s
  • 32 Tokens/s werden als ausreichend für interaktive Nutzung bewertet
    • Das wurde sogar mit tensor splitting über zwei unterschiedliche GPU-Architekturen hinweg per PCIe erreicht
    • Einschließlich Netzwerklatenz sei dies in den meisten Fällen schneller als Cloud-API-Endpunkte

MTP und Bildeingabe

  • MTP steht für Multi-Token Prediction
    • Normale LLM-Inferenz sagt jeweils nur ein Token voraus, akzeptiert es und berechnet dann das nächste
    • MTP sagt mehrere zukünftige Tokens auf einmal voraus und validiert anschließend die richtigen
    • Akzeptierte Tokens sind praktisch nahezu kostenlos, falsche Vorhersagen fallen auf den normalen Pfad zurück
  • Das Ergebnis von MTP ist eine etwa 1,5- bis 2-fach höhere Generierungsgeschwindigkeit ohne Genauigkeitsverlust
    • In dieser Konfiguration seien statt rund 32 tok/s bei gut passendem MTP sogar 50–60 tok/s möglich
    • Besonders bei vorhersehbaren Ausgaben wie Code ist der Effekt groß
  • Die MTP-Unterstützung in llama.cpp ist noch neu
    • Die llama.cpp-Version in nixpkgs unterstützt die Qwen3.6-MTP-Architektur nicht
    • Deshalb musste llama.cpp aus dem Quellcode eines bestimmten Commits gebaut werden, in dem die Unterstützung hinzugefügt wurde
    • Unter NixOS wurde eine benutzerdefinierte Derivation auf diesen Commit fixiert, um reproduzierbare Builds zu erhalten
    • Änderungen am Modell oder an der llama.cpp-Version werden durch Anpassen einer Zeile in der Konfiguration und anschließendes nixos-rebuild switch erledigt
  • Qwen3.6-27B unterstützt Bildeingaben über eine separate multimodale Projektor-Datei mmproj
    • Die zusätzliche Datei ist etwa 928 MB groß
    • Der Vision-Encoder wandelt Bildpixel in den Token-Embedding-Raum des LLM um
    • Das Modell „sieht“ Bilder nicht wie ein Mensch
    • Das LLM verarbeitet die umgewandelten Vektoren einfach wie eine weitere Token-Sequenz
  • Die Start-Flags für llama.cpp lauten wie folgt
--mmproj /mnt/nas/llamacpp/mmproj-F16.gguf --mmproj-offload
  • --mmproj-offload lädt den Vision-Encoder zusammen mit dem Modell auf die GPU
    • Dadurch bleibt die Inferenz auch mit Bildeingaben schnell

Lokale Nutzung

  • Diese Konfiguration wird mit OpenCode genutzt
    • OpenCode ist ein AI-Coding-Assistent, der mit lokalen Modellen arbeiten kann
  • Der LLM-Server läuft auf dem Desktop, wird aber von anderen Geräten aus genutzt
    • Der Zugriff erfolgt im Heimnetz über andere Rechner
    • Von außen wird über Tailscale zugegriffen
  • In OpenCode wird der llama.cpp-Server über die API-URL konfiguriert
    • Das Modell läuft lokal
    • Die Antworten kommen schnell, und die Daten verlassen das Netzwerk nicht

Verbleibende Probleme und Grenzen

  • Die V100 verschwindet gelegentlich nach einem warmen Neustart
    • Nach einem Neustart, bei dem nur das OS neu startet und das Mainboard weiter unter Strom bleibt, taucht die V100 mitunter weder in lspci noch in nvidia-smi auf
    • Die Ursache scheint ein Problem bei der ACPI-Enumeration des PCIe-Slots zu sein
    • Nach einem vollständigen Ausschalten und einigen Sekunden Wartezeit funktioniert sie per Kaltstart immer wieder
  • Ohne die V100 startet llama.cpp nicht
    • Das Modell passt nicht auf eine einzelne GPU mit 16 GB
    • Bis die GPU zurückkommt, gerät der Dienst in eine Crash-Loop
    • Im praktischen Einsatz wird das nicht als großes Problem gesehen, da beim Neustart meist ohnehin jemand in der Nähe ist
  • Die Konfiguration mit tensor splitting über zwei GPUs unterschiedlicher Architektur ist nicht so sauber wie eine einzelne GPU
    • Die V100 ist auch nicht die schnellste GPU für Inferenz
    • Das Preis-Leistungs-Verhältnis wird jedoch als sehr hoch bewertet

Optionen und Fazit

  • Für rund 200 £ erhielt man Folgendes
    • Eine 16-GB-Rechenzentrums-GPU, die zusammen mit einer Gaming-GPU arbeitet
    • Insgesamt 32 GB VRAM für lokale LLM-Inferenz
    • 32 Tokens/s bei einem Modell mit 27 Milliarden Parametern
    • Ein Kontextfenster von 128k Tokens
    • Vision-Unterstützung für Bildeingaben
    • Ein vollständig lokal laufendes Modell ohne Cloud und ohne Kosten pro Token
  • Der eigentliche Preis war der Lüfterlärm, der sich jedoch mit Jumper-Kabel und Pin-Prüfung beheben ließ
  • Wer ernsthaft lokale Modelle betreiben will, könnte im Markt für gebrauchte Server-GPUs eine Alternative finden
    • Auch ohne vorhandene GPU lässt sich mit einer einzelnen V100 in einem günstigen Servergehäuse eine brauchbare lokale LLM-Umgebung mit 16 GB VRAM aufbauen
    • Die V100 SXM2 ist nicht die einzige Option
    • Eine P40 bietet für ähnliche Kosten 24 GB, ist aber langsamer und hat keine Tensor Cores
    • Das V100-32-GB-Modell ist teurer, aber immer noch günstiger als Consumer-GPUs mit derselben VRAM-Kapazität
  • Man sollte allerdings auf das Lüfterproblem vorbereitet sein

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Lobste.rs-Kommentare

  • Der Ansatz ist wirklich cool, und das Verschwinden der GPU aus PCIe macht noch neugieriger, weil es dafür so viele mögliche Ursachen gibt
    Das laute Hochdrehen der GPU-Lüfter erinnert an meine Zeit im NVIDIA-CUDA-Team. Ein Kollege arbeitete gerade daran, die Lüftersteuerung zu NVML und nvidia-smi hinzuzufügen; von hinter der Trennwand hörte man, wie die Lüfter schneller und wieder langsamer wurden, und dann streckte er strahlend lächelnd den Kopf heraus
    Er meinte, es sei eine seiner Lieblingsfunktionen gewesen, weil man das Ergebnis in dem Moment, in dem der Code funktionierte, direkt hören konnte

  • Falls dich selbstgehostete LLMs interessieren: Eine Dell-OEM-RTX 3090 war meist günstiger als Produkte großer Marken und war für etwa 800 kanadische Dollar zu bekommen
    Jetzt sollte ich wohl mehr darüber lesen, wie vLLM funktioniert. Das Modell beginnt manchmal, lange Listen mit passenden Namen und Adjektiven auszuspucken; vermutlich ist etwas falsch konfiguriert

    • Ich frage mich, welche Modelle auf einer RTX 3090 laufen
      Nach meinem Verständnis brauchen die meisten brauchbaren Modelle mindestens 48–64 GB VRAM, um ordentlich zu laufen, deshalb dachte ich, dass Apple-M-Series-Chips mit ihrer Unified-Memory-Architektur in diesem Bereich so beliebt sind

  • Solche Produkte gibt es auch schon als fertig verpackte Variante, aber dann endet es bei etwas wie 3 Monaten Herstellergarantie
    https://ebay.com/itm/297819576914/…

    • Das ist wirklich verlockend. Ich vermute, der hier erwähnte Lüfter-Umbau ist dabei nicht gemacht worden

  • In den USA werden gebrauchte 32-GB-Modelle für etwa 600 Dollar gehandelt
    Den Adapter würde ich wahrscheinlich direkt aus China kaufen, dem Ursprungsland

  • Ich frage mich, ob es auf AMD-Seite ein entsprechendes Produkt gibt. Ich nutze derzeit zwei 48-GB-W7900 und würde gern erweitern, um größere Modelle laufen zu lassen

    • Bis zu einem gewissen Grad schon. Es gibt die Instinct MI60 aus derselben Ära wie die V100; sie ist ziemlich alt, hat aber 32 GB VRAM und kam bereits als PCIe-Karte heraus
      Für die Kühlung muss man etwas ergänzen, aber mit Adaptern muss man nicht herumhantieren
      Ich lese jedes Mal mit, wenn ich auf eine lokale Modellkonfiguration stoße, und im mittleren VRAM-Bedarf von 48 bis 128 GB scheint es derzeit wirklich keinen echten Sweet Spot beim Preis-Leistungs-Verhältnis zu geben. Die Optionen sind ungefähr drei: mehrere Datacenter-GPUs von vor drei Generationen (Tesla V100, Instinct MI60), mehrere aktuelle Einstiegsprodukte mit viel VRAM (Arc Pro B70) oder aktuelle All-in-one-Boxen (DGX Spark, Mac Mini, Strix Halo)
      Für jemanden, der von einer einzelnen 32-GB-Consumer-GPU oder zwei 16-GB-Karten aufrüstet, hat jede dieser Optionen ihre Kompromisse, aber auch Vorteile. Wenn man allerdings bereits zwei 48-GB-Karten nutzt, bin ich mir nicht sicher, ob es überhaupt ein Upgrade mit gebrauchter Hardware gibt, das sich spürbar wie eine Verbesserung anfühlt