AI Tahmin, Eğitim Değil, Sıradaki Büyük Mühendislik Mücadelesidir

Geçtiğimiz on yıl boyunca, yapay zeka alanında odak noktası eğitim üzerinde yoğunlaştı. Büyük atılımlar, büyük ölçekli hesaplama kümelerinden, trilyon parametreli modellerden ve sistemleri “düşünme”ye öğretmek için harcanan milyarlarca dolardan geldi. AI gelişimini büyük ölçüde bir inşaat projesi olarak ele aldık: zeka gökdelenini inşa etmek. Ancak şimdi bu gökdelen inşa edildiğine göre, gerçek zorluk milyonlarca kişinin aynı anda içinde yaşamasını ve çalışmasını sağlamak. Bu, AI araştırmacıları ve mühendislerinin odak noktasını eğitim (zeka oluşturma eylemi) yerine tahmin (onu kullanma eylemi) yönünde değiştiriyor. Eğitim, bir defaya mahsus büyük bir sermaye harcaması (CapEx) iken, tahmin, sınırsız olarak devam eden bir operasyonel harcama (OpEx)’dir. Şirketler, milyonlarca kullanıcıya hizmet veren ajanları saat başı dağıttıkça, bir gerçekle karşılaşıyorlar: tahmin, sadece “eğitim”in tersi değil. Temel olarak farklı ve belki de daha zor bir mühendislik zorluğu.

Neden Tahmin Maliyetleri Her Zamankinden Daha Önemli

Mühendislik zorluğunu anlamak için, önce temel ekonomik zorunluluğu anlamak gerekiyor. Eğitim aşamasında, verimsizlik hoş görülebilir. Bir eğitim çalışması dört hafta yerine üç hafta sürerse, bu bir can sıkıntısıdır. Tahminde ise verimsizlik, işletme için felaket olabilir. Örneğin, bir frontier modeli eğitmek 100 milyon dolar maliyetinde olabilir. Ancak bu modeli günde 10 milyon sorgu yanıtlamak için dağıtmak, optimize edilmezse birkaç ay içinde bu maliyeti aşabilir. Bu nedenle, bir pazar değişimi yaşadığımızı görüyoruz, tahmin yatırımlarının eğitim yatırımlarını geçeceği öngörülüyor.

Mühendisler için bu, hedefleri değiştiriyor. Artık veri işleme hızı (bu büyük veri kümesini ne kadar hızlı işleyebilirim?) için optimize değiliz. Gecikme (tek bir tokenı ne kadar hızlı döndürebilirim?) ve eşzamanlılık (bir GPU’da kaç kullanıcıya hizmet verebilirim?) için optimize ediyoruz. Eğitim aşamasında, basitçe daha fazla hesaplama ekleyerek hakim olan “kaba kuvvet” yaklaşımı burada çalışmıyor. Bir gecikme sorununda, tıkanıklığın bellek bant genişliği olduğunu düşünürsek, daha fazla H100 ekleyemezsiniz.

Bellek Duvarı: Gerçek Tıkanıklık

Büyük Dil Modeli (LLM) tahmini hakkında az bilinen gerçek, bunun genellikle hesaplama ile sınırlı olmaması, bellek ile sınırlı olmasıdır. Eğitim sırasında, verileri büyük toplu işleriz ve GPU’nun hesaplama birimlerini tam olarak kullanırız. Tahminde, özellikle sohbet botları veya ajanlar gibi gerçek zamanlı uygulamalar için, istekler sıralı olarak gelir. Üretilen her bir token, modelin milyarlarca parametrelerini yüksek bant genişimli bellek (HBM) üzerinden hesaplama çekirdeklerine yüklemesini gerektirir. Bu, “Bellek Duvarı“dır. Bu, bir Ferrari motoruna (GPU çekirdeği) sahip olmak ancak trafik sıkışıklığında (sınırlı bellek bant genişliği) takılı kalmak gibidir.

Bu zorluk, mühendislik ekiplerini, silikon seviyesine kadar sistem mimarisini yeniden düşünmeye zorluyor. Bu nedenle, Linear Processing Units (LPUs) gibi Groq’dan olanlar ve özel Neural Processing Units (NPUs) gibi çiplerin yükselişini görüyoruz. Bu çipler, HBM tıkanıklığını bypass etmek için devasa miktarlarda yonga üstü SRAM kullanıyor ve bellek erişimini basit bir algoritma işlemi olarak değil, sürekli bir veri akışı olarak ele alıyor. Yazılım mühendisi için bu, “varsayılan CUDA” dönemini sonlandırıyor. Artık donanımının farkında olan kodu yazmak zorundayız, verilerin kablodan nasıl geçtiğini tam olarak anlamak zorundayız.

Yeni AI Verimliliği Cephesi

Donanımı her zaman değiştiremeyeceğimiz için, önümüzdeki mühendislik cephesi yazılım optimizasyonunda yatıyor. İşte bazılarından en yenilikçi atılımların gerçekleştiği yer burası.

