Vor ein paar Monaten habe ich zwei Wochen lang Gemma 4 vollständig offline auf meinem Pixel 9a benutzt – kein Cloud-Aufruf, kein Login, keine Telemetrie. Ein kleines Experiment mit einer großen Pointe: Lokale KI ist kein Bastelthema mehr, sie ist ein Werkzeug.
Aber ein Handy beantwortet eine Frage. Es tut nichts. Ein 1,5-GB-Modell in der Hosentasche schreibt keine Zeile Python in ein 3D-Programm und liest keine fünf Webseiten, um sie mit Quellen zusammenzufassen. Genau das war die Frage, die mich zum neuen Tuxedo InfinityBook Pro 14 gezogen hat: Nicht „kann ein Laptop offline plaudern”, sondern kann ein normaler Linux-Laptop einen Agenten tragen, der echte Werkzeuge bedient – in andere Programme greift, das lebende Web durchsucht – und das komplett auf dem eigenen Schreibtisch?
Die These dieses Artikels ist deshalb konkret und ein bisschen unbescheiden: Was leistet ein 32-GB-Linux-Laptop ohne dedizierte Grafikkarte praktisch an lokaler, agentischer KI? Das Gerät hat einen AMD Ryzen AI 7 350 mit integrierter Radeon 860M und keine einzige NVIDIA-Karte im Gehäuse. Die kurze Antwort vorweg: mehr, als das Datenblatt vermuten lässt. Zwei Dinge tut es inzwischen wirklich – es steuert Blender per Sprache, und es recherchiert offline im Web, mit Zitaten. Beide Male tool-nutzend, beide Male ohne dass ein Prompt an ein Cloud-Modell geht.
Warum das überhaupt geht: Speicher schlägt Rechenleistung
Der wichtigste Satz für alles Weitere widerspricht dem Marketing: Nicht die Rechenleistung ist der Engpass, sondern der Speicher. Zwei Fragen entscheiden.
Erstens die Kapazität: Passt das Modell hinein? Die Gewichte müssen vollständig im schnellen Speicher liegen, sonst wird in langsamen System-RAM ausgelagert und das Tempo bricht ein. Zweitens die Bandbreite: Jedes einzelne Token muss das gesamte aktive Modell einmal durch den Speicher lesen. Tempo ist also eine Frage der Bandbreite, nicht der TOPS.
Und hier die ehrliche Einordnung meines Geräts: Der Tuxedo hat 32 GB DDR5-5600, die sich CPU und die integrierte Radeon 860M teilen – Bandbreite rund 90 GB/s. Zum Vergleich: Ein Apple M5 Max erreicht über 600 GB/s, ein Strix-Halo-Chip gut 250. Mein Laptop spielt also nicht in der Liga der Lokal-KI-Monster. Ein großes, dichtes 70-Milliarden-Modell wäre hier bandbreiten-verhungert und quälend langsam.
Dass es trotzdem funktioniert, liegt an einer einzigen Architektur-Entscheidung – und die hat einen Namen.
Das Modell: ein MoE, das groß im Speicher und klein im Rechnen ist
Das Modell, das auf dem Gerät läuft, ist Qwen3.5-35B-A3B – ein Mixture-of-Experts mit 35 Milliarden Gesamtparametern, von denen aber nur etwa 3 Milliarden pro Token aktiv sind. Das bricht die Intuition auf die schönste Art:
- Der Speicherbedarf richtet sich nach den Gesamt-Parametern – rund 20 GB bei Q4_K_M, passt bequem in die 32 GB.
- Das Tempo richtet sich nach den aktiven Parametern – nur ~3B müssen pro Token durch den langsamen Speicher, also läuft das Modell brauchbar schnell, obwohl die Bandbreite bescheiden ist.
Genau diese Klasse macht den bandbreitenschwachen Laptop erst nutzbar. Meine frühere Recherche hatte die MoE-Klasse „30B mit 3B aktiv” als Sweet Spot identifiziert; Qwen3.5-35B-A3B ist die neuere Generation derselben Idee. Für einen Agenten, der echte Werkzeuge bedient, zählt nicht die schönste Prosa, sondern zuverlässiges Tool-Calling – und Qwen3.5-35B-A3B liegt komfortabel über der ~14B-Schwelle, ab der lokale Modelle Werkzeuge verlässlich rufen, statt sie zu erfinden.
Der Stack: llama.cpp mit Vulkan, nicht ROCm
Ein Detail, das auf genau dieser Hardware Gold wert ist: Für die Radeon 860M (sie meldet sich dem System als „GFX1152”) ist nicht AMDs offizieller ROCm-Stack die schnellste Wahl, sondern Vulkan. Im Referenz-Benchmark auf exakt dieser CPU: 80,8 Tokens/s über Vulkan gegen 43,3 über ROCm – fast doppelt so schnell, und ohne den Spoofing-Hack, den ROCm hier bräuchte, weil native Kernel für GFX1152 fehlen.
Der Motor ist deshalb selbst kompiliertes llama.cpp (Build 9931) mit Vulkan-Backend. Der llama-server lädt das Qwen3.5-GGUF und stellt es auf Port 8080 bereit:
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.5-35B-A3B-Q4_K_M.gguf \
--host 127.0.0.1 --port 8080 \
-ngl 99 --cpu-moe --flash-attn on \
--cache-type-k q8_0 --cache-type-v q8_0 \
--ctx-size 25000 --jinjaDie Flags sind der eigentliche Trick: -ngl 99 schiebt alle Layer in den (geteilten) iGPU-Speicher, --cpu-moe lässt die dünn besetzten Experten-Tensoren auf der CPU rechnen – dieser Hybrid-Split ist es, der ein 35B-MoE auf einer iGPU überhaupt flüssig fahren lässt. Der quantisierte KV-Cache (q8_0) hält die 25K Kontext bezahlbar, --jinja lädt das passende Chat-Template.
Das Ergebnis: rund 20 Tokens/s. Kein Rennwagen, aber genug für einen Agenten, der erst denkt und dann handelt. Entscheidend ist die Sparsamkeit des Aufbaus: Dieser eine llama-server auf :8080 ist das gemeinsame Backend für beide Demos. Ein Modell, zwei Frontends.
Demo 1: Blender per Sprache steuern
Ein blankes LLM hat keine Werkzeuge – es erzeugt nur Text. Hände bekommt es erst durch die Harness drumherum. Bei Blender sind das drei Schichten: Qwen-Agent (Agent-Harness und MCP-Client, redet mit Qwen3.5 auf :8080) startet selbst den MCP-Server blender-mcp (via uvx), der wiederum über einen Socket auf :9876 mit einem Addon spricht, das innerhalb von Blender läuft.
Qwen-Agent uvx blender-mcp addon.py Blender
(MCP-Client + ⇄ (MCP-Server) ⇄ (Socket :9876) ⇄ (3D-Szene)
Qwen3.5 @ :8080) spawnt der Agent läuft IN Blender
In der Praxis tippt man „Erzeuge einen roten Würfel”, Qwen3.5 denkt kurz, formuliert selbstständig einen execute_blender_code-Aufruf – also beliebiges Python direkt in Blender –, Qwen-Agent führt ihn über blender-mcp aus, und die Szene baut sich auf. Der erste echte Erfolg am 8. Juli 2026: Der Prompt „Create a cube at the origin and make its material red” führte dazu, dass Blender „Created cube named: Würfel” meldete, samt rotem Material. Vollständig offline, in etwa 64 Sekunden (Denken plus ein Tool-Call).
Bedienen lässt sich das auf drei Wegen: als Einmal-Befehl, als interaktiver Chat mit Verlauf, oder über eine kleine Web-GUI auf localhost:7860.
Zwei ehrliche Vorbehalte gehören dazu:
execute_blender_codeist beliebiges Python in Blender. Anfangs leerte der Agent die Szene von selbst; der System-Prompt verbietet das jetzt ausdrücklich („never delete existing objects”). Macht, ohne Leitplanken, was es für richtig hält.- Telemetrie ist der Default, nicht die Ausnahme. blender-mcp funkt per Voreinstellung an Supabase, und Gradios Analytics ist von Haus aus an. Beide sind in den Skripten hart abgeschaltet (
DISABLE_TELEMETRY/BLENDER_MCP_DISABLE_TELEMETRY/DO_NOT_TRACK/GRADIO_ANALYTICS_ENABLED=False) – belegt durch die Log-Zeile „Telemetry disabled via environment variable”. Souveränität ist hier Handarbeit, kein Schalter.
Demo 2: Offline im Web recherchieren
Die zweite Demo ist ein „eigenes Perplexity”, nur privat. Der entscheidende Gedanke: Modell ≠ Recherche. Das LLM synthetisiert nur – die Fakten kommen aus der Such-Schicht. Deshalb war die eigentliche Arbeit nicht „ein Modell installieren”, sondern Suche und Frontend an das bestehende :8080 zu hängen.
Browser Open WebUI Brave API + Embedder llama.cpp
localhost:3000 ⇄ (Recherche-GUI, Docker- ⇄ Suche → Seiten laden → ⇄ :8080
frei, via uv/pip) MiniLM rankt Treffer Qwen3.5-35B-A3B
Der Ablauf pro Frage: Query → Brave liefert 5 Treffer → die Seiten werden geladen → all-MiniLM-L6-v2 rankt die relevanten Text-Chunks (das schont den 25K-Kontext) → der Kontext geht an Qwen3.5 → Antwort mit Zitaten. Das Frontend ist Open WebUI (v0.10.2), bewusst ohne Docker, als schlichtes Python-venv.
Der Datenschutz ist das Schöne daran: alles nur auf 127.0.0.1, kein Login, Telemetrie aus (ANONYMIZED_TELEMETRY / DO_NOT_TRACK / SCARF_NO_ANALYTICS). Die einzige Außenverbindung ist die Suchanfrage an Brave (kostenlose Stufe, ~2k/Monat). Wer auch die loswerden will, hängt ein selbstgehostetes SearXNG davor – Open WebUI zeigt dann auf eine andere Engine, :8080 bleibt unangetastet. Der Brave-Key liegt ausschließlich im Launcher start.sh (chmod 600). Dass es Brave wurde und nicht das key-freie DuckDuckGo/DDGS, war eine bewusste Wahl: DDGS war schlicht zu unzuverlässig (Timeouts).
Und hier zahlt sich der geteilte Backend-Aufbau aus: Beide Demos hängen am selben llama-server. Modellwechsel = ein GGUF tauschen – die Frontends merken davon nichts. Auch die alte Sorge „unzensiert → keine Chinesen?” löst sich damit weitgehend auf: Lokal fällt der Cloud-Filter weg (der sitzt in App und Web, nicht in den Gewichten), und für Recherche ist die Schlagseite des Modells ohnehin zweitrangig – die Fakten kommen aus den Quellen.
Was es kostet: der ehrliche Realitäts-Check
Jetzt mit echten Zahlen statt Extrapolation:
- Tempo: ~20 Tokens/s. Ein Agent, der denkt und dann handelt, kein flotter Chatbot. Eine einfache Blender-Aufgabe dauert rund eine Minute; komplexe Aufgaben bedeuten mehr Tool-Runden.
- Nur ein Modell im RAM. 32 GB heißt: Es passt immer nur ein 20-GB-Modell in den Speicher. Beide Demos beginnen deshalb mit „llama-server muss laufen” – hält ein anderes Programm das Modell schon, muss es erst weichen.
- Zerbrechlichkeit der Reihenfolge. Nach einem Reboot ist
:8080weg → neu starten. Und immer der Server vor dem Frontend, sonst bleibt die Modell-Liste leer. - Kontext-Steuer. Der KV-Cache wächst mit der Kontextlänge; lange RAG-Kontexte fressen Bandbreite und drücken das Tempo. 25K Kontext mit quantisiertem Cache ist der arbeitsfähige Kompromiss.
- Souveränität ist Handarbeit. Jedes einzelne dieser Werkzeuge liefert Telemetrie an aus. Die Privatsphäre kam vom Aufspüren und Abschalten, nicht aus einer Voreinstellung.
- Die NPU schläft. Kein Linux-Stack nutzt die NPU des Ryzen AI bislang für Inferenz – die iGPU bleibt das Arbeitspferd.
Fazit
Zurück zur Ausgangsthese. Ein normaler Linux-Laptop ohne dedizierte GPU und mit „nur” ~90 GB/s geteiltem Speicher fährt keine 70-Milliarden-Modelle und ist kein M5 Max. Aber das war nie die Frage. Die Frage war, ob er echte agentische KI tragen kann – und das kann er: ein lokales Modell, das ein 3D-Programm steuert, indem es selbstständig das richtige Werkzeug wählt, und eines, das das lebende Web mit Quellen recherchiert. Beides, ohne dass ein einziger Prompt an ein Cloud-LLM geht. Möglich macht es die MoE-Architektur – groß im Speicher, klein im Rechnen –, die die bescheidene Hardware gerade ausreichen lässt.
Der Bogen schließt sich damit: von Gemma 4 in der Hosentasche, das Fragen beantwortet, zu einem werkzeugnutzenden Agenten auf dem Schreibtisch, der Dinge tut – offline. „Meine KI, meine Daten, meine Maschine” ist 2026 kein Manifest mehr. Auf einem Mittelklasse-Linux-Laptop ist es ein ganz normaler Donnerstag.
Verwendete Software & Projekte
Modell & Engine
- llama.cpp – die Inferenz-Engine, selbst kompiliert mit Vulkan-Backend
- Qwen3.5 / Qwen-Modelle – das lokale MoE-Modell (35B-A3B, Q4_K_M)
- Vulkan – GPU-Backend für die Radeon 860M, schneller als AMDs ROCm
- Model Context Protocol (MCP) – das Werkzeug-Protokoll, das beide Agenten anbinden
Demo 1 – Blender-Agent
- Blender – das per Sprache gesteuerte 3D-Programm
- blender-mcp – MCP-Server, der Blender fernsteuert
- Qwen-Agent – Agent-Harness und MCP-Client
- uv / uvx – startet den MCP-Server ohne Extra-Installation
- Gradio – die kleine Web-GUI auf
localhost:7860
Demo 2 – Lokale Webrecherche
- Open WebUI – das Recherche-Frontend (ohne Docker, als Python-venv)
- Brave Search API – die Such-Schicht, die die Fakten liefert
- all-MiniLM-L6-v2 – Embedder, der die Treffer rankt
- SearXNG – selbstgehostete Such-Alternative für noch mehr Privatsphäre
- DuckDuckGo / DDGS – key-freie, aber verworfene Such-Alternative
Dieser Artikel ist der zweite von zweien. Der erste – Ein neuer Anfang auf Linux: Das Tuxedo InfinityBook Pro 14 – erzählt die Kaufentscheidung und den Umstieg. Hier ging es um die spannendere Frage dahinter: Was die Maschine kann, wenn man ihr die Cloud wegnimmt.