Yerel LLM'lerle Kodlama: Kurulum, Maliyet ve Verimlilik Anatomisi

Geçen ay bir müşteri projesinde API bazlı LLM maliyetlerinin tahminimin üzerine çıktığını görünce, yerel LLM’lere dönme fikri yeniden aklıma geldi. Her ne kadar bulut tabanlı çözümler hızlı ve erişilebilir olsa da, özellikle hassas kod tabanlarıyla çalışırken veri gizliliği ve tekrarlayan maliyetler ciddi birer sorun haline gelebiliyor. Bu durum, beni kendi donanımım üzerinde çalışan, kontrolü tamamen bende olan bir LLM ortamı kurmaya itti.

Yerel LLM’lerle kodlama, sadece maliyetleri düşürmekle kalmıyor, aynı zamanda geliştirme sürecine benzersiz bir esneklik ve gizlilik katıyor. Kendi sunucumda çalıştırdığım bir üretim ERP’sinin backend’inde kod yazarken, hassas iş mantığını dışarıya gönderme endişesi olmadan, istediğim kadar kod üretme ve refactor etme imkanına sahip olmak büyük bir avantaj. Bu yazıda, yerel LLM ortamı kurarken karşılaştığım zorlukları, maliyet analizini ve bu süreçten elde ettiğim verimlilik kazanımlarını detaylıca anlatacağım.

Neden Yerel LLM’lere Yöneldim?

Bulut tabanlı LLM servislerinin sunduğu kolaylıklar inkar edilemez; API anahtarı alıp hemen kullanmaya başlayabiliyorsunuz. Ancak, özellikle kurumsal veya kişisel projelerdeki hassas kod tabanları söz konusu olduğunda, bu kolaylığın ciddi gizlilik ve maliyet dezavantajları olabiliyor. Bir üretim ERP’sinin kritik modüllerini geliştirirken, yazdığım kodu veya veri şemalarını üçüncü taraf bir API’ye gönderme düşüncesi beni her zaman rahatsız etti. Veri gizliliği, ticari sırların korunması açısından kritik bir öneme sahip.

Ayrıca, bulut LLM’lerinin token bazlı maliyetlendirmesi, yoğun kullanımlarda öngörülemez faturalara yol açabiliyor. Bir fonksiyonu tekrar tekrar optimize ederken veya yeni bir modül için boilerplate kod üretirken, her API çağrısı cebinizden giden bir maliyet demek. Özellikle uzun bağlam pencereleri veya karmaşık sorgular kullandığımda, bu maliyetler hızla artabiliyor. Yerel bir kurulum ise, ilk donanım yatırımından sonra, işletme maliyetini büyük ölçüde öngörülebilir kılıyor ve adeta sınırsız kullanım imkanı sunuyor. Bu iki temel neden, beni kendi donanımımda bir LLM çalıştırma arayışına itti.

Yerel LLM Kurulumunun Anatomisi: Donanım ve Yazılım Gereksinimleri Nelerdir?

Yerel bir LLM ortamı kurmak, bulut tabanlı bir API anahtarı almaktan biraz daha fazla çaba gerektiriyor, ancak bu çabanın karşılığını uzun vadede fazlasıyla alıyorsunuz. Benim deneyimimde, donanım seçimi ve doğru yazılım katmanlarını bir araya getirmek kritik öneme sahipti. Özellikle GPU’nun (Graphics Processing Unit) performansı, LLM çıkarım hızını doğrudan etkiliyor; bu yüzden VRAM miktarı ve GPU’nun işlem gücü ilk başta dikkat etmemiz gerekenler arasında.

Minimum 12GB VRAM’e sahip bir NVIDIA GPU (örneğin RTX 3060 veya üstü) çoğu 7B model için yeterli olsa da, 13B veya 34B gibi daha büyük modellere yönelmek isterseniz 24GB veya daha fazla VRAM’e sahip bir kart (RTX 4090 gibi) ideal olacaktır. CPU tarafında ise modern bir Intel i7 veya AMD Ryzen 7 işlemci yeterli performansı sunuyor. RAM olarak 32GB, 7B-13B modeller için genellikle yeterli, ancak 64GB veya daha fazlası, büyük modelleri CPU’ya aktarma (offloading) durumunda veya RAG (Retrieval-Augmented Generation) gibi ek süreçler için daha iyi bir deneyim sağlıyor. Hızlı bir NVMe SSD, model dosyalarının yüklenme süresini kısaltarak genel performansa katkıda bulunuyor.