• Sürekli Toplu İşleme: Geleneksel toplu işleme, “otobüs”ün dolmasını bekler, bu da gecikmelere neden olur. Sürekli toplu işleme (vLLM gibi çerçeveler tarafından öncülük edilen), bir metro sistemi gibi çalışır, yeni isteklerin her bir iterasyonda GPU işleme trenine katılmasına veya ayrılmalarına izin verir. Bu, gecikme pahasına olmadan verimi en üst düzeye çıkarır, derin işletim sistemi uzmanlığı gerektiren karmaşık bir zamanlama sorununu çözer.

• Spekülatif Kod Çözme: Bu teknik, bir yanıt taslağı oluşturmak için küçük, hızlı ve ucuz bir model kullanır, daha büyük, daha yavaş ve daha yetenekli bir model ise paralel olarak onu doğrular. Metin doğrulamanın metin oluşturmaktan çok daha az hesaplama gerektirdiği gerçeğine dayanır.
• KV Önbellek Yönetimi: Uzun sohbetlerde, “geçmiş” (Anahtar-Değer önbelleği) hızla büyür ve büyük miktarda GPU belleği tüketir. Mühendisler şimdi, işletim sistemlerindeki sanal bellek sayfalamasından esinlenen “PagedAttention” tekniğini uygulamaya başladılar. Bu teknik, belleği parçalara ayırır ve parçaları sürekli olarak yönetir.

Ajantik Karmaşıklık

Standart tahmin zor ise, Ajantik AI bunu üssü olarak daha da zorlaştırır. Bir sohbet botu standarttır: Kullanıcı sorar, AI cevaplar, işlem biter. Bir AI Ajansı ise bir döngüye sahiptir. Planlar, araçları çalıştırır, sonuçları gözlemler ve yineleme yapar. Mühendislik açısından bu, bir kâbus. Bu mimari değişim, birkaç temel zorluğu ortaya koyar:

1. Durum Yönetimi: Tahmin motoru, ajanın düşünce sürecinin “durumunu” birden fazla adımda, genellikle dakikalar boyunca korumalıdır.
2. Sonsuz Döngüler: Öngörülemeyen bir ileri geçişin aksine, bir ajan, bir akıl yürütme döngüsüne takılabilir. Olasılıklı kodu için güçlü “bekçi köpekleri” ve “devre kesicileri” geliştirmek, tamamen yeni bir alandır.
3. Değişken Hesaplama: Bir kullanıcı sorgusu, tek bir tahmin çağrısını tetikleyebilirken, diğeri elli tane tetikleyebilir. Her isteğin aşırı varyans taşıdığı bir altyapının yükünü yönetmek ve otomatik ölçeklendirme altyapısını yönetmek, tamamen yeni bir sınıf olan orkestrasyon mantığı gerektirir.

Aslında, “model sunmaktan” “bilişsel mimarileri orkestrasyonuna” geçiyoruz.

AI’ı Her Gün Kullanılan Cihazlara Getirmek

Son olarak, enerji ve ağ gecikmesi sınırları, sonunda tahmini kenara taşıyacaktır. Her akıllı ampulün, otonom aracın veya fabrika robotunun isteklerini bir veri merkezine yönlendirmesini bekleyemeyiz. Mühendislik zorluğu burada, sıkıştırma. İnternette öğrendiği bir modeli, parmak izinden küçük bir yonga üzerinde, bir pil üzerinde nasıl çalıştırabilirsiniz?

Teknikler gibi kantitatif (16-bit’ten 4-bit veya hatta 1-bit’e indirgeme) ve model damıtma (küçük bir öğrenci modelinin büyük bir öğretmen modelini taklit etmesini öğretme) standart uygulama haline geliyor. Ancak gerçek zorluk, bu modelleri, her biri kendi donanım kısıtlamalarına sahip milyarlarca cihaza (Android, iOS, gömülü Linux, özel sensörler) dağıtmak. Bu, mobil geliştirmedeki “parçalanma kâbusu”, sinir ağlarının karmaşıklığı ile çarpılmış hali.

Alt Çizgi

Üretken AI’ın “2. Gün” dönemine giriyoruz. 1. Gün, AI’ın şiir yazabileceğini göstermekti. 2. Gün, bu yeteneği daha güvenilir, daha uygun fiyatlı ve daha yaygın hale getirmek için mühendislik yapmak. Gelecek on yılı tanımlayacak mühendisler, yeni model mimarileri icat edenler değil, bir milyarı saniyede tokenları sunmadan elektrik şebekesini eritmeden veya şirketi iflas ettirmeden, sistem mühendisleri, çekirdek hileleri ve altyapı mimarları olacaklar. AI tahmini artık sadece bir çalışma zamanı ayrıntısı değil. Ürün budur. Ve onu optimize etmek, sıradaki büyük mühendislik zorluğudur.