KI-Server: RTX 3090 mit llama.cpp + Qwen3.6 35B aktivieren #99

New issue

Closed

opened 2026-06-10 18:46:54 +00:00 by orbitalo · 2 comments

orbitalo commented

2026-06-10 18:46:54 +00:00

Owner

Ziel

RTX 3090 als primären lokalen LLM-Server aktivieren. Verzeichnisse C:\llm\models und C:\llm\bin sind bereits angelegt.

Finale Konfiguration

Modell: Unsloth UD-Q4_K_XL (22,4 GB) — Unsloth Dynamic 2.0 Kalibrierung, bei MoE-Modellen qualitativ relevant
Repo: unsloth/Qwen3.6-35B-A3B-GGUF auf Hugging Face (nicht HauhauCS)
Backend: llama.cpp CUDA 12.x (nicht 13.x — Gibberish-Bug)
KV-Cache: K=4bit / V=3bit asymmetrisch
Kontext: Ziel 256K, Fallback 128K falls VRAM nicht reicht
Erwartete Geschwindigkeit: ~100 tok/s
Kosten: 0 €

Plan

Schritt 1 — llama.cpp Binary laden

https://github.com/ggml-org/llama.cpp/releases
Datei: llama-*-bin-win-cuda12-x64.zip  ← NICHT cuda13
Entpacken nach C:\llm\bin\

Schritt 2 — Modell laden (22,4 GB)

