OpenRouter US In-Region Routing: Kurulum ve Sınırlar

Hassas istemlerin işlenmesinin ABD sınırları içinde kalması gerekiyorsa OpenRouter US in-region routing, yalnızca ABD merkezli bir sağlayıcı tercihi olmaktan çok daha fazlasını sunuyor: gerçek bir veri yerleşimi denetimi. Ancak önemli bir karşılığı var. Özellik yalnızca Business ve Enterprise planlarında kullanılabiliyor; model için uygun bir ABD uç noktası yoksa istek başka bir bölgeye yönlendirilmek yerine başarısız oluyor.

30 saniyelik karar özeti

OpenRouter US in-region routing, birden fazla model sağlayıcısına erişimi korurken istem işleme sürecini ABD'de tutmak zorunda olan kurumlar için değerlendirmeye değer. Sıradan, herkese açık veri iş yüklerinde ise genellikle gereksizdir. Ayrıca zero-data-retention ayarlarının veya sağlayıcı sözleşmelerinin incelenmesinin yerini tutmaz.

OpenRouter, mevcut AB uç noktasına ek olarak 9 Eylül 2026'da ABD yönlendirmesini duyurdu. Resmî duyuru yazısına göre, ABD ana makine adına gönderilen istekler istek yaşam döngüsünün tamamında ABD'de şifresi çözülerek işleniyor.

Hassas servislerde ABD yönlendirmesini kullanıp daha düşük riskli trafiği küresel uç noktada bırakabilirsiniz; geçişi kademeli yapmak mümkün.

Bölgesel uç nokta gerçekte neyi denetliyor?

Bölgesel ana makine adı, OpenRouter'ın bir isteğin şifresini nerede çözeceğini, nerede işleyeceğini ve hangi sağlayıcı uç noktalarının isteği sunabileceğini belirler. OpenRouter ayrıca sunucu araçlarını yargı bölgesine göre değerlendirdiğini söylüyor; veriyi seçilen bölgenin dışına çıkaracak bir araç, küresel altyapıyı sessizce kullanmak yerine devre dışı bırakılıyor.

Modeli geliştiren şirketin ülkesi, ağ geçidinin veriyi nerede çözdüğünü ya da çıkarımın nerede yapıldığını tek başına göstermez.

OpenRouter süreci şu şekilde tanımlıyor:

1. İstek us.openrouter.ai adresine ulaşır.
2. TLS sonlandırma, şifre çözme, ağ geçidi işleme ve uygun sunucu aracı işleme ABD'de gerçekleşir.
3. Yönlendirme yalnızca ABD'de çalışan sağlayıcı uç noktalarını dikkate alır.
4. Uygun sağlayıcı çıkarımı ABD'de gerçekleştirir.
5. Uygun bir rota yoksa OpenRouter 404 No endpoints found supporting your data region. yanıtını döndürür.

Bu kapalı devre başarısızlık davranışı kritik önem taşıyor. Küresel bir geri dönüş, erişilebilirliği artırırdı ancak katı bir veri yerleşimi politikasını geçersiz kılardı; OpenRouter bölgesel isteklerde tamamlanma yerine yerleşim kuralını önceliklendiriyor.

“Sağlayıcının milliyetinden çok gerçek veri yolu, günlük tutma politikası, alt işleyiciler, barındırma bölgesi ve zero-data-retention'ın zorunlu kılınıp kılınamayacağı önemlidir.” — r/openrouter topluluğunda u/MembershipEmergency7

Bu kullanıcı yorumu, satın alma değerlendirmesi için doğru bakış açısını sunuyor. Bölgesel yönlendirme, OpenRouter'ın iddia ettiği işleme konumu sorusunu yanıtlıyor; ancak sözleşmeler, saklama süreleri, alt işleyiciler, denetim dışa aktarımları ve olay prosedürleri yine de ayrıca incelenmeli.

ABD üzerinden yönlendirilen istek nasıl kurulur?

OpenRouter US in-region routing kurulumu, çoğu durumda isteği baştan yazmayı değil API temel URL'sini değiştirmeyi gerektirir. Aynı API anahtarı, istek gövdesi, model kimliği, sağlayıcı tercihleri, geri dönüşler ve gizlilik ayarları kullanılmaya devam eder.

1. Plan erişimini doğrulayın

