Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Du hast wahrscheinlich schon mal ein YouTube-Video gesehen, den Befehl zur Installation eines Modells ins Terminal kopiert und plötzlich fror der Bildschirm ein. Der Grund, warum lokale LLMs auf älteren MacBooks oder Einsteiger-Laptops mit 8 GB oder 16 GB RAM abstürzen, sind nicht zu wenige Rechenkerne. Der eigentliche Grund ist, dass die Laufzeitumgebung versucht, Daten zu lesen, die das Limit bei extrem schmaler Speicherbandbreite übersteigen. Wenn du die Bandbreite deines Geräts misst und nur die Kontextgröße anpasst, kannst du Code-Assistenzmodelle sogar auf älterer Hardware problemlos nutzen.
Neuere macOS- und Ubuntu-Versionen hindern dich daran, Pakete willkürlich im System-Python zu installieren. Sobald du pip install eingibst, bricht der Prozess mit einem PEP 668-Fehler (error: externally-managed-environment) ab. Wenn du aus Bequemlichkeit das Flag zum Aufheben des Systemschutzes (--break-system-packages) verwendest, riskierst du, dass die grundlegenden Betriebssystem-Tools durcheinandergeraten und du das System neu aufsetzen musst. Verwende stattdessen pipx, das isolierte virtuelle Umgebungen unterstützt, um das Diagnosetool zu installieren.
Das von Alex Jones entwickelte Open-Source-Diagnosetool llmfit wird in einer isolierten Umgebung bereitgestellt, um deine Hardware-Spezifikationen zu ermitteln.
`bash
brew install pipx
pipx ensurepath
pipx install llmfit
mkdir -p ~/local-ai-workspace/{configs,logs,scripts}
llmfit --json system > ~/local-ai-workspace/logs/system_specs.json
`
Wenn du diesen Prozess im Terminal abschließt, werden die RAM-Kapazität und Informationen zum Speicherbus deines Geräts innerhalb einer Minute in der Datei system_specs.json übersichtlich gespeichert, ohne die Systembibliotheken zu beeinträchtigen.
Der Prozess, bei dem ein lokales Sprachmodell Text ausgibt, ist eine sequenzielle Aufgabe, bei der das nächste Zeichen anhand der zuvor ausgegebenen Token vorhergesagt wird. In jedem Schritt müssen die Milliarden Gewichtungen des Modells komplett aus dem Speicherbus gelesen werden. Mit anderen Worten: Die gefühlte Geschwindigkeit wird nicht durch den GPU-Takt, sondern durch die Speicherbandbreite bestimmt.
Die Token-Ausgabegeschwindigkeit pro Sekunde (TPS) wird nach folgender Formel berechnet:
TPS approx rac{ ext{Memory Bandwidth (GB/s)}}{ ext{Model Weights Size (GB)} + ext{KV Cache per Step (GB)}} imes etaDas in der Formel ist die effektive Bandbreiteneffizienz (MBU) der Laufzeitumgebung und liegt normalerweise bei etwa 0,65.
Wenn du ein 4-Bit-quantisiertes 7B-Modell (ca. 4,5 GB) vollständig in einen normalen DDR4-Desktop-RAM mit einer Bandbreite von rund 45 GB/s lädst, verbleibt die Rechengeschwindigkeit bei . Der Text erscheint zeichenweise stotternd, was die Nutzung als Assistenz im Alltag frustrierend macht. Lädst du es hingegen auf ein RTX 4060 8GB-Modell mit einer Bandbreite von 288 GB/s oder einen M-Series Unified Memory mit über 100 GB/s Bandbreite, erreichst du 35 bis 40 Token pro Sekunde, was die Echtzeit-Tippgeschwindigkeit locker übertrifft.
Nachdem du die Spezifikationen deines Geräts überprüft hast, teilen sich die infrage kommenden Modelle in genau zwei Typen auf:
Qwen2.5-Coder-7B-Instruct (Q4_K_M). Auf einem MacBook mit 16 GB Unified Memory oder einer externen Grafikkarte mit 8 GB VRAM werden über 35 TPS erreicht.Llama-3.2-3B-Instruct (Q4_K_M). Selbst in einer DDR4-Umgebung auf leistungsschwachen Laptops benötigt es weniger RAM und liefert konstant etwa 15 TPS.Selbst wenn du das Modell erfolgreich startest, schaltet sich der Prozess nach ein paar Fragen und Antworten im Hintergrund ab. Ein im Terminal ausgegebener Exit Code 137 bedeutet, dass der Speicherverwaltung-Kernel des Betriebssystems (Linux OOM-Killer oder macOS JetSam) den Prozess aufgrund von RAM-Mangel gewaltsam beendet hat (SIGKILL).
Bei der Verwendung von dedizierten GPUs tritt ein noch tückischeres Phänomen auf: der Silent CPU Fallback. Wenn die VRAM-Grenze überschritten wird, stürzt der Prozess zwar nicht ab, aber ein Teil der Rechenschichten wird auf den extrem langsamen System-RAM ausgelagert. Dabei bricht die GPU-Auslastung ein und die Geschwindigkeit kriecht auf etwa 1 Token pro Sekunde herunter.
Der Übeltäter ist der KV-Cache (Key-Value), der mit längeren Unterhaltungen immer mehr RAM verschlingt. Lässt man den Kontext basierend auf der Llama-3-Architektur bis zu 32.768 (32K) Token offen, kommen zu den 4,5 GB Modellgewicht noch einmal 4,0 GB allein für den Cache hinzu. Auf einem 8GB-Gerät führt das unweigerlich zum Absturz. Wenn du diese Länge auf 4.096 (4K) Token begrenzen, schrumpft die Cache-Größe auf 512 MB, sodass es auch in einer 8GB-Umgebung nicht zu Fehlern kommt.
Hier sind die Schritte, um den aktuellen Status zu überprüfen und das Limit festzulegen.
Gib zunächst ollama ps im Terminal ein. Wenn unter dem Punkt PROCESSOR nicht 100% GPU, sondern eine Aufteilung wie 30%/70% CPU/GPU angezeigt wird, ist das VRAM bereits voll und das Modell wurde in den langsamen RAM ausgelagert.
Erstelle eine Konfigurationsdatei, um die Kontextgröße festzulegen. Öffne ~/local-ai-workspace/configs/Modelfile.coder und füge den folgenden Inhalt ein:
`dockerfile
FROM qwen2.5-coder:7b
PARAMETER num_ctx 4096
PARAMETER temperature 0.2
`
Erstelle das benutzerdefinierte Modell im Terminal:
`bash
ollama create custom-coder:7b -f ~/local-ai-workspace/configs/Modelfile.coder
`
Nach Abschluss des Build-Vorgangs gibst du unter macOS sudo purge in das Terminal ein, um den Festplattencache zu leeren. Unter Windows bereinigst du ungenutzte WSL-Instanzen mit wsl --shutdown, um mindestens 2 GB oder mehr an verfügbarem Standardspeicher freizugeben.
Damit unternehmenseigene Quellcodes oder persönliche Projekte nicht nach außen gelangen, wird der Modell-Serving-Endpunkt ausschließlich an das lokale Loopback (127.0.0.1) gebunden.
Erstelle die Datei ~/local-ai-workspace/scripts/serve_secure.sh und füge folgenden Code ein:
`bash
#!/bin/bash
export OLLAMA_HOST="127.0.0.1:11434"
export OLLAMA_ORIGINS="http://127.0.0.1:*,http://localhost:*"
ollama serve > ~/local-ai-workspace/logs/ollama_runtime.log 2>&1 &
`
Nach dem Ausführen des Skripts gibst du lsof -i :11434 | grep LISTEN in das Terminal ein, um zu überprüfen, ob die Empfangsadresse als 127.0.0.1:11434 angezeigt wird. Falls 0.0.0.0:11434 zu sehen ist, worüber auch externe Zugriffe möglich wären, musst du den Prozess umgehend stoppen.
Für die Integration wird das VS-Code-Plugin Continue.dev verwendet. Öffne die Konfigurationsdatei (~/.continue/config.json), um zwischen dem Chat-Modell und dem Autovervollständigungs-Modell zu unterscheiden.
`json
{
"models": [
{
"title": "Local Qwen2.5-Coder (Chat)",
"provider": "ollama",
"model": "custom-coder:7b",
"apiBase": "http://127.0.0.1:11434"
},
{
"title": "Local Llama3.2 (Summary)",
"provider": "ollama",
"model": "llama3.2:3b",
"apiBase": "http://127.0.0.1:11434"
}
],
"tabAutocompleteModel": {
"title": "Local Autocomplete",
"provider": "ollama",
"model": "qwen2.5-coder:1.5b",
"apiBase": "http://127.0.0.1:11434"
},
"allowAnonymousTelemetry": false
}
`
Dem Frage-Antwort-Bereich wird das 7B-Modell mit dem zuvor begrenzten Kontext zugewiesen, während für die Tab-Autovervollständigung das 1-GB-Leichtgewichtsmodell qwen2.5-coder:1.5b festgelegt wird. Dadurch verschwinden Verzögerungen bei der Autovervollständigung.
Die Überprüfung erfolgt bei getrennter Internetverbindung. Schalte das Wi-Fi aus, öffne das Terminal im Offline-Zustand und sende eine direkte Testanfrage:
`bash
curl -s -X POST http://127.0.0.1:11434/api/generate -d '{
"model": "llama3.2:3b",
"prompt": "Lokaler Test im isolierten Netzwerk",
"stream": false
}' | grep "response"
`
Wenn bei unterbrochener Verbindung eine ordnungsgemäße JSON-Antwort zurückgegeben wird, ist die Einrichtung einer Entwicklungsumgebung, die sicher ausschließlich innerhalb der Ressourcen deines Laptops ohne Abhängigkeit von externen Clouds läuft, erfolgreich abgeschlossen.