Bir solution demosu yayımlama

TL;DR

Yayımlama, backend'lerinden birini — inşa ettiğin bir solution'ı — herkesin kendi URL'sinde, hesap gerektirmeden açabileceği genel, paylaşılabilir bir demoya dönüştürür. Bir solution girişi, o backend'i bir genel alias'a, ziyaretçi tarafından oluşturulan çalıştırmalar için bir hedef node flavor'ına, taksonomi etiketlerine (endüstri, iş hedefi, modalite) ve şablon workspace'inin ödediği isteğe bağlı bir sponsorlu-çalıştırma bütçesine bağlar.
Yayımlama, demoyu kendi başına genel kılar. Küratörlü Solutions kataloğu — göz at-ve-keşfet vitrini — yayımlanmış demoların platform tarafından seçilmiş bir alt kümesini öne çıkarır; orada görünmek bir platform kararıdır, ayarladığın bir bayrak değil. Demon, öne çıkarılsa da çıkarılmasa da genel URL'sinde erişilebilirdir.
Bir giriş mevcut bir backend'den yayımlanır. Backend'in component'leri, graph'ı, parametreleri ve dosya bağlamaları ziyaretçilerin etkileşime girdiği şeydir; giriş, onları bir genel URL'ye bağlayan yayımlama katmanıdır.
İki CLI fiili yüzeyi kapsar: ppl solution create bir giriş kaydeder ve ppl solution update mevcut alanları patch'ler. Bir backend en fazla bir giriş taşır; o var olduğunda, create bir conflict döndürür ve update onu değiştirmenin yoludur.
Sponsorlu çalıştırmalar içeren planlarda, şablon workspace'i ziyaretçi hesaplamasını yapılandırılabilir bir bütçeye kadar karşılayabilir. Bütçe sıfıra ulaştığında, doldurulana kadar ziyaretçi çalıştırmaları durur.
Flavor, ziyaretçiler için runtime sözleşmesidir: on-demand çalıştırmalarının ineceği node sınıfını sabitler, bu da ziyaretçi deneyimi için soğuk başlatma süresini, GPU sınıfını ve kapasiteyi sabitler.

Bir solution girişi nedir

Bir solution girişi, workspace sahipliğindeki bir backend ile bir genel URL arasında yayımlanmış bir bağlamadır. Giriş, genele dönük yapılandırmayı tutar — alias, flavor, taksonomi etiketleri, sponsorlu-çalıştırma bütçesi — ve backend'e ID ile referans verir; backend'in graph'ını kopyalamaz. Backend'i değiştirmek, ziyaretçilerin etkileşime girdiği şeyi senkronize tutulacak ayrı bir artefakt olmadan değiştirir.

Taksonomi etiketleri (endüstri, iş hedefi, modalite) Solutions kataloğundaki keşfi yönlendirir. Flavor, ziyaretçi çalıştırmalarını bilinen bir node sınıfına sabitler, böylece soğuk başlatma süresi ve kapasite öngörülebilir olur. Sponsorlu-çalıştırma bütçesi, takım tarafından fonlanan ziyaretçi hesaplamasını sınırlar. Takım tek bir nesneyi — girişi — yönetir ve platform yönlendirmeyi, throttling'i ve ziyaretçi oturum yaşam döngüsünü halleder.

Taksonomi kümesi, ziyaretçi oturum modeli ve flavor kataloğu keyfi değil, platform tanımlıdır. Bu kısıtlamalar, yayımlamayı tek satırlık bir işlem yapan şeydir. Yayımlanmış bir demonun ardından küratörlü Solutions kataloğunda öne çıkarılıp çıkarılmayacağı bir platform tarafı karardır; yayımlama sana genel URL'yi her halükarda verir.

Zihinsel model

workspace'in                                      genele dönük
──────────────                                    ─────────────
  backend (vertex'ler, params, files, endpoint'ler)
        │
        │ ppl solution create --backend <id>
        ▼
  solution girişi ───▶  genel solution URL'si (alias ile çözümlenir)
   - alias                                                 │
   - flavor (ziyaretçi runtime sınıfı)                     ▼
   - industry / business-goal / modality            ziyaretçi oturumu
   - sponsorlu-çalıştırma bütçesi                    (on-demand deploy,
                                                     bütçe boşalana dek
                                                     şablon workspace'ine
                                                     faturalandırılır)

Giriş, workspace sahipliğindeki backend ile genel URL arasında oturur. Backend'i değiştirmek ziyaretçilerin gördüğünü günceller; girişi değiştirmek ziyaretçilerin onu nasıl bulduğunu ve çalıştırmalarının neye benzediğini günceller.

Altta yatan ilkeler için bkz. Backends ve Runtimes ve nodes.

Bir giriş oluşturma

Bir backend'i ilk kez yayımlamak için bu adımı kullan.

