Docker Model Runner'ın OpenAI uyumlu API'si ile Spring Boot üzerinden yerel LLM'leri çalıştırın

Java geliştiricileri, büyük dil modellerini kendi makinelerinde çalıştırabilir ve prompt'ları OpenAI veya AWS Bedrock gibi barındırılmış bir sağlayıcıya yönlendirmeden, Spring AI aracılığıyla bir Spring Boot uygulamasından bu modellere erişebilir. dev.to'da yayımlanan bir eğitim, kurulum adımlarını anlatıyor ve bunun geliştirme sırasında bulut bağımlılıklarını ortadan kaldırdığını, uygulama kodunu ise büyük ölçüde değiştirmeden bıraktığını savunuyor.

Stack nasıl bir araya geliyor

Eğitim katmanlı bir kurulum anlatıyor: Spring Boot uygulaması Spring AI ile konuşuyor, Spring AI OpenAI uyumlu bir API'ye çağrılar yapıyor, bu API'yi Docker Model Runner yerel makinede sunuyor ve arkasında yerel olarak çalışan bir model bulunuyor. Kilit nokta, uyumluluk değil kaynağın ne olduğu değil — OpenAI uyumlu bir endpoint, OpenAI'nin API'siyle aynı istek ve yanıt formatını izlediği için, bir OpenAI istemcisini localhost'a yönlendirmek yerel bir modele erişmek için yeterli oluyor.

Yerel çıkarım (inference) gerekçesi

Yazar çeşitli motivasyonlar sıralıyor. Geliştirme süreci çoğu zaman yüzlerce ya da binlerce prompt içeriyor ve yerel bir model, deneme yaparken API ücretlerini ortadan kaldırıyor. Prompt'lar ve uygulama verileri dış bir sağlayıcıya gitmek yerine geliştiricinin makinesinde kalıyor; bu da hassas veya tescilli materyallerle çalışırken önemli. Model yerel olarak mevcut olduğunda çıkarım internet bağlantısı olmadan çalışıyor ve geliştiriciler bulut kimlik bilgilerini tekrar tekrar yapılandırmadan prompt'lar, tool calling, RAG pipeline'ları ve uygulama mantığı üzerinde yineleme yapabiliyor.

Eğitime göre belki de en büyük avantaj, Spring AI programlama modelinin aynı kalması. İş mantığı belirli bir sağlayıcıya sıkı sıkıya bağlı değil, dolayısıyla soyutlama modelin nerede çalıştığından bağımsız olarak sürüyor.

Spring Boot'ta bağlantıyı kurma

Anlatım beş adımda ilerliyor:

1. Docker Desktop'ı kurun ve başlatın. Model Runner'ın kullanılabilirliği Docker Desktop sürümüne ve yapılandırmasına bağlı; yazar, komutların ve model kataloğunun Docker ekosistemi geliştikçe değişebileceğini, bu nedenle güncel Docker belgelerinin başvuru noktası olduğunu belirtiyor.
2. Docker Desktop'ta Model Runner'ı etkinleştirin; bu, uygulamanın hedefleyebileceği bir API endpoint'i açığa çıkarıyor.
3. Bir Spring Boot projesi oluşturun ve spring-ai-starter-model-openai Maven bağımlılığını ekleyin. Bu starter, OpenAI'nin bulut servisinin çağrılması için değil, iletişim formatı (wire format) nedeniyle seçiliyor.
4. Spring AI'ın OpenAI base URL'sini yerel Model Runner endpoint'ini gösterecek şekilde yapılandırın, chat options model özelliğini yerel modelin adına ayarlayın ve yer tutucu bir API anahtarı sağlayın — yerel runtime bunu gerektirmeyebilir, ancak Spring AI istemcisi özelliğin mevcut olmasını bekliyor.
5. Bir ChatClient oluşturun.

Uygulama kodu tarafında, eğitim otomatik yapılandırılan ChatClient.Builder'ı bir REST controller'a enjekte ediyor, istemciyi constructor'da oluşturuyor ve bir message parametresi alıp basit bir prompt çağrısının yanıtını döndüren bir GET endpoint'i açığa çıkarıyor. Sonuç, message sorgu parametresi alan bir chat endpoint'i biçiminde bir URL oluyor; istek, HTTP'den Spring Boot, ChatClient ve Spring AI üzerinden Docker Model Runner'a ve yerel modele akıyor.

Sağlayıcı ChatClient'ın arkasında kayboluyor

Controller yalnızca ChatClient soyutlamasını gördüğü için, arka ucun OpenAI, Azure OpenAI, AWS Bedrock, Ollama, Docker Model Runner ya da başka bir uyumlu sağlayıcı olup olmadığını bilmesi gerekmiyor. Uygulama modelden ne istediğini belirtiyor ve alttaki iletişimi Spring AI hallediyor. Pratikte sağlayıcı değiştirmek, yeniden yazım değil bir yapılandırma değişikliği haline geliyor.

Yerel ile bulut arasındaki ödünlüşler

Eğitim yerel çalıştırmayı olduğundan büyük göstermekten kaçınıyor. Yerel modeller veriyi makinede tutuyor ve istek başına ücretlerden kaçınıyor, ancak yerel işlem gücü tüketiyor, daha yavaş çalışabiliyor ve mevcut donanımla sınırlı. Bulut teklifleri altyapıyı hallediyor, genellikle daha hızlı ve çok daha büyük modellere erişim sunuyor, çoğunlukla kullanım bazlı fiyatlandırmayla. Bir geliştirici dizüstü bilgisayarı daha küçük bir modeli rahatça barındırabilirken, büyük bir frontier model kayda değer derecede daha fazla bellek ve işlem gücü gerektiriyor. Yazarın ortaya koyduğu soru, yerelin bulutu yenip yenmediği değil, hangi dağıtım stratejisinin belirli bir iş yüküne uyduğu — geliştirme için yerel, üretim için bulut.

Neden önemli

Bu birleşim, üretken yapay zekâ ile deneyler yapan Java ekipleri için engeli düşürüyor: geliştirme sırasında bulut hesabı yok, prompt başına harcama yok ve makineden çıkan veri yok. Ayrıca ekosistemdeki daha geniş bir deseni de gözler önüne seriyor — OpenAI uyumlu API'ler fiili bir arayüz haline geldi, dolayısıyla formatı uygulayan herhangi bir runtime, aslında OpenAI için geliştirilmiş araçlara doğrudan bağlanabiliyor. Zaten Docker üzerinde standartlaşmış ekipler için Model Runner, model çalıştırmayı yerel geliştirme ortamının geri kalanının yanına getiriyor ve Spring AI uygulamayı sağlayıcıdan yalıttığı için, daha sonra barındırılmış bir modele geçiş çoğunlukla kodu baştan yazmak değil yapılandırmayı düzenlemek meselesi.