HN Launch: Virtuelle GPU-Verbindungen über TCP

 (thundercompute.com)
2 Punkte von GN⁺ 2024-08-10 | 1 Kommentare | Auf WhatsApp teilen
  • GPUs sind im Gegensatz zu CPU, Storage, Networking und Arbeitsspeicher noch nicht als reichlich verfügbare Ressource virtualisiert worden; Thunder Compute will dies auf der Systemebene lösen
  • Beim Ausbau des Angebots geht es nicht nur darum, mehr Chips zu produzieren, sondern auch darum, bereits bereitgestellte GPUs durch Software-Nutzung besser auszulasten
  • Während bisherige Optimierungen auf der Workload-Ebene blieben, etwa beim Batching von Inferenz oder beim Queuing von Trainingsjobs, zielt GPU-Virtualisierung auf einen vergleichsweise wenig bearbeiteten Systembereich
  • NVIDIA H100 kann ab 1,38 $ pro Stunde in VS Code, CLI und Browser genutzt werden; hervorgehoben werden 80 % Einsparung gegenüber AWS, keine Verträge, keine Egress-Kosten und skalierbarer Storage
  • Vier Jahre lang wurden im Stealth-Modus Forschungsprototypen entwickelt; über die eigene Cloud und Enterprise-Partner soll eine Verbesserung der GPU-Kapazität in Rechenzentren ausgerollt werden

Niedrige Auslastung durch GPU-Virtualisierung verbessern

  • Thunder Compute ist der Ansicht, dass mehrere knappe Ressourcen im Computing mit der Zeit reichlich verfügbar wurden, GPUs diesen Wandel jedoch noch nicht durchlaufen haben
  • GPUs reichlich verfügbar zu machen, hängt nicht nur von der Produktion weiterer Chips ab, sondern auch von Software, die bereits bereitgestellte Chips besser nutzt
  • Derzeit werden GPUs häufig nicht ausreichend ausgelastet, und bestehende Lösungen konzentrieren sich vor allem auf die Workload-Ebene
    • Inferenzanfragen werden per Batching verarbeitet
    • Trainingsjobs werden über mehrere Server-Flotten hinweg per Queuing organisiert
  • CPU, Storage, Networking und Arbeitsspeicher sind weithin virtualisiert, bei GPUs hat sich Virtualisierung auf vergleichbarem Niveau jedoch noch nicht etabliert
  • Diesen freien Bereich auf Systemebene anzugehen, ist der Kernansatz von Thunder Compute

Produktansatz und Rollout-Plan

  • Thunder Compute ist ein Systemlabor mit kommerziellem Fokus, das aktuelle Forschung zur GPU-Virtualisierung in Produktionsumgebungen anwenden will
  • Das Team beschreibt sich als bestehend aus Infrastruktur-Experten und Systemforschern mit Erfahrung bei Citadel Securities, Aquatic und AWS
  • Vier Jahre lang wurden im Stealth-Modus Forschungsprototypen entwickelt; aktuell werden die Ergebnisse über die eigene Cloud und Enterprise-Partner ausgerollt
  • Laut Produktbeschreibung ist NVIDIA H100 ab 1,38 $ pro Stunde nutzbar
    • Zugriff ist über VS Code, CLI und Browser möglich
    • Hervorgehoben werden 80 % Einsparung gegenüber AWS
    • Keine Verträge, keine Egress-Kosten und skalierbarer Storage werden angeboten
  • Ziel ist es, die GPU-Kapazität in Rechenzentren schrittweise zu verbessern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-10
