Qwen3.5-27B lokal für agentisches Coding ausführen

In diesem Tutorial richtest du auf Vast.ai eine entfernte H100-SXM-Instanz ein, stellst Qwen3.5-27B mit vLLM bereit, verbindest es mit OpenCode und testest seine agentische Coding-Fähigkeit an einem realen FastAPI-Projekt.

Wir verwenden hier bewusst nicht llama.cpp. Obwohl llama.cpp für viele lokale Inferenz-Setups hervorragend ist, bringt das Ausführen eines quantisierten 27B-Modells darüber oft Nachteile mit sich: geringere Output-Qualität, reduzierte Coding-Performance und mehr Reibung beim Setup. 

Bei größeren Modellen wie Qwen3.5-27B kann Quantisierung die Zuverlässigkeit spürbar beeinträchtigen, und lokale Deployments über llama.cpp werden schnell unhandlich, wenn du ein reibungsloses, produktionsähnliches Agentenverhalten erwartest.

Stattdessen setzt dieses Tutorial auf vLLM auf einer gemieteten H100-SXM-GPU. So bekommst du einen stabileren, OpenAI-kompatiblen Endpoint, mehr Leistung aus dem vollständigen Modell und ein deutlich saubereres Setup für agentische Coding-Workflows.

Eine separate Anleitung zum lokalen Betrieb von Qwen3.5-397B-A17B findest du hier. 

Voraussetzungen

Bevor du startest, stelle sicher, dass du Folgendes hast:

• ein Vast.ai-Konto
• mindestens 5 $ Guthaben zum Mieten einer GPU-Instanz
• grundlegende Vertrautheit mit dem Linux-Terminal

Eine H100 SXM ist für dieses Setup eine sehr gute Wahl, da Qwen3.5-27B viel Speicher und hohen Durchsatz benötigt – besonders für längere Kontextfenster und eine flüssige, coding-fokussierte Inferenz.

Schritt 1: Vast.ai-Instanz starten und darauf zugreifen

Wir verwenden Vast.ai, weil es als GPU-Marktplatz in der Regel deutlich mehr Flexibilität bei Preis und Hardware bietet als ein klassischer Single-Vendor-Cloudanbieter. 

Du kannst alles mieten – von Community-gehosteten Maschinen bis zu Secure Cloud-/Rechenzentrums-Angeboten, die Vast mit einem blauen Datacenter-Label kennzeichnet. Für ein Setup wie dieses empfehle ich dringend, eine dieser blau markierten Rechenzentrumsmaschinen zu wählen – für mehr Zuverlässigkeit und eine reibungslosere Erfahrung.

Lege zunächst ein Vast.ai-Konto an und lade genug Guthaben für deine Session auf. Öffne dann die Suche, wähle das PyTorch-Template mit aktiviertem Jupyter und suche nach einem Angebot 1× H100 SXM. 

Die Preise auf Vast.ai ändern sich laufend, da es ein Live-Marktplatz ist. Betrachte daher jeden Stundensatz als Richtwert, nicht als fixen Preis.

Sobald du die Maschine gemietet hast, wechsle zum Tab Instances. Wenn der Status auf Open wechselt, klicke auf den Button Open, um das Instanz-Portal im Browser zu öffnen. 

Von dort aus kannst du Jupyter öffnen und direkt auf der Remote-Maschine eine Terminal-Session starten.

Für dieses Tutorial lässt du zwei Terminals geöffnet:

• Ein Terminal, um Qwen3.5-27B mit vLLM zu serven
• Ein Terminal, um OpenCode zu installieren und auszuführen

Die Trennung dieser Aufgaben macht den Workflow deutlich einfacher, sobald der Model-Server läuft.

Schritt 2: vLLM installieren und Qwen3.5 serven

In diesem Schritt erstellst du eine isolierte Python-Umgebung, installierst vLLM und startest Qwen3.5-27B als OpenAI-kompatible API, mit der OpenCode kommunizieren kann. 

vLLM ist eine High-Throughput-Inferenz-Engine für große Sprachmodelle, die Modelle effizient per API bereitstellt.

Workspace und virtuelle Umgebung erstellen

Erstelle im ersten Terminal einen sauberen Workspace für den Model-Server:

mkdir qwen-servercd qwen-server/uv venv --python 3.12source .venv/bin/activate

