Qwen3.6-27B na Vast.ai — benchmark coding + decyzja zakupowa GPU

Data: 2026-04-23. Model: Qwen/Qwen3.6-27B (wydany 2026-04-22, flagship coding, SWE-bench Verified 77.2%). Klient: pi-mono v0.69.0 (coding agent CLI Mario Zechnera).

TL;DR

• Cel: sprawdzić czy warto kupować RTX 4090 / 5090 / PRO 6000 Blackwell / H100 do lokalnego coding agenta na Qwen3.6-27B
• Metoda: 4 zadania kodowania (unit tests, bug fix, refactor, debug) uruchomione przez pi-mono przez SSH tunel do Vast.ai
• Testowane: faza A — RTX 4090 24GB + Ollama Q4_K_M; faza B — PRO 6000 Blackwell 96GB + vLLM FP8
• Wynik prędkości: 4090 = 18.3 tok/s, PRO 6000 = 37.5 tok/s (2.05×)
• Wynik jakości: 4/4 zadań zielone na obu konfiguracjach
• Koszt całości: ~$1 (Vast.ai on-demand)
• Wniosek: 4090 spokojnie wystarcza do realnego coding agenta na 27B Q4 — odczuwalnie wolniejsze niż PRO 6000 ale funkcjonalnie pełne. PRO 6000 to 2× speed + 4× VRAM (dla 70B) za 4-5× cenę.

Kontekst i cel

Rozważane GPU (decyzja zakupowa solo devs / małe zespoły):

| GPU | VRAM | Cena ~ | Status |
|---|---|---|---|
| RTX 4090 | 24 GB | ~$1800 used | przetestowane |
| RTX 5090 | 32 GB | ~$2500-3000 | pominięto (brak NVLink blokuje TP) |
| 2× RTX 5090 | 64 GB | ~$5000-6000 | pominięto (PCIe bez NVLink → bottleneck) |
| RTX PRO 6000 Blackwell | 96 GB | ~$8-10k | przetestowane |
| H100 80GB | 80 GB | ~$25k | pominięto (nie-zakupowe dla osoby) |

Test case: coding agent używający tool callingu (read, write, edit, bash) w realnych zadaniach programistycznych w Pythonie.

Setup — klient lokalny

Instalacja: npm install -g @mariozechner/pi-coding-agent. Konfiguracja providerów w pliku ~/.pi/agent/models.json — dwóch providerów typu openai-completions, jeden dla Ollamy na porcie 11434 (model qwen3.6:27b), drugi dla vLLM na porcie 8001 (model Qwen/Qwen3.6-27B-FP8). Oba mają compat.thinkingFormat: qwen-chat-template (pi wysyła chat_template_kwargs.enable_thinking), supportsDeveloperRole: false (Ollama/vLLM nie mają roli developer), reasoning: true (pi oczekuje pola reasoning w odpowiedzi).

Setup — Vast.ai

Oba scenariusze: instancja on-demand (nie serverless). Własne skrypty zarządzające: offers.py (non-interactive wyświetlenie ofert GPU), instance.py (list/ssh/destroy), create_by_id.py (Ollama instance), create_vllm.py (vLLM instance).

Ważne: klucz SSH musi być zarejestrowany na koncie Vast.ai (panel web lub vast.create_ssh_key). Bez tego dostaniesz "Permission denied (publickey)". Po rejestracji klucza propagacja trwa ~15-30s.

Test suite

4 zadania w katalogu benchmark/tasks/:

| # | Nazwa | Co testuje | Min. tool calls |
|---|---|---|---|
| 01 | fibonacci-memo | funkcja + testy | write×2, bash×1 |
| 02 | fix-strip-thinking | bug fix z tool calls | read, edit, bash×2 |
| 03 | long-context-refactor | refactor 300-linijkowego modułu | read, write/edit, bash |
| 04 | debug-failing-test | off-by-one w pętli | read, edit, bash×2 |

Runner benchmark/runner.sh parametryzowany przez env (PROVIDER, MODEL, PORT_CHECK, RUN_TAG). Loguje wall time przez /usr/bin/time -v i pełne sesje pi (--session-dir).

Faza A — RTX 4090 24GB + Ollama Q4_K_M

