Modeller

Özet

Pipelogic'te bir model, bir component vertex'inde yaşar. İki entegrasyon yolu vardır: file-served (bir artifact yükleyin ve onu bir vertex'in file_schema slot'una bağlayın) ve runtime-fetched (bir vertex parametresini bir hub model id'sine işaretleyin ve serving service'inin onu deploy zamanında çekmesine izin verin).
Serving runtime'lar service'lerdir, component'ler değil. Triton, TorchServe, Ollama, vLLM ve SGLang platform-yönetimli service'lerdir. Bir component component.yml'sinde depends_on: [<service>] bildirir; platform service'i deploy zamanında component'in container'ının yanında ayağa kaldırır. Triton'un kendisini asla bir vertex olarak sabitlemezsiniz.
Serving service'leri arasında bilinmeye değer iki şekil vardır: multi-model service'ler (Triton, TorchServe, Ollama) birçok modele hizmet eden tek bir instance çalıştırır, çağrı zamanında seçilir. Parametrize service'ler (vLLM, SGLang) model başına bir instance çalıştırır — ikinci bir model ikinci bir instance demektir.
Bir model entegrasyonu, temsili fixture'lar canlı runtime'da beklenen davranışı ürettiğinde tamamlanmıştır. "Yükleme 200 döndürdü" ölçü değildir; anlamsal doğruluktur. Uyumsuzluk (yanlış etiketler, yanlış tokenizer, yanlış image boyutu, yanlış ön işleme), temiz deploy'lardan sağ çıkan hata modudur.
Platform artifact'ı (değiştirilemez workspace dosyası), bağlama'dan (bir backend'deki vertex slot'u), serving'den (component'in yanındaki yönetilen service) ayırır. Üçünden herhangi birini değiştirmek bir sistem geçişi değil, tek bir graf mutasyonudur.

"Pipelogic'te modeller" aslında ne anlama gelir

Üretimde bir modeli kullanmanın üç yaygın yolu vardır: ağırlıkları component image'ına gömün, component'in bağımlı olduğu bir service olarak bir model sunucusu çalıştırın veya barındırılan bir endpoint'e işaret edin. Pipelogic ikincisine odaklanır: model artifact'ı ve serving runtime'ı component kodundan ayrı tutulur, böylece component neye ihtiyaç duyduğunu bildirir ve platform onu sağlar.

Pipelogic üç kaygıyı ayırır. Model artifact'ı, tipli bir workspace dosyasıdır — bir kez yüklenir, file_id ile adreslenebilir, birçok backend boyunca yeniden kullanılabilir, image'a gömülmek yerine bir component dosya slot'una bağlanır. Vertex bağlaması, artifact'ın yaşadığı backend grafındaki yerdir — component'in file_schema slot'u, ppl backend add-file ile bağlanmış, operasyon log'unda kaydedilmiş, ne artifact'a ne de component'e dokunmadan backend başına değiştirilebilir. Serving runtime'ı, component'in depends_on: aracılığıyla gerektirdiği platform-yönetimli bir service'tir — platform onu deploy zamanında component container'ının yanında ayağa kaldırır, component ona yerel ağ üzerinden konuşur, ekip Triton veya vLLM'i asla el ile işletmez.

Bu tasarımın istediği disiplin, modelleri component'in içinde çalışan kod olarak düşünmeyi bırakmaktır. Component, tipli sözleşmeyi backend'in geri kalanına açan sarmalayıcıdır; model, sarmalayıcının tükettiği artifact'tır; serving runtime'ı, artifact'ı yükleyen ve inference isteklerini yanıtlayan service'tir. Üçünü ayrı tutmak, "bu modeli şununla değiştir"i bir kod değişikliği, bir yeniden yayımlama ve bir yeniden deploy yerine tek bir graf mutasyonu yapan şeydir.

Zihinsel model — component vertex'i, artı yanında bir serving service'i