So erhältst du eine dedizierte Python-3.12-Umgebung, damit die Abhängigkeiten des Model-Servers vom Rest der Maschine getrennt bleiben.

vLLM installieren

Installiere jetzt vLLM:

uv pip install vllm --torch-backend=auto --extra-index-url https://wheels.vllm.ai/nightly

Damit installierst du die Inferenz-Engine, die Qwen3.5 über eine OpenAI-kompatible API bereitstellt.

Hinweis: Für dieses Setup brauchst du die Nightly-Wheels eventuell nicht, da die aktuelle vLLM-Unterstützung für Qwen3.5 oft auch mit der Standardinstallation funktioniert.

Den Qwen3.5-Server starten

Sobald vLLM installiert ist, startest du den Model-Server mit:

vllm serve Qwen/Qwen3.5-27B \
 --host 127.0.0.1 \
 --port 8000 \
 --api-key local-dev-key \
 --served-model-name qwen3.5-27b-local \
 --tensor-parallel-size 1 \
 --max-model-len 64000 \
 --enable-auto-tool-choice \
 --tool-call-parser qwen3_coder \
 --reasoning-parser qwen3

Beim ersten Ausführen lädt vLLM die Model- und Tokenizer-Dateien herunter.

Anschließend lädt es das Modell in den GPU-Speicher. Sobald alles bereit ist, siehst du eine Meldung, dass der Server-Start abgeschlossen ist.

Damit läuft Qwen3.5-27B lokal auf Port 8000 und der Endpoint ist mit dem API-Schlüssel local-dev-key geschützt.

Ein paar Details sind wichtig:

• --served-model-name vergibt einen Modellnamen, auf den OpenCode zugreifen kann
• --enable-auto-tool-choice unterstützt agentenartiges Verhalten
• --tool-call-parser qwen3_coder ist für Qwen-Coding-Workflows geeignet
• --reasoning-parser qwen3 verarbeitet Qwens Reasoning-Output korrekt

Lass dieses Terminal geöffnet, sobald der Server bereit ist.

Schritt 3: OpenCode installieren und konfigurieren

In diesem Schritt öffnest du ein zweites Terminal, installierst OpenCode und verbindest es mit dem lokalen vLLM-Endpoint aus Schritt 2. 

OpenCode ist ein Open-Source-Coding-Agent, der im Terminal läuft und über seine Provider-Konfiguration lokale Modelle anbinden kann.

Wechsle zurück ins Instanz-Portal und öffne ein zweites Jupyter-Terminal. Lass das erste Terminal weiterlaufen, denn dort servst du Qwen3.5 über vLLM. 

Falls der Jupyter-Terminal-Button wieder dasselbe Terminal öffnet, kannst du meist ein weiteres starten, indem du die Zahl am Ende der Terminal-URL änderst. Wenn dein aktuelles Terminal z. B. mit /terminals/1 endet, ändere sie auf /terminals/2.

Dieses zweite Terminal ist dein OpenCode-Terminal, während das erste weiter den Model-Server ausführt.

OpenCode installieren

Führe den folgenden Befehl aus, um OpenCode zu installieren:

curl -fsSL https://opencode.ai/install | bash

Anschließend die Shell aktualisieren:

exec bash

Dadurch wird die Shell neu geladen, sodass der Befehl opencode sofort verfügbar ist.

OpenCode auf deinen lokalen vLLM-Server zeigen lassen

OpenCode sucht seine globale Konfiguration unter ~/.config/opencode/opencode.json, und die Provider-Einstellungen unterstützen eigene Werte für baseURL und apiKey. Das passt ideal zu einem lokalen OpenAI-kompatiblen Server wie dem, den du mit vLLM gestartet hast.

Erstelle die Konfigurationsdatei mit:

mkdir -p ~/.config/opencode && cat > ~/.config/opencode/opencode.json <<'EOF'
{
 "$schema": "https://opencode.ai/config.json",
 "provider": {
   "vllm": {
     "npm": "@ai-sdk/openai-compatible",
     "name": "Local vLLM",
     "options": {
       "baseURL": "http://127.0.0.1:8000/v1",
       "apiKey": "local-dev-key"
     },
     "models": {
       "qwen3.5-27b-local": {
         "name": "Qwen3.5-27B Local"
       }
     }
   }
 },
 "model": "vllm/qwen3.5-27b-local",
 "small_model": "vllm/qwen3.5-27b-local"
}
EOF

