Docs

Model artefaktı entegrasyonu

Özet

  • Model artefaktı entegrasyonu, eğitilmiş veya seçilmiş bir modeli çalışan bir backend'e bağlayan ve beklenen çıktıları ürettiğini doğrulayan iş akışıdır. Çalışma zamanı yolunu seçmeyi, artefaktı backend'e sokmayı, onu grafa kablolamayı, temsili fixture'ları çalıştırmayı, benchmark yapmayı ve üretime hazırlık kararı için kanıtı kaydetmeyi kapsar. Test etmek, içindeki bir adımdır.
  • Çalışma zamanı yolu seçimi — file-served'a karşı runtime-fetched — /concepts/models içinde ele alınan, artefakt başına bir karardır. Bu akış, o seçim yapıldıktan sonraki operasyonel sıradır.
  • Cold-start ölçümün bir parçasıdır. Yeni deploy edilmiş bir modelde ilk istek gecikmesi, kararlı durum gecikmesinin bir büyüklük mertebesi üstünde olabilir, bu yüzden yalnızca sıcak runtime'ı ölçen bir benchmark gerçek soğuk yolu olduğundan az gösterir.
  • Version karşılaştırması "bu artefakt mevcut olandan daha mı iyi" sorusunu yanıtlar: aynı fixture seti, kardeş bağlamalarda iki artefakt, her ikisine uygulanan aynı semantik kriterler. Delta, promote kararının ihtiyaç duyduğu kanıttır.

Model entegrasyonu aslında nedir

Model entegrasyonu, "model bir dosya veya hub id'si olarak var" durumundan "model, önemli olan input'larda, üretim trafiğini sunacak runtime üzerinde, ölçülmüş karakteristiklerle beklenen çıktıları üretiyor" durumuna giden yoldur. Yedi konuyu kapsar: çalışma zamanı yolunu seçmek, artefaktı doğru tiple yüklemek, onu doğru vertex'teki doğru slota bağlamak, çevreleyen ön ve son işleme component'lerini kablolamak, temsili fixture'ları çalıştırmak, çalışma zamanı karakteristiklerini ölçmek ve promote kararının arkasındaki kanıtı yakalamak.

Platform, component'leri backend'lerden ayrı tuttuğu nedenle artefaktı component'ten ayrı tutar: yaşam döngüleri hizalanmaz. Bir component release'i, input ve output tipleri ile yapılandırma şekli hakkında bir sözleşmedir. Bir model artefaktı, dosya-bağlama yolu üzerinden bağlanan, bu sözleşmelerin hiçbirini değiştirmeden takas edilebilir bir weights snapshot'ıdır. Artefaktı component image'ine pişirmek, her weights değişikliği için bir component yeniden yayını zorlar ve artefaktın ayrı, adreslenebilir bir dosya olarak ait olduğu her image'de weights'i taşırdı.

Döngüdeki her adım küçüktür. İş, 200 döndüren ilk istekte durmak yerine hepsini yapmaktadır.

Zihinsel model

artifact                          backend graph
─────────                         ──────────────

file-served path
  ppl file upload ──(file_id)──▶ ┌──────────────────┐
                                 │ vertex file slot │ ◀─┐
                                 └──────────────────┘   │
                              ppl backend add-file ──────┘

runtime-fetched path
  hub model id ──(string param)─▶ ┌──────────────────┐
  workspace secret (private)      │ vertex model_id  │ ◀─┐
        │                         └──────────────────┘   │
        ▼                                                 │
  ppl backend change-parameter ───────────────────────────┘

                            │
                            ▼
                      backend deploy
                            │
                            ▼
              live runtime + fixture run
                            │
                            ▼
                  evidence + benchmark

Çalışma zamanı yolu taksonomisi — file-served ve runtime-fetched'ın ne anlama geldiği, her birinin deploy anında nasıl davrandığı ve serving runtime'larının vertex değil component'in bağımlı olduğu hizmetler olduğu gerçeği — /concepts/models içinde yaşar. Bu akış her yolun kullandığı operasyonları gösterir; file-served yolu için ayrıntılı olarak Dosya yükleme ve bağlama bölümüne bakın.

