Mimari ve çalışma modeli
Bulut API ile yerel açık model seçimi gizlilik sloganıyla değil kullanım profiliyle yapılır. Veri sınıfı ve aktarım sınırı, kalite, context, araç desteği, gecikme, erişilebilirlik, kapasite dalgalanması, ekip becerisi, lisans ve toplam maliyet aynı matriste değerlendirilir.
Bulut API, yönetilen ölçek ve hızlı model erişimi sağlayabilir; kota, bölge, veri işleme koşulu, ağ bağımlılığı ve birim fiyat riski taşır. Yerel model daha fazla kontrol ve sabit kapasite sağlar; GPU tedariki, güvenlik yaması, model sunumu, eval, güç ve nöbet sorumluluğu kuruma geçer. Hibrit routing belirli veri sınıflarını ve görevleri farklı yollara ayırabilir.
Taşınabilirlik için uygulama, sağlayıcı API'sini doğrudan iş mantığına gömmemelidir. Ortak mesaj/araç şeması, eval seti, token muhasebesi, hata sözleşmesi ve policy router kullanılır. Model eşdeğerliği varsayılmaz; her route kendi kabul eşiğinden geçer.
- 1İstek, kimlik ve veri sınıfı
- 2Policy router ve model route'u
- 3Bulut API veya yerel serving
- 4Ortak eval, telemetri ve fallback
Tasarım parametreleri
- Veri sınırı
- Hangi alanların dış hizmete çıkabileceğini, saklama/eğitim seçeneklerini ve bölgeyi sözleşme ile doğrulayın.
- Talep eğrisi
- Ortalama yerine tepe QPS, context/output dağılımı ve mevsimselliği kapasite/maliyet modeline koyun.
- Operasyon yükü
- GPU, enerji, soğutma, yedeklilik, patch, 7×24 izleme ve uzman zamanı için TCO hesaplayın.
- Çıkış planı
- Taşınabilir API, eval seti, veri export'u ve alternatif route'u yılda en az bir kez tatbik edin.
Hesap ve uygulama örneği
Aylık 60 milyon input ve 8 milyon output token'lı işte API maliyeti birim fiyatlarla hesaplanır; retry, embedding, rerank ve ağ ayrıca eklenir. Yerel tarafta dört GPU'nun amortismanı, %35 ortalama kullanım, N+1 yedek, enerji ve personel dahil edilir. Yalnız GPU satın alma bedelini API faturasıyla karşılaştırmak hatalıdır.
İnteraktif isteklerin %90'ı genel ve düşük hassasiyetli, %10'u gizli belge içeriyorsa policy router ilk grubu buluta, ikincisini yerel RAG/model yoluna gönderebilir. Her iki yol aynı görev evalinde test edilir; yanlış sınıflandırma güvenlik olayı sayılır.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
ai-route test --dataset enterprise-routing-v2 --routes cloud,onprem --verify-data-policy
ai-tco compare --horizon 36m --demand demand.csv --include-gpu,energy,staff,api,network
ai-failover exercise --from cloud --to onprem --max-rto 120sHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Bulut route kotaya takılıyor | Tepe trafik veya token limiti kapasite modelinde eksiktir. | 429, queue, quota ve token dağılımını inceleyip backoff/fallback politikasını test edin. |
| Yerel model ucuz görünmüyor | Kullanım düşük, N+1 ve operasyon maliyeti yüksektir. | GPU saatini, boşta oranı, enerji ve iş gücünü görev/tenant bazında dağıtın. |
| Fallback farklı cevap davranışı veriyor | Alternatif model aynı eval/şema kapısından geçmemiştir. | Route bazlı kalite, tool schema ve güvenlik regresyonunu çalıştırın. |
Kabul ve doğrulama kontrolleri
- Veri sınıfı ve bölgesel aktarım kurallarını route politikasına kodlayın.
- Bütün adayları aynı görev ve güvenlik eval setinde karşılaştırın.
- API maliyeti ile yerel TCO'yu aynı üç yıllık talep senaryosunda hesaplayın.
- Kota, ağ kesintisi ve GPU arızasında fallback tatbikatı yapın.
- Model sağlayıcısı ayrıntılarını uygulamadan soyutlayan sözleşme kullanın.
- Lisans, model kartı ve kullanım kısıtlarını release kanıtına ekleyin.
İlgili kavramlar
Maliyet ölçümünün sınırı
Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayın.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Bağımlılık ve yeniden başlatma sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Hizmetlerin yeniden başlatılma sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.