- Fly.io, auf dem Apps in der Nähe der Nutzer ausgeführt werden, bietet jetzt GPU-Unterstützung, sodass sich AI-Inferenz nicht mehr in einer zentralen Region, sondern näher am Edge platzieren lässt
- An Apps kann eine Nvidia A100 angebunden werden, um CUDA und großen VRAM zu nutzen; einsetzbar für Spracherkennung, Textsegmentierung, Artikelzusammenfassungen, Bildgenerierung und das Ausführen von Code-Assistent-Modellen
- GPU-Apps auf Basis von Ollama lassen sich bereitstellen, indem in
fly.toml vm.size = "a100-40gb" und das Image ollama/ollama angegeben werden; anschließend erfolgt das Deployment mit fly apps create und fly deploy
- In Regionen mit GPU-Unterstützung kann dasselbe Programm unter derselben öffentlichen IP und mit demselben TLS-Zertifikat ausgeführt werden; eine Skalierung etwa in die Region Amsterdam ist mit
fly scale count 2 --region ams möglich
- A100 40GB kostet $2.50 pro Stunde, A100 80GB $3.50, L40s $2.50; mit automatischem Starten und Stoppen lässt sich eine GPU-Abrechnung nach Laufzeit vermeiden, wenn keine Anfragen eingehen
GPU-Ausführung nahe bei den Nutzern
- Fly.io ist eine Cloud, auf der Full-Stack-Apps oder auf der Fly Machines API basierende Entwicklungsplattformen in der Nähe der Nutzer ausgeführt werden können; nun kommt GPU-Ausführung hinzu
- Fly.io-GPUs binden eine Nvidia A100 an Apps an, sodass CUDA und mehr VRAM als bei einer lokalen 4090 genutzt werden können
- Geeignete AI/ML-Workloads sind unter anderem
Deployment von Ollama-GPU-Apps
- Fly.io verfolgt das Ziel, dass Nutzer ihre bevorzugten Modelle und selbst geschriebenen Code auf dem Cloud-Backbone von Fly.io bereitstellen
- GPU-Apps auf Basis von Ollama lassen sich allein mit einer
fly.toml-Konfiguration und Deployment-Befehlen starten
app = "sandwich_ai"primary_region = "ord"vm.size = "a100-40gb"- Als Build-Image wird
ollama/ollama verwendet
- Ein
100gb-Volume wird unter /root/.ollama gemountet
- Der Ausführungsbefehl lautet wie folgt
fly apps create sandwich_ai && fly deploy
Inferenz in Regionsnähe
- Der von Fly.io betonte Punkt ist nicht nur das Bereitstellen von GPUs, sondern Edge-Inferenz
- Die Beispiel-App ist so aufgebaut, dass Nutzer Zutaten eingeben, die sie in ihrer Küche haben, und dafür ein Sandwich-Rezept erhalten
- Bei einem Deployment mit
primary_region = "ord" erhalten Nutzer in der Nähe von Chicago ihr Sandwich-Rezept schnell
- Für Nutzer außerhalb Chicagos, etwa in Amsterdam, müssen Anfragen jedoch den Atlantik überqueren, was mehr Zeit kosten kann
- In Regionen mit GPU-Unterstützung kann dasselbe Programm mit derselben öffentlichen IP-Adresse und demselben TLS-Zertifikat ausgeführt werden
- Die Erweiterung nach Amsterdam erfolgt mit folgendem Befehl
fly scale count 2 --region ams
GPUs nur bei Anfragen nutzen
- GPUs sind leistungsstarke Geräte für Parallelverarbeitung, aber nicht günstig; für kleine Apps ist eine Konfiguration vorteilhaft, bei der nur bei Nutzeranfragen Kosten entstehen
- Im Abschnitt
services von fly.toml lassen sich automatisches Starten und automatisches Stoppen konfigurieren
[[services]]
internal_port = 8080
protocol = "tcp"
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0
auto_stop_machines = true und auto_start_machines = true bedeuten, dass Maschinen ohne Anfragen gestoppt und bei Bedarf erneut gestartet werden- Bei
min_machines_running = 0 fallen GPU-Laufzeitkosten nicht an, wenn keine Anfragen für Sandwich-Rezepte eingehen
Verfügbare GPUs und Basisressourcen
- GPUs sind in mehreren US- und EU-Regionen sowie in Sydney verfügbar
- Die verfügbaren Deployment-Ziele und Preise sind wie folgt
- Auf GPUs bereitgestellte Apps nutzen standardmäßig 8 AMD EPYC-CPU-Kerne
- Es können Volumes mit bis zu 500GB angebunden werden
- Auch Rabatte für reservierte Instanzen und Dedicated Hosts sind möglich
1 Kommentare
Meinungen auf Hacker News
Ich frage mich, ob Fly die grundlegenden Funktionen wirklich im Griff hat. Beim Einsatz in echter Produktion war ich enttäuscht: Der Support war nicht einmal in der Lage, interne Plattformprobleme nachzuschlagen, und Fehlermeldungen waren vage oder fehlten komplett.
Für Leute, die Kubernetes scheuen oder nicht gut kennen, mag es attraktiv wirken, aber nachdem ich Fly genutzt habe, vermisse ich Kubernetes eher.
watch -n 2 curllaufen lässt; das passierte mit allen dokumentierten Strategien, einschließlich Blue-Green.Im schlimmsten Fall hätte ich erwartet, dass nur bestehende Verbindungen vorzeitig beendet werden und neue Verbindungen nicht abbrechen; im besten Fall ein sauberes Warten, bis bestehende Verbindungen auslaufen. Tatsächlich war es jedes Mal ein vollständiger Downtime-Switch. Wenn man sich die im Blog gezeigte Netzwerktopologie ansieht, hat man das Gefühl, dass es von Anfang an gar nicht korrekt hätte implementiert werden können.
Ich kommentiere selten negativ über einen Service, aber dass der Support selbst nach einem Video als Beleg so reagierte, als seien wir die Merkwürdigen, war für ein Infrastrukturunternehmen ziemlich störend. Inzwischen würde ich es außer für Spielzeug-Apps nicht mehr empfehlen.
Ich habe auch ein ziemlich großes Deployment-System für Kubernetes gebaut, aber das Problem hier ist nicht, dass ich Kubernetes nicht verstehe. Für ordentliches Deployment im Heroku-Stil gibt es eindeutig Platz, nur macht es offenbar niemand gut, oder die Compute-Ressourcen sind absurd knapp oder teuer.
Ich könnte noch über als managed vermarktete, aber unmanaged DBs, zufällige Downtimes und mehr sprechen, aber es ist kein produktionsreifer Service, deshalb sind wir vor ein paar Monaten gegangen.
Anfangs war ich sehr begeistert von Fly und habe sogar einen kompletten Orchestrator auf Fly Machines gebaut, aber dann gab es einen mehrtägigen Ausfall, und es dauerte ebenfalls Tage, bis wir Antworten bekamen.
Kubernetes kann komplex sein, aber diese Komplexität ist zumindest kontrollierbar und ein bereits vielfach bewährter Weg.
Ich bin der Autor des Beitrags und Developer-Relations-Mitarbeiter bei Fly.io. Wenn es Fragen gibt, kann ich sie beantworten. GPUs sind gestern offiziell gestartet, und wenn die Gottheit der Betrugspräventionsalgorithmen es zulässt, könnt ihr nach Herzenslust experimentieren.
Eher überraschend finde ich, dass ein Erklärartikel dazu, was eine „GPU“ eigentlich ist, hier nicht so gut ankam: https://fly.io/blog/what-are-these-gpus-really/
Werden der Vorteil beim Fertigungsprozess und der bevorzugte Zugriff auf SoC/HBM lange genug anhalten, damit die Software aufholen kann? High-End-Metal-Hardware wirkt teuer, aber im Vergleich zu NVIDIA mit 64 GB+ ziemlich hoher Speicherbandbreite und dedizierten FP-Vektoreinheiten sieht es anders aus.
Wenn man Inference-Workloads mit einer Plattform wie
fly.ioin Geräte hinein und aus ihnen heraus verschieben könnte, würde das Anwendungen mit hohem Edge-Anteil wohl viel Freiheit geben.In einem Workflow zur Segmentierung medizinischer Bilder dauert eine Datei etwa 5 Minuten.
Soweit ich weiß, verwendet Fly Firecracker für VMs. Ich habe Firecracker eine Zeit lang verfolgt und auch in Projekten genutzt; grundsätzlich unterstützt es keine GPUs und es gibt auch keine Pläne dafür [1].
Ich bin neugierig, wie Fly eigene GPU-Unterstützung mit Firecracker gelöst hat. Früher gab es sehr ausführliche technische Artikel dazu, wie bestimmte Funktionen implementiert wurden; schön wäre, wenn später auch ein Beitrag zur GPU-Unterstützung käme.
[1]: https://github.com/firecracker-microvm/firecracker/issues/11...
Dass ihr bis auf 0 herunterskalieren könnt, ist cool. Das ist besonders nützlich für experimentelle Sites mit wenigen Nutzern, bei denen sich selbst die Kosten für einen kleinen Server schwer rechtfertigen lassen.
Ein Beispiel dafür, mit welcher Zeit ein einzelner Request abgerechnet wird, wäre hilfreich. Natürlich wird es variieren, aber ich frage mich, ob es 2 Sekunden sind oder eher „mindestens 60 Sekunden pro Spin-up“.
GPU-Machines brauchen je nach Größe der Daten, die in den GPU-Speicher geladen werden, möglicherweise etwa 30 Sekunden Laufzeit, bis sie wirklich nützlich sind.
Fly.io wurde früh eingeführt, ist aber nicht produktionsreif. Bevor neue Funktionen hinzugefügt werden, sollten erst die Grundfunktionen repariert werden
Die Einrichtung braucht etwas mehr Aufwand und der Preis ist auch deutlich höher, aber in Produktion braucht man Zuverlässigkeit. Man kann nicht riskieren, dass Kunden wegen Ausfällen anrufen
Software kann kaputtgehen, aber Flys Umgang mit Incidents ist unprofessionell und unreif. Im Grunde zahlt man das Zehnfache für einen instabilen Service, der nur „gut“ aussieht
Jetzt nutzen wir Hetzner + Kamal mit deutlich besserer Hardware zu einem Viertel der Kosten; es läuft stabil, die Preise sind vorhersehbar, und wir zahlen im nächsten Monat bei gleicher Nutzung nicht plötzlich 25 % mehr
https://news.ycombinator.com/item?id=36808296
Unabhängig von der GPU-Ankündigung wäre ein S3-Ersatz bei Fly wünschenswert. Aktuell wird ein GNU-Affero-Projekt vorgeschlagen, was aus Unternehmenssicht ein Hindernis ist
Wenn man für die Speicherung von Nutzer-Assets außerhalb von Fly gehen muss, ist es schwer, Fly im nächsten Projekt einzusetzen. Schade, denn Einfachheit, Preis-Leistungs-Verhältnis und das integrierte VPN sind gut
Wird auch hier diskutiert: https://benhoyt.com/writings/flyio-and-tigris/ und hier: https://news.ycombinator.com/item?id=39360870
https://fly.io/docs/reference/tigris/
Wenn man auf einen S3-ähnlichen Service nur über eine HTTPS API zugreift, fällt der eigene Code dadurch nicht unter die AGPL
Ich frage mich, wer der Zielmarkt für diesen Service ist. Sind das kleine, noch nicht validierte Apps, die irgendein KI-Modell ausführen müssen, aber die zahlreichen preisaggressiven Startups für das Hosting von Open-Source-Modellen nicht nutzen oder nicht nutzen können?
Nachdem ich selbst viele Modelle und Hardware betrieben habe, verstehe ich den Wunsch, bis aufs Bare Metal Kontrolle zu haben. Ich würde nur gern wissen, auf wen das abzielt
In der Praxis dauert die Inferenz selbst lange, daher ist der Unterschied vielleicht nicht so entscheidend
Es kann ein großer Vorteil sein, wenn GPU-Compute im selben Rechenzentrum oder zumindest beim selben Cloud-Anbieter liegt. Es war auch nicht ungewöhnlich, dass A100s bei mehreren Anbietern ausverkauft waren; selbst bei großen Anbietern habe ich das mehrfach erlebt. Wenn man nicht an eine bestimmte Region gebunden ist, ist das weniger problematisch
Nicht jeder Anbieter bietet ein brauchbares On-Demand-Modell mit Scale-down auf 0. Ich weiß nicht, wie gut das bei Fly langfristig funktioniert, aber es kann ein weiterer Vorteil sein
Preisaggressive Startups halten tendenziell nicht lange durch; es ist eher ein Modell, bei dem von 100 nur sehr wenige überleben
Wenn man Fly bereits nutzt und nur ein paar private Tech-Demos evaluieren lässt, kann Fly GPU eine naheliegende Standardwahl sein, über die man nicht groß nachdenken muss. Natürlich ist es vielleicht üblicher, Services von Hugging Face zu nutzen
Es gibt auch viele Unternehmen, die aus verschiedenen Gründen keine eigene Hardware betreiben können und bestenfalls Racks in einem anderen Rechenzentrum mieten; für kleine Use Cases lohnt sich das nicht immer. Manchmal braucht man eine A100, lässt sie aber nur selten laufen, etwa für wöchentliche Analysen; bei weniger als einer Stunde pro Woche ist ein preisaggressiver Service womöglich gar nicht besonders attraktiv
Rezeptbeispiele oder generell beliebige LLM-Use-Cases wirken wie sehr schlechte Beispiele, um Edge-Inferenz zu betonen. Ein paar hundert ms zusätzliche Roundtrip-Latenz spielen dabei kaum eine Rolle
Allerdings ist das ein Bereich mit hohem Missbrauchspotenzial, weshalb sich offenbar noch niemand damit einlassen will. Wahrscheinlich geht es im nächsten Artikel darum; dann müsste man einen eigenen Online-GPT im Stil von Perplexity bauen. Im Moment scheint die Einführung absichtlich gewöhnlich gehalten zu sein, um zu sehen, ob andere Ideen auftauchen
Ich frage mich, ob jemand die Performance schon ausprobiert hat. Auf den ersten Blick wirkt es ziemlich teuer, etwa im Vergleich zu Hetzner-CPU-Maschinen.
Sogar eine H100 bekommt man dort mit 2,24 US-Dollar pro Stunde günstiger als zu diesem Preis.
Daher wirkt es etwas teuer, aber das könnte auch daran liegen, dass die Kundennachfrage hoch und das Angebot knapp ist.
Ich nutze den kostenlosen Tarif von Fly.io, um Uptime Kuma für Uptime-Monitoring zu betreiben. Es funktioniert extrem gut, daher bin ich sehr zufrieden.