Hacker-News-Kommentare

  • Ziemlich interessant. Ich brauchte früher einmal GPU-over-IP, allerdings nur für Video-Transcoding
    Mein Homelab-Server hatte eine leistungsschwache AMD-GPU, die jedes Mal den Kernel abstürzen ließ, wenn ich Video-Encoding versuchte, und mein Gaming-PC hatte eine NVIDIA RTX 3080. Also habe ich https://github.com/steelbrain/ffmpeg-over-ip gebaut, den Server auf der Windows-Maschine und den Client auf dem Medienserver (Plex, Emby, Jellyfin usw.) laufen lassen, und es funktionierte perfekt

    • Falls du das noch nie bei Show HN gepostet hast, wäre das vielleicht einen Versuch wert
      https://gist.github.com/tzmartin/88abb7ef63e41e27c2ec9a5ce5d...
      https://news.ycombinator.com/showhn.html
      https://news.ycombinator.com/item?id=22336638
    • Als ich den Titel sah, hatte ich ungefähr so etwas erwartet. Schade, dass die eigentliche Einreichung kein nützliches allgemeines Tool ist, sondern ein kostenpflichtiger Cloud-Service. Wie so oft steckte der eigentliche Inhalt in den Kommentaren
      Ich frage mich auch, ob es abseits von Video-Encoding sinnvolle Einsatzfälle für GPU-over-network gibt. Wenn die Latenz steigt, dürfte das für Machine Learning oder grafikintensive Arbeit doch schwierig werden
    • Interessant. Ich frage mich, ob auch Multi-File-Konvertierungen unterstützt werden, bei denen wie bei HLS mehrere Timeslice-Dateien entstehen

  • Wenn das an der CPU/GPU-Grenze arbeitet, frage ich mich, ob es bei Datensätzen, die nicht in den VRAM passen, nicht zu einem enormen I/O-Flaschenhals kommt
    Vielleicht verstehe ich die Funktionsweise falsch, aber wenn GPU-I/O abgefangen wird, klingt es so, als müsste in jeder Epoche der komplette Datensatz zur Remote-Maschine gestreamt werden, was verschwenderisch wirkt

    • Dieses Verständnis des Systems ist korrekt. Um es praxistauglich zu machen, haben wir verschiedene Optimierungen implementiert, um die I/O-Kosten zu senken
      Die BERT-Inferenzleistung ist hier zu sehen: https://youtu.be/qsOBFQZtsFM?t=69
      Training hat mehr Overhead als Inferenz, und wir arbeiten an weiteren Optimierungen, um näher an native Performance zu kommen

  • Für alle, die neugierig sind, wie das tatsächlich funktioniert: Es sieht so aus, als würde eine Bibliothek in den Prozess injiziert, diese Funktionen[1] hooken und dann an den Service weiterreichen
    [1] https://pastebin.com/raw/kCYmXr5A

    • Ich frage mich, wie herausgefunden wurde, dass diese Funktionen gehookt werden. Ich vermute, es gibt ein ld-/ldd-Flag, das anzeigt, welche Symbole neu gebunden werden
      Außerdem dachte ich, dass Symbole schwach sein müssten, um neu gebunden zu werden. Da NVIDIA kaum schwache Symbole exponieren dürfte, heißt das wohl, dass es praktisch ein LD_PRELOAD-Ansatz ist
    • Ich hatte auf eine magische Methode gehofft, das komplette PCIe-Gerät durchzureichen

  • Interessant, aber mich interessiert eher Self-Hosting. Ich habe bereits viele GPUs, einige laufen und einige stehen ungenutzt herum
    Ich frage mich, ob es eine Self-Hosting-Option gibt, damit man die bereits vorhandenen GPUs nutzen kann

    • Self-Hosting wird derzeit noch nicht unterstützt, aber dieselbe Technologie scheint sehr gut dazu zu passen
      Vorteile wie effizientes Job-Scheduling, GPU-Sharing und einfache Bedienung würden auch in einer Self-Hosting-Umgebung unverändert greifen. Wir sind für diese Möglichkeit in Zukunft definitiv offen
    • Wenn du eigene GPUs hast, egal ob fest installierte Hardware oder Cloud, und etwas mit einem ähnlichen Bediengefühl wie PyTorch möchtest, schau dir https://github.com/run-house/runhouse an
    • Wenn du deine eigenen GPUs oder Cloud-Konten nutzen und trotzdem eine gute Developer Experience haben willst, schau dir SkyPilot an
    • Über Dienste wie Akash Network kann man eigene GPUs in der Cloud vermieten, und auf thundercompute.com kann man GPUs mieten. Das geht fast in Richtung eines Admin-Pfads, der sich wie Self-Hosting betreiben lässt

  • Ich verstehe es nicht ganz. Man kann in ECS doch einfach direkt die gewünschte GPU-Instanz starten. Warum sollte man in ECS eine Instanz starten, um dann eure GPUs von ECS aus zu nutzen?
    Außerdem verstehe ich nicht, warum man statt echtem Nitro ein halbes Nitro wollen sollte

    • Guter Punkt. Es gibt ein paar Vorteile
      Wenn man fortlaufend Entwicklung mit GPU-Bedarf betreibt, zahlt man normalerweise für die gesamte Zeit, in der die Instanz eingeschaltet ist. Mit Thunder zahlt man nur für die Zeit, in der die GPU tatsächlich genutzt wird. Wenn also nur CPU-Code läuft, fallen keine GPU-Zeitkosten an. Die Alternative wäre, Instanzen manuell ein- und auszuschalten, was umständlich sein kann
      Außerdem kann man Typ und Anzahl der verwendeten GPUs leicht skalieren. Wenn du zum Beispiel auf einer günstigen T4-Instanz entwickelst und dann ein komplettes Deep-Learning-Training auf 8 A100s laufen lassen willst, musst du nicht die Instanz wechseln und die Umgebung neu einrichten. Du führst einfach einen Befehl aus und lässt es direkt auf stärkeren GPUs laufen
    • Aus Systemsicht wirkt es transparenter. Wenn man zum Beispiel auf einem Thin Client eine GUI-Anwendung mit GPU-Beschleunigung nutzt (Matlab, SolidWorks, Blender), geht das, ohne ECS einzurichten
      Man kann ohne GPU entwickeln und dann plötzlich eine GPU anhängen, wenn eine Simulation läuft, und es dürfte deutlich günstiger als AWS sein. Im Kern wirkt es so, als würde es das Problem, das Ray(https://www.ray.io/) löst, auf allgemeinere Weise angehen. Noch spannender wäre feineres GPU-Sharing, etwa halbe GPUs

  • Das interessiert mich sehr, deshalb habe ich beschlossen, T4-Instanzen kostenlos freizuschalten. Probiert es gern aus und sagt mir, was ihr davon haltet

    • Ich frage mich, wie die Preise für A100 und H100 aussehen

  • Cool. Ich frage mich, ob ihr es auch mit MIG oder vGPU zum Laufen bringen konntet

    • Wir haben es nicht mit MIG oder vGPU getestet, aber da es im Wesentlichen eine physische Partitionierung der GPU ist, sollte es funktionieren
      Eines der wichtigsten kurzfristigen Ziele ist GPU-Sharing. Dabei sollen Nutzer nicht auf einen Teil des Speichers begrenzt sein, sondern den gesamten GPU-Speicher verwenden können, was besser sein könnte als MIG oder vGPU

  • Ich frage mich, wie es sich bei echter Nutzung mit sinnvoller Auslastung anfühlt. Taugt es auch für Hash-Cracking?
    Immer wenn ich an virtuelle GPUs über das Netzwerk denke, muss ich an Botnets denken. Besonders an diese Stelle hier: https://www.hpcwire.com/2012/12/06/gpu_monster_shreds_passwo... — „Gosney musste zunächst Professor Amnon Barak, Mitbegründer von Mosix, davon überzeugen, dass er nicht ‘die Welt in ein gigantisches Botnet verwandeln’ wollte“

    • Ein interessantes Gedankenexperiment, aber unser System verteilt GPUs in der Praxis nicht über viele Orte, daher ist es eher mit AWS vergleichbar als mit einem Botnet
      Diese Technologie hat interessante Anwendungsmöglichkeiten für den Aufbau sehr flexibler Cluster innerhalb eines Rechenzentrums, und genau das untersuchen wir derzeit

  • Die ursprünglichen SGI-Ingenieure, die glx entwickelt haben, haben sehr sorgfältig darauf geachtet, für GPU-Transfers X11-Mechanismen zu verwenden. Deshalb war es ziemlich einfach, einen GL-Stream übers Netzwerk zu schicken und auf meiner Grafikkarte rendern zu lassen
    Das war so nach dem Motto: „Auf dem Supercomputer am Ende des Flurs ausführen, auf der Workstation rendern.“ Neuere Treiberentwicklung scheint darauf keine Rücksicht mehr zu nehmen, daher ist das heute meist nicht mehr möglich. Ich weiß nicht, wie nützlich es in der Praxis wirklich war. Wenn man eine gute Grafikkarte hatte, hatte man meistens auch eine gute CPU. Trotzdem war es spaßig zum Herumspielen, und es hatte einen seltsamen Reiz, dass ein Programm im Maschinenraum beschleunigte Grafik bekam. Einmal habe ich es sogar geschafft, glquake auf diese Weise laufen zu lassen

  • Dass das überhaupt möglich ist, ist beeindruckend, aber ich frage mich, was passiert, wenn die Netzwerkverbindung abbricht oder nicht zu 100 % stabil ist
    Meiner Erfahrung nach reagieren Treiber schon dann nicht gut, wenn sich die lokale GPU nur ein bisschen merkwürdig verhält