Bir model bir Component vertex'inde yaşar. Serving runtime'ı, Component'in depends_on: aracılığıyla gerektirdiği bir service'tir; platform onu deploy zamanında Component'in container'ının yanında ayağa kaldırır. Component'in component.yml'si entegrasyon yolunu seçer:

  File-served (yüklenmiş artifact)
  ┌─────────────────────────────┐
  │ file_schema:                │
  │   model:                    │
  │     file_type: triton_model │
  │     config_key: model_name  │
  │ depends_on: [triton]        │
  └─────────────────────────────┘
      ▲ ppl backend add-file
      │   $BID --vertex N --key model
      │   --file <file_id>

  Runtime-fetched (hub id)
  ┌─────────────────────────────┐
  │ config_schema:              │
  │   model_name:               │
  │     type: String            │
  │     default: "<hub-id>"     │
  │ cache:                      │
  │   huggingface_hub:          │
  │     - ids: model_name       │
  │ depends_on: [sglang]        │
  └─────────────────────────────┘
      ▲ ppl backend change-parameter
      │   $BID --vertex N --name model_name
      │   --type String --value "<hub-id>"

Backend iki taraftan birini iki operasyondan biriyle bağlar; component kodu genel kalır ve serving service'i component onu gerektirdiği için otomatik olarak ayağa kalkar.

Hangi yol hangi model için doğru

Yeni bir model entegrasyonu planlarken bu çerçeveyi kullanın.

File-served, artifact özel-eğitilmiş, dışa aktarılmış veya başka bir şekilde ekibe ait olduğunda doğrudur. Belirli bir etiket kümesi olan ince ayarlı bir ONNX modeli, özel bir config.pbtxt'li bir Triton model repository'si, özel pre/post handler'lı bir TorchServe MAR — bunların hepsi file-served'dır. Artifact, tipli bir workspace dosyası olarak yüklenir, tüketen vertex'in slot'una bağlanır ve backend grafıyla birlikte bir bağlama olarak seyahat eder. Daha sonra artifact'ları değiştirmek, farklı bir file_id'ye işaret eden aynı add-file operasyonudur.

