- Das Repository bündelt Hardware-Konfigurationen, PCIe-Switch-Setup und Docker-Laufzeitkonfigurationen, um modernste LLMs und Speech-to-Text lokal zu betreiben
- Das Budget von rund 2.000 $ zielt auf eine Konfiguration mit 2× RTX 3090 und 48 GB VRAM ab, um Qwen3.6-27B und lokales STT auf Basis von
whisper-large-v3 auszuführen
- Das Budget von rund 40.000 $ geht von 4× RTX PRO 6000 Blackwell Workstation mit 384 GB VRAM aus, um eine Modellintelligenz zu erreichen, die ziemlich nahe an Claude Opus liegt
- Das reale 4×-RTX-6000-Pro-System kombiniert ein Chassis auf Basis gebrauchter EPYC-/DDR4-Komponenten mit einem c-payne PCIe Gen4 Switch, sodass die P2P-Kommunikation zwischen GPUs innerhalb des Switch-Fabrics statt über den CPU-Root-Complex abgewickelt wird
- Nach Feinabstimmung von BIOS, GRUB, ACS und Power-Limits erreicht P2P 27,5 GB/s unidirektional, 50,4 GB/s bidirektional und 0,37–0,45 µs Latenz und damit Gen4-Leitungsrate
Budgetklassen für lokales LLM-Running
- Diese Konfiguration richtet sich an Nutzer, die lokal Modelle auf modernstem Niveau und Speech-to-Text ausführen möchten
- Das Repository enthält die verwendete Hardware, die Gründe für die Auswahl, Setup-Tipps, die lokale STT-Ausführung und containerbasierte Modell-Run-Konfigurationen
- Es gibt den Hinweis, dass mit Ausnahme der Tabelle in der README nichts per KI geschrieben wurde
-
Konfiguration für etwa 2.000 $
- Vorgeschlagen wird eine Konfiguration mit 2× RTX 3090 und insgesamt 48 GB VRAM
- In dieser Konfiguration lässt sich Qwen3.6-27B ausführen
- Für lokales STT wird whisper-large-v3 verwendet, mit dem plattformübergreifenden
stt-Harness für den Zugriff
./runners/stt enthält eine sofort nutzbare STT-Konfiguration, die von nur rund 11 GB VRAM auf einer Nvidia-GPU ausgeht- Lokales STT wird als Werkzeug behandelt, das sich komfortabler nutzen lässt als Hosting-Dienste
-
Konfiguration für etwa 40.000 $
- Ausgegangen wird von einer Konfiguration mit 4× RTX 6000 Pro und insgesamt 384 GB VRAM
- In dieser Preisklasse wird das als Schritt zu einer Modellintelligenz beschrieben, die ziemlich nah an Claude Opus liegt
- Als derzeit bestes Modell für 4× RTX6kPRO per Stand 2026-07 wird
GLM-5.2-Int8Mix-NVFP4-REAP-594B genannt
- Die Laufzeitkonfiguration befindet sich in
runners/GLM-5.2-594B
- Als anderer Ansatz wird auch erwähnt, 4× DGX-Spark-Cluster zu koppeln, um 512 GB VRAM zu erhalten, und Qwen3.7-27B als langsames großes Gehirn wiederkehrende Aufgaben schnell abarbeiten zu lassen
Reale Hardware für 4× RTX 6000 Pro
- Das reale System basiert auf 4× RTX PRO 6000 Blackwell Workstation
- Die GPUs haben jeweils 96 GB, insgesamt 384 GB VRAM, bei Kosten von rund 46.000 $
- Das Grundsystem nutzt EPYC-Hardware der vorherigen Generation und DDR4-Komponenten von eBay, um die Basis-Systemkosten zu senken und das Budget auf VRAM zu konzentrieren
- Da PCIe5-/DDR5-basierte Systeme per Juli 2026 sehr teuer sind, fiel die Wahl auf einen PCIe-Gen4-Switch und ein DDR4-basiertes Grundsystem
-
Grundlegende System-BOM
- Das Basissystem besteht größtenteils aus EPYC-Komponenten der vorherigen Generation, die überwiegend über eBay beschafft wurden
- Die wichtigsten Teile und Preise sind wie folgt
- ASRock Rack ROMED8-2T Mainboard: 715 $
- AMD EPYC Milan 7313P 16-Core 3,0 GHz CPU: 504 $
- 8× 16 GB Crucial DDR4 ECC RDIMM, insgesamt 128 GB RAM: 642 $
- 2× Super Flower 1700W PSU: 750 $
- c-payne Microchip Switchtec PM40100 Gen4 PCIe Switch: rund 1.330 $
- 4-TB-Boot-NVMe: 291 $
- 2× 8-TB-NVMe für Modellgewichte: 1.200 $
- Die Summe für das Grundsystem beträgt 5.587 $
-
PCIe-Gen4-Switch
- Mit dem PCIe4-Switch von c-payne wird die Kommunikation zwischen den GPUs nahezu direkt abgewickelt
- In der Allreduce-Phase der Tensor-Parallelisierung bewegen sich Daten zwischen den GPUs innerhalb des Switch-Fabrics, ohne den PCI-Root-Complex zu durchlaufen
- Die Sub-BOM des Switches liegt bei rund 1.220 €, etwa 1.330 USD
- Microchip Switchtec PM40100-basierter PCIe Gen4 5× x16 Switch
- SlimSAS PCIe Gen4 Host Adapter x16
- Zwei SlimSAS-SFF-8654-8i-Kabel
- Ein Holzgehäuse für GPU und PCI-Switch wurde selbst gebaut, was etwa einen Tag dauerte
- Der eingebaute Lüfter des PCI-Switches war extrem laut und wirkte nutzlos, daher wurde er vom Board entfernt
Speicherung der Modellgewichte und Ausführungsweise
- Alle Modellgewichte werden lokal auf einem über zwei 8-TB-Laufwerke replizierten ZFS-Dateisystem gespeichert
- Das Dateisystem ist unter
~/storage eingehängt
- Das auszuführende Modell wird zunächst mit folgendem Befehl lokal heruntergeladen
hf download <model-name> --local-dir ~/storage/<model-name>
- Jedes Modell läuft in einem eigenen Docker-Container mit eigener
docker-compose.yml in einem separaten Verzeichnis
- Die Laufzeitkonfigurationen liegen unter
./runners/
- Jeder Container mountet
~/storage/models schreibgeschützt, um auf die zwischengespeicherten Gewichte zuzugreifen
- Wenn das Modell unter
http://clank.j.co:5000 bereitgestellt wird, erfolgt der Zugriff über opencode, das in einer VM auf einer anderen Maschine gehostet wird
- Ein interner DNS-Server mappt
clank.j.co auf die LLM-Maschine, möglich ist aber auch http://<llm-machine-ip>:5000
Agent-Harness und Tooling
- In einer separaten VM wird eine Anwendung genutzt, die für jedes Verzeichnis im Baum
~/src eine tmux-Session anlegt und in jeder Session eine opencode-Instanz startet
- Jede
opencode-Instanz verwendet als Backend die HTTP-API der Inferenzmaschine unter http://clank.j.co:5000
- Der Schlüssel für den produktiven Einsatz von Open-Source-Modellen wird als Tooling-Konfiguration beschrieben
- Die Zusammenfassung in
skills/ umfasst folgende Werkzeuge
- camofox, einen kagi.com-API-Key sowie Web-Browsing und Suche über searXNG
- Kommunikation und Benachrichtigungen per Telegram-Bot
- Eine lokale private Gitea-Instanz für die Zusammenarbeit am Quellcode
- Mit dem Agenten kann interaktiv in einer Session zusammengearbeitet werden, oder er kann Issues in Gitea bearbeiten und PRs einreichen
- Das läuft innerhalb einer Sandbox-VM, und die Kommunikation mit dem Host erfolgt nur über gemountete Shared-Filesysteme
PCIe-Switch und Multi-GPU-Setup
-
BIOS-Einstellungen
- Auf dem ROMED8-2T-Mainboard wurden die BIOS-Einstellungen angepasst, damit die Geschwindigkeit des PCI-Switches nicht absinkt
AMD PCIE Link Width wird für den Switch-Slot auf x16 gesetzt- Die frühere x8/x8-Bifurkation teilt den Slot auf, sodass der Upstream-Link nur als Gen4 x8 trainiert wird
- Beide SlimSAS-8i-Kabel müssen angeschlossen sein; jedes Kabel übernimmt x8
- Die PCIe-Link-Geschwindigkeit wird auf Gen4 erzwungen
- Wenn Blackwell-Gen5-Geräte über den Gen4-Switch automatisch aushandeln, kann das Training fehlschlagen und auf Gen1 zurückfallen
- ASPM wird auf Disabled gesetzt
- ASPM L1 senkt inaktive Links auf 2,5 GT/s ab
- Das war der Grund, warum
lspci eine Herabstufung auf Gen1 anzeigte, obwohl unter Last Gen4 genutzt wurde
- Re-Size BAR wird auf Enabled gesetzt
- Das ist für die vollständige 96-GB-VRAM-BAR-Exposition und GPU-P2P erforderlich
- SR-IOV wird auf Disabled gesetzt
- Diese Einstellung dient dazu, IOMMU-Overhead und P2P-Störungen in einer Bare-Metal-Inferenzumgebung zu vermeiden
- Preferred IO bleibt auf Auto
- Eine manuelle Zuordnung des c-payne-Switch-Busses
81 könnte die Latenz leicht verbessern, ist aber eine Optimierung statt einer Korrektur, und Bus-Nummern können sich nach BIOS-Änderungen ändern
-
Redriver und Kabel
- Auf Empfehlung von c-payne wurde der Redriver-Gain mit dem c-payne-Tool auf
lvl 3 abgesenkt
- Die Gain-Stufe hängt von der Kabellänge der SAS-Steckverbinder ab
- Da bei c-payne zu wenige Kabel bestellt wurden, wurden bei Amazon ähnlich aussehende SAS-Kabel gekauft; kleine Unterschiede führten jedoch zu Problemen, sodass erneut bestellt werden musste
Kernel, ACS und Power-Limits
-
GRUB und NVIDIA UVM
- In
/etc/default/grub wurden folgende Kernel-Parameter gesetzt
GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
sudo update-grub
- Ohne
iommu=off bleibt NCCL bei Multi-GPU-P2P hängen
- Für einen NVIDIA-UVM-P2P-Fix wurde folgende Konfiguration angewendet
echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
sudo update-initramfs -u
-
ACS deaktivieren
- Wenn ACS standardmäßig aktiviert ist, bleibt P2P-Traffic nicht innerhalb des Switch-Fabrics, sondern läuft über den CPU-Root-Port
- In diesem Zustand verpufft der Nutzen des PCIe-Switches
- Da
pcie_acs_override einen gepatchten Kernel erfordert, wird ACS zur Laufzeit per setpci deaktiviert
- Beim Booten führt ein systemd-Oneshot-Service
/usr/local/bin/disable-acs.sh aus
- Die Verifikation erfolgt wie folgt
- In
lspci -vvv | grep ACSCtl sollten überall Minuszeichen erscheinen
- In
nvidia-smi topo -m sollte zwischen allen vier GPUs PIX stehen, nicht PHB oder NODE
- Mit
./tools/measure-gpu-speed.sh lassen sich P2P-Bandbreite und Latenz einfach messen
-
GPU-Power-Limit
- Um die Installation eines 220-V-Stromkreises zu vermeiden, läuft das System an einem einzelnen 110-V-Stromkreis, wobei die GPU-Leistung begrenzt wird
- Per systemd werden beim Booten der Persistence Mode und das Power-Limit gesetzt
sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 350
- Das GPU-Power-Limit liegt bei 350 W pro GPU, der Standardwert bei 600 W
- 4×350 W ergeben 1.400 W GPU-Last und passen damit ins PSU-Budget
- In der Phase mit nur einem 1700-W-PSU vor dem Umstieg auf 240 V liefen die GPUs bei rund 260 W
- 4×260 W = 1.040 W GPU
- Hinzu kommen rund 280 W für das System, also insgesamt etwa 1.320 W
- Die Verifikation erfolgt mit
nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv
Messergebnisse und Referenzen
- Der CPU-seitige Upstream ist Gen4 x16 und erreicht rund 30 GB/s
- P2P über den Switch erreicht 27,5 GB/s unidirektional und 50,4 GB/s bidirektional
- Die Latenz liegt bei 0,37–0,45 µs und damit auf Gen4-Leitungsrateniveau
- Wenn ASPM irgendwo aktiv ist, kann
lspci einen inaktiven Downstream-GPU-Link als 2.5GT/s (downgraded) anzeigen
- Diese Anzeige ist kosmetisch; unter Last trainiert der Link wieder auf Gen4 hoch
-
Resources
- local-inference-lab/rtx6kpro: häufig aktualisiertes Repository zur Nutzung von RTX-6000-Pro-Karten mit 4, 6 oder 8 GPUs
- c-payne: der in diesem Setup verwendete Indie-PCI-Switch
- RTX6kPRO Discord: Discord-Server für RTX6kPRO-Benchmarks und Tests neuer Modelle
1 Kommentare
Hacker-News-Meinungen
Ich habe viele lokale LLMs ausprobiert und auch übermäßig viel Geld in Hardware gesteckt; man sollte die Erwartungen senken und die Details genau lesen.
Der große Build im Artikel beginnt zwar mit einem Budget von 40.000 US-Dollar, enthält aber vier GPUs zu je 12.000 US-Dollar, sodass er real eher bei 50.000 bis 55.000 US-Dollar liegt.
Lokale Setups verlassen sich häufig auf Techniken wie Quantisierung oder REAP, um das Modell an die Hardware anzupassen. Oft wird behauptet, 4-Bit-Quantisierung sei verlustfrei, aber das stammt aus KL-Divergenz-Messungen auf kleinen Korpora; bei Coding-Aufgaben mit langem Kontext ist der Qualitätsverlust deutlich sichtbar. Selbst bei Nicht-Coding-Aufgaben wie Dataset-Analysen lassen sich Qualitätsunterschiede zwischen 4-Bit-, 8-Bit-Quantisierung und manchmal dem 16-Bit-Original recht gut messen.
Der Beitrag empfiehlt auch die Nutzung von REAP-Modellen, was bedeutet, dass jemand bestimmte Gewichte entfernt hat, um das Modell kleiner zu machen. Die Idee ist, Gewichte zu entfernen, die für bestimmte Aufgaben weniger nützlich sind, aber die Gesamtqualität der Ausgabe sinkt dadurch erneut.
Die Falle ist: Wenn Leute sagen, sie ließen „GLM-5.2 lokal laufen“, sieht das mit Blick auf die Benchmarks beeindruckend aus, tatsächlich läuft aber nicht GLM-5.2, sondern ein abgeleitetes Modell, bei dem die meisten Bits verworfen und einige Experten entfernt wurden. Bei sehr kleinen Aufgaben oder im Chat sieht man den Unterschied zwischen quantisierten/REAP-Modellen und dem Original kaum, aber bei längeren Arbeiten, bei denen sich kleine Fehler aufsummieren, wird der Unterschied schmerzhaft.
Und weil man dann schon 50.000 US-Dollar ausgegeben hat, gerät man auf eine schiefe Ebene: Um die Qualität noch etwas zu erhöhen und die Investition lohnender zu machen, müsse man ja nur noch ein oder zwei GPUs à 12.000 US-Dollar dazukaufen.
Für Coding-Aufgaben muss man die Session auf mehrere Aufrufe aufteilen. Ich habe https://github.com/aka-rider/orqestra gebaut, aber mit heutigen Tool-Ausführungsumgebungen kann man etwas Ähnliches fast überall selbst machen.
Der Kern ist, eine eigene Session dafür zu haben, Code zu lesen und Tools aufzurufen, wobei Kontext verbraucht wird, und daraus einen Markdown-Bericht zu erstellen nach dem Muster „hier sind der relevante Code und die Dokumente, und das sind die Belege“, um Halluzinationen zu reduzieren. Die Planungssession ist separat; weil kleine Modelle Details überspringen, lässt man Kritiker und Architekt 1–3 Runden hin und her gehen, und aus demselben Grund auch Worker und Prüfer.
Qwen3.6 kann im Read-only-Modus stundenlang nach komplexen Bugs suchen und findet sie meistens. Die vorgeschlagenen Fixes sind vermutlich hacky, aber bei Sonnet ist es genauso.
Qwen3.6 kann mechanisch Code nach einem von Opus erstellten Plan schreiben. Danach muss man mit Prompts wie „Überprüfe deine Änderungen selbst. Gibt es Bugs? Vergleiche mit dem ursprünglichen Plan: Fehlt etwas? Gibt es Verstöße gegen CLAUDE.md?“ nachhaken. Das muss man bei Sonnet allerdings genauso tun.
Lokale LLMs nutze ich auch zum Re-Indexieren einer Knowledge Base. Beim Ticket-Triaging reicht es, rohe Notizen wie „ein einzelnes Panel fürs Rendern von Fehlern, alle Fehlermeldungen verschieben“ zu hinterlassen, und man bekommt eine zu etwa 90 % fertige Spezifikation mit Ziel und Kontext zurück.
Für kleine Aufgaben ist es wirklich gut, aber als ich ihm die erste größere Aufgabe gab, vergaß es, was seine Agent-Ausführungsumgebung war, und begann, Tool-Aufrufe im falschen Format zu schreiben. Es lief auf einem Pi, glaubte aber selbst, in Claude zu laufen, und versuchte, nicht existierende Claude-Tools aufzurufen.
Es schreibt nicht im Alleingang eine komplette Anwendung, aber es hat ein lästiges Netzwerkproblem in meinem tailnet gelöst, für das mir weder Zeit noch Motivation zur eigenen Analyse fehlten, und ich greife nun öfter Aufgaben an, die zwar einfach sind, aber wegen des hohen Rechercheaufwands liegen geblieben wären. Es ist nicht Opus, aber nützlich, und ich muss mir keine Sorgen machen, ob ich den Gegenwert für ein Abo oder API-Kosten heraushole.
Kleine Tools für Natural Language Processing, Sprachsynthese, Bildverarbeitung, Audio-Engineering, Signalverarbeitung oder Diffusion-Plugins für Krita eignen sich sehr gut für lokale Setups. Vor ein paar Tagen habe ich dazu auch einen kurzen Beitrag geschrieben[1].
[1] https://abishekmuthian.com/multiple-20-ai-plans-are-better-t...
Dass „für etwa 40.000 Dollar die Modellintelligenz eine Stufe steigt und ziemlich nah an Claude Opus herankommt“, entspricht bei 200 Dollar pro Monat den Kosten für 16,8 Jahre Nutzung von Claude Opus 4.8 oder Codex GPT 5.5.
Ich mag es wirklich, lokale Modelle auszuführen, aber es ist immer noch absurd teuer, die Qualität ist niedriger, und falls es Backdoors gibt, kann es auch gefährlich sein. Ich wünschte wirklich, es wäre nicht so.
Allerdings ist fraglich, ob lokale Hardware tatsächlich ein API-Nutzungsvolumen im Wert von 4.000 Dollar pro Monat gleichwertig verarbeiten kann. Denn lokale Hardware kann Prompts schwerlich so effizient parallel ausführen wie die mehreren Rechenzentren von Anthropic.
Unternehmen wie OpenAI und Anthropic verkaufen ihre Tarife derzeit noch zu Preisen, die durch Venture Capital subventioniert sind, und dieses Kapital wird irgendwann Rendite verlangen.
Mit OEM spark habe ich im ersten Monat 1 Milliarde Tokens verbraucht, was nach Opus-Preisen mehr als 1.000 Dollar wären. Wegen unterschiedlicher Token-Muster ist das kein fairer Vergleich, aber seither ist die Geschwindigkeit durch vLLM-Verbesserungen, vor allem dank MTP, ebenfalls um das 2- bis 3-Fache gestiegen. DiffusionGemma ist etwa 4-mal schneller als normales Gemma.
Man besitzt ja auch keine Glasfaserleitung; warum also noch einen schnell an Wert verlierenden, teuren und lästigen Vermögenswert besitzen wollen?
Wenn man Cloud-GPUs mietet, kann man an Ownership-Kultur, Datenkontrolle, Preiskontrolle und Hacker-Kultur teilhaben, ohne eine riesige Frankenstein-Kiste als Hobbyprojekt zu bauen. Diese Kiste ist teuer, durch Destillation praktisch weniger nützlich und auch in der Wartung ein Ärgernis.
Es heißt zwar „für 40.000 Dollar fast Opus“, aber wenn GLM 5.2 „fast Opus“ ist, braucht man für angenehme Inferenz mindestens 8xH200, also eher 400.000 Dollar als 40.000 Dollar.
Im Artikel wird vorgeschlagen, ein modifiziertes Modell zu verwenden: „GLM-5.2, mit REAP beschnitten, sodass etwa 22 % der Experten entfernt wurden, und mit Int8-mix NVFP4 quantisiert, etwa 594B Parameter“.
Ich frage mich, wie es außerhalb von Benchmarks tatsächlich funktioniert. Auch Qwen3.6 gerät bei 6-Bit-Quantisierung während der Inferenz häufig in Schleifen, und hier wurden sogar noch einige Experten entfernt. Manchmal kann ein kleineres Modell mit 8 oder 16 Bit klüger sein als ein großes Modell mit lobotomisierten Teilen. Für Coding scheint der Konsens zu sein, nicht unter 8 Bit zu gehen.
Außerdem ist unklar, wie viel nutzbarer Kontext übrig bleibt, wenn man das lobotomisierte Modell auf 4 RTX 6000 unterbringt. Unter 100k ist es oft kaum nutzbar, weil man in die Kompression läuft, bevor man den nötigen Kontext gesammelt hat. Im Repository nachgesehen: Der Kontext lag bei 240k.
Ich würde gern wissen, ob es gar nicht startet oder nur so langsam ist, dass es unbrauchbar wird. Ich möchte lokal Build und Konzepte eines Spitzenmodells validieren und dann in 18 bis 24 Monaten den Rest auffüllen, wenn die GPU-Preise deutlich gefallen sind.
Bedeutet das, dass man Hunderte Prompts gleichzeitig ausführen kann?
Das ist in llamacpp enthalten. Die Person, die heretic gebaut hat, hat auch moderne Strategien zur Schleifenvermeidung und Diversifizierung entwickelt.
Es gibt keinen praktischen Grund, 8x H200 zu betreiben, außer man will es einfach so. Eine Ausnahme wäre, wenn man regelmäßig viele gleichzeitige Nutzer oder Agents bedienen muss.
Es gibt auch Zwischenlösungen. Wenn man 128GB VRAM bereitstellt, gibt es inzwischen mehrere Optionen, die über eine Unified-Memory-Architektur ungefähr diese Kapazität liefern, und über DwarfStar kann man DeepSeek V4 flash mit guter Geschwindigkeit ausführen.
Ich würde dafür kein Geld ausgeben, aber für viele Leute dürfte das ein guter Kompromiss sein.
Allerdings muss man Pi verwenden. claude code hat so viel Bootstrap-Kontext, dass alles deutlich langsamer wird.
Es heißt zwar: „Mit zwei RTX 3090 und insgesamt 48 GB VRAM kann man Qwen3.6-27B laufen lassen, und es ist ein hervorragendes Modell“, aber für 3.000 Dollar bekommt man auch ein M5 MacBook Pro mit 48 GB Shared Memory, und das ist keine riesige Kiste.
Oder man könnte überlegen, das Geld bei einem Cloud-Hosting-Anbieter auszugeben. Zumindest bis zu einem gewissen Grad könnte das, vielleicht sogar deutlich, günstiger sein. Natürlich ist es cool, ein Modell lokal ausführen zu können.
Erst nachdem ich einmal etwas Brauchbares wie Gemma 4 31B und Qwen 3.6 27B ausprobiert hatte, wurde mir klar, wie nützlich das ist.
Man hört auf, sich Sorgen zu machen, dass man sensible Informationen teilt, man macht sich keine Gedanken mehr darüber, ob die Tokens ausgehen, und man sorgt sich auch nicht um die Verfügbarkeit einer Remote-KI. Lokale LLMs sind sehr wertvoll.
Zwei 3090 kommen zusammen auf 1,87 TB/s, also 0,936 TB/s pro Karte, während ein M5 MacBook Pro nur 0,3 TB/s hat. Der Max-Chip schafft bis zu 0,63 TB/s, aber diese Konfiguration ist eine Maschine für 10.000 Dollar.
Deshalb läuft Qwen 27B auf zwei 3090 für echte Arbeit ausreichend schnell, fühlt sich auf einem MacBook Pro aber quälend langsam an. Außerdem ruckelt die UI, wenn man auf dem MacBook Pro große Modelle laufen lässt, und die Tastatur wird heiß. Es ist viel besser, zwei 3090 im Keller stehen zu haben und vom MacBook aus darauf zuzugreifen.
Es geht nicht nur um die Token-Generierungsrate, sondern auch um die Zeit bis zum ersten Token, also die Prompt-Verarbeitungszeit. Die M5-Hardware ist für sich genommen großartig, aber GPUs sind immer noch deutlich schneller.
Wenn das Modell auf der GPU-Box läuft, hat das außerdem den Vorteil, dass man den Laptop auf dem Schoß benutzen kann, ohne ihn in eine heiße Platte zu verwandeln.
Daher werden sowohl der FLOPS-gebundene Prefill als auch das bandbreitengebundene Decoding langsamer sein.
Ich habe diese Woche gerade ein lokales LLM aufgebaut, daher kann ich meine Erfahrung beitragen. Ich habe mich für eine 32-GB-Karte namens Arc B70 von Intel entschieden; sie ist günstiger als eine 3090 und hat mehr RAM, aber der Speicherbus ist langsamer.
Ich habe sie gewählt, weil die Modelle, die ich nutzen wollte, etwas zu groß sind, um bequem in 24 GB zu passen, und weil ich noch Platz für ein paar kleine Modelle für Autocomplete und Spracherkennung brauchte. Außerdem hatte ich bereits einen günstigen Server, und für Dual-GPU hätte ich Mainboard und Netzteil sowie vermutlich auch das Gehäuse tauschen müssen.
Die Einrichtung war ziemlich knifflig. Intels Linie braucht ein Treiberpaket namens „level zero“, um SYCL zu unterstützen, grob gesagt Intels Variante von CUDA, und es war schwierig, das richtig zum Laufen zu bringen. Ich lasse llama.cpp in einem Docker-Container laufen, und es war auch etwas Arbeit nötig, damit der Container die Karte sieht. Außerdem braucht man einen Kernel aus den letzten Monaten.
Sobald es lief, waren die Ergebnisse für eine Investition von 1.000 Dollar sehr beeindruckend. Qwen 3.6 35B in q4-Quantisierung nutzt etwa 3/4 des RAMs und kommt auf ungefähr 88 Tokens/Sekunde. Wenn man günstig ein Modell brauchbarer Größe will, ist das ein Weg.
Die B70 hat einen 256-Bit-Bus mit 2375 MHz und 608 GB/s, die 3090 einen 384-Bit-Bus mit 2438 MHz und 936 GB/s. Sie ist nicht langsamer, sondern hat weniger Kanäle, also eine geringere Breite.
qwen3.6-27b kann man in der q4-Variante auf einer 3090 sogar mit insgesamt etwa 250K Kontext laufen lassen.
Es ist schnell genug, um nicht frustrierend zu sein, daher ist der Geschwindigkeitsgewinn durch zwei 3090 für mich nicht wertvoll. Es gäbe auch die Option, q6 auf zwei Karten mit halber Geschwindigkeit und kleinerem Kontext laufen zu lassen, aber da es ohnehin nicht mit den allerneuesten Modellen konkurrieren kann, halte ich bei den aktuellen Preisen eine einzelne Karte für die beste Investition, wenn man nicht bereits zwei 3090 besitzt. Mit einer gut eingerichteten Laufzeitumgebung reicht das für viele Aufgaben aus.
Meiner Erfahrung nach fällt bei dieser Präzision die Genauigkeit beim Abruf aus langem Kontext deutlich ab. Ich kam besser damit zurecht, den KV-Cache auf q8 zu lassen und mit 120k Kontext zu arbeiten.
In dem Zusammenhang frage ich mich, welches derzeit das beste Isolationssystem ist, das man verwenden kann. Ich weiß nicht, ob man bis zu einer vollwertigen, schweren VM gehen muss oder ob etwas Firecracker-Ähnliches ausreicht.
Bei jeder möglichen Option scheint es subtile Fallstricke zu geben, mit denen man sich leicht den Fuß wegschießen kann, sodass man am Ende praktisch gar keine Sicherheit hat. VMs nutzt man, weil man tatsächlich darauf vertrauen kann, dass Sicherheit ein Grundprinzip dieser Technik ist – nicht nach dem Motto: „Wenn man diese 20 Flags setzt und die Augen zusammenkneift, passt es schon.“
Zuerst muss man die Angriffsvektoren modellieren.
rm -rflässt sich durch Schreibbeschränkungen verhindern, undcurl malware.sh | shdadurch, dass Ausführung in beschreibbaren Verzeichnissen eingeschränkt wird (Seatbelt/SELinux). Schon Schreibbeschränkungen für sensible Verzeichnisse dürften die meisten Malware-Arten erheblich entschärfen.Das Abfließen von Zugangsdaten verhindert man, indem man Umgebungsvariablen bereinigt, das Lesen von .ssh, .aws usw. verbietet und das LLM nicht in die Nähe des Betriebssystems lässt.
Ich habe ein kleines Utility für MacOS gebaut: https://github.com/aka-rider/leash, aber es geht auch mit Bash-Skripten.
Wenn man etwas Leichtgewichtiges will, kann man etwas wie bubblewrap[1] verwenden, oder eine microVM wie libkrun[2]; wenn man auch die zugehörigen Tools möchte, kann man bis zu vollwertigem Docker gehen.
[1] https://github.com/containers/bubblewrap
[2] https://github.com/libkrun/libkrun
Ich kann die Unsicherheit nachvollziehen, wie man tatsächlich wissen soll, dass alles fest verriegelt ist.
Persönlich halte ich VMs oder microVMs für den richtigen Weg. Anders als Container sind sie als echte Sicherheitsgrenzen konzipiert. Auch im Vergleich zu bubblewrap kann man dem Agenten das gesamte Dateisystem geben und im YOLO-Modus laufen lassen, während man bei bubblewrap die Verfügbarkeit jedes einzelnen Entwicklungstools bootstrappen und Konfigurationsverzeichnisse, Package-Caches usw. sicher mounten muss – und trotzdem wahrscheinlich ständig auf Berechtigungsfehler stößt. Auch die Isolation ist deutlich schwächer.
Die Unterstützung durch Laufzeitumgebungen ist begrenzt, aber ich halte den Ansatz für ziemlich sinnvoll, den Prozess der Laufzeitumgebung auf dem Host auszuführen und alle Tool-Aufrufe sowie Dateisysteminteraktionen an die VM zu delegieren. Dann kann man Sitzungsdaten und Authentifizierungsschlüssel auf der Hauptmaschine behalten, sodass sie niemals in den Kontext gelangen. Der Kompromiss ist allerdings, dass die Laufzeitumgebung selbst Teil der Sicherheitsgrenze wird.
Auch die Frage, wie man Daten in die VM hinein und wieder heraus bekommt, ist ein Usability-Problem. Ich nutze Skripte, die ein lokales Git-Repository in die VM schieben und es wie von einem Remote wieder zurückholen; dadurch kann die VM keine Verbindung zum Host initiieren und braucht auch keine Git-Zugangsdaten. Für Leute, die wollen, dass der Agent direkt zu GitHub pusht, ist das aber möglicherweise zu viel Aufwand.
Optionen, die ich bei VMs selbst ausprobiert oder gesehen habe, sind qemu + libvirt, crun-vm und die libkrun-Familie. qemu + libvirt erfordert etwas Handarbeit beim Einrichten, ist aber sehr bewährt und stark konfigurierbar. crun-vm ist ein PoC für eine High-Level-Integrationsschicht zwischen podman und qemu; es scheint aufgegeben zu sein, ist aber interessant, weil es auf bestehenden Tools und Standards aufsetzt. libkrun ist ein neuerer Kandidat, mit Wrappern wie microsandbox, smolvm und krunvm. Alles bezogen auf Linux.
Es fühlt sich seltsam an, so viel Aufwand zu treiben, um LLMs zu nutzen. Besonders, wenn man auf diese Weise dem State of the Art hinterherläuft.
Wenn Dinge wie Claude morgen verschwinden würden, würde ich nicht mit der Wimper zucken.
Ich verstehe nicht, warum Menschen ihre Gehirnwindungen gegen Zugang zu Slop-Maschinen eintauschen. Eine passende Analogie wäre vielleicht, einem erfahrenen Tischler eine Maschine zu geben, die Möbel ausspuckt, deren Qualität ein oder zwei Stufen unter Ikea liegt. Erledigt sie die Arbeit? Meistens schon. Hat der Tischler Freude an diesem Prozess? Nein.
Nach meiner Erfahrung habe ich nie ein stark quantisiertes Modell wie q4 oder ein irgendwie verändertes Modell laufen lassen und gedacht: „Wow, das ist wirklich großartig.“ Eher landete es nach ein paar Prompts im Papierkorb.
Ich habe eine RTX 6000 PRO mit 96 GB; bequem laufen darauf etwa Qwen 3.6 27B oder MoE sowie Gemma 4 31B. Wenn ich Modelle mit voller Präzision und maximaler Kontextlänge betreibe, ist das die Grenze.
Diese Modelle sind leistungsfähig und für Coding, Internetrecherche und andere Einsatzzwecke brauchbar. Wenn man nachrechnet und voraussichtlich mehr als 2.400 Dollar pro Jahr bei Anthropic ausgeben würde, kann der Kauf so einer Karte sinnvoll sein, aber man muss Qualitätsverluste akzeptieren. Wobei ohnehin fraglich ist, ob Menschen in fünf Jahren noch programmieren werden.