Damit nutzt OpenCode deinen lokalen vLLM-Endpoint unter http://127.0.0.1:8000/v1 statt einer gehosteten API. Außerdem wird derselbe API-Schlüssel verwendet, den du beim Start des vLLM-Servers in Schritt 2 gesetzt hast, sodass OpenCode sich erfolgreich authentifizieren kann.

Schritt 4: OpenCode mit dem lokalen Modell verbinden

Erstelle nun ein Projektverzeichnis, um den Coding-Agenten zu testen:

mkdir investment-apicd investment-apiopencode

Damit startest du OpenCode im Ordner investment-api und nutzt dein lokales Qwen3.5-Modell als Backend. 

Ab hier kannst du es Dateien untersuchen lassen, Code erklären oder neue Projektkomponenten generieren – mit dem Modell, das auf deiner gemieteten GPU läuft.

Schritt 5: Qwen3.5 an einer realen Coding-Aufgabe testen

Jetzt ist es Zeit, das komplette Setup an einer echten Aufgabe zu testen.

Ich habe zunächst mit einem sehr einfachen Prompt geprüft, ob alles funktioniert. Nach weniger als einer Sekunde kam eine Antwort zurück – ein gutes Zeichen dafür, dass das Modell korrekt verbunden war.

Als Nächstes gab ich eine realistischere agentische Coding-Aufgabe vor:

"Build a FastAPI backend for investment market data that 
collects the latest public data every few minutes for S&P 500, 
gold, silver, Brent, major indices, and selected stocks."

Nach etwa einer Minute Reasoning stellte das Modell sinnvolle Rückfragen: Welche Datenquelle genutzt werden soll, welche Art von Speicher oder Datenbank vorgesehen ist und welche Ticker enthalten sein sollen. 

Das war ein gutes Zeichen, denn es zeigte, dass das Modell nicht blind in den Code sprang, sondern zuerst die Anforderungen klärte.

Danach erstellte es einen Plan und arbeitete die Aufgabe Schritt für Schritt ab. Es zerlegte das Problem in Teilaufgaben, setzte sie auf eine To-do-Liste und schloss die Punkte nacheinander ab.

In weniger als fünf Minuten stand die vollständige Projektstruktur und ein größtenteils funktionierendes FastAPI-Backend – für diese Aufgabe sehr schnell.

Anschließend ließ ich die API testen und einen Smoke-Test durchführen. Das Ergebnis war eine nahezu funktionierende Finanz-API. Es gab noch ein paar Punkte zu korrigieren, aber für einen so kurzen Lauf war die Leistung sehr beeindruckend.

Fazit

Wir haben jetzt ein vollständiges lokales Coding-Setup auf einer gemieteten Vast.ai-H100-SXM-Instanz. In diesem Tutorial haben wir vLLM genutzt, um Qwen3.5-27B über eine OpenAI-kompatible API bereitzustellen und diesen Endpoint anschließend mit OpenCode zu verbinden, um das Modell in einem agentischen Coding-Workflow zu nutzen.

Dieser Ansatz bietet eine praxisnahe Möglichkeit, ein starkes Open-Weight-Coding-Modell für reale Aufgaben einzusetzen – ohne von einem gehosteten Anbieter abhängig zu sein. Außerdem behältst du die Kontrolle über den gesamten Stack, vom Model-Server bis zur Coding-Oberfläche.

Im Vergleich zum Versuch, ein stark quantisiertes 27B-Modell lokal über llama.cpp zu betreiben, ist dieses Setup oft stabiler und besser für ernsthafte Coding-Arbeit geeignet. Viele Performance-Kompromisse, Speichergrenzen und Setup-Probleme, die bei großen Modellen in einer rein lokalen Umgebung auftreten können, werden so vermieden.

Ein weiterer großer Vorteil ist die Performance. Mit diesem Setup erhalten wir einen sehr hohen Tokens-pro-Sekunde-Durchsatz, eine große Kontextlänge und insgesamt eine deutlich flüssigere Coding-Erfahrung. Damit wird es viel praktikabler für längere Prompts, Aufgaben über mehrere Dateien hinweg und agentische Workflows, bei denen das Modell mehr Raum zum Denken braucht und mehr Kontext im Blick behalten muss.