# LLM sağlayıcısını (Ollama → Bedrock/OpenAI) nasıl soyutlamalıyım?

> Tek bir dar arayüz (complete(prompt, opts)) ve config ile seçilen üç implementasyon kurun; context penceresi, gecikme ve maliyeti config olarak taşıyın.

- Soruldu: 2026-05-03
- Yanıtlandı: 2026-05-06
- Soran: Deniz
- Etiketler: mimari
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/ollama-dan-uretimde-bedrock-openai-a-gecerken-llm-soyutlamasi/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Uygulamaya kod analizi ve metin özetleme yapan bir AI özelliği ekliyoruz. Geliştirici makinelerinde maliyet olmasın diye Ollama + yerel LLM (Llama 3) kullanıyoruz; üretimde AWS Bedrock veya OpenAI planlıyoruz.

LLM sağlayıcısını soyutlamak için hangi tasarım kalıbını uygulamalıyım? Lokaldeki token sınırları ve yanıt süreleriyle üretimdeki yapısal farkları mimaride nasıl tolere ederim?


Kısa cevap: Sağlayıcının etrafına değil, **yeteneğin** etrafına dar bir port/adapter (Strategy) kurun. Küçük bir arayüz + config'le seçilen gerçek implementasyonlar; daha fazlası değil.

Sizin asıl tehlikeniz aşırı soyutlama: insanlar bunu jenerik bir "AI framework"e çevirmeye çalışıp aylarını yiyor. İhtiyacınız olan tek bir ince arayüz.

1. **Arayüzü yetenek üzerinden tanımlayın, vendor üzerinden değil.** `complete(prompt, opts): Result` gibi minik bir kontrat yeter. Ollama, Bedrock ve OpenAI bunun üç implementasyonu olur; hangisinin çalışacağını `config`/`env` seçer. Sağlayıcıya özel parametreleri core mantığa sızdırmayın — arayüz küçük ve yetenek-tabanlı kalsın.
2. **Farkları açık timeout + ucuz fallback ile tolere edin.** Üretimde sağlayıcı yavaşlar veya rate-limit yer; her çağrıya net bir timeout koyun ve gerektiğinde ucuz/yerel bir fallback'e düşün. Bu, mimariyi tek bir sağlayıcının kapris yapmasına bağımlı olmaktan kurtarır.
3. **Token bütçesini kenarda yönetin.** Her modelin context penceresi farklı; girdiyi modele sığacak şekilde kenarda truncate/özetleyin. "Lokalde küçük, üretimde büyük pencere" gibi farklar iş mantığında `if` olmamalı — config olmalı.
4. **Streaming'i aynı arayüzün arkasına koyun.** İhtiyaç varsa stream desteğini opsiyonel olarak aynı kontratta tutun; çağıran taraf sağlayıcının stream API'sını bilmesin.
5. **Golden-prompt test seti tutun.** Aynı prompt setini her sağlayıcıya karşı çalıştırın; çıktı kalitesi ve regresyon kıyaslamasını otomatikleştirin. Sağlayıcı değiştirdiğinde neyin bozulduğunu bu yakalar.

**Sonuç:** Ben olsam tek bir küçük arayüz, üç gerçek implementasyon ve config-tabanlı seçim kurardım — fazlası YAGNI. Yerel Ollama dev maliyeti ve hızlı iterasyon içindir; üretimdeki context penceresi, gecikme, rate-limit ve maliyet farklarını **konfigürasyon** olarak ele alın, iş mantığına dallanma olarak değil. Soyutlama dar oldukça sağlam olur.

## İlgili Yazılar

- [AI-Assisted Engineering Workflow'um](https://sade.dev/tr/journal/ai-assisted-engineering-workflow) — sade.dev
- [Gitflow'dan Trunk-Based'e geçerken feature flag mimarisini nasıl konumlandırırım?](https://www.muhammetsafak.com.tr/sor-bakalim/gitflow-mu-trunk-based-mi-ve-feature-flag-mimarisi/) — Sor Bakalım
- [CQRS'i ne zaman uygulamalı ve okuma/yazma modellerini nasıl senkronlamalıyım?](https://www.muhammetsafak.com.tr/sor-bakalim/cqrs-ne-zaman-uygulanir-ve-okuma-yazma-senkronizasyonu/) — Sor Bakalım
- [Esnek ürün nitelikleri için NoSQL mu, PostgreSQL mi seçmeliyim?](https://www.muhammetsafak.com.tr/sor-bakalim/esnek-urun-nitelikleri-icin-nosql-mu-postgresql-mi/) — Sor Bakalım