Oferta: id=35433708, Hungary, $0.341/h (7 Gbps down — pull 17 GB modelu w ~30s). Obraz ollama/ollama, model qwen3.6:27b (default Q4_K_M, 17 GB wag). Deployment: SSH → ollama serve & → ollama pull qwen3.6:27b → smoke test → SSH tunel 11434.

Wyniki

| Zadanie | Wall | Tok/s | In / Out tok | Thinking | Tool calls |
|---|---|---|---|---|---|
| 01 Fibonacci | 48.7 s | 17.1 | 8 464 / 835 | ~80 | write×2, bash×1 |
| 02 Fix strip_thinking | 54.4 s | 16.7 | 15 382 / 906 | ~247 | bash×2, read×2, edit×1 |
| 03 Refactor 300-linii | 269.4 s | 19.0 | 60 109 / 5 128 | ~459 | bash×3, read×2, write×2 |
| 04 Debug off-by-one | 37.2 s | 16.7 | 14 582 / 621 | ~115 | read×2, bash×2, edit×1 |
| TOTAL | 409.7 s | 18.3 | 98 537 / 7 490 | | 20 tool calls, 0 błędów |

Obserwacje:

• Jakość: 4/4 zielone. Qwen3.6 Q4_K_M poradził sobie idiomatycznie — @lru_cache dla Fibonacciego z 7 testami, poprawna diagnoza bug-a i jednolinijkowa poprawka, refactor 300→256 linii (-15%), poprawna diagnoza off-by-one.
• VRAM: 22.5 / 24 GiB (92%) — ciasno, zero zapasu na większy kontekst.
• Tool calling: 20/20 udanych — znany problem z qwen3.5 w Ollama wygląda na naprawiony w 3.6 + Ollama 0.21.1.
• Thinking: adaptuje się do złożoności (80 tok dla Fibonacciego, 459 tok dla refactoru).
• Bottlenecki: ~17 tok/s to sufit 27B Q4 na 4090. Ollama bez persistent KV cache — każdy tool call = prompt re-processing. Model wyładowuje się z VRAM po 5-10 min idle (naprawione przez keep_alive: -1).

Faza B — PRO 6000 Blackwell 96GB + vLLM FP8

Oferta: id=30474088, Czechia, $1.122/h (8.7 Gbps down — pull 27 GB wag FP8 w 28.4s). GPU: NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation (96 GB, CUDA 13.1). Obraz vllm/vllm-openai:latest (vLLM 0.19.1). Model Qwen/Qwen3.6-27B-FP8 (oficjalny fine-grained FP8, block size 128). Flagi vLLM: --max-model-len 65536, --gpu-memory-utilization 0.90, --reasoning-parser qwen3, --enable-auto-tool-choice --tool-call-parser qwen3_coder.

Wyniki

| Zadanie | Wall | Tok/s | In / Out tok |
|---|---|---|---|
| 01 Fibonacci | 21.6 s | 34.1 | 12 567 / 719 |
| 02 Fix strip_thinking | 24.6 s | 32.3 | 22 148 / 761 |
| 03 Refactor 300-linii | 253.0 s | 38.9 | 89 821 / 9 880 |
| 04 Debug off-by-one | 19.9 s | 29.5 | 21 542 / 598 |
| TOTAL | 319.1 s | 37.5 | 146 078 / 11 958 |

Obserwacje:

• Jakość: 4/4 zielone — identycznie jak na 4090, ta sama jakość diagnoz i rozwiązań.
• VRAM: 28.5 / 96 GiB (30%) — ogromny zapas na długi kontekst i batching.
• Startup: pierwsza kompilacja torch.compile ~3 min z zimnego cache. Z cache: 5.7s load wag + ~1 min graph capture.
• Więcej tokenów outputu (12k vs 7.5k): model na FP8 jest bardziej "gadatliwy" w thinkingu — pełna precyzja skutkuje dłuższym rozumowaniem. Zadanie 03 speedup wall tylko 1.06× mimo 2× szybszego tok/s właśnie dlatego.
• Continuous batching vLLM teoretycznie skraca tool-call round-trips (persistent KV cache), ale dla pojedynczego użytkownika efekt ograniczony.

Porównanie apples-to-apples

