Ein nützliches lokales LLM in 30 Minuten: Programmieren, Dokumenten-FAQ und Sprachsteuerung
Ein nützliches lokales LLM in 30 Minuten mit Ollama, Qwen3 und Whisper.cpp: ein Programmierassistent, RAG für Ihre Notizen sowie ein offline-Funktionierender Sprachkreislauf, angepasst an Ihre Speicherkapazität.
Quellen: Run a Useful Local LLM in 30 Minutes (Coding, RAG, Voice)
Ein lokales Modell kann eine echte Programmierfrage beantworten, auch wenn das Netzwerk nicht angeschlossen ist, und zwar auf einem Laptop, der bereits auf dem Schreibtisch liegt. Die Einrichtung dauert etwa acht Minuten und die monatlichen Kosten betragen nichts. Ein Prompt wie der untenstehende reicht aus, um zu sehen, wie es funktioniert.
$ ollama run qwen3:8b
>>> rewrite this function to use async/await
Die Qualität ist überraschend. Sie erreicht zwar nicht das Niveau der besten Cloud-Modelle bei komplexen, mehrschrittigen Überlegungen, doch sie bewältigt alltägliche Ingenieuraufgaben zuverlässig genug, sodass die Lücke zwischen einem Wochenendspielzeug und einem funktionsfähigen Werkzeug stark geschrumpft ist.
Drei Entwicklungsphasen im Laufe von etwa anderthalb Jahren haben dies praktikabel gemacht. Die Modelldateien sind so verkleinert worden, dass sie in herkömmlichen RAM-Speichern untergebracht werden können: Qwen 3 bietet eine Variante mit 8 Milliarden Parametern und einem Umfang von etwa 5 GB. Qwen3-Coder, der im Februar 2026 veröffentlicht wurde, erreicht 70,6 Prozent auf dem SWE-bench. Zudem wurde er mit einem 30 Milliarden Parameter umfassenden „Mixture-of-Experts“-Design getestet, das pro Token nur 3 Milliarden Parameter aktiviert. Dank Ollama wurde die Installation von einem komplizierten Netzwerk an Python-Umgebungen auf ein einziges Binärdatei vereinfacht.
Unten sind drei separate Versionen zu je etwa einer halben Stunde zu finden: ein Programmierassistent innerhalb des Editors, ein Python-Skript, das Fragen zu einer Ordnerstruktur mit Dokumenten beantwortet, sowie eine Sprachschleife, die zuhört und antwortet. Alle teilen sich eine fünfminütige Grundversion, gehen danach jedoch eigene Wege – daher ist es sinnvoll, die Version zu wählen, die am nächsten am täglichen Arbeitsablauf liegt, und die anderen auf später zu verschieben.
Die gemeinsame Grundversion
Jeder Ansatz benötigt einen Inferenzmotor sowie eine Reihe von Modellgewichten.
Ollama übernimmt die Rolle des Motors. Es kümmert sich um Unterschiede im Hardware-Setup, erkennt, ob das Gerät eine NVIDIA-GPU, einen Apple Silicon-Chip oder nur einen CPU besitzt, und bereitet den entsprechenden Ausführungsgraphen vor. Es läuft im Hintergrund und stellt eine lokale HTTP-API zur Verfügung, die sich wie die Endpunkte der großen Cloud-Anbieter verhält.
Die Installation hängt von der Plattform ab. Unter macOS übernimmt Homebrew diese Aufgabe:
brew install ollama
Linux verfügt über ein Installationsskript:
curl -fsSL https://ollama.com/install.sh | sh
Windows-Nutzer können den MSI-Installer von der Ollama-Website herunterladen.
Sobald der Engine-Teil bereitsteht, folgt das Modell. Als Grundlage dient hier qwen3:8b, das etwa 5 GB Speicherplatz benötigt und problemlos in 16 GB RAM untergebracht werden kann. Ohne eine dedizierte GPU greift Ollama auf CPU-Berechnungen zurück, was eine Geschwindigkeit von etwa 8 bis 12 Tokens pro Sekunde ergibt – was dennoch vollständig lesbar ist.
Herunterladen:
ollama pull qwen3:8b
Bestätigen Sie anschließend, dass alles bei einem schnellen Test funktioniert:
ollama run qwen3:8b "Write a python script to reverse a string."
Die Antwort wird in das Terminal gestreamt. Im Hintergrund lädt Ollama eine GGUF-Datei, ein Format, das die Gewichte direkt vom Festplatten-Speicher in den RAM abbildet, sodass ein Blick auf den Systemmonitor zeigt, dass der Speicherbedarf um etwa die Größe der Datei ansteigt.
Ein Rechner mit 8 GB RAM oder weniger beginnt, Daten auf die Festplatte auszulagern, wodurch die Verarbeitungsgeschwindigkeit stark abnimmt. Für solche Fälle sind qwen3:4b oder gemma3:4b die bessere Wahl. Mit einer 24 GB großen GPU gibt es genügend Kapazität für qwen3:14b als natürlichen nächsten Schritt.
Weg A: Ein Programmier-Assistent im Editor
Alle, die hauptsächlich in einem Code-Editor arbeiten, erzielen hier die schnellste Rendite. Ziel ist es, ein lokales Modell mit VS Code zu verbinden, um Code umzustrukturieren, Dokumentationen zu erstellen und Standardvorlagen zu nutzen.
Das allgemeine Qwen 3-Modell ist kompetent, doch bei der Codeverarbeitung bringt spezialisierte Schulung Vorteile. Stand Mai 2026 ist Qwen3-Coder der stärkste allround-fähige lokale Code-Generator, der 70,6 Prozent auf SWE-bench Verified und 44,3 Prozent auf SWE-Bench Pro erreicht. Seine Gesamtparameteranzahl beträgt 30 Milliarden, wobei für jeden Token nur 3 Milliarden Parameter aktiv sind, sodass er in 24 GB VRAM passt oder reibungslos auf einem Mac der M-Serie mit 32 GB integrierter Speicher arbeitet.
Ein 16-GB-Laptop ohne dedizierte GPU wird vermutlich mit dem 30-Milliarden-Parameter-Modell überfordert sein. Als Alternative kommt qwen2.5-coder:7b in Frage, der 4,7 GB Speicher benötigt und dennoch etwa 92 Prozent auf HumanEval erreicht.
# For 24GB+ VRAM or 32GB+ Mac Unified Memory
ollama pull qwen3-coder:30b
# For 16GB RAM laptops
ollama pull qwen2.5-coder:7b
Der Editor benötigt eine Benutzeroberfläche, um mit dem Modell zu kommunizieren. Cline, eine agentbasierte VS Code-Erweiterung mit mehr als 5 Millionen Installationen, kann Dateien lesen, Unterschiede vorschlagen und Terminalbefehle ausführen. Sie ist über die Suche im Marketplace nach ihrem Namen verfügbar.
Eine Fallgrube verdient besondere Aufmerksamkeit: Cline enthält eine lange Systemanweisung, die erklärt, wie Unterschiede formatiert, der Dateistrom gelesen und Werkzeuge verwendet werden sollen. Diese Anweisung umfasst oft bereits 25.000 Token, bevor überhaupt Code angehängt wird. Ollamas Standardkontextfenster für Qwen 3-Modelle beträgt 40.000 Token. Wenn mehrere Dateien geöffnet werden, überschreitet die Gesamtanzahl dieser Token leicht diesen Wert, wodurch Ollama die Anweisung ohne Vorwarnung abschneidet. Das Modell verliert anschließend die Formatierungsanweisungen, ignoriert die Regeln und erzeugt stattdessen reinen Text anstelle gültiger Unterschiede.
Die Lösung besteht darin, eine benutzerdefinierte Modelldatei zu verwenden, die ein größeres Kontextfenster erzwingt.
Eine für Cline optimierte Modelldatei
Speichern Sie den folgenden Inhalt im Arbeitsverzeichnis als Datei mit dem Namen Modelfile.
# Modelfile — cline-tuned qwen3-coder
# Save as: ./Modelfile
FROM qwen3-coder:30b
# Cline's system prompt is ~25-30K tokens before your code is added.
# Ollama's default num_ctx for Qwen 3 is 40K, but Cline ships an
# expanded system prompt in v3+ that comfortably exceeds it on any
# real task. 65536 is the safe floor for serious use; 131072 if
# you have RAM/VRAM to spare.
PARAMETER num_ctx 65536
# Code edits want low-variance output. The default 0.7 is too loose.
PARAMETER temperature 0.2
# Stop after the model's natural turn. Cline parses this.
PARAMETER stop "<|im_end|>"
Bauen Sie das Modell daraus mit der Ollama CLI und überprüfen Sie anschließend, ob die Einstellung des Kontexts Wirkung gezeigt hat:
# Build the Cline-tuned model from the Modelfile in the current dir
ollama create qwen3-coder-cline -f ./Modelfile
# Verify the context window actually took
ollama show qwen3-coder-cline --modelfile | grep num_ctx
# Expected output: PARAMETER num_ctx 65536
# Sanity-check it answers
ollama run qwen3-coder-cline "write a python one-liner to read /etc/hostname"
In VS Code öffnen Sie das Befehlspalier mit Cmd+Shift+P und wählen Sie den Eintrag „Cline settings“. Weisen Sie es auf den lokalen Engine zu:
API Provider: Ollama
Base URL: http://localhost:11434
Model: qwen3-coder-cline
Context Window: 65536
Der Wert des Kontextfensters in der GUI muss exakt mit dem Wert von num_ctx in der Modelldatei übereinstimmen. Ist er niedriger, geht Cline davon aus, dass das Fenster kleiner ist, und beschränkt stillschweigend die Dateien, die gesendet werden.
Um es auszuprobieren, öffnen Sie eine Python-Datei mit einer synchronen Funktion, rufen das Cline-Chat-Fenster auf und bitten um eine Umstrukturierung in async/await. Cline liest die Datei, sendet sie an das lokale Qwen3-Coder-Modell, erhält die Antwort und zeigt einen sauberen Diff im Editor an. Die Annahme erfolgt mit einem einzigen Klick, und der gesamte Prozess läuft offline ab.
Diese Konfiguration bewältigt Refaktorisierungen einzelner Dateien, Tests für isolierte Funktionen sowie die Erstellung von Boilerplate-Code. Community-Tests zeigen, dass sie bei eng gefassten Aufgaben etwa 70 bis 85 Prozent der Qualität führender Cloud-Lösungen erreicht.
Es versagt bei großen Änderungen der mehrdateibasierten Architektur. Der Umstieg eines zwanzig Dateien umfassenden Flask-Projekts auf FastAPI ist genau der Punkt, an dem es scheitert: Die Threads gehen verloren, Importe werden fälschlich hinzugefügt und die Codebasis wird schließlich beschädigt. Arbeiten dieser Größenordnung gehören weiterhin zu einem modernen Cloud-Modell. Für die Dutzenden kleiner, zeitaufwendiger Änderungen, die täglich vorgenommen werden, reicht jedoch der lokale Betrieb aus.
Weg B: Abruf über eigene Dokumente
Bei diesem Weg handelt es sich um eine Ordnerstruktur mit Markdown-Zetteln, Sitzungsprotokollen oder Projektdokumentation, die manuell durchsucht wird. Der gesamte Ablauf passt in etwa 60 Zeilen herkömmlichen Python-Code, wobei nur der Ollama-Client und numpy verwendet werden.
Ein Embedding-Modell wandelt Text in Vektoren um. Nomic Embed Text v1.5 verfügt über 137 Millionen Parameter, erzeugt 768-dimensionalen Vektoren, nimmt weniger als 300 MB Speicher in Anspruch, kann einen Kontext von 8192 Token verarbeiten und erzielt gute Ergebnisse in den MTEB-Abruf-Benchmarks.
Laden Sie das Embedding-Modell herunter und installieren Sie die Python-Pakete:
llama pull nomic-embed-text
pip install ollama numpy
Speichern Sie anschließend das Skript als rag.py.
"""Local RAG over a folder of notes — Ollama embeddings + numpy cosine.
No vector DB. For a few hundred docs, an in-memory list + numpy is
faster to set up and fast enough to run. Swap in sqlite-vec when
the corpus outgrows it (typically past ~5000 chunks).
Setup:
ollama pull qwen3:8b
ollama pull nomic-embed-text
pip install ollama numpy
Run:
python rag.py ./notes "what did the team decide about pricing?"
"""
from __future__ import annotations
import glob
import os
import sys
import numpy as np
import ollama
EMBED_MODEL = "nomic-embed-text"
CHAT_MODEL = "qwen3:8b"
CHUNK_WORDS = 400 # ~500 tokens; fits 4 chunks in an 8K context
TOP_K = 3
def load_chunks(folder: str) -> list[str]:
"""Read every .md / .txt under folder, split into ~CHUNK_WORDS chunks."""
chunks: list[str] = []
for path in glob.glob(os.path.join(folder, "**/*"), recursive=True):
if not path.endswith((".md", ".txt")):
continue
with open(path, encoding="utf-8") as f:
words = f.read().split()
for i in range(0, len(words), CHUNK_WORDS):
chunk = " ".join(words[i : i + CHUNK_WORDS])
if chunk.strip():
chunks.append(chunk)
return chunks
def embed(texts: list[str]) -> np.ndarray:
"""Embed a batch of texts via Ollama. Returns an (N, D) matrix."""
resp = ollama.embed(model=EMBED_MODEL, input=texts)
return np.array(resp["embeddings"], dtype=np.float32)
def top_k_indices(
query_vec: np.ndarray, doc_mat: np.ndarray, k: int
) -> list[int]:
"""Return indices of the k most cosine-similar rows in doc_mat.
The trick: if both vectors are unit-length (norm == 1), their
dot product equals their cosine similarity. So we normalize
once, then one matrix multiply gives a similarity score for
every chunk against the query — no Python loop needed.
"""
# Normalize query and every chunk to unit length.
# The 1e-8 prevents division by zero on a zero vector.
q = query_vec / (np.linalg.norm(query_vec) + 1e-8)
d = doc_mat / (np.linalg.norm(doc_mat, axis=1, keepdims=True) + 1e-8)
# One matmul across all chunks: scores[i] = cos(query, chunk_i).
scores = d @ q
# Sort descending, take the first k indices.
return np.argsort(scores)[::-1][:k].tolist()
def answer(query: str, chunks: list[str], doc_mat: np.ndarray) -> str:
"""Retrieve top-K chunks, stuff them into a prompt, generate."""
q_vec = embed([query])[0]
idx = top_k_indices(q_vec, doc_mat, k=TOP_K)
context = "\n\n---\n\n".join(chunks[i] for i in idx)
prompt = (
"Answer the question using ONLY the context below. "
"If the context does not contain the answer, say so plainly.\n\n"
f"CONTEXT:\n{context}\n\nQUESTION: {query}"
)
resp = ollama.chat(
model=CHAT_MODEL,
messages=[{"role": "user", "content": prompt}],
)
return resp["message"]["content"]
if __name__ == "__main__":
if len(sys.argv) != 3:
sys.exit('usage: python rag.py <folder> "<question>"')
folder, query = sys.argv[1], sys.argv[2]
chunks = load_chunks(folder)
if not chunks:
sys.exit(f"no .md or .txt files found under {folder}")
print(f"indexing {len(chunks)} chunks...")
doc_mat = embed(chunks)
print(answer(query, chunks, doc_mat))
Richten Sie es auf ein Verzeichnis mit Notizen und stellen Sie eine Frage:
python rag.py ~/Documents/meeting_notes "what did the team decide about pricing?"
Die Skript durchläuft den Ordner, liest die Dateien und teilt sie in Blöcke à 400 Wörter auf. Die vollständige Liste der Blöcke wird in einem einzigen Batch an Ollamas Embedding-Endpunkt gesendet. Für jede Frage wird der Abfragevektor mithilfe der Kosinusähnlichkeit mit jedem Dokumentvektor verglichen.
Die drei besten Blöcke werden in den Erstellungsaufruf eingefügt, und qwen3:8b schreibt die Antwort. Eine Anweisung in diesem Aufruf ist streng: Die Antwort muss ausschließlich auf dem bereitgestellten Kontext beruhen, und es muss klar gesagt werden, falls der Kontext keine Antwort enthält. Lokale Modelle erzeugen leicht hilfreich klingende Fälschungen, wenn die Suche nichts liefert, und diese Anweisung zwingt sie dazu, ihre Unwissenheit einzugestehen.
Das ist keine Produktivumgebung zur Datenabfrage. Das Chunking ist eine grobe Wortzählung, die manchmal einen Satz in zwei Teile teilt. Embeddings befinden sich im Speicher und verschwinden beim Beenden, weshalb das Korpus bei jedem Lauf erneut eingebettet werden muss. Sobald eine Sammlung mehrere tausend Dokumente umfasst und das Starten des Programms lästig wird, ersetzt das Ersetzen der numpy-Matrix durch sqlite-vec die Vektoren in einer lokalen SQLite-Datei. Für persönliche Notizen reicht ein kurzer Script aus.
Path C: eine Sprachschleife
Um ohne Tippen mit einem Modell zu sprechen und ohne Audio an einen Cloud-Dienst zu senden, erstellt dieser Weg eine vollständige Sprache-zu-Sprache-Schleife auf lokaler Hardware.
Der Ablauf besteht aus drei Teilen: Speech-to-Text zur Transkription des Mikrofons, dem LLM zur Erstellung einer Antwort sowie Text-to-Speech zur Lautverlesung.
Die Transkription verwendet Whisper.cpp, eine stark optimierte C++-Version von OpenAI’s Whisper, die auf CPU, Apple Metal und NVIDIA CUDA läuft. Für die Audioumwandlung ist die Abhängigkeit von ffmpeg erforderlich. Unter macOS:
brew install whisper-cpp ffmpeg
Auf Linux sollte man ffmpeg über den Paketmanager installieren, das Whisper.cpp-Repository klonen und anschließend „make“ ausführen.
Whisper.cpp benötigt Gewichte im GGML-Format. Die Datei ggml-base.en.bin mit etwa 150 MB Größe ist im offiziellen Hugging Face-Repository verfügbar und eignet sich schnell und präzise für Englisch. Für andere Sprachen oder höhere Genauigkeit dient ggml-large-v3.bin als Alternative. Legen Sie die Datei in einen bekannten Ordner wie ~/models/.
Die Sprachausgabe stammt von Kokoro ONNX, einem leichten TTS-Engine, dessen Gewichte insgesamt etwa 300 MB umfassen und das in Echtzeit auf einem normalen CPU synthetisiert. Derzeit werden Python 3.10 bis 3.13 benötigt; eine Installation unter Python 3.14 ist nicht möglich.
pip install -U sounddevice ollama kokoro-onnx
Das Pipeline-Skript
Speichern Sie den folgenden Text als voice.py und ändern Sie den Pfad zu WHISPER_MODEL so, dass er auf die gerade heruntergeladene GGML-Datei verweist.
"""Local voice loop — mic → whisper.cpp → Ollama → Kokoro → speaker.
Everything runs offline. Nothing leaves the machine.
Setup:
brew install whisper-cpp ffmpeg # macOS
# (Linux: apt install ffmpeg; build whisper.cpp from source)
pip install -U sounddevice ollama kokoro-onnx
# Whisper GGML model — pick one:
# ggml-base.en.bin (~150MB, fast, English-only)
# ggml-large-v3.bin (~3GB, accurate, multilingual)
# Download from https://huggingface.co/ggerganov/whisper.cpp
# Kokoro model files auto-download to ~/.cache/kokoro-onnx/
# on first run, or grab them manually from
# https://github.com/thewh1teagle/kokoro-onnx/releases
Run:
python voice.py
"""
from __future__ import annotations
import subprocess
import tempfile
import wave
from pathlib import Path
import sounddevice as sd
import ollama
from kokoro_onnx import Kokoro
WHISPER_MODEL = Path.home() / "models" / "ggml-base.en.bin"
CHAT_MODEL = "qwen3:8b"
KOKORO_VOICE = "af_sarah" # see kokoro voices.json for all options
SAMPLE_RATE = 16000 # whisper.cpp requires 16kHz mono
RECORD_SECONDS = 5
# Kokoro auto-downloads the model files on first instantiation.
kokoro = Kokoro("kokoro-v1.0.onnx", "voices-v1.0.bin")
def record() -> Path:
"""Record from the default mic, write a 16kHz mono WAV, return its path."""
print(f"listening for {RECORD_SECONDS}s...")
audio = sd.rec(
int(RECORD_SECONDS * SAMPLE_RATE),
samplerate=SAMPLE_RATE,
channels=1, # mono
dtype="int16", # 16-bit PCM is what wave.open expects
)
sd.wait() # block until recording finishes
# Fixed path in the system tempdir — overwritten each invocation.
wav_path = Path(tempfile.gettempdir()) / "voice_in.wav"
with wave.open(str(wav_path), "wb") as w:
w.setnchannels(1) # mono
w.setsampwidth(2) # 2 bytes per sample == int16
w.setframerate(SAMPLE_RATE) # 16 kHz — whisper.cpp's required rate
w.writeframes(audio.tobytes())
return wav_path
def transcribe(wav_path: Path) -> str:
"""Run whisper.cpp on a WAV file, return the transcript text."""
result = subprocess.run(
[
"whisper-cli",
"-m", str(WHISPER_MODEL),
"-f", str(wav_path),
"-otxt", # write the transcript to <input>.txt
"-np", # suppress progress prints on stdout
],
capture_output=True,
text=True,
timeout=60,
)
if result.returncode != 0:
raise RuntimeError(f"whisper-cli failed: {result.stderr}")
# -otxt writes the transcript next to the input file, with .txt
# tacked onto the existing name — so /tmp/voice_in.wav becomes
# /tmp/voice_in.wav.txt (same directory, same stem, extra suffix).
txt_path = wav_path.with_suffix(wav_path.suffix + ".txt")
return txt_path.read_text(encoding="utf-8").strip()
def respond(text: str) -> str:
"""Send the transcript to the local LLM, return the reply."""
resp = ollama.chat(
model=CHAT_MODEL,
messages=[
{
"role": "system",
"content": (
"You are a voice assistant. Keep replies to one or "
"two short sentences. No markdown, no lists."
),
},
{"role": "user", "content": text},
],
)
return resp["message"]["content"]
def speak(text: str) -> None:
"""Synthesize the reply with Kokoro and play it back."""
samples, sample_rate = kokoro.create(
text, voice=KOKORO_VOICE, speed=1.0, lang="en-us"
)
sd.play(samples, sample_rate)
sd.wait()
if __name__ == "__main__":
wav = record()
heard = transcribe(wav)
if not heard:
print("nothing heard. exiting.")
raise SystemExit(0)
print(f"you said: {heard}")
reply = respond(heard)
print(f"model: {reply}")
speak(reply)
Beim Ausführen lauscht das Skript fünf Sekunden lang, transkribiert, erzeugt eine Antwort und spricht sie aus. Beim ersten Start wird eine Pause eingelegt, während Kokoro seine ONNX-Dateien in ~/.cache/kokoro-onnx/ herunterlädt.
Drei Gestaltungsoptionen sind wichtiger, als es auf den ersten Blick scheint. Die Aufnahme in 16kHz Mono ist zwingend erforderlich: Whisper wurde mit 16kHz-Audio trainiert, und 44,1kHz von Standardmikrofonen liefert erfundenen Text oder leere Ausgaben. Das Ausführen von whisper-cli als separater Unterprozess anstelle einer Python-Bindung vermeidet Konflikte um Ressourcen sowie fehlerhafte C-Erweiterungen, und sein Flag für die Textausgabe speichert die Transkription in einer Datei, sodass niemand die Standardausgabe abrufen muss. Der Systemprompt verbietet außerdem ausdrücklich Markdown, weil Kokoro Sterne laut vorliest und eine formatierte Antwort das Erlebnis zerstört.
Die Schleife handhabt nur eine einzige Umwandlung. Sie streamt keine Audio-Blöcke in Echtzeit und speichert auch keine Konversationshistorie. Ein echter konversationeller Agent würde eine Stimmenaktivitätserkennung hinzufügen, um zu erkennen, wann das Sprechen endet, anstelle eines festgelegten Zeitraums von fünf Sekunden. Als Grundlage zeigt dies, dass lokale Hardware die gesamte Kette von Sprache zu Text, Modell und Sprachsynthese in wenigen Sekunden ausführen kann.
Was die Hardware zulässt
Locale Modelle sind weit stärker durch die Speicherkapazität als durch die reine Rechenleistung eingeschränkt. Wie schnell die Gewichte von RAM in die Recheneinheiten übertragen werden, ist wichtiger als die Geschwindigkeit, mit der der Prozessor Arithmetikoperationen durchführt – und genau diese Tatsache bestimmt, welches Modell für eine Maschine geeignet ist.
Ein 16 GB großer Laptop ohne dedizierte GPU erreicht eine Systemmerkmembrastreitbreite von maximal 50 bis 70 GB/s. Er kann qwen3:8b oder qwen2.5-coder:7b auf der CPU mit 8 bis 12 Tokens pro Sekunde ausführen, was für Suchfunktionen und Sprachverarbeitung ausreicht, aber für das Koden zu langsam ist. Apple Silicon ändert dieses Bild durch ein vereintes Speichersystem mit 200 bis 400 GB/s, sodass ein M-Serie Pro oder Max mit 24 bis 36 GB problemlos qwen3-coder:30b verarbeiten kann, da das MoE-Design pro Token nur 3 Milliarden Parameter aktiviert.
NVIDIA-Karten tauschen Kapazität gegen Streitbreite ein. Mit 12 bis 16 GB VRAM läuft qwen3:8b sofort, und quantifiziertes qwen3-coder:30b passt ebenfalls hinein. Bei 24 GB oder mehr, wie bei einer RTX 3090 oder 4090, läuft das 30B-Modell in voller Geschwindigkeit – was für Einzeldateien fast einer kostenpflichtigen Mitgliedschaft entspricht. Bei weniger als 8 GB RAM ist der Weg zum Koden meist nicht möglich, weshalb qwen3:4b oder phi-4-mini mit Sprachfunktionen und kleinen Suchaufgaben die realistische Option sind.
Verwandte Artikel
- Praktische Anmerkungen: Erstellung eines Private-Cloud-Coding-Agenten – OpenCode + ein lokales LLM — Detaillierte Anleitung zu den Praktischen Anmerkungen zur Erstellung eines Private-Cloud-Coding-Agenten: OpenCode + ein lokales LLM, einschließlich Verträgen, Überprüfungen sowie Code-Blöcken, die Teams zur Umsetzung dieses Ansatzes verwenden können.
- Verfolgung des Verhaltens eines Voice-RAG-Agenten mit LiveKit, Qdrant und MLflow — Erstellung eines Sprach-zu-Sprach-Hypotheken-Assistenten unter Verwendung von LiveKit, LlamaIndex und Qdrant, wobei OpenTelemetry-Spuren in MLflow jede Abfrage sowie jeden Schritt des LLMs anzeigen.