Çalışma zamanı yolunu seçme

Bu adımı önce kullanın. Seçim, izleyen her adımı kısıtlar.

Hangi yolun hangi artefakta uyduğu — ve seçimin arkasındaki yeniden-üretilebilirliğe-karşı-depolama ödünleşimi — /concepts/models içinde ele alınır. Devam etmeden önce o kararı verin; bu akışın geri kalanı her yol için operasyonlardır.

Yükleme ve bağlama (file-served yolu)

Bunu, takımın sahip olduğu özel eğitilmiş veya dışa aktarılmış artefaktlar için kullanın.

Yükleme, artefaktı tipli bir workspace dosyası olarak kaydeder, ardından bir bind onu vertex'teki model slotuna ekler. Genel mekanikler — --type, açıklama bayrakları, artefaktla seyahat eden --config varsayılanları ve ppl backend add-file — Dosya bağlama içindedir; --type triton_model'in beklediği Triton model-repository düzeni File tipleri içindedir.

ppl file upload <artifact_path> --type <type> --name "<display>" --readme @./README.md --config ./model.config.ymlppl backend add-file <backend_id> --vertex <vertex_id> --key <file_schema_key> --file <file_id>

Özellikle bir model artefaktı için, --config varsayılanları, version'ın amaçlanan çalışma zamanı ayarlarının onunla seyahat ettiği yerdir: fine-tune'un eğitildiği güven eşiği, bu version'a özgü bir label haritası, ön işlemenin varsaydığı görüntü boyutu. Bind, backend'in event-sourced operasyon logunun bir parçasıdır — geri alınabilir, yeniden oynatılabilir ve aynı operasyonu farklı bir file_id'ye yönelterek takas edilebilir.

Bir hub modeline işaret etme (runtime-fetched yolu)

Bunu, serving hizmetinin talep üzerine çekebileceği hub-barındırmalı modeller için kullanın.

runtime-fetched yolu, bir dosya yerine bir parametre bağlar. Component bir model tanımlayıcısı parametresi deklare eder, backend onu hub tarafı id'sine ayarlar ve serving hizmeti çekme işlemini halleder.

ppl backend change-parameter <backend_id> --vertex <v> \    --name model_name --type String --value "<hub-model-id>"

Private hub modelleri için, erişim token'ı, component'in bu amaçla deklare ettiği bir secret: true parametresine bağlı bir workspace secret'ıdır:

ppl backend change-parameter <backend_id> --vertex <v> \    --name hub_token --type String --value "<secret-id>"

Açık metin token'ı asla backend grafına girmez. Token'ı workspace UI'sında döndürmek yeterlidir; backend yeni değeri bir sonraki deploy'da alır. Bind sözleşmesi için Secrets bölümüne bakın.

Çevreyi kablolama

Herhangi bir modeli entegre olarak değerlendirmeden önce bu adımı kullanın.

Bir model bir backend'de nadiren tek başına oturur. Ona doğru şekillendirilmiş veri besleyen bir input kaynağına ve ürettiği şekli tüketen bir output sink'ine ihtiyaç duyar. Kablolama adımında, platformun tip çıkarımı şekil uyumsuzluklarını runtime onları görmeden önce, graf-düzenleme anında yakalar.

Tip sistemin erken yakaladığı yaygın kablolama hataları: model belirli bir boyutta Image bekler ve upstream yeniden boyutlandırma olmadan ham Image yayar (bir resize transformasyonu ekleyin), model [BoundingBox] yayar ama downstream tüketici Polygon<Double> bekler (bir dönüştürücü ekleyin), modelin platformun ayrı bir component olarak sunduğu ön işlemeye ihtiyacı vardır (onu bir vertex olarak ekleyin). Doğru kablolanmış bir graf bunları runtime'ın dışında tutar; yakalanmamış bir tanesi kafa karıştırıcı bir çalışma zamanı hatası üretir.

Entegrasyonu kanıtlama

Bunu her seferinde kullanın. Bind'in geçerli olması, modelin doğru olmasıyla aynı şey değildir.

