Tek laptopta dokuz coding harness: kullanılabilirliği belirleyen token hızı değil, prompt boyutu

Bir geliştirici, tamamen bir laptop üzerinden sunulan bir modelle dokuz coding harness'i çalıştırdı ve ortaya çıkan ölçümler, ham throughput kıyaslamalarının bu araçların kullanımında nasıl hissettirdiğine dair neden bu kadar az şey söylediğini açıklıyor. Notion'da barındırılan ve Hacker News'in ana sayfasında öne çıkan yazı, llama-bench gibi bir aracın vadettiği ile bulut API'leri için tasarlanmış bir harness'in localhost ile karşılaştığında yaşananlar arasındaki uçuruma odaklanıyor.

Neler test edildi

Yazar, mini-swe-agent, pi, cline, codex, dsh, goose, crush, opencode ve chad araçlarını sekiz Exercism alıştırmasından oluşturulan 24 görevden geçirdi; her biri otomatik onay modunda ve aynı tek cümlelik prompt ile çalıştı. Donanım, 24GB RAM'e sahip, macOS 26.6.2 çalıştıran ve llama.cpp build 10470 üzerinden Qwen 3.8 27B'nin 3-bit quantization'ını sunan bir M4 MacBook Pro'ydu. Tüm harness'ler aynı llama-server örneğini, Qwen'un önerilen sampling ayarlarını zorunlu kılan bir proxy'yi (temperature 1.0, top_k 20, top_p 0.95, min_p 0.05) ve dört slota yayılmış aynı 32.768 token'lık birleşik cache'i paylaştı. Tüm veriler harness'lerin kendi bildirimlerinden değil llama-server'ın muhasebesinden geldi; yalnızca kendi süre içi MLX motorunu kullanan chad satırları, chad'in prefill izinden alındı.

Zaman nereye gidiyor

Analiz laptop fiziğiyle başlıyor. Bu sınıfta bir makine bir prompt'u saniyede kabaca 90 token okur ve yaklaşık 10 token üretir; yani prompt'un her 1.000 token'ı, model bir şey yazmadan önce yaklaşık 11 saniyelik sessizliğe mal olur. Sistem prompt'u artı tool şemaları, mini-swe-agent için 1.171 token'dan opencode için 18.046 token'a kadar değişiyordu; pi ise 2.008'deydi. Saniyede 10.000 üzeri token prefill yapan bir veri merkezi GPU'sunda bu uçlar arasındaki fark 0,2 ile 1,8 saniye arasındadır. Laptop'ta yazar 22 saniye ile 226 saniye ölçtü.

İkinci maliyet context'tir. Makul bir laptop üzerinde makul bir modelle yazar, ağırlıklar yüklendikten sonra yaklaşık 32.000 token'lık çalışma alanı tahmin ediyor. pi bu bütçenin %94'ünü gerçek göreve bırakıyor; konuşma başlamadan 18.046 token harcayan opencode ise %44 bırakıyor.

Üçüncüsü yan isteklerdir. Harness'ler uzak bir sunucu varsayar ve oturum başlıkları, özetler gibi şeyler için ek çağrılar yapar. Yerelde laptop hem istemci hem sunucu olduğundan bu çağrılar agent'ın turunun arkasında sıraya girer ya da onunla çakışır. 24 görev boyunca opencode 33, crush 51 ve dsh 24 böyle istek yaptı; neredeyse hepsi bir agent turuyla örtüşüyordu. Model, opencode altında duvar saatinin %125'i, crush altında %114'ü kadar fiilen meşguldü; yani tek GPU için rekabet eden iki istek demek bu.

Harness'ler nasıl performans gösterdi

İlk token öncesi ölçülen bekleme: mini-swe-agent 12,2 saniye, pi 21,6, llama.cpp üzerinde chad 25,6, cline 64,1, codex 87,8, dsh 94,4, goose 110,3, crush 199,8 ve opencode 225,7. Chad'in süre içi MLX motoru bunu kabaca 4,7 saniyeye indirdi ve dflash2 varyantı, üretilen token'ları prefill ve tool süresi dahil toplam duvar saatine bölerek hesaplanan deneyimlenen token cinsinden saniyede 17,4 token'a ulaştı; diğerleri için bu değer kabaca 5,7 ile 8,1 arasındaydı.

Yazarın bir sıralama olarak okunmaması gerektiğini söylediği, bilerek basit seçilmiş 24 Python görevinden oluşan geçiş eşiğinde llama.cpp üzerinde chad 24/24 tamamladı, goose 22/24, pi ve codex 19/24, dsh ve crush 18/24, cline 17/24, opencode 15/24 ve mini-swe-agent 1.200 saniyelik sınırda 14 zaman aşımıyla 11/24 tamamladı. Cache yeniden kullanımı güncel sürümlerde %94 ile %100 arasındaydı; yazar, goose'un bu konumdaki yerini ancak 1.50.0 sürümünde kazandığını belirtiyor, çünkü önceki sürümler her turda ilk kullanıcı mesajına dakika çözünürlüklü bir zaman damgası yeniden işliyor ve cache yeniden kullanımını %78'e düşürüyordu.

Yazar alanı üç gruba ayırıyor: yerelde kutudan çıktığı gibi çalışan yalın araçlar (pi, mini-swe-agent, chad; mini-swe-agent'ın zaman aşımı sayısı göz önünde bulundurulmalı); önekleri byte olarak kararlı olduğu için acının öne yüklendiği daha ağır araçlar (dsh, cline, codex, goose); ve ekranda üç dört dakika boyunca hiçbir şey görünmeyen iki araç, crush ve opencode.

Dikkate değer uyarılar

Yazar doğrudan bir çıkar ilişkisi olduğunu açıklıyor: chad ile uğraşıyor, ki bu da tam olarak test edilen konfigürasyon olan Apple silikon üzerinde Qwen 3.8 27B için özel olarak ayarlanmış bir harness. Deneyimlenen throughput geceler arasında %50'ye kadar değiştiğinden, yalın araçlar arasındaki ince farklar anlamlı değil. Yazı açıkça ölçüm olarak çerçevelenmiş, eleştiri olarak değil: opencode'un büyük prompt'u bir API arkasındaki frontier modellere yardım ettiği için var ve crush'un 26 tool şeması 200k context ve neredeyse anlık prefill ile zararsız. Bu seçimler yalnızca prefill bedava olmaktan çıktığında bozuluyor.

Neden önemli

Throughput kıyaslamaları motoru ölçer, onun etrafına kurulmuş aracı değil. Yerel modeller tüketici donanımında gerçekten kullanılabilir hale geldikçe harness, model kadar belirleyici oluyor: prompt boyutu, tool şema sayısı, cache kararlılığı ve arka plan istekleri artık yerel bir kurulumun duyarlı mı yoksa kullanılamaz mı hissettirdiğini belirliyor. Geçiş oranları bu noktayı vurguluyor, çünkü en ağır harness'ler daha fazla değil daha az görev tamamladı; yerel durum için tasarlanmış bir konfigürasyon ise 24 görevin tamamını bütçe içinde bitirdi. Harness geliştiricileri için bu yazı, aynı zamanda veri merkezi localhost ile değiştirildiği an sessizce geçersiz hale gelen varsayımların bir kontrol listesi olarak da okunabilir.