84 lines
3.3 KiB
Markdown
84 lines
3.3 KiB
Markdown
---
|
||
date: 2026-03-21
|
||
topic: model-provider-switch
|
||
---
|
||
|
||
# Model Provider Switch
|
||
|
||
## What We're Building
|
||
WiseClaw admin paneline global bir model sağlayıcı seçimi ekliyoruz. Yönetici ister mevcut yerel LM Studio akışını aktif edecek, ister z.ai sağlayıcısına geçip API key ile `glm-4.7` veya `glm-5` modellerini kullanacak.
|
||
|
||
Bu seçim tüm yeni istekler için ortak runtime ayarı olacak. Yani Telegram, admin testleri ve backend orkestrasyonu seçili sağlayıcıya göre aynı LLM istemcisini kullanacak.
|
||
|
||
## Why This Approach
|
||
En sade ve güvenli çözüm global provider seçimi. Per-user ya da per-chat seçim şu aşamada gereksiz karmaşıklık getirir; secret yönetimi, UI, audit ve hata ayıklama zorlaşır.
|
||
|
||
z.ai tarafı OpenAI-uyumlu API sunduğu için mevcut istemci mimarisi çok büyük kırılım olmadan genişletilebilir. Bu da LM Studio ile z.ai arasında ortak bir soyutlama kurmayı mantıklı hale getiriyor.
|
||
|
||
## Approaches Considered
|
||
### Approach A: Tek Global Provider Ayarı
|
||
Admin panelde provider seçilir, sadece ilgili alanlar görünür, backend seçili provider'a göre çağrı yapar.
|
||
|
||
Pros:
|
||
- En basit kullanıcı deneyimi
|
||
- Backend davranışı öngörülebilir
|
||
- Secret ve runtime yönetimi kolay
|
||
|
||
Cons:
|
||
- Aynı anda iki farklı provider kullanılamaz
|
||
- Deneysel karşılaştırmalar için manuel geçiş gerekir
|
||
|
||
Best when: Ürün tek bir aktif model hattı ile çalışacaksa
|
||
|
||
### Approach B: Global Provider + Manual Override Alanı
|
||
Global seçim korunur ama bazı akışlarda provider/model override edilebilir.
|
||
|
||
Pros:
|
||
- Daha esnek
|
||
- Test ve karşılaştırma kolaylaşır
|
||
|
||
Cons:
|
||
- UI ve backend karmaşıklığı artar
|
||
- Hangi isteğin hangi modelle çalıştığı daha az net olur
|
||
|
||
Best when: Kısa vadede A/B model denemesi yapılacaksa
|
||
|
||
### Approach C: Ayrı Provider Sekmeleri ve Bağımsız Konfigürasyonlar
|
||
Hem local hem z.ai ayarları hep görünür, ama aktif flag ayrı tutulur.
|
||
|
||
Pros:
|
||
- Tüm ayarlar tek ekranda görünür
|
||
- Geçişler hızlı olur
|
||
|
||
Cons:
|
||
- UI kalabalıklaşır
|
||
- İlk sürüm için gereğinden fazla yapı
|
||
|
||
Best when: Sık sağlayıcı değişimi bekleniyorsa
|
||
|
||
## Recommendation
|
||
Approach A.
|
||
|
||
İlk sürüm için en doğru yol bu. Admin panelde:
|
||
- `Model Provider`: `local` / `zai`
|
||
- `local` seçiliyken: base URL + local model
|
||
- `zai` seçiliyken: API key + model dropdown (`glm-4.7`, `glm-5`)
|
||
|
||
Backend tarafında ortak bir LLM gateway oluşturulmalı. Seçili provider'a göre:
|
||
- Local: mevcut LM Studio/OpenAI-compatible endpoint
|
||
- Z.AI: z.ai OpenAI-compatible endpoint + bearer/api key
|
||
|
||
## Key Decisions
|
||
- Provider seçimi global olacak: sistem davranışı tek bir aktif modele bağlı kalacak.
|
||
- z.ai API key secret olarak saklanacak: normal runtime settings içine düz yazı olarak girmeyecek.
|
||
- z.ai model listesi ilk aşamada sabit olacak: `glm-4.7` ve `glm-5`.
|
||
- UI conditional olacak: sadece seçili provider'ın alanları gösterilecek.
|
||
- Backend provider-aware olacak: mevcut `ollama_base_url/default_model` yaklaşımı daha genel `provider/base_url/model` yapısına genişletilecek.
|
||
|
||
## Open Questions
|
||
- z.ai için sabit bir base URL kullanıp UI'da göstermeyelim mi, yoksa readonly/default bir alan olarak mı gösterelim?
|
||
- `glm-4.7` ve `glm-5` dışında gelecekte serbest model adı girişi de desteklenecek mi?
|
||
|
||
## Next Steps
|
||
- `/workflows:plan` seviyesinde implementasyon planına geç
|