Kanıt, Davranışı kanıtla içinde tanımlanan döngüdür: test edilen birimi belirleyin (component veya backend değil, artefakt), bir fixture seti dondurun, onları deploy edilmiş backend üzerinden çalıştırın ve gözlemlenen çıktıları semantik beklentilerle karşılaştırın. Model kanıtı şekli değil, anlamı kontrol eder: yanlış label'larla geçerli JSON yayan bir detektör bozuktur, yanlış dilde iyi biçimlendirilmiş metin yayan bir transkripsiyon modeli bozuktur, yanlış koordinat sisteminde geçerli polygon'lar yayan bir segmentasyon modeli bozuktur. Şema doğrulaması bunların hiçbirini yakalamaz.

ONNX-on-Triton artefaktları için bir Triton'a özgü kontrol kanıt döngüsüne aittir: config.pbtxt dims, ONNX şekliyle eleman eleman eşleşmelidir. Sembolik ONNX boyutları runtime'a -1 olarak görünür, bu yüzden somut bir boyutu sembolik bir boyuta karşı sabitleyen bir config yüklenemez. Bir yükleme başarısızlığını model sorunu olarak değerlendirmeden önce repository'nin deklare edilmiş şekillerinin ONNX grafıyla hizalandığını doğrulayın.

Cold-start ölçümü kanıtın bir parçasıdır, ondan ayrı değildir. Modeller genellikle ilk kullanımda tembel yüklenir: bir hub modeli ilk istekte çeker, ONNX ilk çıkarımda başlatılır, Triton ilk eşleşen istek geldiğinde repository'yi yükler. İlk istek gecikmesi kararlı durumun 10–30 saniye üstünde olabilir, bu yüzden yalnızca sıcak runtime'ı ölçen bir benchmark soğuk yolu olduğundan az gösterir. Fixture setini iki kez çalıştırın, bir kez soğuk ve bir kez sıcak, ve her ikisini de raporlayın.

Version karşılaştırması

Bir aday artefakt mevcut bir artefakta karşı çıktığında bunu kullanın.

"Aday mevcut olandan daha mı iyi" sorusu, aynı fixture setini kardeş vertex bağlamalarındaki iki artefakta karşı, her ikisine uygulanan aynı semantik kriterlerle çalıştırarak yanıtlanır. Delta, promote kararının ihtiyaç duyduğu kanıttır. İyi ama mevcut olandan daha kötü bir aday promote edilmemelidir; kusurlu ama mevcut olandan maddi olarak daha iyi bir aday genellikle edilmelidir.

Sabitleme, karşılaştırmayı dürüst tutan şeydir. Her iki artefaktın adreslenebilir file_id'leri (veya adreslenebilir hub id'leri) vardır, fixture seti adreslenebilirdir ve backend, iki farklı bağlamayla aynı graftır. Artefaktın kendisi, test altındaki tek değişkendir.

Adlandırmaya değer uyumsuzluk riskleri

Temiz bir deploy'u atlatan uyumsuzluk biçimleri kümesi — yanlış label'lar, yanlış tokenizer, yanlış ön işleme, yanlış görev, soğuk-yükleme-bozuk-sanılan, eksik gated-model erişimi — /concepts/models içinde sıralanmıştır. Kanıt döngüsünü, test altındaki artefakta uygulanan her birine karşı çalıştırın; onları kontrol etmek, "bu model çalışıyor" ile "bu model denediğimiz tek örnekte çalıştı" arasındaki farktır.

Bunun yeri

Model entegrasyonu, test etmekten fazlasını yaptığı için platformdaki en uzun tek iş akışıdır. Artefakt workspace'e girer, doğru vertex'e bağlanır, tiplerine saygı duyan bir backend'e kablolanır, temsili input'larda çalıştırılır ve çalışma zamanı davranışı için karakterize edilir. Her adım küçüktür; birini atlamak, üretimde öngörülebilir bir nedenle düşük performans gösteren bir model gönderir.

Platform döngüyü yeniden üretilebilir kılar: sabitlenmiş artefaktlar, sabitlenmiş component'ler, sabitlenmiş backend'ler, deklaratif kablolama, her adımda yakalanan kanıt. Disiplin takımındır; primitive'ler onu tekrarlanabilir tutar.

İlgili

Bu sayfa yardımcı oldu mu?