Yazılım tarafında ise Linux tabanlı bir işletim sistemi (Ubuntu veya Debian) genellikle en iyi uyumluluğu ve araç desteğini sunuyor. Benim tercihim, kolay kurulum ve yönetim sağlayan ollama veya LM Studio gibi inference motorları oldu. Bu araçlar, llama.cpp gibi alt seviye kütüphaneleri sizin için yöneterek model yüklemeyi ve çalıştırmayı basitleştiriyor. Docker veya Podman kullanarak bu ortamı konteynerize etmek, bağımlılık sorunlarını minimize ediyor ve farklı modelleri izole ortamlarda test etmeme olanak tanıyor. Model dosyaları için ise genellikle GGUF formatı tercih ediliyor; bu format, modellerin CPU ve GPU kaynaklarını daha verimli kullanmasını sağlayan niceleme (quantization) seçenekleri sunuyor.

# Ollama kurulumu (Linux için)
curl -fsSL https://ollama.com/install.sh | sh

# Ollama ile bir model çalıştırma örneği
ollama run codellama:7b-code

# LM Studio ile model indirme ve çalıştırma
# LM Studio'yu indirin ve GUI üzerinden model seçip çalıştırın.
# Sonra http://localhost:1234/v1/chat/completions gibi bir endpoint üzerinden erişebilirsiniz.

Bu temel kurulumla, kodlama ihtiyaçlarım için oldukça güçlü ve esnek bir yerel LLM ortamına sahip oldum. Başlangıçtaki bu yatırım, sonrasında bana büyük bir bağımsızlık ve maliyet avantajı sağladı.

Model Seçimi ve Performans: Hangi Modeller Ne İçin Uygun?

Yerel LLM’lerle kodlama serüvenimde, doğru modeli seçmek, performans ve maliyet dengesini kurmak açısından en kritik adımlardan biri oldu. Piyasada çok sayıda model var ve her birinin kendine özgü güçlü ve zayıf yönleri bulunuyor. Genellikle, modelin boyutu (parametre sayısı) ve niceleme (quantization) seviyesi, bir modelin ne kadar VRAM kullanacağını ve ne kadar hızlı çıkarım yapacağını belirliyor.

Benim deneyimimde, 7 milyar parametreli (7B) modeller, daha az VRAM gerektirmeleri ve hızlı olmaları nedeniyle başlangıç için ideal. CodeLlama:7b-code veya Phind-CodeLlama:7b-v2 gibi modeller, basit kod tamamlama, küçük fonksiyonlar yazma veya regexp oluşturma gibi görevlerde oldukça başarılılar. Ancak daha karmaşık iş mantığı veya büyük refactoring işlemleri için bazen yetersiz kalabiliyorlar. Bu noktada 13B veya 34B parametreli modellere yönelmek gerekebiliyor. Deepseek Coder’ın farklı boyutları ve Mixtral’ın uzman karışımı (MoE) yapısı, genel yetenekler ve kodlama performansı açısından çok daha iyi sonuçlar verdiğini gördüm. Mixtral, 7B boyutunda uzmanları olmasına rağmen, 47B gibi bir toplam parametre sayısına ulaşıyor ve bu, onu oldukça yetenekli kılıyor, ancak daha fazla VRAM gerektiriyor.

Niceleme seviyesi (örneğin Q4_K_M, Q8_0) ise modelin disk boyutunu ve VRAM tüketimini doğrudan etkiliyor. Q4_K_M gibi daha düşük niceleme seviyeleri, daha az VRAM kullanır ve daha hızlı çalışır, ancak bazı durumlarda kod doğruluğunda küçük kayıplara yol açabilir. Q8_0 ise daha fazla VRAM kullanır ancak daha doğru sonuçlar verir. Benim için optimal dengeyi bulmak, kullandığım GPU’nun VRAM kapasitesi ve projenin hassasiyetine göre değişti. Genellikle Q4_K_M ile başlayıp, eğer yetersiz gelirse Q5_K_M veya Q8_0’a geçiş yapıyorum. Özellikle HumanEval veya MBPP gibi kodlama benchmark skorlarına bakarak genel yetenekleri hakkında fikir edinsem de, asıl karar verici pratik testlerim ve modelin kendi kod tabanımdaki performansı oldu.