Runtime-fetched, artifact hub-barındırmalı ve ekip hub'a bağımlı olmaya istekli olduğunda doğrudur. vLLM veya SGLang'in talep üzerine nasıl çekeceğini bildiği bir hub-barındırmalı LLM, serving service'inin kataloğuna karşı çözdüğü bir Ollama model adı, uzak bir registry'de barındırılan bir Triton model repository'si — bunların hepsi runtime-fetched'dır. Vertex bir dize tanımlayıcısı taşır; serving service'i pull'u ilk istekte (veya service'in caching stratejisine bağlı olarak deploy zamanında) yapar.

Değiş tokuş, yeniden üretilebilirliğe karşı depolamadır. File-served, artifact'ın workspace dosya deposunda sabitlendiği anlamına gelir — her seferinde bit-için-bit yeniden üretilebilir çalıştırmalar. Runtime-fetched, artifact'ın hub'da yaşadığı anlamına gelir — yeniden üretilebilirlik, hub'ın belirli bir tanımlayıcıyı zaman içinde aynı ağırlıklara çözmesine bağlıdır. Ekibe ait artifact'lar için değiş tokuş genellikle file-served'ı tercih eder; kararlı hub modelleri için değiş tokuş genellikle runtime-fetched'ı tercih eder. Hub'ın zaten barındırdığı bir modeli file-serve etmek onu workspace depolamasında çoğaltır; özel bir ince ayarı runtime-fetch etmek, ekibin kontrol etmediği bir hub'a bağlıdır.

İzlenecek yol — file-served (Triton detector)

# 1. Triton model repository'sini yükle (dizin kökü, ÖNCEDEN tar'lanmış DEĞİL)ppl file upload ./model_repository \    --type triton_model \    --name "warehouse-detector" \    --readme @./README.md \    --config ./model.config.yml# $FID döndürür# 2. dosyayı Triton Component vertex'inin `model` slot'una bağlappl backend add-file $BID --vertex 2 --key model --file $FID# 3. deploy et ve temsili fixture'lar çalıştırppl backend deploy --backend $BID

Bir Triton repository'sinin beklenen düzeni:

model_name/
├── config.pbtxt
└── 1/
    └── model.onnx        # veya model.plan / model.pt / model.savedmodel/

CLI, dizini yükleme zamanında tar'lar; önceden tar'lanmış yüklemeler, Triton'ın yükleyemediği iç içe geçmiş bir arşiv üretir. İsteğe bağlı --config, Backend'in artifact'tan ayrışmaması için bağlama zamanında eşleşen vertex parametrelerini (çıktı adları, eşikler, image boyutu, class etiketleri) ayarlayan bir YAML ekler.

İzlenecek yol — runtime-fetched (SGLang aracılığıyla LLM)

# 1. vertex'i bir hub model id'sine işaretleppl backend change-parameter $BID --vertex 3 \    --name model_name --type String --value '"Qwen/Qwen2.5-1.5B-Instruct"'# 2. gated bir model için hub token'ı için bir Workspace secret bağlappl backend change-parameter $BID --vertex 3 \    --name hf_token --type String --value "<secret-id>"# 3. deploy et — deploy, hazır olduğunu raporlamadan önce#    runtime'ın cold pull / ağırlık yüklemesinde bloklarppl backend deploy --backend $BID

Gated hub modelleri için token, düz metin parametresi değil, ID ile bağlanmış bir workspace secret'idir — bkz. Workspace secret'leri.

Multi-model vs parametrize serving service'leri

Bir component'in hangi serving service'ine bağımlı olması gerektiğini seçerken bu çerçeveyi kullanın.

Serving service'leri iki operasyonel şekilde gelir ve şekil, kaç model için kaç instance'ın çalışacağını belirler.

Multi-model service'ler birçok modele hizmet eden tek bir instance çalıştırır. Triton, TorchServe veya Ollama'ya bağımlı component'ler aynı service instance'ını paylaşır ve modellerini çağrı zamanında ID ile seçer. Bu desen, ekip benzer runtime özelliklerine sahip birçok modele hizmet verdiğinde — farklı etiket kümeleri olan yarım düzine ONNX detector, farklı kullanım durumları için bir filo küçük LLM, özel handler'lı bir TorchServe MAR kümesi — ve bağımsız instance'lar çalıştırmanın model başına maliyeti gerçek inference maliyetine baskın geleceğinde doğrudur.

Parametrize service'ler model başına bir instance çalıştırır. vLLM veya SGLang'e bağımlı component'ler başlangıçta belirli bir model_name bağlar; ikinci bir modele hizmet vermek service'in ikinci bir instance'ı demektir. Bu desen, model yeterince büyük olduğunda veya inference engine'i, modelleri bir instance içinde karıştırmanın engine'in var olma nedeni olan optimizasyonu yeneceği kadar fikir sahibi olduğunda doğrudur. vLLM'in sürekli batching'i, SGLang'in yapılandırılmış-üretim runtime'ı ve benzeri özelleşmiş engine'ler "bu süreçte bir model yaşar" varsayılarak yazılmıştır; platform buna saygı duyar.

Service	Tür	En iyi şu için
Triton	multi-model	CV detection / segmentation / classification, ONNX / TensorRT / TorchScript / TF SavedModel, dinamik batching.
TorchServe	multi-model	Özel Python pre/post handler'lı PyTorch modelleri (MAR).
Ollama	multi-model	Hızlı LLM / VLM iterasyonu, yerel veya self-hosted.
vLLM	parametrize	Yüksek-throughput LLM serving'i, uzun bağlam.
SGLang	parametrize	Yapılandırılmış üretim, VLM'ler, OpenAI-uyumlu serving.

Backend tasarımı için pratik sonuç: SGLang veya vLLM aracılığıyla farklı LLM'leri tüketen iki vertex iki service instance'ı ayağa kaldırır; aynı iki vertex Ollama veya Triton'a karşı birini paylaşır. Bu paylaşım "birçok küçük model" için doğru varsayılan ve "tek bir büyük optimize edilmiş model" için yanlış varsayılandır.

Uyumsuzluk hata modudur

Temiz bir deploy ilk kez bozuk bir model sevk ettiğinde bu çerçeveyi kullanın.

Temiz yüklenen, temiz bağlanan ve temiz deploy edilen bir model entegrasyonu yine de bozuk olabilir. Hatalar, bir özelliği paylaşan küçük bir şekil kümesine kümelenir — hiçbiri deploy zamanında schema hataları üretmez. Platformun tip sistemi şekil hatalarını yakalar (slot için yanlış dosya tipi, bir parametre için yanlış literal tipi); anlamsal hatalar, ekibin kanıt döngüsüyle yakalayacağı şeylerdir.

Adlandırılmaya değer şekiller, kabaca sıklık sırasına göre:

Yanlış etiketler — modelin çıktı class ID'leri aşağı akış tüketicisinin beklediğiyle eşleşmiyor. Schema-geçerli çıktı, anlamsal olarak yanlış.
Yanlış tokenizer — text-in / text-out JSON olarak çalışır; tokenizer modelin eğitim tokenizer'ı ile anlaşmazlığa düştüğü için her karakter yanlış.
Yanlış ön işleme — image boyutu, kanal sırası, normalleştirme, modelin beklediği ile upstream'in yaydığı arasında dtype uyumsuzluğu.
Yanlış görev — classification ağırlıkları bir detector component'ine, segmentation ağırlıkları bir classifier'a bağlanmış.
Cold-start'ın bozuk endpoint sanılması — serving service'i hala modeli yüklediği için ilk istek zaman aşımına uğrar; ikinci istek başarılı olurdu.
Gated modeller için eksik erişim — hub token'ı için workspace secret'i component'in access-token parametresine bağlanmamış, bu yüzden runtime'ın gated repository'yi çekmesi hub tarafından reddedilir ve model asla yüklenmez. Deploy, schema'da değil, ağırlık yüklemesinde başarısız olur.

Davranışı kanıtla içindeki kanıt döngüsü, bu hataların yakalandığı yerdir. Platform kanıtı ucuz kılar (sabitlenmiş artifact'lar, deterministik graf'lar, lease-izolasyonlu test çalıştırmaları); ekibin işi "tamamlanmış" demeden önce kanıtı gerçekten çalıştırmaktır.

Değiştirme ve iterasyon

"Artifact'ın değişmesi gerekiyor" gündeme geldiğinde bu çerçeveyi kullanın.

Bağlanmış bir artifact'ı değiştirmek tek bir graf mutasyonudur. Yeni bir dosya yükleyin (ppl file upload), sonra slot'u yeni file_id'ye yeniden bağlayın. Platformun operasyon log'u değişimi kaydeder; önceki bağlama olağan backend undo aracılığıyla geri alınabilir. Component yeniden yayımlama yok, grafın geri kalanı boyunca yeniden deploy yok — yalnızca tek bağlama düzenlemesi ve serving service'i gerektiriyorsa, etkilenen vertex'in bir yeniden deploy'u.

Ucuz iterasyonu destekleyen desen, artifact'ı adreslenebilir tutmaktır. Her yüklenmiş dosyanın kararlı bir file_id'si vardır; onlardan herhangi birini vertex slot'una bağlamak aynı operasyondur; ekip, onları aynı backend'deki kardeş vertex'lere bağlayarak ve çıktıları aynı fixture kümesinde karşılaştırarak iki artifact arasında A/B yapabilir. Bu, "aday mevcuttan daha mı iyi" sorusunun yapısal yanıtıdır — karşılaştırma döngüsü için Model artifact entegrasyonu sayfasına bakın.

Bunun yeri

Modeller platformda birinci sınıf bir kaygıdır çünkü entegrasyon döngüsü, çoğu AI projesinin karmaşıklık biriktirdiği yerdir. Artifact'ı bağlamadan, bağlamayı serving service'inden ayırarak, platform her parçayı bağımsız olarak değiştirilebilir kılar — ve bu değiştirilebilirlik, proje büyüdükçe entegrasyon döngüsünü ucuz tutan şeydir. Ekip component'i bir kez yazar, serving service'i ekip operasyonları olmadan çalışır, artifact model geliştikçe değişir. Her parçanın kendi yaşam döngüsü vardır; platformun işi onları oluşturulabilir kılmaktır.

İlgili

Dosyalar — File primitive'i ve yaşam döngüsü.
Dosya şeması — modelin file_schema slot'unu bildirme.
Dosya tipleri — model artifact'ları için file_type değerleri.
Dosya bağlama — artifact'ı yükle ve bağla.
Backend operasyonları — add-file ve change-parameter semantiği.
Secret'ler — gated hub token'larını düz metin olarak değil ID ile bağlama.
Model artifact entegrasyonu — tam yükle + bağla + iterasyon döngüsü.
Çözümler — serving component'lerinin input / transform / output component'lerinin yanında nereye uyduğu.