"Bir bulut yedeği ekle" kulağa bir yapılandırma bayrağı gibi gelir. Bir erişim (retrieval) sistemi içinse, yapılandırma bayrağı kılığına girmiş bir veri bütünlüğü problemine çok daha yakındır.
Metin üretimi durumsuzdur — bir sağlayıcı yavaşsa bir başkasını kullanırsınız ve sonradan kimse farkı anlayamaz. Gömme öyle değildir. Gömme, aylarca sorgulayacağınız bir tabloya yazar ve bir sorgu ancak sorguyu gömen kodlayıcı ile satırları gömen kodlayıcı birbiriyle uyuşuyorsa anlamlıdır.
Fantom MCP Server'ın bulut entegrasyonu, büyük ölçüde bunu güvenli kılmak için gereken düzenekten ibarettir.
Beş rol, ayrı ayrı yönlendirilir
Tek bir "bulutu kullan" anahtarı yoktur, çünkü beş çıkarım rolünün gereksinimleri gerçekten birbirinden farklıdır. Her biri kendi politikasıyla yönlendirilir:
Dört politika:
| Politika | Davranış |
|---|---|
local |
Yalnızca yerel GPU ve sidecar sunucuları. Ağdan hiçbir şey çıkmaz. |
cloud |
Yalnızca OpenRouter. Hiç GPU gerekmez. |
aggregate |
Her ikisi de, aynı kuyruktan çeken tek bir yayılım havuzunda. (varsayılan) |
backup |
Önce yerel, bulut yedekte tutulur. |
aggregate varsayılandır; çünkü hem zaten parasını ödediğiniz donanımı kullanan hem de ani yük artışlarını soğuran seçenek odur.
Bunu güvenli kılan kapı
aggregate altında yerel ve bulut vektörleri aynı tabloya, iç içe geçmiş biçimde, aynı çalıştırma sırasında düşer. İki servis yığını birbirinin yerine geçebilir vektörler üretmiyorsa, kosinüs mesafesi karşılaştırılabilir olmaktan çıkar ve erişim sessizce bozulur — hangi satırın nereden geldiğini anlamanın hiçbir yolu olmadan.
Dolayısıyla uyumluluk bir uyarı değildir. Katı bir önkoşuldur: testi geçmemiş bir sağlayıcı tek bir metne bile hizmet etmemelidir.
Kontrol bilinçli olarak kaba saba: aynı sonda metinleri her iki rota üzerinden gömülür, karşılık gelen her çift için ikili kosinüs benzerliği alınır, en düşük değerin 0,99'u geçmesi ve dönen boyutun yapılandırılan genişliğe tam olarak eşit olması istenir.
İlginç olan sayı, testi geçemeyendir. Yerel model ile bulut modeli arasında ölçülen kosinüs 0,976 — üstünkörü bir kontrolde sorunsuz görünecek kadar yakın, tabanın rahatça altında ve tam da cloud politikasının var olma nedeni. Bu iki kodlayıcı birbirinin yerine geçemez; dolayısıyla bulut olanı kullanmak istiyorsanız, dizinin tamamının ondan inşa edilmesi gerekir. Bu bir geçici çözüm değildir; politikanın işini yapmasıdır.
Bu da referansın her zaman yerel olmadığı anlamına gelir. GPU'ların hizmet verdiği üç politika altında referans yerel olmak zorundadır, çünkü test edilen özellik tam olarak tabloda hâlihazırda bulunan satırlarla uyuşmadır. cloud altında yerel bir modelle karşılaştırma anlamsız olurdu — hiçbir yerel vektör yazılmaz — bu yüzden referans başka bir bulut sağlayıcı olur ve kapı bunun dışında değişmez. Hiçbir zaman devre dışı bırakılmaz.
Gömülmek yerine açıkça belirtilen sınır
Tam olarak tek bir bulut sağlayıcı varsa bir eş yoktur ve sağlayıcılar arası tutarlılık boştur: bir sağlayıcı kendisiyle çelişemez ve her satırı yalnızca o yazar. Kapı bu durumda boyutu ve yukarı akış sabitlemesini kontrol eder, başka bir şeyi değil.
Bu, kapsamda gerçek bir daralmadır. Sabitlenmiş tek bir yukarı akış, zamanla aynı sabitleme arkasında servis yığınını değiştirebilir — bir barındırıcının aynı model etiketinin farklı bir nicemlemesini yeniden dağıtması gibi — ve tek sağlayıcılı bulut rejiminde bunu hiçbir şey yakalamaz. Bu yapılandırmayı çalıştırıyorsanız bilmeye değer.
Gömme neden sabitlenir, yeniden sıralama neden sabitlenmez
Aynı model etiketine hizmet eden iki OpenRouter yukarı akışı, özdeş vektörler üreteceğini garanti etmez. Sabitlenmemiş bir gömme rotası bu nedenle tek bir vektör uzayını istekler arasında bölebilir ki bu, aynı bozulmanın daha sessiz bir yoludur. Dolayısıyla her gömme rotası yukarı akış sağlayıcısını adıyla belirtmek zorundadır ve belirtmezse sistem kapalı biçimde başarısız olur.
Yeniden sıralama durumsuzdur — bir aday listesini puanlar ve hiçbir şey yazmaz — bu yüzden sabitlemeye ihtiyacı yoktur.
Tek bütçe, her sağlayıcının üstünde tutulur
Bütün bulut yolunu şekillendiren tuzak şu: OpenRouter hız sınırını çağrı yapan başına değil, anahtar başına uygular.
Her sidecar aynı anahtarı alır. Her biri sekiz eşzamanlı istekle sınırlanmış üç sağlayıcı, tek bir ortak bütçeye karşı yirmi dört istek demektir. Sağlayıcı başına bir üst sınır bu limiti koruyamaz — üst sınırın hepsinin üstünde yaşaması gerekir.
Oradaki birkaç ayrıntıyı öne çıkarmaya değer.
İzin birimi eşzamanlılıktır, dakikadaki istek sayısı değil. Keşfedilen bir rate_limit bir RPM değeridir; bu yüzden havuzun kendi ölçtüğü gidiş-dönüş gecikmesi kullanılarak dönüştürülür — Little Yasası — yani açılıştaki bir sayıya sabitlenmek yerine gecikme kaydıkça kendini yeniden türetir.
Güvenilen bir RPM ayrıca doğrudan uygulanır, kayan pencereli bir kapı olarak; böylece kısa süreliğine fazla yüksek çıkan bir gecikme tahmini hesabı aşırı kullanamaz. Ama bu ikinci kapı yalnızca herkesin güvendiği bir RPM için devreye alınır. Anahtarı bozuk bir hız limiti bildiren — ya da hiç bildirmeyen, ki modern biçim budur — bakiyeli bir hesap bunun yerine kredi bakiyesine göre boyutlandırılır ve pencere kapısı almaz. Körelmiş bir "dakikada 1" değeri için bu kapıyı devreye almak kesinlikle daha kötüydü: tüm bulut yayılımını dakikada tek isteğe düşürüyordu.
Geri çekilme uyarlanabilirdir, asla anında yeniden deneme değildir. Bir 429, etkin bütçeyi yarıya indirir ve jitterlı bir soğuma başlatır; sürekli temiz geçen bir pencere ise bütçeyi tavana doğru birer izin artışıyla geri tırmandırır.
Varsayılanlar bilinçli olarak çekingendir. Hiçbir şey keşfedilemediğinde dört izin; çünkü okuyamadığınız bir boşluğu varsaymak, 429 fırtınasına ve yarım yazılmış bir tabloya giden yoldur. Ve 256'lık sert bir tavan; çünkü bir geçersiz kılma kutusuna yapılan yazım hatası hesabı doyurmamalıdır.
Yerel GPU'lar tamamen muaftır. İş sağlayıcı başına çekilir; bu yüzden engellenen bir bulut sağlayıcısı basitçe çekmeyi bırakır, yereller çalışmaya devam eder. Bir bulut hız limiti bulutu yavaşlatır; donanımınızı boşta bırakmaz.
Anahtar yönetimi
OpenRouter anahtarı, Fantom MCP Server açısından yalnızca yazılabilirdir. Bir yönetici isteğiyle gelir, doğrudan WebSocket çerçevesi üzerinden onu kullanacak sidecar'a gider; yapılandırmaya asla yazılmaz, asla günlüklenmez, hiçbir uç nokta tarafından asla döndürülmez ve çağrının ötesinde asla tutulmaz.
Kalıcılaştırılan tek şey, kalıcılaştırılması güvenli olandır: hangi rollere model eşlendiği, hangi yukarı akışın sabitlendiği, yönlendirme modları ve bir gönderimin gerçekleştiği bilgisi. Bir modu ya da modeli değiştirmek için anahtarsız yeniden gönderim normal durumdur — sidecar, kısmi bir gönderimi zaten elinde tuttuğu kayıtla birleştirir.
Varsayılan olarak ne nerede çalışır
- Yeniden sıralayıcı —
qwen/qwen3-reranker-8b - Kod asistanı —
poolside/laguna-s-2.1 - RLM sanal alanı —
deepseek/deepseek-v4-flash, yalnızca-yerel yedek moduyla
Gömme modelleri dağıtım başına seçilir, çünkü dizininizin ne olduğunu belirleyen seçim odur. Kod vektör tablosu 2560 boyutlu tek bir uzaydır; yukarıdaki her şey onu öyle tutmak için vardır.
Mesele
Bunların hiçbiri bulutu hızlandırmaz. Kazandırdığı şey, belirli bir şeyi söyleyebilme yeteneğidir: dizindeki her satırın, sorgunuzu gömecek kodlayıcıyla birbirinin yerine geçebilirliği kanıtlanmış bir kodlayıcı tarafından yazıldığını, hiçbir tek projenin hesabı yiyip bitiremeyeceğini ve bulut kısıtlandığında GPU'ların çalışmaya devam ettiğini.
"Bir bulut yedeği ekle" gerçekten de bir yapılandırma bayrağıdır. Bu yazıdaki her şey, o bayrağı açmanın güvenli olması için altta doğru olması gerekenlerdir.
Fantom MCP Server, github.com/Project-SandStar/FantomMcpServer adresinde kaynağı erişilebilir haldedir. Önceki yazılar: Sidecar filosu ve RLM · diller arası kod zekâsı.