Verimlilik ve Entegrasyon: Geliştirme Akışına Nasıl Dahil Ettim?

Yerel LLM’leri geliştirme akışıma entegre etmek, sadece kod üretmekten çok daha fazlasını ifade ediyor. Amacım, bu güçlü araçları günlük rutinimin doğal bir parçası haline getirmekti; tıpkı bir linter veya debugger kullanır gibi. Bu entegrasyon, özellikle büyük bir üretim ERP’sinin karmaşık modüllerinde çalışırken, inanılmaz bir verimlilik artışı sağladı.

İlk adım, kullandığım IDE olan VS Code’a entegrasyonu sağlamaktı. Code GPT, Continue.dev veya Cursor gibi uzantılar, yerel ollama veya LM Studio sunucularına bağlanma yeteneği sunuyor. Bu sayede, kod yazarken doğrudan IDE içinden kod tamamlama, refactoring önerileri, yorum veya dökümantasyon oluşturma gibi işlemleri kolayca yapabiliyorum. Örneğin, belirli bir fonksiyonun karmaşık iş mantığını açıklayan bir docstring’i saniyeler içinde oluşturmak, manuel olarak yazmaya harcayacağım zamanın çok ötesinde bir verimlilik sağladı.

Ancak LLM’lerin asıl gücü, kod tabanımın bağlamını anlamalarında yatıyor. İşte burada RAG (Retrieval-Augmented Generation) devreye giriyor. Kendi yan ürünlerimin backend’inde veya kurumsal projelerde, LLM’in mevcut kodu, mimariyi ve hatta geçmiş commit mesajlarını anlayarak daha alakalı çıktılar üretmesi kritik. Bunun için, kod tabanımı düzenli olarak indeksleyen ve vektör veritabanına (örneğin ChromaDB veya Faiss ile) kaydeden Python tabanlı bir script geliştirdim. LlamaIndex veya LangChain gibi kütüphaneleri kullanarak, LLM’e bir soru sormadan önce, sorguyla ilgili kod parçacıklarını bu vektör veritabanından alıp, LLM’in bağlamına ekleyerek çok daha doğru ve projeye özgü yanıtlar alabiliyorum.

# Basit bir RAG akışı için Python örneği (LlamaIndex ve Ollama ile)
from llama_index.llms import Ollama
from llama_index import VectorStoreIndex, SimpleDirectoryReader

# Belgeleri yükle (örneğin kod dosyaları)
documents = SimpleDirectoryReader("path/to/your/codebase").load_data()

# Yerel Ollama LLM'i tanımla
llm = Ollama(model="codellama:7b-code", request_timeout=120.0)

# Vektör indeksi oluştur
index = VectorStoreIndex.from_documents(documents)

# Sorgu motorunu oluştur
query_engine = index.as_query_engine(llm=llm)

# Sorgu yap
response = query_engine.query("Mevcut 'user_service.py' dosyasındaki 'get_user_by_id' fonksiyonunu açıkla.")
print(response)

Bu RAG entegrasyonu, özellikle legacy sistemlerde veya büyük kod tabanlarında yeni bir geliştiricinin onboarding sürecini bile hızlandırabiliyor. Bir fonksiyonun neden böyle yazıldığını, hangi bağımlılıkları olduğunu veya hangi test senaryolarının bulunduğunu sormak, saatlerce kod okumaktan çok daha hızlı ve verimli.

graph TD;
  A["Geliştirici"] --> B["Kod Düzenleyici (IDE)"];
  B --> C{"Sorgu/İstek"};
  C -- "Kod Bağlamı Gerekli mi?" --> D{Karar};
  D -- "Evet" --> E["Vektör Veritabanı (RAG)"];
  E -- "İlgili Kod Parçaları" --> F["Yerel LLM Modeli (Ollama/LM Studio)"];
  D -- "Hayır" --> F;
  F -- "Önerilen Kod/Tamamlama" --> B;
  F -- "Açıklama/Dokümantasyon" --> G["Terminal/IDE Çıktısı"];
  B --> G;

