Model çalışmadan önce
Kullanıcı bir komut ve cheap, fast veya smart gibi bir takma ad sağlar. Üretim sunucusu, görevi kabul etmeden önce kimlik doğrulama, çalışma alanı sahipliği ve yetkilendirmeyi kontrol eder. Sağlayıcı model kimlikleri ve gizli anahtarları bu sınırın arkasında kalır — dost takma ad, istemcinin ihtiyaç duyduğu tek model sözlüğüdür; çünkü gerçek sağlayıcı modeliyle eşleme sözleşme değil, yapılandırmadır.
Dayanıklı bir görev kaydı, arka plan yürütmesi başlamadan önce isteğe bir kimlik verir. Bu kimlik gönderimi, işçiyi, kullanım kayıtlarını ve sonucu birbirine bağlar. Ayrıca kullanıcıya uzaklaştıktan sonra işi kurtarma yolu verir.
Sıralama önemlidir: pahalı iş, ancak ucuz kontroller geçtikten sonra başlar. Herhangi bir şey kuyruğa alınmadan önce kimlik doğrulama, sahiplik ve yetkilendirmeyi doğrulamak, kimliği doğrulanmamış ya da ödenmemiş isteklerin sağlayıcıya asla ulaşmamasını sağlar — ve hatayı kullanıcıya açıklanabilir kılar. YZ modülü kılavuzu bu kontrollerin nerede yaşadığını belgeler; çalışma alanı sınırları yazısı sahipliğin neden istemciden güvenilmek yerine sunucuda türetildiğini açıklar.
Kimin anahtarları ve kimin limitleri olduğuna karar verin
Bir YZ özelliği bir harcama kararıdır. supastack, çalışma alanlarının kendi sağlayıcı anahtarlarını getirmesine izin verir — şifreli saklanır, istemcilere asla açılmaz — ya da platform anahtarlarıyla çalışır ve bir model fiyat kataloğuna karşı çalışma alanı başına bütçeleri uygular. Uygulamanız ne olursa olsun sorular aynıdır: kim öder ve limit nerede uygulanır?
Uygulama, tarayıcı tarafı bir tahminde değil, sunucu iş akışında olmalıdır. Üretimden sonra kontrol edilen bir bütçe yalnızca aşırı harcamayı kaydeder; gönderimden önce kontrol edilen onu önler. Sağlayıcı anahtarı kurulumu yapılandırma tarafını kapsar.
Yürütmeyi açık hale getirin
Trigger.dev, ai.generate iş akışını çalıştırır. Yetenek duyarlı yönlendirici, yapılandırılmış politikayı ve isteğin gereksinimlerini kullanarak bir model seçer. Bu politikayı operasyonel bir girdi olarak ele alın: kullanılamayan bir takma ad, arayüzde çalışan bir seçenek olarak görünmemelidir.
Gönderim sırasındaki ağ hatası, istemcinin işin kuyruğa alınıp alınmadığı konusunda belirsiz kalmasına neden olabilir. Üretim yolu, kurtarmanın orijinal isteği yeniden kullanabilmesi için görev kapsamlı bir idempotency anahtarı ve kayıtlı bir gönderim kullanır. Her zaman aşımından sonra yeni görev göndermek, yinelenen iş ve yinelenen maliyet riski taşır.
Arayüzü sade tutan da dayanıklılıktır: ekran, yeniden denemeleri yönetmek yerine görev durumunu okur ve çizer. Üretim model çağrılarına, araç adımlarına ya da zamanlamalara yayıldığında, “devam ediyor”u dürüst tutan açık iş akışı sözleşmesidir — enqueue, status, cancel.
Hata modlarını adlandırın
İstekle sonuç arasında ters gidebilecek belirli, sonlu bir küme vardır. Soyutta “hatalar” için değil, her biri için adıyla tasarlayın — her görev açıklanabilir bir durumda bitmelidir: kuyrukta, çalışıyor, bir nedeniyle başarısız ya da bir sonuçla tamamlandı. Görev kurtarma kitin kurtarma tarafı için referansıdır.
Alttaki arayüz gereksinimi, hiçbir durumun yalan söyleyemeyeceğidir. İşten uzun yaşayan bir döner simge ya da hiç çalışmamış bir görev için başarı mesajı, olmayı bekleyen bir destek talebi ve faturalama anlaşmazlığıdır.
- Gönderim zaman aşımına uğradı — yeniden kuyruğa almak yerine kayıtlı gönderim ve görev kapsamlı idempotency anahtarıyla kurtarın.
- Sağlayıcı görev ortasında başarısız oldu — görevi, arayüzün gösterebileceği bir nedenle başarısız işaretleyin.
- Bütçe tükendi — harcamadan sonra değil, gönderimden önce reddedin.
- Kullanıcı uzaklaştı — dayanıklı kayıt ve kurtarma URL'si durumu ve sonucu geri yükler.
Ne olduğunu takip edin
Üretim metinden fazlasını üretir. Uygulama kullanımı ve bir görev sonucunu kaydeder; arayüz durumu kimliği doğrulanmış API üzerinden okur. Bütçeyi uygulanabilir kılan kullanım kaydıdır — sonradan tahmin edilmez, sonuç döndürülmeden önce yazılır.
Tamamlanma e-postası, ayrı teslimat kayıtlarına sahip ayrı bir adımdır. Başarılı bir model yanıtı, e-postanın teslim edildiğini kanıtlamaz. Bu sonuçları ayrı tutmak, modeli gereksiz yere yeniden çalıştırmadan hataları açıklamayı ve yeniden denemeyi kolaylaştırır.
Sonucun da kullanıcının dönebileceği bir yuvaya ihtiyacı vardır: bir görev sayfası, bir geçmiş listesi, o tamamlanma e-postasında teslim edilen bir kurtarma URL'si. Yalnızca geçici bir bildirimde var olan bir üretim, iki kez üretmeniz istenecek iştir.
Her sınırı doğrulayın
Önce uygulamanın kararlarını deterministik sahte bağdaştırıcılarla test edin: reddedilen erişim, devre dışı takma adlar, yinelenen gönderimler, sonuç kurtarma ve genel hatalar. Bu testler sağlayıcı kimlik bilgileri olmadan çalışmalıdır.
Ardından gerçek entegrasyonlar için açıkça etkinleştirilen sağlayıcı smoke sürecini kullanın. Belgelenen sanal ortam yapılandırmasını ve harici çağrılar için onayı gerektirir. Bu ayrım, sıradan geliştirmeyi hızlı tutarken üretim kanıtını belirli ve hesap verebilir kılar.
Ürün değiştikçe bu ayrımı sabit tutun: her sınır kararının yakınında deterministik kapsam olsun ki sağlayıcı değişimi, yönlendirici politikası değişikliği ya da yeni bir takma ad bir müşteriyi değil, bir testi başarısız etsin.
SaaS'te YZ özellikleri hakkında sık sorulan sorular
YZ'yi bir ödeme duvarının arkasına koyma hakkındaki her konuşmada birkaç soru gündeme gelir.
- YZ özellikleri için yetkilendirme nerede olmalı? — Herhangi bir şey kuyruğa alınmadan önce: kimlik doğrulayın, çalışma alanını çözün, yetkilendirmeyi kontrol edin, sonra görevi oluşturun. Üretimden sonra çalışan kontroller yalnızca kötüye kullanımı belgeler.
- Kendi anahtarını getir desteğine ihtiyacım var mı? — Müşterilerinizin kendi sağlayıcı ilişkileri varsa evet: kimin ödediğini ve hız limitlerini kimin sahiplendiğini belirler. Anahtarları şifreli saklayın ve istemcilerden uzak tutun — YZ yapılandırma kılavuzu modeli anlatır.
- Yeniden denemelerin çift ücretlendirmesini nasıl önlerim? — Idempotency anahtarını göreve kapsamlayın ve kurtarma sırasında kayıtlı gönderimi yeniden kullanın; böylece bir zaman aşımı ikinci bir ücretli çalıştırma yaratamaz.
- Hangi kullanım verisini kaydetmeliyim? — Görev başına: model, tüketilen birimler, fiyat kataloğuna karşı maliyet ve çalışma alanı — işleri yeniden çalıştırmadan bütçeleri uygulamaya ve harcama sorularını yanıtlamaya yetecek kadar.
- Üretim ne zaman arka plan işine aittir? — Bir istekten uzun yaşayabildiği her zaman. Model gecikmesi, yeniden denemeler ve çok adımlı iş dayanıklı yürütmeyi savunur; yalnızca anlık, ucuz çağrılar satır içi kalmalıdır.