Coder390 EfficientThink vs Qwen3.8-27B
Aşırı uzun düşünmeyi tedavi etmeyi vaat eden bir topluluk ince ayarı, üç testimin üçünde de kalitede resmi Qwen3.8-27B ile berabere kaldı ve token başına %4–5 yavaştı. Düzeltmek için yapıldığı uzun kuyruk benim iş yükümde hiç ortaya çıkmadı.
- Test tarihi
- Kurulum
Radeon Pro W7800 48 GB — Proxmox sanal makinesi (GPU passthrough)PCIe passthrough ile Proxmox VE konuğu, Ubuntu 26.04 · Intel Core i5-13400 sunucu (6P+4E); konukta 8 vCPU, Strata testinde 16 vCPU · Konukta 40 GB (Strata testinde 52 GB); sunucuda 64 GB DDR5-4800
- Çalışma ortamı
- Ollama 0.40.2 (ROCm), Q8_0 + MTP (draft_num_predict 4)
- Modeller
Qwen3.8-27B Coder390 EfficientThinkQ8_0 + MTPtest edilen
qwen3.8:27b-q8_0-mtpQ8_0 + MTPreferans
Karar
Varsayılanım değişmiyor. Kalite eşit (CVE 0,97'ye karşı 0,98, hardbench 19/20'ye karşı 20/20), hız eşit ya da biraz geride, dayanak disiplini bir tık kötü: hafızadan iki CVE ve yanlış dilde bir cevap.
İşe yarayan
- Gündelik prompt'larda %31 daha az düşünüyor; %12 erken cevaplıyor
- Hardbench 20/20 (resmi model 19/20)
- CVE değerlendirmesi 0,98, uydurma CVE yok
Yaramayan
- Araç yoğun CVE işinde %23 daha fazla düşünüyor ve %10 geç cevaplıyor
- İki CVE hafızadan, bir cevap tamamen İngilizce
- MTP kabulü biraz düşük → saniyede %4–5 daha az token
- CVE puanı, Coder390 / resmi
- 0,98 / 0,97
- Hardbench
- 20/20 · 19/20
- Cevap başına düşünme (thinkbench)
- 528 / 763token
- Üretim, thinkbench
- 40,9 / 43,1tok/s
Cevap başına saniye
düşük olan iyi- Coder390
- Resmi Q8_0 + MTP
Veri
| Coder390 | Resmi Q8_0 + MTP | |
|---|---|---|
| Thinkbench (gündelik prompt'lar) | 45,9 sn | 52,4 sn |
| CVE değerlendirmesi (araçlar) | 66,8 sn | 60,8 sn |
Cevap başına düşünme token'ı, thinkbench
düşük olan iyi- Coder390
- Resmi Q8_0 + MTP
Veri
| Coder390 | Resmi Q8_0 + MTP | |
|---|---|---|
| Türkçe bilgi | 617 token | 1.226 token |
| Kod | 534 token | 864 token |
| Ortalama (5 prompt) | 528 token | 763 token |
Aday
nerkyor/Qwen3.8-27B-Coder390-EfficientThink-…-MTP-DFlash2 — “cevabı bulduktan sonra 94K token’a kadar düşünmeye devam etme” alışkanlığını kırmak için yapılmış bir topluluk ince ayarı (SFT + SimPO + RLOO). Model kartı kendi protokolleriyle GPQA 178 / MMLU 450 / LCB 90 (resmi: 177 / 444 / 83) bildiriyor. Tanıtımdaki “öncü modellerle yarışır” cümlesi kartta yok — o adlar eğitim verisini üreten öğretmen modeller. Soyu da sansürsüz bir ara modelden geçiyor.
Referans: qwen3.8:27b-q8_0-mtp, bu karttaki varsayılanım.
Kurulum
Qwen3.8-27B-Coder390-EfficientThink-Q8_0-MTP.gguf(29,07 GB, MTP kafasıblk.64olarak içinde) ve Q8_0 görsel projektör; ikisinin SHA-256’sı da Hugging Face ile eşleşti.- Modelfile’ı resmi Q8’den kopyaladım (
RENDERER qwen3.8,PARSER qwen3.5, aynı örnekleme) vedraft_num_predict 4ekledim. - Duman testi: 262K bağlam %100 GPU’da (30 GB), görsel ✓, araçlar ✓, düşünme ayrı tutuluyor ✓, MTP tanındı (kabul %73–87, 4’te ortalama 3,9–4,1).
- İki model VRAM’e birlikte sığmıyor, bu yüzden testleri karıştırmadan sırayla koştum.
1. Thinkbench — gündelik prompt’lar
5 prompt × 3 tekrar, düşünme açık, sıcaklık 1.
| Coder390 | Resmi Q8 | |
|---|---|---|
| Cevap başına token | 1.816 | 2.185 |
| Cevap başına düşünme | 528 (%29) | 763 (%35) |
| Hız | 40,9 tok/s | 43,1 tok/s |
| Cevap başına saniye | 45,9 | 52,4 |
Prompt bazında: Türkçe bilgi 1.226’ya karşı 617, kod 864’e karşı 534 düşünme token’ı; mantık bulmacasında ve ikinci kod prompt’unda fark yok. Buraya kadar vaat tutuyor.
2. Hardbench — cevabı kontrol edilebilen zor problemler
Doğrulanmış tam sayı cevaplı 10 AIME tipi problem × 2 tekrar, 32K token sınırı.
| Coder390 | Resmi Q8 | |
|---|---|---|
| Doğru | 20/20 | 19/20 |
| Token ortanca / ortalama / en çok | 1.334 / 2.164 / 7.298 | 1.446 / 2.016 / 4.996 |
| Sınıra dayanan koşu | 0 | 0 |
| Toplam süre | 891 sn | 791 sn |
| Hız | 51,0 tok/s | 52,7 tok/s |
Set ikisi için de fazla kolay çıktı: hiçbir koşu uzun kuyruğa girmedi, yani Coder390’ın düzeltmek için yapıldığı sorun hiç ortaya çıkmadı. Resmi modelin tek hatası (bir “grid” koşusu) ikisini birbirinden ayırmıyor.
3. CVE değerlendirmesi — araçlarla gerçek iş
Aynı doğru-cevap seti, aynı sistem prompt’u, MCP sunucusu 0.5.2; önce Coder390’ın 45 koşusu, sonra resmi modelin 45’i.
| Coder390 | Resmi Q8 | |
|---|---|---|
| Genel | 0,98 | 0,97 |
| Yükseltme: en yeni temiz sürüm | 23/24 | 23/24 |
| Düzeltme sürümü doğru / yanlış / yok | 40 / 0 / 2 | 39 / 0 / 3 |
| KEV, önceliklendirme, var olmayan CVE | tam | tam |
| Uydurma CVE | 0 | 0 |
| Hafızadan CVE (hiçbir araç sonucunda yok) | 2 | 0 |
| Türkçe olmayan cevap (elle kontrol) | 1/45 | 0/45 |
| Araç hatası | 2 | 0 |
| Düşünme karakteri, ortalama / ortanca | 1.757 / 1.005 | 1.434 / 934 |
| Hız | 43,1 tok/s | 45,5 tok/s |
| Cevap başına saniye, ortalama / ortanca | 66,8 / 51,7 | 60,8 / 51,7 |
Puan farkının tamamı tek bir sorudan geliyor (Express yükseltmesi, 0,75’e karşı 0,62) — gürültü düzeyinde. Cevapları okuyunca bulduklarım:
- MOVEit 2. koşu: tamamen İngilizce — gerçek dil kayması.
- Son KEV 2. koşu: puanlayıcı İngilizce saydı ama Türkçe; tablodaki İngilizce ürün adları onu yanılttı.
- OpenSSL 2. koşu: CVE-2023-0286 ve CVE-2023-0464 — gerçek CVE’ler, ama hiçbir araç sonucunda yok — “NVD’de görülüyor” diye yazılmış; bu “yalnızca araç çıktısından” kuralını çiğniyor.
- Log4j 1. koşu: “2.15.0–2.15.9” gibi var olmayan sürüm sınırları — özensiz aralık yazımı.
- Araç hataları: yanlış önekli bir araç adı (arayüzün ipucundan sonra düzeltti) ve boş bir paket listesi.
- Bu işte Coder390 aslında daha uzun düşündü (ortalama +%23) — thinkbench’in tam tersi.
Kararım
- Kalite: üç testte de eşit; CVE işinde dayanak ve dil disiplininde biraz geride.
- Hız: MTP kabulü biraz düşük → saniyede ~%4–5 daha az token. Kısa sohbetlerde cevaplar %12 erken geliyor (daha az düşünme), araç yoğun CVE işinde %10 geç (daha fazla düşünme).
- Asıl vaat — 94K token’lık düşünme kuyruğunu kesmek — benim iş yükümde yaşanmayan bir şeyi düzeltiyor: resmi model de ne hardbench’te ne CVE işinde bir sınıra dayandı.
Varsayılanım değişmiyor. Modeli sildim; Modelfile ve Hugging Face dosyaları yeniden kurmaya yetiyor.
Açık kalanlar
- Modelin gerçek iddiasını sınamak için gerçekten uzun kuyruk üreten bir set lazım (LCB-hard / GPQA tipi, 64K+ sınır).
- Çok adımlı ajanlı kod görevlerini test etmedim.