curl -L -o C:\llm\models\Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf `
  "https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF/resolve/main/Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf"

⚠️ Repo-Name beim Pullen prüfen: unsloth/Qwen3.6-35B-A3B-GGUF — nicht die HauhauCS-Variante.

Schritt 3 — Erster Teststart OHNE KV-Quant, kleiner Kontext

C:\llm\bin\llama-server.exe ^
  -m C:\llm\models\Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf ^
  -ngl 99 ^
  --ctx-size 8192 ^
  --flash-attn ^
  --jinja ^
  --host 127.0.0.1 --port 8080

Ziel: sauberen Build bestätigen, noch keine KV-Quant.

Schritt 4 — Kohärenztest

curl http://127.0.0.1:8080/v1/chat/completions `
  -H "Content-Type: application/json" `
  -d '{"model":"qwen","messages":[{"role":"user","content":"hallo"}],"max_tokens":50}'

Diagnose:

Gibberish hier → falscher CUDA-Build, anderen Release nehmen
Saubere Antwort → Build ok, weiter zu Schritt 5
Gibberish erst nach Schritt 5 → KV-Quant-Problem, nicht Build

Schritt 5 — Vollstart mit KV-Quant und großem Kontext ⚠️ Kritischer Schritt

C:\llm\bin\llama-server.exe ^
  -m C:\llm\models\Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf ^
  -ngl 99 ^
  --ctx-size 262144 ^
  --cache-type-k q4_0 ^
  --cache-type-v q3_K ^
  --flash-attn ^
  --jinja ^
  --host 127.0.0.1 --port 8080

nvidia-smi parallel laufen lassen — VRAM muss unter ~23,5 GB bleiben.

Falls OOM oder VRAM > 23,5 GB:
→ Erst --ctx-size 131072 versuchen, NICHT am Quant drehen.
128K ist immer noch weit über dem Cursor-Bedarf. 256K beim ersten Versuch ist nicht garantiert.

Schritt 6 — Cline anbinden

VS Code → Cline → Settings → API Provider: OpenAI Compatible
Base URL: http://127.0.0.1:8080/v1
API Key: beliebig (wird ignoriert)
Context Window: je nachdem was in Schritt 5 gelaufen ist (262144 oder 131072)

Checkliste

llama.cpp CUDA 12.x Binary nach C:\llm\bin\ entpackt
Modell UD-Q4_K_XL von unsloth/Qwen3.6-35B-A3B-GGUF geladen
Teststart ctx 8192 ohne KV-Quant läuft durch
Kohärenztest Schritt 4 bestanden
Vollstart ctx 262144 mit K4/V3 — VRAM check
Falls OOM: ctx auf 131072 reduziert
Cline angebunden, erste Antwort erhalten

Stolpersteine

Stelle	Problem	Lösung
Schritt 2	Falsches Repo	`unsloth/` nicht `HauhauCS/`
Schritt 4	Gibberish	CUDA 13.x Build → CUDA 12.x nehmen
Schritt 5	OOM / VRAM zu hoch	ctx-size auf 131072, nicht Quant ändern
Schritt 5	Gibberish nach Schritt 4 ok	KV-Quant-Inkompatibilität, flash-attn prüfen

Quelle: Tipp von Claude Opus 4.8, Korrekturen eingearbeitet 10.06.2026

## Ziel RTX 3090 als primären lokalen LLM-Server aktivieren. Verzeichnisse `C:\llm\models` und `C:\llm\bin` sind bereits angelegt. ## Finale Konfiguration - **Modell:** Unsloth `UD-Q4_K_XL` (22,4 GB) — Unsloth Dynamic 2.0 Kalibrierung, bei MoE-Modellen qualitativ relevant - **Repo:** `unsloth/Qwen3.6-35B-A3B-GGUF` auf Hugging Face (nicht HauhauCS) - **Backend:** llama.cpp CUDA 12.x (nicht 13.x — Gibberish-Bug) - **KV-Cache:** K=4bit / V=3bit asymmetrisch - **Kontext:** Ziel 256K, Fallback 128K falls VRAM nicht reicht - **Erwartete Geschwindigkeit:** ~100 tok/s - **Kosten:** 0 € --- ## Plan ### Schritt 1 — llama.cpp Binary laden ``` https://github.com/ggml-org/llama.cpp/releases Datei: llama-*-bin-win-cuda12-x64.zip ← NICHT cuda13 Entpacken nach C:\llm\bin\ ``` ### Schritt 2 — Modell laden (22,4 GB) ```powershell curl -L -o C:\llm\models\Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf ` "https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF/resolve/main/Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf" ``` ⚠️ Repo-Name beim Pullen prüfen: `unsloth/Qwen3.6-35B-A3B-GGUF` — nicht die HauhauCS-Variante. ### Schritt 3 — Erster Teststart OHNE KV-Quant, kleiner Kontext ```bat C:\llm\bin\llama-server.exe ^ -m C:\llm\models\Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf ^ -ngl 99 ^ --ctx-size 8192 ^ --flash-attn ^ --jinja ^ --host 127.0.0.1 --port 8080 ``` Ziel: sauberen Build bestätigen, noch keine KV-Quant. ### Schritt 4 — Kohärenztest ```powershell curl http://127.0.0.1:8080/v1/chat/completions ` -H "Content-Type: application/json" ` -d '{"model":"qwen","messages":[{"role":"user","content":"hallo"}],"max_tokens":50}' ``` **Diagnose:** - Gibberish hier → falscher CUDA-Build, anderen Release nehmen - Saubere Antwort → Build ok, weiter zu Schritt 5 - Gibberish erst nach Schritt 5 → KV-Quant-Problem, nicht Build ### Schritt 5 — Vollstart mit KV-Quant und großem Kontext ⚠️ Kritischer Schritt ```bat C:\llm\bin\llama-server.exe ^ -m C:\llm\models\Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf ^ -ngl 99 ^ --ctx-size 262144 ^ --cache-type-k q4_0 ^ --cache-type-v q3_K ^ --flash-attn ^ --jinja ^ --host 127.0.0.1 --port 8080 ``` `nvidia-smi` parallel laufen lassen — VRAM muss unter ~23,5 GB bleiben. **Falls OOM oder VRAM > 23,5 GB:** → Erst `--ctx-size 131072` versuchen, NICHT am Quant drehen. 128K ist immer noch weit über dem Cursor-Bedarf. 256K beim ersten Versuch ist nicht garantiert. ### Schritt 6 — Cline anbinden - VS Code → Cline → Settings → API Provider: **OpenAI Compatible** - Base URL: `http://127.0.0.1:8080/v1` - API Key: beliebig (wird ignoriert) - Context Window: je nachdem was in Schritt 5 gelaufen ist (262144 oder 131072) --- ## Checkliste - [ ] llama.cpp CUDA 12.x Binary nach `C:\llm\bin\` entpackt - [ ] Modell `UD-Q4_K_XL` von `unsloth/Qwen3.6-35B-A3B-GGUF` geladen - [ ] Teststart ctx 8192 ohne KV-Quant läuft durch - [ ] Kohärenztest Schritt 4 bestanden - [ ] Vollstart ctx 262144 mit K4/V3 — VRAM check - [ ] Falls OOM: ctx auf 131072 reduziert - [ ] Cline angebunden, erste Antwort erhalten --- ## Stolpersteine | Stelle | Problem | Lösung | |---|---|---| | Schritt 2 | Falsches Repo | `unsloth/` nicht `HauhauCS/` | | Schritt 4 | Gibberish | CUDA 13.x Build → CUDA 12.x nehmen | | Schritt 5 | OOM / VRAM zu hoch | ctx-size auf 131072, nicht Quant ändern | | Schritt 5 | Gibberish nach Schritt 4 ok | KV-Quant-Inkompatibilität, flash-attn prüfen | *Quelle: Tipp von Claude Opus 4.8, Korrekturen eingearbeitet 10.06.2026*