Bu akış, LLM’in sadece bir kod üreteci olmaktan çıkıp, projenin derinliklerine inen bir “akıl hocası” rolünü üstlenmesini sağlıyor.

Maliyet Analizi: Bulut Çözümleriyle Yerel LLM’leri Karşılaştırmak

Yerel LLM’lere geçiş yapmamın en büyük motivasyonlarından biri, şeffaf ve öngörülebilir maliyet yapısıydı. Bulut tabanlı LLM servisleri, ilk bakışta düşük maliyetli gibi görünse de, benim gibi yoğun kullanan bir geliştirici için uzun vadede ciddi bir yük haline gelebiliyor. Bir bankanın iç platformu için kod yazarken veya kendi Android spam uygulamamın backend’ini geliştirirken, her API çağrısının token başına maliyeti hızla birikiyor.

Bulut sağlayıcıları (OpenAI, Anthropic, Google Gemini, Groq, Cerebras, OpenRouter gibi çoklu sağlayıcıları bile denedim) genellikle token bazlı ücretlendirme yapar. Bu, hem girdi (prompt) hem de çıktı (tamamlama) token’ları için ödeme yapmanız gerektiği anlamına gelir. Uzun prompt’lar veya detaylı yanıtlar, maliyeti katlayabilir. Özellikle prompt engineering yaparken veya RAG ile geniş bağlam pencereleri kullandığımda, bir anda yüzlerce dolarlık faturalarla karşılaşabiliyordum. Bu maliyetler, projenin bütçesine doğrudan yansıyor ve bazen tahminleri aşabiliyor.

Yerel LLM’lerde ise maliyet yapısı tamamen farklı. İlk olarak, bir donanım yatırımı yapmanız gerekiyor: güçlü bir GPU, yeterli RAM ve hızlı SSD. Bu, bir seferlik bir maliyet. Örneğin, ben bir RTX 4090’a ve 64GB RAM’e sahip bir sistem kurmak için belli bir miktar harcadım. Bu yatırımın ardından, tek düzenli maliyet elektrik tüketimi oluyor. Bir RTX 4090, tam yük altında yaklaşık 450W güç tüketir. Günde 8 saat tam yükte çalıştığını varsayarsak, bu yıllık elektrik maliyeti, bulut LLM API’lerine ödeyeceğim binlerce doların yanında devede kulak kalır.

Benzer bir maliyet analizini daha önce kendi VPS’imde self-hosted runner’ları çalıştırırken de yapmıştım. Başlangıçta pahalı gibi görünen bir donanım yatırımı, orta ve uzun vadede sürekli ödenen bulut servis ücretlerinden çok daha ekonomik olabiliyor. Özellikle projelerimde yüksek hacimli LLM kullanımım varsa, bu yatırımın geri dönüş süresi oldukça kısa oluyor.

Kısacası, eğer LLM’leri yoğun ve sürekli kullanıyorsam, özellikle gizliliğin kritik olduğu bir üretim ERP’si veya kendi finansal hesaplayıcılarım gibi projelerde, yerel LLM çözümü maliyet ve kontrol açısından açık ara önde.

Karşılaşılan Zorluklar ve Çözümler: Pratik Deneyimlerim

Yerel LLM kurulumu, her ne kadar avantajlı olsa da, yol boyunca bazı zorluklarla karşılaşmadım değil. Bu süreç, “olur o kadar” dediğim, deneyimle sabitlenmiş birçok dersi beraberinde getirdi.

En büyük zorluklardan biri, şüphesiz VRAM limitleriydi. Özellikle 34B veya 70B gibi daha büyük modelleri çalıştırmaya çalıştığımda, 24GB VRAM’e sahip GPU’m bile yetersiz kalabiliyordu. Bu durumda, ya daha küçük boyutlu modellere (7B-13B) yönelmek ya da daha yüksek niceleme seviyeleri (örneğin Q4_K_M) kullanarak modelin VRAM tüketimini düşürmek zorunda kaldım. llama.cpp’nin GPU offloading özelliklerini kullanarak modelin bir kısmını CPU’da çalıştırmak da bir çözüm oldu, ancak bu, çıkarım hızında belirgin bir düşüşe yol açtı.

