Yapay zekâ ekipleri neden kendi C ve C++ çıkarım motorlarını yazıyor?

Bir şirketin üretimde bir yapay zekâ modelini çalıştırması gerektiğinde, çoğu ekip için varsayılan seçim yerleşik bir çerçevedir: araştırma ve giderek üretim kullanımı için PyTorch, TensorFlow Serving, ONNX Runtime ya da bulut sağlayıcıların sunduğu birkaç yönetilen çıkarım platformundan biri. Ancak yapay zekâ altyapı ekipleri arasında tekrarlayan bir örüntü, yakın zamanda geniş çapta paylaşılan bir mühendislik blog yazısında belgelendiği gibi, bunun yerine sıfırdan C ya da C++ dilinde özel bir çıkarım motoru yazma kararı — bu diller, çoğu makine öğrenmesi mühendisinin günlük olarak kullandığı Python tabanlı araçlardan donanıma çok daha yakın oturuyor.

Bu karar ilk bakışta sezgilere aykırı görünüyor. Genel amaçlı çerçeveler tam olarak bir çıkarım motoru inşa etmenin zor olduğu için var: model formatlarını, bellek yönetimini, donanıma özgü optimizasyonu, toplu işlemeyi (batching) ve sayısal hassasiyeti, bir modelin çıktısını sessizce bozan hatalar ortaya çıkarmadan doğru bir şekilde ele almayı gerektiriyor. Bu makineyi, bu sorunları zaten çözmüş bir çerçeveyi yeniden kullanmak yerine C ya da C++ ile yazmak, aylarca ek mühendislik işi üstlenmek anlamına geliyor.

Yine de bunu yapmanın gerekçesi genellikle performansla başlıyor. Esneklik ve kullanım kolaylığı için inşa edilen çerçeveler, ham hızdan çok geliştirici rahatlığı için optimize edilmiş soyutlama katmanları, dinamik gönderim (dispatch) ve bellek ayırma örüntüleri gibi bir yük taşıyor; özel amaçlı bir motor bunları ortadan kaldırabiliyor. Büyük ölçekte ya da sıkı gecikme bütçeleriyle çıkarım çalıştıran ekipler için gereksiz soyutlama katmanlarını ortadan kaldırarak her istekten milisaniyeler tıraşlamak, doğrudan daha düşük altyapı maliyetlerine ya da somut ölçüde daha iyi bir kullanıcı deneyimine dönüşebiliyor.

Bellek ayak izi ikinci büyük itici güç. Genel amaçlı çerçeveler geniş bir model mimarisi ve kullanım senaryosu yelpazesini desteklemek için tasarlanıyor; bu da herhangi bir tekil dağıtımın ihtiyaç duymadığı kod yolları ve bağımlılıklar taşıdıkları anlamına geliyor. Tek bir model ya da model ailesi için inşa edilen özel bir motor, tam olarak o kullanım senaryosunun gerektirdiği şeye indirgenebilir; bu da çarpıcı derecede daha küçük bir ikili dosya ve daha düşük bellek kullanımı sağlar — bir modelin kısıtlı donanımda çalışması gerektiğinde muazzam önem taşıyan bir fark.

Bu kısıtlama, uç (edge) ve yerel çıkarım dağıtım senaryolarında belirleyici hâle geliyor: bir modeli bir telefonda, gömülü bir cihazda, bir dizüstü bilgisayarda ya da tam bir veri merkezi GPU yığını bulunmayan herhangi bir ortamda çalıştırmak. Bu tür ortamlarda, büyük bir çalışma zamanı ayak izine sahip çok gigabaytlık bir çerçeve bağımlılığı basitçe sığmayabilir ya da uygulamanın geri kalanı için çok az alan bırakabilir. Hedef donanım için özel olarak derlenmiş sade bir C ya da C++ motoru, belleğin ve disk alanının çok küçük bir kısmında çalışabilir.

Bağımlılık yönetimi, ilişkili ama ayrı bir gerekçe. Genel amaçlı ML çerçeveleri genellikle diğer kütüphaneler, CUDA'nın ya da diğer donanım sürücülerinin belirli sürümleri, Python çalışma zamanı gereksinimleri gibi büyük bağımlılık ağaçları çekiyor; bu da dağıtımı karmaşıklaştırabilir, sürüm çakışmaları yaratabilir ya da bir uygulamayı tek, kendi kendine yeten bir ikili dosya olarak göndermeyi zorlaştırabilir. Minimum dış bağımlılığa sahip özel olarak inşa edilmiş bir motor, bu bağımlılıkların aksi hâlde sağlayacağı işlevselliği yeniden uygulamak pahasına bu karmaşıklığın büyük kısmından kaçınıyor.

Donanımlar arası taşınabilirlik, ekiplerin belirttiği bir başka faktör. C ya da C++ ile donanıma yakın yazmak, farklı CPU mimarileri, özel hızlandırıcı çipler ya da gömülü işlemciler gibi alışılmadık ya da kaynak kısıtlı donanımları, genel amaçlı bir çerçevenin resmî destek eklemesini beklemeden doğrudan hedeflemeyi daha pratik hâle getiriyor. Ana akım çerçevelerin öncelik vermediği donanımlar için geliştirme yapan ekipler, bazen kendi motorlarını yazmanın, başkasının çerçevesindeki boşlukları beklemek ya da onlarla uğraşmaktan daha hızlı olduğunu görüyor.

Değiş tokuş ve bu gerçek bir değiş tokuş — mühendislik maliyeti ve süregelen bakım yükü. Özel bir çıkarım motorunun her model güncellemesinde, her yeni donanım hedefinde ve genel amaçlı bir çerçevenin aksi hâlde zaten ele almış olacağı her sayısal uç durumda inşa edilmesi, test edilmesi ve doğru tutulması gerekiyor. Bu yolu seçen ekipler, aslında işlerini yapmanın kalıcı bir maliyeti olarak küçük bir çerçeve bakım ekibinin işini üstleniyor; bu da yalnızca performans, ayak izi ya da dağıtım kazanımları bunu haklı çıkaracak kadar büyük olduğunda mantıklı oluyor.

Bu yüzden bu uygulama, genellikle yeni bir projenin başlangıç noktası olarak değil, bir şirketin büyümesinde belirli bir noktada ortaya çıkma eğiliminde: genel amaçlı araçların kısıtlamaları — hesaplama harcamasında, bir ürünün destekleyebileceği donanımda ya da ürünün kendisini etkileyen gecikmede — ölçülebilir, tekrarlayan bir maliyet hâline geldikten sonra. Çoğu ekip, bu çerçevelerin yükü kendi özel kullanım senaryoları için önemli olmadığı sürece mevcut çerçevelerle iyi hizmet görüyor.

Yapay zekâ altyapısı dışındaki geliştiriciler için daha geniş ders, özellikle C ve C++ ile ilgili değil, sistem mühendisliğindeki genel bir ilkeyle ilgili: genel amaçlı araçlar yaygın durum ve esneklik için optimize edilir ve bu değiş tokuş genellikle doğrudur — ta ki belirli bir dağıtım hedefi, performans gereksinimi ya da kaynak kısıtlaması, o esnekliğin yükünü, bunun yerine daha dar ve donanıma daha yakın bir şey inşa ederek ortadan kaldırmaya değer bir maliyete dönüştürene kadar.