| Zadanie | 4090 Q4 Ollama | PRO 6000 FP8 vLLM | Speedup wall | Speedup tok/s |
|---|---|---|---|---|
| 01 Fibonacci | 48.7 s @ 17.1 tok/s | 21.6 s @ 34.1 tok/s | 2.26× | 2.00× |
| 02 Fix bug | 54.4 s @ 16.7 tok/s | 24.6 s @ 32.3 tok/s | 2.21× | 1.94× |
| 03 Refactor | 269.4 s @ 19.0 tok/s | 253.0 s @ 38.9 tok/s | 1.06× | 2.05× |
| 04 Debug | 37.2 s @ 16.7 tok/s | 19.9 s @ 29.5 tok/s | 1.87× | 1.77× |
| TOTAL | 409.7 s @ 18.3 tok/s | 319.1 s @ 37.5 tok/s | 1.28× | 2.05× |

Interpretacja:

• Per-token throughput: stabilne ~2× na korzyść PRO 6000. To twardy sufit architekturalny — memory bandwidth, compute.
• Wall time speedup różny (1.06-2.26×) — zależy od relacji input/output. PRO 6000 generował ~60% więcej tokenów, więc "dłużej pracował" mimo szybszej generacji.
• Jakość: parity — 4/4 vs 4/4. Q4_K_M nie "gubi" zdolności kodowania wobec FP8 na tych zadaniach.
• Kontekst: 4090 realny max 32K (ciasno), PRO 6000 realny 128-200K komfortowo, 256K+ z --kv-cache-dtype fp8.

Znaleziska techniczne — gotchas i fixe

1. Qwen3.6 zawsze thinking — nie da się łatwo wyłączyć. chat_template_kwargs.enable_thinking: false przez Ollama /v1/chat/completions jest ignorowany. /no_think w user message też ignorowany. Qwen3.6 niezmiennie generuje thinking w message.reasoning (content pusty jeśli max_tokens < thinking_length). Fix: dawać max_tokens >= 2000 dla nawet prostych pytań; akceptować narzut ~100-500 tok thinkingu.

2. Tool call parser w vLLM — Qwen3.6 używa XML, nie JSON. Domyślny --tool-call-parser hermes (JSON) nie parsuje Qwen3.6. Fix: --tool-call-parser qwen3_coder (dedykowany parser w vLLM 0.19). Bez tego parsera finish_reason: stop, content z XML-em, tool_calls: [] — pi nie wywoła narzędzi.

3. args_str + runtype=args przy create_instance (on-demand) — ignorowane. Działa tylko dla serverless endpoint API. Dla on-demand trzeba SSH i ręczny vllm serve.

4. Ollama model wyładowanie po ~10 min idle. Po bezczynności model znika z VRAM, pierwszy request cold-loaduje (~60s dla 17 GB). Fix: zapytanie do /api/generate z keep_alive: -1 albo zmienna środowiskowa OLLAMA_KEEP_ALIVE=-1.

5. vLLM i zombie EngineCore po pkill. pkill -f vllm nie łapie procesu VLLM::EngineCore (wielkie litery). Po restarcie: ValueError: Free memory 7.52/94.97 GiB — stary EngineCore wciąż trzyma wagi. Fix: pkill -9 -i vllm; pkill -9 -f EngineCore lub kill -9 <PID> bezpośrednio.

6. Vast.ai SSH — "Too many authentication failures". Klient próbuje wszystkich kluczy z ~/.ssh/, Vast odrzuca. Fix: -i ~/.ssh/id_ed25519_vast -o IdentitiesOnly=yes.

7. Vast.ai — klucz SSH musi być zarejestrowany. vast.create_ssh_key(ssh_key=<pubkey>) + chwila na propagację (15-30s).

8. Model rodziny qwen3.6:27b w Ollama — tylko Q4_K_M zmieści się na 24 GB. Q8 (30 GB) nie wchodzi. nvfp4 tylko Blackwell. Coding fine-tune tylko w bf16/mxfp8/nvfp4 (brak Q4/Q5). Q5_K_M nie istnieje w oficjalnej bibliotece Ollama — trzeba GGUF z Unsloth + import Modelfile.

9. SSH tunel — kolizja z lokalnym portem 8000. Fix: tunel -L 8001:localhost:8000 + baseUrl z portem 8001.