orbitalo commented

2026-06-11 15:10:44 +00:00

Author

Owner

Erledigt – 11.06.2026

Abweichungen vom ursprünglichen Plan

Modell gewechselt: Statt Unsloth UD-Q4_K_XL → HauhauCS IQ4_XS (uncensored, 17.4 GB)
- Begründung: Unsloth belegte 22.7 GB VRAM, ließ kaum Kontext übrig. HauhauCS IQ4_XS beläuft auf ~19.8 GB → 4.3 GB frei für KV-Cache = 131K Kontext realistisch
- Bonus: 0/465 Refusals (uncensored)
llama.cpp: b9561 (CUDA 12.4), kein beellama
Kontext: 131072 statt 256K (VRAM-Limit bei einem 24 GB GPU)

Stabiler Startbefehl

C:\llm\bin\llama-server.exe ^
  -m C:\llm\models\Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive-IQ4_XS.gguf ^
  -ngl 99 -np 1 ^
  --ctx-size 131072 ^
  --cache-type-k q4_0 --cache-type-v iq4_nl ^
  --flash-attn on --jinja --reasoning off ^
  --host 0.0.0.0 --port 8080

Learnings

-np 1 ist Pflicht – 4 Slots à 131K = OOM-Crash
--reasoning off nötig, sonst verbrennt das Modell alle Tokens im Thinking-Block
q3_K gibt es in b9561 nicht → iq4_nl für V-Cache
Server läuft als Windows Task Scheduler Task (SYSTEM) – überlebt SSH-Trennung und Neustarts
Firewall-Regel für TCP 8080 gesetzt

Checkliste

llama.cpp CUDA 12.x Binary nach C:\llm\bin\ entpackt
Modell IQ4_XS von HauhauCS/Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive geladen
Teststart ctx 8192 ohne KV-Quant läuft durch
Kohärenztest bestanden (Berlin, München, Hamburg – saubere Antwort)
Vollstart ctx 131072 mit K=q4_0/V=iq4_nl – VRAM 19.8 GB, 4.3 GB frei
Server via Task Scheduler dauerhaft eingerichtet
API von Homelab-Nodes erreichbar (getestet von pve-hetzner)
Cline anbinden (nächster Schritt)

## Erledigt – 11.06.2026 ### Abweichungen vom ursprünglichen Plan - **Modell gewechselt:** Statt Unsloth `UD-Q4_K_XL` → **HauhauCS `IQ4_XS`** (uncensored, 17.4 GB) - Begründung: Unsloth belegte 22.7 GB VRAM, ließ kaum Kontext übrig. HauhauCS IQ4_XS beläuft auf ~19.8 GB → 4.3 GB frei für KV-Cache = 131K Kontext realistisch - Bonus: 0/465 Refusals (uncensored) - **llama.cpp:** b9561 (CUDA 12.4), kein beellama - **Kontext:** 131072 statt 256K (VRAM-Limit bei einem 24 GB GPU) ### Stabiler Startbefehl ```bat C:\llm\bin\llama-server.exe ^ -m C:\llm\models\Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive-IQ4_XS.gguf ^ -ngl 99 -np 1 ^ --ctx-size 131072 ^ --cache-type-k q4_0 --cache-type-v iq4_nl ^ --flash-attn on --jinja --reasoning off ^ --host 0.0.0.0 --port 8080 ``` ### Learnings - `-np 1` ist Pflicht – 4 Slots à 131K = OOM-Crash - `--reasoning off` nötig, sonst verbrennt das Modell alle Tokens im Thinking-Block - `q3_K` gibt es in b9561 nicht → `iq4_nl` für V-Cache - Server läuft als Windows Task Scheduler Task (SYSTEM) – überlebt SSH-Trennung und Neustarts - Firewall-Regel für TCP 8080 gesetzt ### Checkliste - [x] llama.cpp CUDA 12.x Binary nach `C:\llm\bin\` entpackt - [x] Modell `IQ4_XS` von `HauhauCS/Qwen3.6-35B-A3B-Uncensored-HauhauCS-Aggressive` geladen - [x] Teststart ctx 8192 ohne KV-Quant läuft durch - [x] Kohärenztest bestanden (`Berlin, München, Hamburg` – saubere Antwort) - [x] Vollstart ctx 131072 mit K=q4_0/V=iq4_nl – VRAM 19.8 GB, 4.3 GB frei - [x] Server via Task Scheduler dauerhaft eingerichtet - [x] API von Homelab-Nodes erreichbar (getestet von pve-hetzner) - [ ] Cline anbinden (nächster Schritt)