ppl solution create girişi kaydeder. Gerekli olan tek bayraklar --backend (yayımladığın workspace backend'i) ve --flavor'dır (ziyaretçi çalıştırmalarının ineceği node sınıfı); diğer her şey isteğe bağlı metadata'dır.

ppl solution create \  --backend <backend_id> \  --flavor n1-gpu-micro \  --industry healthcare --industry retail \  --modality vision \  --alias vision-demo

Bir backend en fazla bir giriş taşır. İlk create onu kaydeder; aynı backend için ikinci bir create üzerine yazmak yerine bir conflict döndürür, böylece mevcut bir girişteki değişiklikler ppl solution update üzerinden geçer.

--flavor, ziyaretçi runtime'ını belirler. Ziyaretçi çalıştırmaları, adlandırılan flavor'ın node sınıfına iner; bu, soğuk başlatma süresini, GPU veya CPU sınıfını ve mevcut RAM'i ayarlar: inference-yoğun demolar için bir GPU sınıfı, daha hafif iş için bir CPU sınıfı, bellek-bağlı modeller için daha fazla RAM içeren bir sınıf. CLI gerektiğinde mevcut flavor'ları listeler; temsili bir ziyaretçi çalıştırmasının gerektirdiğiyle eşleşen birini seç.

--alias, ziyaretçilerin URL'de göreceği genel slug'tır (küçük harf, en fazla 64 karakter; özel bir alias, özel demo URL'leri içeren planlarda mevcuttur). Onu atla, giriş backend'in tanımlayıcısıyla erişilebilir olsun; onu geç, URL paylaşılabilir bir slug haline gelsin. Taksonomi etiketleri (--industry, --business-goal, --modality) Solutions kataloğundaki keşfi yönlendirir; gerektiğinde tekrarla.

Mevcut bir girişi patch'leme

Tüm girişi yeniden belirtmeden tek bir alanı değiştirmek için bu adımı kullan.

ppl solution update, geçtiğin alanları patch'ler ve diğer her şeyi olduğu gibi bırakır. Patch'lemenin en yaygın nedenleri sponsorlu-çalıştırma bütçesini ayarlamak, bir taksonomi etiketi eklemek veya kaldırmak ya da genel slug'ı temizlemektir (--alias "" geç).

ppl solution update --backend <backend_id> \  --industry healthcare --modality vision --sponsored 500

Patch artımlıdır: yalnızca çağrının adlandırdığı alanlar değişir. Bu biçim, yaygın düzenlemelere uyar — sponsorlu bütçeyi ayarlamak, bir etiketi düzeltmek — tam giriş yapılandırmasını yeniden belirtmeden.

Sponsorlu çalıştırmalar

Sponsorlu çalıştırmalar içeren planlarda, takım ziyaretçi hesaplamasını bir bütçeye kadar fonladığında mevcuttur.

--sponsored <runs> alanı, şablon workspace'inin ödediği bütçeyi belirler. Her ziyaretçi güdümlü çalıştırma sayacı azaltır; sayaç sıfıra ulaştığında, bütçe doldurulana kadar ziyaretçi çalıştırmaları durur. Bütçe, takım tarafından fonlanan ziyaretçi hesaplamasını sınırlar.

Bir bütçe, girişi ziyaretçiler için yapılandırılan çalıştırma sayısına kadar ücretsiz denenebilir kılar. Onu giriş başına ayarlamak ve zaman içinde değiştirmek, takımın hangi girişlerin ücretsiz denemeler sunduğuna ve hangilerinin sunmadığına karar vermesini sağlar.

Ziyaretçi deneyimi

Bir ziyaretçi girişin genel URL'sini açtığında, platform yapılandırılan flavor üzerinde bağlı backend'e karşı bir ziyaretçi oturumu başlatır. Oturum yaşam döngüsü platform tarafından yönetilir: ziyaretçinin bir hesaba ihtiyacı yoktur, backend'ler veya runtime'larla doğrudan etkileşmez ve dahili workspace durumunu görmez. Girişe iliştirilmiş replay'ler — takım tarafından kaydedilen tek bir çalıştırmanın deterministik oynatımları — hafif görüntüleme yoludur; ziyaretçiler onları gerçek hesaplama döndürmeden izler. Canlı deneme çalıştırmaları daha ağır yoldur ve bir tane yapılandırıldığında sponsorlu bütçeyi tüketir.

Yaygın bir yapılandırma, girişin ne yaptığını görmek isteyen ziyaretçiler için birkaç iliştirilmiş replay, artı kendi girdilerini beslemek isteyen ziyaretçiler için sponsorlu bir canlı deneme bütçesidir. Replay'ler hesaplama tüketmeden görüntülenir; canlı deneme bütçeyle sınırlıdır.

Bir şey ters gittiğinde

--flavor'da invalid_value — flavor adı mevcut katalogta değil. Mevcut flavor'ları listele ve var olan birini seç.
solution create'te conflict — o backend için zaten bir giriş var (ya da seçilen alias başka bir giriş tarafından zaten alınmış). Mevcut girişi patch'lemek için ppl solution update kullan veya farklı bir alias seç.
permission_denied — yayımlamak için kullanılan workspace kimliğinin hedef backend'de veya solution yüzeyinde yazma erişimi yok. Düzeltme workspace tarafıdır, CLI tarafı değil.
Ziyaretçi çalıştırmaları durdu — sponsorlu bütçe sıfıra ulaştı ya da bağlı backend silindi. Bütçeyi doldur veya güncel bir backend'e karşı yeniden yayımla.

Bu nereye uyar

Solutions, bir solution demosunu kullanıcıların — iş arkadaşları, müşteriler veya genel kamu — önüne tek bir işlemde koymak için yayımlama yüzeyidir. Giriş, backend'e ID ile referans verir, böylece backend değiştikçe onunla senkronize kalır ve sponsorlu-çalıştırma bütçesi takım tarafından fonlanan ziyaretçi hesaplamasını sınırlar. Ziyaretçi oturum modeli takım tanımlı değil, platform tarafından yönetilir.

İlgili

Backends — bir girişin bağlandığı nesne.
Runtimes ve nodes — flavor'ın içinden seçim yaptığı runtime dokusu.
Deploy et ve izle — bu yüzeyin genel olmayan karşılığı.
Applications — bir yayımlama yüzeyinin bir girişten fazlasına ihtiyaç duyduğunda.
Solutions — backend endpoint'leri ve hizmet ettikleri tüketiciler.