10. Ollama MoE perf na GPU. Znany issue — MoE modele (qwen3:30b-a3b) mają "poor GPU utilization" w Ollama. Dla MoE fallback na vLLM jest bezpieczniejszy.

Koszty

| Faza | GPU | Czas | Cena/h | Koszt |
|---|---|---|---|---|
| A | RTX 4090 | ~25 min | $0.341 | ~$0.14 |
| B | PRO 6000 WS | ~45 min | $1.171 | ~$0.88 |
| — | — | — | — | Total: ~$1.02 |

Dla porównania: RTX 4090 za $1800 to równoważność 5300 godzin na Vast.ai przy $0.34/h — mało sensowne by nie kupić jeśli używasz regularnie. PRO 6000 za $8000 to ~6800 godzin przy $1.17/h — break-even około 280 dni 24/7.

Wnioski zakupowe

Jeśli budżet ≤ $2000: RTX 4090 24 GB. 4/4 zadań przeszło — agent kodujący na Qwen3.6-27B Q4_K_M działa funkcjonalnie pełno. ~17-18 tok/s, odczuwalnie wolne ale użyteczne dla pair-programming. Ograniczenie: kontekst realnie 32K, tylko Q4 mieści się, nie otworzy drzwi do 70B.

Jeśli budżet ≤ $3000: RTX 5090 32 GB. Niezweryfikowane, ale logika: więcej VRAM niż 4090 → Q5/Q6 mieszczą się z zapasem, prawdopodobnie +30-50% tok/s (GDDR7, Blackwell). UWAGA: 2× 5090 bez NVLink = PCIe bottleneck dla tensor parallelism. Nie kupuj dwóch jeśli cel to 1 duży model.

Jeśli budżet ~$8-10k: RTX PRO 6000 Blackwell 96 GB. 2× szybsze niż 4090 (zmierzone). 4× VRAM otwiera drzwi do 70B Q4 i 30B+ MoE. Długi kontekst (128-256K) bez kompromisów. Single card — brak NCCL/PCIe headache. ROI vs Vast.ai około 280 dni 24/7.

Jeśli "chcę mieć dostęp ale nie codziennie": Vast.ai on-demand. $0.34-1.17/h za session kodowania. Re-setup w 2 min (model cached w Vast machine albo pulli w ~30s). Ten projekt kosztował ~$1 za komplet danych do decyzji.

Co NIE warto. H100 — nierealne cenowo ($25k+), chmura tak (~$1.87/h). 2× RTX 5090 — PCIe bez NVLink psuje TP; 2× throughput tylko przy data parallelism. 1× RTX 5090 dla vLLM FP8 Qwen3.6-27B — ciasne (27 GB wag na 32 GB, krótki kontekst). Lepiej Ollama Q4/Q5.

FAQ

Czy Q4_K_M jest "za słabe" dla coding? Nie — na naszych 4 zadaniach jakość = FP8 (4/4 vs 4/4). Dla bardzo trudnych agentic tasków (duży repo, wielokrokowy reasoning) mogłaby być różnica — nie testowano.

Czy thinking mode spowalnia? Marginalnie. Thinking to ~10-20% tokenów output w naszych zadaniach. Większy koszt to bazowa prędkość tok/s i prompt re-processing przy tool calls.

Dlaczego Ollama a nie vLLM na 4090? Ollama just works z Q4_K_M i 17 GB. vLLM na 4090 wymaga kompromisu (bitsandbytes 4-bit z dużym overhead + brak miejsca na KV cache). vLLM błyszczy od ~40+ GB VRAM.

Czy warto eksperymentować z większym kontekstem? Na PRO 6000: tak (128-256K realne). Na 4090: nie (KV cache gryzie się z wagami; 32K to górny sensowny).

Czy pi-mono jest lepsze od innych coding agentów? Nie testowaliśmy porównawczo. Plus: unified API (OpenAI/Anthropic/Google/custom), custom providerzy bez kodu, qwen-chat-template ready, sesja + compaction + resume. Minus: CLI only (brak IDE), mniej toolkitów niż Claude Code, społeczność mniejsza.

Projekt wykonany w ramach sesji Claude Code 2026-04-23. Wszystkie pomiary pochodzą z rzeczywistych uruchomień na infrastrukturze Vast.ai.