Bir diğer sorun yavaş çıkarım (inference) süreleriydi. Büyük modeller veya düşük niceleme seviyeleri, yanıt sürelerini uzatabiliyordu. Özellikle IDE içinde anlık tamamlama beklerken bu durum can sıkıcı olabiliyor. Çözüm olarak, kritik anlarda daha küçük, hızlı modeller kullanmayı tercih ettim ve daha karmaşık sorgular için biraz daha beklemeyi göze aldım. Donanım yükseltme, tabii ki en kesin çözüm, ancak her zaman bütçe dahilinde olmayabiliyor.

Model halüsinasyonları, bulut LLM’lerinde olduğu gibi yerel modellerde de karşılaştığım bir problemdi. Özellikle kod üretirken yanlış bir syntax veya mantık hatası yapması, debugging sürecini uzatabiliyor. Bu sorunu aşmak için RAG entegrasyonumu güçlendirdim ve LLM’e daha fazla bağlam sunarak halüsinasyon riskini azalttım. Ayrıca, LLM’in ürettiği kodları otomatik testlerden geçiren bir CI/CD adımı ekleyerek, hataları erken yakalamayı hedefledim. Kendi yan ürünümün backend’inde, LLM tarafından üretilen her fonksiyonun unit testlerini de LLM’e yazdırıp kontrol mekanizmasını iki katına çıkardım.

Kurulum sürecinin kendisi de bazen karmaşık olabiliyor; bağımlılık çakışmaları, NVIDIA sürücü sorunları veya ollama ile LM Studio arasındaki yapılandırma farklılıkları gibi. Bu tür durumlarda, ortamı Dockerize etmek veya ollama gibi hepsi bir arada çözümler kullanmak, işleri büyük ölçüde basitleştirdi. Kendi VPS’imde farklı servisleri konteynerize ederken edindiğim deneyimler, burada da çok işime yaradı.

Son olarak, model güncellemelerini takip etmek ve yeni, daha yetenekli modeller çıktıkça ortamımı güncellemek de zaman zaman bir zorluk oldu. Bunun için basit bir bash script’i ile belirli aralıklarla ollama pull komutunu çalıştırarak modellerimi güncel tutmaya çalışıyorum.

Her ne kadar bu zorluklar zaman zaman canımı sıksa da, yerel LLM’lerin sunduğu gizlilik, kontrol ve uzun vadeli maliyet avantajları, bu küçük engelleri aşmaya değdiğini gösterdi.

Sonuç

Yerel LLM’lerle kodlama dünyasına adım atmak, benim için sadece bir teknoloji denemesi olmaktan öteye geçti; bu, yazılım geliştirme süreçlerimi daha özerk, güvenli ve maliyet etkin hale getiren stratejik bir karardı. Bulut tabanlı çözümlerin kolaylığı cazip gelse de, özellikle hassas projelerde veri gizliliği ve öngörülemez maliyetler gibi dezavantajları, beni kendi donanımım üzerinde tam kontrol sahibi olmaya itti.

Kurulum sürecinde donanım gereksinimlerinden model seçimine, entegrasyon stratejilerinden maliyet analizine kadar birçok detayı deneyimledim. VRAM limitleri, yavaş çıkarım hızları ve model halüsinasyonları gibi zorluklarla karşılaştım ancak bu engelleri aşmak için pratik çözümler geliştirdim. Özellikle RAG entegrasyonu ve IDE uzantıları sayesinde, LLM’ler artık günlük kodlama akışımın ayrılmaz bir parçası.

Eğer sizin de yüksek hacimli LLM kullanımınız varsa, veri gizliliği sizin için kritikse ve uzun vadede maliyetleri öngörülebilir kılmak istiyorsanız, yerel bir LLM kurulumunu şiddetle tavsiye ederim. Başlangıçtaki yatırım ve kurulum çabası, sonrasında size sunduğu esneklik ve bağımsızlıkla fazlasıyla karşılığını veriyor. Unutmayın, en iyi LLM, sizin ihtiyaçlarınıza en uygun olanıdır ve bazen bu, kendi sunucunuzda çalışan bir model anlamına gelir.