orbitalo referenced this issue

2026-06-11 18:38:41 +00:00

[Session 2026-06-11] Cline intensiv testen & einstellen (lokales Qwen läuft) #100

orbitalo commented

2026-06-11 18:50:04 +00:00

Author

Owner

Abgeschlossen 11.06.2026 — Ziel erreicht, aber anderer Weg

Das Kernziel dieser Issue (RTX 3090 als lokaler LLM-Server für Cline) ist erreicht. Der hier geplante llama.cpp-Weg wurde NICHT genommen — stattdessen Ollama, weil es auf dem KI-Server längst lief und die gleichen GGUF-Modelle bedient, ohne den ganzen Binary-/Argument-/Persistenz-Aufwand von llama.cpp.

Was anders lief als im Plan

Plan (#99)	Tatsächlich umgesetzt
Backend llama.cpp CUDA 12.x	Ollama (lief schon, stabiler für Cline)
Modell Unsloth UD-Q4_K_XL (22,4 GB)	HauhauCS uncensored IQ4_XS (17,4 GB) — kleiner = mehr Platz für Kontext, und uncensored war ausdrücklich gewünscht
KV-Quant K4/V3, ctx 256K	Aktuell 98K nativ (kein KV-Quant), Modell kann 256K
Cline via OpenAI-Compatible :8080	Cline via nativem Ollama-Provider :11434 — über den /v1-Pfad blieb `content` bei Thinking-Modellen leer

Learnings (Details in #100)

llama.cpp war ein Umweg — erst Ist-Zustand prüfen, dann bauen.
Ollama kann Thinking nur per Request-Param think:false abschalten, nicht per Modelfile.
Größeres Modell = weniger Kontext-VRAM. Kleineres uncensored war die bessere Wahl.

Offen → verschoben nach #100

KV-Cache-Quantisierung + Kontext auf 160K–256K
Heunadel-Test (needle-in-haystack)
llama.cpp-Reste auf dem KI-Server aufräumen

Schließe diese Issue. Weiterarbeit läuft über #100.

## Abgeschlossen 11.06.2026 — Ziel erreicht, aber anderer Weg Das **Kernziel** dieser Issue (RTX 3090 als lokaler LLM-Server für Cline) ist erreicht. Der hier geplante **llama.cpp-Weg wurde NICHT genommen** — stattdessen Ollama, weil es auf dem KI-Server längst lief und die gleichen GGUF-Modelle bedient, ohne den ganzen Binary-/Argument-/Persistenz-Aufwand von llama.cpp. ### Was anders lief als im Plan | Plan (#99) | Tatsächlich umgesetzt | |---|---| | Backend llama.cpp CUDA 12.x | **Ollama** (lief schon, stabiler für Cline) | | Modell Unsloth UD-Q4_K_XL (22,4 GB) | **HauhauCS uncensored IQ4_XS (17,4 GB)** — kleiner = mehr Platz für Kontext, und uncensored war ausdrücklich gewünscht | | KV-Quant K4/V3, ctx 256K | Aktuell **98K nativ** (kein KV-Quant), Modell kann 256K | | Cline via OpenAI-Compatible :8080 | Cline via **nativem Ollama-Provider** :11434 — über den /v1-Pfad blieb `content` bei Thinking-Modellen leer | ### Learnings (Details in #100) - llama.cpp war ein Umweg — erst Ist-Zustand prüfen, dann bauen. - Ollama kann Thinking nur per Request-Param `think:false` abschalten, nicht per Modelfile. - Größeres Modell = weniger Kontext-VRAM. Kleineres uncensored war die bessere Wahl. ### Offen → verschoben nach #100 - KV-Cache-Quantisierung + Kontext auf 160K–256K - Heunadel-Test (needle-in-haystack) - llama.cpp-Reste auf dem KI-Server aufräumen Schließe diese Issue. Weiterarbeit läuft über **#100**.

orbitalo closed this issue

2026-06-11 18:50:10 +00:00