OpenRouter, in-region routing özelliğini Business ve Enterprise müşterileri için listeliyor. Herkese açık fiyatlandırma sayfasında kullandıkça öde kullanım için %5,5 platform ücreti yer alıyor; ancak ABD yönlendirmesi için ayrı, self-servis bir ek ücret yayımlanmıyor. Bütçe planlamadan önce Business fiyatlandırmasını veya sözleşme fiyatını doğrulayın.

2. ABD'de kullanılabilen modelleri bulun

Models uç noktasını bölgesel ana makine adı üzerinden sorgulayın. Dönen katalog, en az bir uygun ABD sağlayıcı uç noktası olan modelleri yansıtır.

curl https://us.openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

Bölgesel katalog, sağlayıcılar ve dağıtımlar değiştikçe farklılaşabilir. Bu nedenle model keşfi, bir kez hazırlanıp unutulan bir elektronik tablo yerine dağıtım kontrollerinin parçası olmalı.

3. İsteği ABD temel URL'si üzerinden gönderin

curl https://us.openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/llama-3.3-70b-instruct",
    "messages": [
      {"role": "user", "content": "Summarize this internal policy."}
    ]
  }'

Bu örnekteki model, OpenRouter'ın sovereign AI dokümantasyonundan alınmıştır. Üretimde kullanmadan önce canlı ABD kataloğunda doğrulayın.

4. Guardrails ile bölgeyi zorunlu kılın

Uygulama yapılandırmaları zamanla değişebilir. OpenRouter'ın sovereign AI dokümantasyonuna göre Guardrails, bir çalışma alanı, ekip, üye veya API anahtarı için allowed_data_regions değerini us olarak ayarlayabiliyor. İzin verilmeyen bir ana makine adına gönderilen istek, işleme alınmadan önce HTTP 403 ile reddediliyor.

Düzenlemeye tabi bir uygulama için çalışma alanı varsayılanı daha güvenli başlangıç noktasıdır; çünkü her geliştiricinin bölgesel ana makine adını hatırlamasına bağlı kalmaz. API anahtarı bazındaki kurallar ise hassas servisleri çalışma alanı varsayılanından daha sıkı hale getirebilir.

5. Yalnızca başarıyı değil, başarısızlığı da test edin

Desteklenen bir modelle bir test, ABD kataloğunda yer almayan bir modelle de başka bir test çalıştırın. Operasyon ekibinin olayı temel URL'yi küresel uç noktaya çevirerek “çözmemesi” için bölgesel 404 yanıtına özel uyarı tanımlayın.

Birbirine karıştırılan gizlilik kontrolleri

US in-region routing coğrafyayı denetler; ZDR, veri toplama filtrelemesi ve sağlayıcı şartları ise farklı risk alanlarını kapsar. Uyumlu bir tasarım bunların dördünü de gerektirebilir; birini etkinleştirmek diğerlerinin de sağlandığı anlamına gelmez.

OpenRouter'ın sağlayıcı günlükleme dokümantasyonu önemli bir ayrım yapıyor: Kullanıcılar sağlayıcıları eğitim veya veri toplama politikasına göre filtreleyebilir, ancak saklama gereksinimleri otomatik olarak yönlendirme kurallarına dönüştürülmez. Sağlayıcı şartlarını değerlendirmek ekiplerin sorumluluğundadır.

Katı kurallı bir istek, bölgesel yönlendirmeyi gizlilik parametreleriyle birlikte kullanabilir:

{
  "provider": {
    "zdr": true,
    "data_collection": "deny"
  }
}

Eklenen her koşul, uygun sağlayıcı kümesini daraltır. Ortaya çıkan 404 yanıtı veya daha sınırlı model seçeneği, mutlaka bir yönlendirme arızasına değil, politikanın doğal sonucuna işaret eder.

Onay vermeden önce iş yükünü doğrulayın

Üretim incelemesinde yalnızca “ABD sağlayıcısı” ifadesini yeterli saymak yerine canlı rotayı ve hata davranışını doğrulamak gerekir. Pratikteki eksik nokta denetlenebilirliktir: OpenRouter coğrafi garantiyi belgeliyor, ancak herkese açık materyaller; gecikme, saklama şartları, önbellek davranışı ve sözleşmesel kanıtları model-sağlayıcı bazında tek bir evrensel matriste sunmuyor.

Onay sürecini şu sırayla yürütün:

