pi harness: Qwen3.8-27B Q4_K_M vs Q8_0

pi nedir

pi, MIT lisanslı bir TypeScript ajan harness’ı (~250K satır, 453 test dosyası). Sağlayıcı katmanı ~40 sağlayıcının tuhaflıklarını veri olarak tutuyor — bağlam taşmasının tespiti bile sağlayıcı başına bir regex tablosu. Bilerek olmayanlar: MCP, alt ajanlar, izin soruları, plan modu, yapılacaklar listesi, arka plan bash’i. Elinizde yedi araç var — bash read write edit ls grep find — gerisi eklenti.

İzin sistemi yok. pi, onu başlatan kullanıcının bütün yetkileriyle çalışıyor; onay sorusu yok, dosya, süreç, ağ ya da kimlik bilgisi kısıtı yok. Bir container’da ya da ayrı bir VM’de çalıştırın — bu bir incelik değil, ön koşul.

Nasıl test ettim

pi’ı yalıtılmış bir npm önekine kurdum, yapılandırmasını PI_CODING_AGENT_DIR ile başka yere yönlendirdim. Modeli OpenAI uyumlu bir sağlayıcı olarak ekledim (supportsDeveloperRole: false, thinkingFormat: qwen-chat-template, sıcaklık 0,7, top_p 0,8, top_k 20).

Cevabı objektif olan iki görev seçtim — karar pytest’in, benim değil — ve çalışma ağacını her koşudan önce git checkout ile sıfırladım.

• Görev A — hata avı. 5 testli küçük bir Python projesi, biri düşüyor: largest_debit() worst_value = Decimal("0") ile başlıyor, bu yüzden bütün bakiyeler pozitifken None dönüyor. Ancak testi okuyunca fark edilen tek satırlık bir mantık hatası.
• Görev B — çok dosyalı özellik. Henüz var olmayan bir özelliği tarif eden 6 test: Entry dataclass’ına yeni bir alan, değişen bir post() imzası, Ledger.balance_as_of() ve report.monthly_summary() — iki dosyada birbirine bağlı dört değişiklik.

İki projenin AGENTS.md’si de “tests/ altını değiştirme” diyordu; her edit/write çağrısının hedef yolunu kontrol ettim.

Sonuçlar

Yanıldığım tahmin: birebir eşleşmeli edit

Ölçmeden önce, birebir metin isteyen edit aracının bir 27B’nin tökezleyeceği yer olacağından emindim — boşluk kayması, bayat oldText, tekrar denemeler. Gerçekte olan: 13 koşuda 32 düzenleme bloğu, sıfır başarısızlık. Görev B’de model üç değişikliği blok dizisiyle tek bir edit çağrısında gönderdi ve hepsi uygulandı.

Düzenleme hataları model boyutunu değil bağlamın ne kadar taze olduğunu izliyor gibi: pi modele dosyayı düzenlemeden hemen önce okutuyor, araya da pek bir şey girmiyor. Uzun, dağınık oturumlar farklı davranabilir.

Yamaların kalitesi

Görev A’nın beş koşusu da birebir aynı yamayı üretti — üstelik artık yanlış hâle gelen docstring’i de düzeltti:

-    """Return the account with the most negative balance, or None if empty."""
+    """Return the account with the lowest balance, or None if empty."""
-    worst_value = Decimal("0")
+    worst_value = None
-        if value < worst_value:
+        if worst_value is None or value < worst_value:

Q8_0 daha iyi değil, yalnızca daha pahalı

Bir Q8 koşusu testler zaten geçtikten sonra iki kozmetik düzenleme daha yaptı — bu kalite değil, gevezelik.

Bekleme nereye gidiyor

pi’ın sistem prompt’u + 7 araç şeması + projenin AGENTS.md’si + görev = 1.917 token. Ağır bir kod asistanı aynı noktada 10–15K taşıyor; bir 27B için bu büyük fark. Ama Ollama’da prompt önbelleği yoktu, yani her tur bütün konuşmayı yeniden işledi: girdi turdan tura 1,9K’dan 3,4K’ya büyüyor ve görev başına 17–25K token yeniden okunuyor.

Yerel bir ajanı hızlandırmanın yolu daha hızlı bir GPU değil, daha kısa bir bağlam: erken sıkıştırın, görevi dar tanımlayın, gereksiz dosya okumalarını atlayın. 60K’da her tur bir buçuk dakika prefill.

Düştüğüm iki tuzak

• pi -p stdin açıkken bloke oluyor. İlk toplu koşum on dakika tek satır yazmadan asılı kaldı; </dev/null ile aynı iş 38 sn’de bitti. Cron/CI’da stdin’i kapatın.
• pgrep -f kendini buluyor. Bekleme döngüm pgrep -f "run.sh taskA" kullanıyordu; kendi komut satırıyla eşleşti ve 59 dakika kendini bekledi. Desenle değil, PID ile bekleyin (kill -0 $PID).

Test etmediklerim

Uzun oturumlar, sıkıştırma sonrası davranış, büyük bir kod tabanında yolunu bulmak ve pi’ın asıl iddiası — kendi TypeScript eklentilerini yazmak.