01Ne değişti: küçük artık oyuncak değilWhat changed: small is no longer a toy
Birkaç yıl önce "küçük model" bir demo oyuncağıydı. Bugün tek haneli milyar parametreli modeller, iyi tanımlanmış görevlerde ciddi iş görüyor. Bunu iki teknik mümkün kıldı: distillation ile büyük bir modelin davranışı küçüğe öğretiliyor; quantization ile ağırlıklar küçülüp bir laptop'ta, telefonda ya da edge cihazda gerçek zamanlı çalışır hâle geliyor. Dün GPU cluster isteyen şey bugün cebe sığıyor.
A few years ago a "small model" was a demo toy. Today models with single-digit billions of parameters do serious work on well-defined tasks. Two techniques made this possible: distillation teaches a large model's behavior to a small one; quantization shrinks the weights until they run in real time on a laptop, a phone or an edge device. What needed a GPU cluster yesterday fits in a pocket today.
Bunun üç pratik sonucu var. Maliyet: API üzerinde küçük model token başına onlarca kat ucuzdur; kendi donanımınızda marjinal maliyet sıfıra yaklaşır. Gecikme: ilk token milisaniyelerle ölçülür; cihaz üstünde ağ gidiş-dönüşü tamamen ortadan kalkar. Gizlilik: veri cihazdan hiç çıkmaz — sağlık, finans ve kişisel veri senaryolarında bu bir tercih değil, çoğu zaman gerekliliktir. Bu üç eksen, yazının geri kalanındaki her kararın terazisi.
Three practical consequences. Cost: over an API, a small model is tens of times cheaper per token; on your own hardware the marginal cost approaches zero. Latency: first token is measured in milliseconds; on-device, the network round-trip disappears entirely. Privacy: data never leaves the device — in health, finance and personal-data scenarios that's not a preference, it's often a requirement. These three axes are the scale every decision in the rest of this post is weighed on.
Doğru soru "hangi model en iyi?" değil; "bu iş için yeterli olan en küçük model hangisi?"
The right question isn't "which model is best?" It's "what's the smallest model that is sufficient for this job?"
02Küçük modelin kesin kazandığı yerlerWhere small wins decisively
Ortak desen şu: görev dar, girdi sınırlı, çıktı doğrulanabilir. Bu üçü bir aradaysa küçük model "idare eder" değil, çoğu zaman doğru mühendislik tercihidir:
The common pattern: a narrow task, bounded input, verifiable output. Where those three meet, a small model isn't a compromise — it's usually the correct engineering choice:
- Sınıflandırma ve yönlendirme. Destek talebini kategorilemek, spam'i ayıklamak, isteği doğru akışa göndermek. Çıktı birkaç etiketten biridir; yanlışsa ölçmesi de düzeltmesi de kolaydır.
- Classification and routing. Categorizing a support ticket, filtering spam, sending a request down the right flow. The output is one of a few labels; when it's wrong, it's easy to measure and fix.
- Yapılandırılmış extraction. Serbest metinden tarih, tutar, ad, adres çekmek. Schema belli olduğu için cevap programatik olarak doğrulanır.
- Structured extraction. Pulling dates, amounts, names and addresses out of free text. The schema is known, so the answer can be validated programmatically.
- Sınırlı özet ve taslak. Toplantı notunu özetlemek, e-posta taslağı çıkarmak, bir paragrafı yeniden yazmak. Girdi kısa, beklenti "mükemmel" değil "kullanılabilir ilk sürüm".
- Bounded summaries and drafting. Summarizing a meeting note, drafting an email, rewriting a paragraph. The input is short and the bar is "usable first draft", not "perfect".
- Cihaz üstü, gizlilik hassas işler. Veri cihazdan çıkmadan işlenir; KVKK/GDPR yüzeyi küçülür, "verim nereye gidiyor?" sorusu daha sorulmadan kapanır.
- On-device, privacy-sensitive work. Data is processed without ever leaving the device; the KVKK/GDPR surface shrinks, and "where does my data go?" is answered before it's asked.
- Sıkı gecikme bütçeleri. Kullanıcı yazarken çalışan her şey: öneri, düzeltme, sorgu genişletme. 100 ms'lik bütçeye frontier API sığmaz; küçük model sığar.
- Tight latency budgets. Everything that runs while the user types: suggestions, corrections, query expansion. A frontier API doesn't fit a 100 ms budget; a small model does.
Dikkat: bu listedeki hiçbir iş "önemsiz" değil. Hepsi, doğru kurulduğunda gerçek para ve gerçek milisaniye kazandıran işler. Küçük model ucuz olduğu için değil, bu işlerin şekline uyduğu için kazanıyor.
Note that nothing on this list is "trivial". Each one, done right, saves real money and real milliseconds. The small model wins not because it's cheap, but because it fits the shape of the work.
03Dürüst sınırlar: nerede yetmezHonest limits: where it isn't enough
Küçük modelin duvara çarptığı yerler de aynı netlikte. Üç başlık:
Where small models hit the wall is just as clear. Three areas:
- Uzun ufuklu akıl yürütme. Çok adımlı plan kurmak, kısıtları uzun bir zincir boyunca akılda tutmak, ara sonuçtan geri dönüp strateji değiştirmek. Küçük model birkaç adım sonra ipi kaybeder.
- Long-horizon reasoning. Multi-step planning, holding constraints across a long chain, backtracking on an intermediate result and changing strategy. A small model loses the thread after a few steps.
- Geniş dünya bilgisi. Küçük model dünyanın daha azını sıkıştırmıştır. Görev tanımının dışına çıkan sorularda uydurma oranı belirgin artar; "her şeyi bilen asistan" küçük modelin işi değildir.
- Broad world knowledge. A small model has compressed less of the world. On questions outside the task definition, hallucination rises sharply; "the assistant that knows everything" is not a small model's job.
- Karmaşık tool orchestration. Onlarca tool arasından doğrusunu seçmek, hatalı bir çağrıdan zincirin ortasında toparlanmak, uzun bir agent akışını yönetmek. Bu hâlâ frontier model işidir.
- Complex tool orchestration. Choosing correctly among dozens of tools, recovering mid-chain from a failed call, managing a long agent loop. That is still frontier-model work.
Fine-tune bu tabloyu değiştirmez: dar bir görevde davranışı keskinleştirir ama akıl yürütme kapasitesi satın almaz. İş, modelin gerçekten "düşünmesini" gerektiriyorsa bedelini ödeyin.
Fine-tuning doesn't change this picture: it sharpens behavior on a narrow task but doesn't buy reasoning capacity. If the job genuinely requires the model to think, pay for it.
04Router deseni: önce küçük, gerekirse büyükThe router pattern: small first, big when needed
İkisinden birini seçmek zorunda değilsiniz; üretimde en iyi çalışan desen ikisini birlikte kullanır. Her istek önce küçük modele gider. Model emin değilse, çıktı doğrulanamıyorsa ya da iş karmaşıklık eşiğini aşıyorsa istek frontier modele yükseltilir. Trafiğin büyük bölümü ucuz ve hızlı yoldan akar; pahalı model yalnızca hak eden isteklere dokunur.
You don't have to pick one; the pattern that works best in production uses both. Every request goes to the small model first. If the model is uncertain, the output fails validation, or the job crosses a complexity threshold, the request escalates to a frontier model. Most traffic flows through the cheap, fast path; the expensive model only touches requests that earn it.
# önce küçük, belirsizlikte büyük / small first, escalate on uncertainty route: "destek-triyaj / support-triage" primary: "slm-8b" # kendi donanımımızda / self-hosted escalate_to: "frontier-api" escalate_if: - confidence_below: 0.85 - schema_invalid: true # çıktı doğrulanamadı / output failed validation - tools_needed: "> 1"
Bu desenin bedeli disiplindir. Küçük modelin yeterli olduğunu hissetmek değil, bilmek zorundasınız — bunun tek yolu iki modeli de aynı eval setiyle ölçmektir. Sonra üretimde iki metriği izlersiniz: kalite skoru ve eskalasyon oranı. Eskalasyon oranı sessizce tırmanıyorsa değişen trafiğinizdir, modeliniz değil; bu drift'i bir dashboard'da görmüyorsanız maliyet avantajınız kimse fark etmeden erir.
The price of this pattern is discipline. You have to know the small model is good enough, not feel it — and the only way is measuring both models against the same eval set. Then in production you watch two metrics: quality score and escalation rate. If the escalation rate climbs quietly, it's your traffic that changed, not your model; unless that drift is on a dashboard, your cost advantage erodes before anyone notices.