1. ABD model kataloğunu, üretimdekiyle aynı hesap ve gizlilik ayarlarıyla sorgulayın.
2. Gerekli modeli seçin ve OpenRouter'ın gösterdiği uygun sağlayıcı uç noktalarını kaydedin.
3. ABD Guardrails kurallarını çalışma alanı veya API anahtarı düzeyinde uygulayın.
4. İş yükü ikisini de gerektiriyorsa ZDR'yi etkinleştirin ve veri toplamayı engelleyin.
5. Sağlayıcının güncel saklama şartlarını ve alt işleyicilerini satın alma süreci üzerinden doğrulayın.
6. Modeli, hizmet veren sağlayıcıyı, istek kimliğini, durumu, gecikmeyi ve politika kaynaklı hataları günlüğe kaydedin.
7. Kullanılamayan bir modeli test edin; hiçbir kod yolunun openrouter.ai üzerinden yeniden deneme yapmadığını doğrulayın.
8. Model, sağlayıcı tercihi veya gizlilik kuralı değiştiğinde kontrolü yeniden çalıştırın.

Topluluk paylaşımları, rotanın yayına alındıktan sonra neden gözlemlenmesi gerektiğini gösteriyor. Bir Reddit tartışmasında u/Cooperman411, “ZDR (Zero Data Retention) etkin olduğu için sağlayıcı olarak Deepseek'i bulamadım.” dedi. Bu bir kıyaslama sonucu değil, tekil bir deneyim; ancak bir gizlilik kontrolünün beklenen bir rotayı nasıl kaldırabileceğini gösteriyor.

Başka bir iş yükü için bildirilen önbellek isabet oranı veya gecikme rakamlarını kendi ortamınıza taşımayın. Sağlayıcı seçimi, gizlilik filtreleri, istem yapısı, model dağıtımı ve trafik koşulları sonucu değiştirebilir; bunun yerine üretim koşullarını yansıtan isteği ölçün.

US in-region routing ne zaman doğru tercih?

OpenRouter US in-region routing, kapalı devre çalışan bir ABD işleme sınırına ihtiyaç duyan ve daha küçük bir katalog karşılığında çoklu model erişimine değer veren kurumlar için uygun. Resmî veri yerleşimi zorunluluğu olmayan bireysel geliştiriciler ve ekipler ise genellikle küresel uç noktada kalmalı; çünkü bölgesel özellik daha üst seviye bir plan gerektiriyor ve erişilebilirliği azaltabiliyor.

Bu özelliği varsayılan hız beklentisiyle değil, veri yerleşimi ihtiyacı için seçin: OpenRouter ABD uç noktası için genel bir gecikme kıyaslaması yayımlamadı ve bölgesel sağlayıcı havuzları farklılık gösterebilir.

OpenRouter US in-region routing: Sık sorulan sorular

Araçlar da ABD'de mi kalıyor?

OpenRouter, sunucu araçlarını yargı bölgesine göre değerlendirdiğini ve veriyi seçilen bölgenin dışına gönderecek araçları devre dışı bıraktığını söylüyor. Canlıya almadan önce iş yükünün gerektirdiği spesifik aracı doğrulayın.

Garanti tüm metadatayı kapsıyor mu?

Duyuru materyali açıkça istemlerden, tamamlamalardan, istek işlemeden, sağlayıcı yönlendirmesinden ve sunucu araçlarından söz ediyor. Bir kurumun politikasının gerektirdiği faturalandırma kayıtları, kötüye kullanım telemetrisi, günlükler, yedekler ve diğer metadatalar için OpenRouter'dan sözleşmesel ayrıntı isteyin.

Kişisel hesapla ABD uç noktasını kullanabilir miyim?

In-region routing, Free veya standart kullandıkça öde katmanları için değil, Business ve Enterprise planları için belgelenmiş durumda. Plan erişimi olmayan bir geliştirici gizlilik ve sağlayıcı yönlendirme kontrollerini kullanmaya devam edebilir; ancak bunlar bölgesel işleme garantisinin yerine geçmez.

Yalnızca bölgesel katalog, Guardrails engeli, gizlilik filtresinden geçmiş sağlayıcı havuzu ve sağlayıcı şartlarının tamamı incelemeyi geçtiğinde onay verin. Kontrollerden biri başarısız olursa modeli veya iş yükü tasarımını değiştirin; küresel geri dönüş, veri yerleşimi sınırını ortadan kaldırır.