Temel model yaşam döngülerini destekleyecek tasarım

Temel modeller, yapay zeka iş yükünüzde kullandığınız sürümlenmiş bağımlılıklardır. Her temel modelin dikkate alınması gereken bir yaşam döngüsü vardır. İş yükünüzdeki kod kitaplıkları ve diğer bağımlılıklar gibi, temel yapay zeka modelleri de performans artırımları ve optimizasyonlar sağlayan küçük sürüm güncellemeleri alır. Ana sürüm güncelleştirmeleri, yetenekler, performans veya eğitim verilerinin güncelliği için önemli değişiklikler sunar. Zaman içinde, temel modeller, zaman aşımına uğrayabilir veya kontrolünüz dışında olan host tercihleri nedeniyle devre dışı bırakılabilir.

bağımlılık olarak seçtiğiniz modellerin belgelenmiş yaşam döngülerini desteklemek için iş yükünüzü tasarlamanız gerekir. Modellerin yaşam döngülerini dikkate almazsanız, barındırma platformunuzun kullanım süresi sonu modellerini işleme şekli nedeniyle gereksiz yere riskli yükseltmeler gerçekleştirebilir, test edilmemiş davranış değişikliklerine neden olabilir, gereksiz iş yükü kapalı kalma süresi alabilir veya kesintilerle karşılaşabilirsiniz.

Modellerinin yaşam döngülerini desteklemek için tasarlanan bir iş yükü, pazara girerken yeni temel modelleri denemeyi ve güvenli bir şekilde geçirmeyi kolaylaştırır.

Model güncelleştirme türleri

Üretici yapay zeka çözümünüzdeki model güncelleştirmesinin kapsamı, küçük bir düzeltme değişikliği için yükseltmeden yeni bir model ailesi seçmeye kadar büyük ölçüde farklılık gösterebilir. Çözümünüzde modeli yükseltmeyi seçmenizin çeşitli nedenleri vardır. Aşağıdaki tabloda, bu yükseltmenin bir örneği ve avantajlarıyla birlikte farklı güncelleştirme kapsamları listelemektedir.

Değişiklik kapsamı	Modeli güncelleştirmenin avantajları	Örnek
Küçük sürüm güncellemesi	Genellikle mevcut uygulamanızda önemli değişiklikler gerektirmeden gelişmiş performans ve geliştirilmiş özellikler sunar	GPT-4o v2024-08-06'dan GPT-4o v2024-11-20'ye geçiş
Ara sürüm güncelleştirmesi	En geriye dönük uyumluluğu korurken ve yalnızca orta düzeyde uygulama ayarlamaları gerektirdiğinde önemli performans iyileştirmeleri, yeni özellikler ve gelişmiş güvenilirlik sağlar	GPT-3'ten GPT-3.5'e geçiş
Ana sürüm güncelleştirmesi	Önemli uygulama değişikliklerini ve istemlerin ayarlanmasını haklı gösteren mantık, yetenekler, bağlam boyutu ve performansta dönüşüm iyileştirmeleri sunar	GPT-3'ten GPT-4'e geçme
Varyant güncellemesi	Çekirdek mimariyi korurken ve genellikle temel modelle geriye dönük uyumluluk sağlarken daha yüksek işleme hızı ve düşük gecikme süresi gibi özel iyileştirmeler sağlar	GPT-4'ten GPT-4-Turbo'ya geçiş
Jenerasyon sürüm güncellemesi	Mantık, çok modlu yetenekler ve performansta önemli iyileştirmeler sağlar ve bu iyileştirmeler, modelin kullanım alanını temelden genişletirken, uygulama stratejilerinin tamamen yeniden tasarlanmasını gerektirebilir.	GPT-4'ten GPT-4o'ya geçiş
Genel model değişikliği	Özel özelliklere, farklı fiyat-performans oranlarına ve potansiyel olarak belirli kullanım örnekleriyle daha iyi hizalamaya erişim sağlar	GPT-4'ten DeepSeek'e geçiş
Özelleştirilmiş model değişikliği	Etki alanına özgü iyileştirme, belirli görevler için gelişmiş performans ve özel uygulamalar için genel amaçlı modelleri kullanmaya kıyasla daha düşük maliyetler sağlar	GPT-4'ten Prizedata'ya geçiş
Dağıtım seçeneği değişikliği	Altyapı, özelleştirme seçenekleri ve olası maliyet tasarrufları üzerinde daha fazla denetim sağlarken, daha fazla yönetim sorumluluğu karşılığında özelleştirilmiş iyileştirme ve gelişmiş veri gizliliği sağlar	Azure AI Foundry'de yönetilen çevrimiçi uç nokta olarak barındırılan LLaMa-1'den sanal makinede kendi kendine barındırılan LLaMa-1'e geçiş

Tabloda gösterildiği gibi, yeni bir modele geçmenin avantajları genellikle aşağıdaki faktörlerin bir bileşimidir:

• Hız ve gecikme süresi gibi performans

• Dakika başına işlemlerle ölçülen aktarım hızı gibi kapasite

• Kota kullanılabilirliği

• Maliyet verimliliği

• Bölgesel erişilebilirlik

• Çok modlu yetenekler

• Güncelleştirilmiş eğitim bilgisi

• Hata düzeltmeleri

• Kullanım senaryonuza daha iyi uyum sağlamak için uzmanlaşma veya uzmanlıktan vazgeçme

• Model ana bilgisayar yaşam döngüsü ilkeleri nedeniyle iş yükü kesintilerini önleme

Emeklilik davranışını modelleme

Modelin emekliye ayrılma davranışı, model dağıtım stratejinize bağlıdır. Modelleri dağıtmak için üç temel strateji vardır. Her stratejinin sürüm kullanımdan kaldırma işlemlerini nasıl işlediğini anlamak önemlidir:

• MaaS (hizmet olarak model) çözümleri , ölçeklenebilirlik ve tümleştirme kolaylığı sağlayan API'ler olarak kullanıma sunulan önceden eğitilmiş modellerdir. Potansiyel olarak daha yüksek maliyetlerden ve modellerin daha düşük denetiminden ödün verme olanağına sahiptirler. MaaS çözümlerine örnek olarak, Döküm Modellerinde Azure OpenAI'de dağıtılan modeller ve sunucusuz API'ler olarak dağıtılan model kataloğundaki modeller verilebilir.

• MaaP (model olarak platform) çözümleri , Azure model kataloğundaki modeller gibi daha büyük bir platformda dağıtılan ve yönetimli hesaplamada dağıtılan modellerdir. Bu çözüm genellikle modeller üzerinde daha fazla denetim sağlar ancak MaaS çözümlerinden daha fazla yönetim gerektirir.

• Kendi kendine barındırma modelleri , kendi altyapınıza dağıtılan modellerdir. Bu dağıtım, modeller üzerinde maksimum denetim sağlar, ancak altyapı, yönetim ve bakım için önemli sorumluluk gerektirir.

Azure yapay zeka modeli kataloğundaki Azure kaynak modellerinde hem MaaS hem de MaaP stratejileri. Model kataloğundaki modeller, modellerin kullanımdan kaldırıldığı ve kullanımdan kaldırıldığı bir yaşam döngüsünü izler. İş yükünüzdeki bu olasılıkları planlamanız gerekir.

Uyarı

Azure OpenAI tarafından dağıtılan modeller ve sunucusuz API modeli kullanılarak dağıtılan modeller de dahil olmak üzere MaaS hizmetleri için, kullanımdan kaldırılan modeller için mevcut dağıtımların HTTP hataları döndürdüğünü anlamak çok önemlidir. Desteklenen bir modele yükseltmezseniz uygulamanız artık beklendiği gibi çalışmaz. Kullanım dışı bırakılan modeller için bu modeller için yeni dağıtımlar oluşturamazsınız, ancak mevcut dağıtımlar kullanımdan kaldırılana kadar çalışmaya devam eder. Daha fazla bilgi için bkz. Sunucusuz API modeli kullanımdan kaldırmalar ve kullanımdan kaldırmalar ve Azure OpenAI modelinin kullanımdan kaldırılması ve kullanımdan kaldırılması.

Kendi kendine barındırılan modeller kullanırken veya yönetilen bilişim kullanırken, tam denetime sahip olur ve modelleri güncellemeye zorunda değilsiniz. Ancak, daha yeni bir modelin iş yükünüz için getirebileceği ek avantajlar için bir model yaşam döngüsünü çoğaltmak isteyebilirsiniz.

Model güncelleştirmeleri için değişiklik genişliği

Diyagramda bir kullanıcıdan akıllı uygulamaya ve ardından bir düzenleyiciye giden bağlantı gösterilir. Üç kutu, kesik çizgilerle orkestratöre işaret eder: Yapılandırma, Talep ve Orkestrasyon mantığı. Düzenleyicinin üç farklı yapay zeka modeline işaret eden düz çizgileri vardır: model-x-v1, model-x-v1.1 ve model-y-v1. Orkestratörde API veya aracı etiketli bir kutuya işaret eden bir ok da vardır. API veya aracı kutusu, bilgi veritabanı etiketli bir kutuya işaret eden düz bir çizgiye sahiptir. Dört adımlı işlem hattı, bilgi veritabanına kesikli çizgiyle işaret eder. Dört adım şunlardır: Öbek belgeleri, Zenginleştirme öbekleri, Ekleme öbekleri ve Kalıcı öbekler. Numaralandırılmış daireler diyagramın birkaç parçasına ek açıklama ekler. İlk daire modellerin yanındadır. İkinci daire yapılandırmanın yanındadır. Üçüncü daire istemin yanındadır. Dördüncü çember orkestrasyon mantığının yanındadır. Beşinci daire, boruyla bilgi veritabanı arasındaki kesikli çizginin yanındadır. Altıncı daire modellerin altındadır.

Eski modelden yeni modele geçişi planlamak için model güncelleştirmesinin iş yükünüzü nasıl etkilediğini değerlendirmeniz gerekir. İş yükü değişikliğinin kapsamı, eski ve yeni modeller arasındaki işlevsel ve işlevsel olmayan farklara bağlıdır. Diyagramda, model güncelleştirmesinin etkili olabileceği alanları vurgulayan numaralandırılmış bölümler içeren basitleştirilmiş bir sohbet mimarisi gösterilmektedir.

Her bir alan için, güncellemelerin neden olduğu kapalı kalma sürelerini ve sistemin işlemekte olduğu istekleri nasıl ele aldığınızı göz önünde bulundurun. İş yükünüz için bakım pencereleri varsa, değişiklik kapsamı büyük olduğunda bu pencereleri kullanın. Bakım pencereleri kullanılamıyorsa, model güncelleştirmesi sırasında iş yükünüzün işlevselliğini ve hizmet düzeyi hedeflerini korumak için bu alanlardaki değişiklikleri ele alın.

1. Model: Belirgin değişiklik, modelin kendisi için geçerlidir. Seçtiğiniz model dağıtım stratejisini kullanarak yeni modeli dağıtırsınız. Yerinde yükseltmeler ile yan yana dağıtım arasındaki dengeleri değerlendirmeniz gerekir.

   İnce ayarlı bir modelden yeni bir model düzeltmesine geçtiğiniz zaman, kullanmadan önce yeni model sürümünde yeniden ince ayarlama yapmanız gerekir. Farklı bir model kullanacak şekilde güncelleştirdiğinizde, ince ayarlamanın gerekli olup olmadığını belirlemeniz gerekir.

2. Model yapılandırması: Yapay zeka çözümünüzdeki temel modeli güncelleştirdiğinizde, yeni modelin mimarisi ve özellikleri için performansı iyileştirmek için hiper parametreleri veya yapılandırmaları ayarlamanız gerekebilir. Örneğin, transformatör tabanlı bir modelden yinelenen bir sinir ağına geçiş yapmak, en iyi sonuçları elde etmek için farklı öğrenme hızları ve toplu iş boyutları gerektirebilir.

3. İstem: İş yükünüzdeki temel modelleri değiştirdiğinizde, düzenleyicilerinizde veya aracılarınızda sistem istemlerini yeni modelin güçlü yönleri ve özellikleriyle uyumlu olacak şekilde ayarlamanız gerekebilir.

   Model yapılandırmasını güncelleştirmenin yanı sıra, modelleri güncelleştirdiğinizde en yaygın değişikliklerden biri istem güncelleştirilmesidir. Küçük bir sürüm güncellemesi için bile yeni bir modeli değerlendirirken, gereksinimlerinizi karşılamıyorsa istemdeki değişiklikleri test edin. Bu yaklaşım, diğer değişiklikleri keşfetmeden önce performans sorunlarını gidermenizi sağlar. Yeni modellere geçtiğiniz zaman uyarıyı dikkate almalısınız. Büyük düzeltme değişiklikleri yaptığınızda, isteği de ele almanız muhtemeldir.

4. Düzenleme mantığı: Bazı model güncelleştirmeleri, özellikle de yeni özelliklerden yararlandığınızda düzenleme veya aracı mantığınızda değişiklik yapmanızı gerektirir.

   Örneğin, işlev çağrısından yararlanmak için modelinizi GPT-4'e güncelleştirirseniz düzenleme mantığınızı değiştirmeniz gerekir. Eski modeliniz çağırana geri dönebildiğiniz bir sonuç döndürdü. İşlev çağırma ile, modelin çağrısı orkestrasyon mantığınızın çağırması gereken bir işlev döndürür. Azure'da düzenleme mantığını Azure AI Foundry Agent Service'te veya Azure'da barındırılan Anlam Çekirdeği veya LangChain gibi kod tabanlı çözümleri kullanarak uygulamak normaldir.

5. Topraklama verileri: Bazı model güncelleştirmeleri ve daha büyük kapsamlı değişiklikler, temel alma veya hassas ayarlama verilerinizde veya bu verileri nasıl aldığınızla ilgili değişiklikler yapmanızı gerektirebilir.

   Örneğin, genelleştirilmiş bir modelden finans veya tıp odaklı bir model gibi etki alanına özgü bir modele geçiş yaptığınızda, artık etki alanına özgü topraklama verilerini modele geçirmeniz gerekmeyebilir. Bir diğer örnek de yeni bir modelin daha büyük bir bağlam penceresini işleyebileceği durumdur. Bu senaryoda, diğer ilgili öbekleri almak veya öbeklerinizin boyutunu ayarlamak isteyebilirsiniz. Daha fazla bilgi için Retrieve-Augmented Generation (RAG) çözümünü tasarlama ve geliştirme bölümüne bakın.

6. Donanım: MaaP'ta çalışan modeller için model değişikliği için yeni donanım gerekebilir. Katalogdaki modeller için yalnızca belirli işlem SKU'ları etkinleştirilmiş durumda. Ayrıca, modeli yeni donanımda çalıştırmanızı gerektiren donanım kullanım dışı bırakılabilir.

Değişim için tasarlama

Büyük olasılıkla iş yükünüzdeki modelleri güncelleştireceksiniz. Azure'da MaaS dağıtım stratejisini kullanıyorsanız modeller kullanımdan kaldırılır ve daha yeni bir sürüme yükseltmeniz gerekir. Yeni özelliklerden, düşük fiyatlandırmadan veya geliştirilmiş performansdan yararlanmak için farklı modellere veya model sürümlerine geçmeyi de seçebilirsiniz. Her iki durumda da mimarinizin, üretken yapay zeka iş yükünüzün kullandığı modeli güncelleştirmeyi desteklemesi gerekir.

Önceki bölümde değişikliğin farklı kapsamları ele alınmıştı. Model ince ayarı, mühendis istemleri, hiper parametreleri değiştirme ve düzenleme mantığını yönetme amacıyla otomatik işlem hatları oluşturmak ve korumak için uygun makine öğrenmesi işlemlerini (MLOps), veri işlemlerini (DataOps) ve üretken yapay zeka işlemlerini (GenAIOps) izlemeniz gerekir.

Hiper parametrelere ve istemlere yönelik güncelleştirmeler çoğu model güncelleştirmesinde yaygındır. Bu değişiklikler çok yaygın olduğundan, mimariniz bu alanlar için denetimli bir değişiklik mekanizmasını desteklemelidir. Önemli bir nokta, istemlerin ve hiper parametrelerin belirli model sürümleri için tasarlandığıdır. İstemlerin ve hiper parametrelerin her zaman doğru model ve sürümle kullanıldığından emin olmanız gerekir.

Otomatik işlem hatları

Üretken yapay zeka uygulamanızın farklı yönlerini test etmek ve değerlendirmek için otomatik işlem hatları uygulayın:

• MLOps: Varsa model ince ayarı için işlem hatları oluşturmak için Azure MLOps kılavuzunu izleyin.

• GenAIOps:Model, model hiper parametreleri, istem ve düzenleme mantığındaki değişiklikleri test etmek ve değerlendirmek için GenAIOps işlem hatlarını uygulayın.

• DataOps:RAG topraklama verilerinizde yapılan değişiklikleri test etmek ve değerlendirmek içinDataOps işlem hatlarını uygulayın.

İşlem hatlarını aşağıdaki nedenlerle uygulamanız gerekir:

• Yinelemeli geliştirme ve denemelerinizde size yardımcı olmak için (iç döngü)
• Üretken yapay zeka çözümünüzün (dış döngü) güvenli dağıtımını ve kullanıma hazır hale getirilmesini gerçekleştirmek için

Mümkün olduğunda, üretim uygulamanızda yaptığınız değişiklikleri test etmek için üretim uygulamasıyla kullandığınız temel verileri kullanın. Güncelleştirilmiş uygulama verilerde değişiklik gerektiren yeni model özellikleri kullanıyorsa bu yaklaşım mümkün olmayabilir.

Mimariyle ilgili dikkat edilmesi gerekenler

Aşağıdaki mimari gibi basit mimarilerde istemci, modeli doğru istem sürümü ve yapılandırmasıyla doğrudan çağırır. İstemde değişiklikler varsa, yeni istemle yeni bir istemci dağıtılır ve yeni modeli çağırır. İstem, yapılandırma ve model sürümlerini bağlamak zor değildir.

Bir kullanıcının doğrudan model-x-v1'e bağlanan akıllı bir uygulamaya bağlanmasını gösteren diyagram. Uygulamanın bu öğeleri içerdiğini gösteren kesik çizgili akıllı uygulamaya üç öğe işaret eder. Öğeler yapılandırma, istem ve düzenleme mantığıdır.

Üretim mimarileri basit değildir. Genellikle herhangi bir bilgi veritabanı ile modeller arasındaki etkileşimlerin akışını yönetmek sorumluluğunda olan bir düzenleyici veya aracı uygularsınız. Mimariniz, yönlendirici veya ağ geçidi gibi bir veya daha fazla soyutlama katmanı da uygulayabilir:

• Yönlendirici: Yönlendirici, trafiği farklı düzenleyici dağıtımlarına yönlendirir. Yönlendirici, güvenli dağıtım uygulamalarınızın bir parçası olarak trafiğin belirli bir yüzdesini yeni bir düzenleyici sürümüne yönlendirmeyi seçebileceğiniz mavi-yeşil dağıtımlar gibi dağıtım stratejilerinde kullanışlıdır. Bu bileşen, test edilmiş ancak doğrulanmamış değişiklikleri üretim trafiğiyle değerlendirmek için A/B testi veya trafik yansıtması için de kullanılabilir.

• Ağ geçidi:Yapay zeka modellerine çeşitli nedenlerle ara sunucu aracılığıyla erişim sağlamak yaygın bir uygulamadır. Örneğin, birden çok arka uç örneği arasında yük dengelemesi yapabilir veya yedeklemeyi etkinleştirebilir, özel kimlik doğrulama ve yetkilendirme uygulayabilir ya da modelleriniz için günlük kaydı ve izleme uygulayabilirsiniz.

Diyagramda, yönlendiriciye bağlanan akıllı bir uygulamaya bağlanan bir kullanıcı gösterilmektedir. Yönlendirici, düzenleyicideki iki dağıtıma bağlanır. Her dağıtım bir ağ geçidine bağlanır. Ağ geçidi üç farklı modele bağlanır: model-x-v1, model-x-v1.1 ve model-y-v1. Düzenleyici, bilgi veritabanına bağlanan bir API veya aracıya da bağlanır. Oklar, üretken bir yapay zeka iş yükündeki yaygın soyutlama katmanlarını belirten bir etiketle yönlendiriciye ve ağ geçidine işaret eder.

Dolaylılık katmanları söz konusu olduğundan, mimarinizin belirli modellere veya model sürümlerine istemlerin belirli sürümlerini göndermeyi destekleyecek şekilde tasarlanması gerekir. Örneğin, üretim ortamında model1 gibi bir model için tasarlanmış istem1 gibi bir isteminiz olabilir. Model1.1'e yükseltirseniz, istem1'i istem2'ye güncelleştirmeniz gerekebilir. Bu örnekte mimarinizin her zaman model1 ile prompt1 ve model1.1 ile prompt2 kullanması gerekir.

Yönlendirici

Aşağıdaki diyagramda, istekleri birden çok dağıtıma yönlendirmek için yönlendirici kullanan bir mimari gösterilmektedir. Bu mimarinin bir diğer örneği de Azure AI Foundry'yi içerir ve yönlendirici olarak yönetilen bir çevrimiçi uç nokta kullanır. Orchestrator'ın farklı sürümleri yönetilen hesaplama kaynaklarına dağıtılır.

Diyagramda, bir yönlendiriciye (1 etiketli) bağlanan akıllı bir uygulamaya bağlanan bir kullanıcı gösterilmektedir. Yönlendirici, bir Orchestrator'da 2 olarak etiketlenmiş iki dağıtıma bağlanır. Her dağıtım bir yapılandırma, istem (3 etiketli) ve düzenleme mantığı (4 etiketli) içerir. Her dağıtım belirli bir modele bağlanır (5 etiketli). Dağıtım 1 model-x-v1'e bağlanırken, Dağıtım 2 model-x-v1.1'e bağlanır. Düzenleyici, bilgi veritabanına bağlanan bir API veya aracıya da bağlanır.

Aşağıdaki akışta, bir düzenleyicinin farklı dağıtımlarının doğru modeli nasıl çağırdığı açıklanmaktadır. Her dağıtımın, kendi model yapılandırma sürümü ve bir istemi vardır.

1. Kullanıcı akıllı bir uygulamadan istek gönderir ve bu istek bir yönlendiriciye gönderilir.

2. Yönlendirici, mantığına bağlı olarak orkestratörün Dağıtım 1 veya Dağıtım 2'sine yönlendirir.

3. Her dağıtımın, kendine ait bir istem ve yapılandırma sürümü vardır.

4. Orkestratör, belirli bir model ve sürümle yapılandırılır. Uygun modeli ve sürümü doğrudan çağırmak için bu bilgileri kullanır.

5. İstemin belirli sürümü, belirli model ve sürümle yapılandırılmış düzenleyiciyle birlikte dağıtıldığından, doğru istem doğru model sürümüne gönderilir.

Geçit

Aşağıdaki diyagramda, istekleri birden çok dağıtıma yönlendirmek için yönlendirici kullanan bir mimari gösterilmektedir. Ancak bu mimaride tüm model istekleri bir ağ geçidi üzerinden yönlendirilir. Yük dengeleme, tek bir bölgedeki veya birden çok bölgedeki birden çok arka uç örneği arasında yük devretmeyi etkinleştirme ve kullandıkça öde taşma stratejisiyle sağlanan bir aktarım hızı birimi uygulama gibi çeşitli nedenlerle yapay zeka modellerine ara sunucu erişimi yaygın olarak gerçekleştirilir.

Diyagramda, bir yönlendiriciye (1 etiketli) bağlanan akıllı bir uygulamaya bağlanan bir kullanıcı gösterilmektedir. Yönlendirici, bir Orchestrator'da 2 olarak etiketlenmiş iki dağıtıma bağlanır. Her dağıtım bir yapılandırma, istem (3 etiketli) ve düzenleme mantığı (4 etiketli) içerir. Her dağıtım, "5" olarak etiketlenmiş bir ağ geçidine bağlanır. Her bağlayıcı satırı, bir HTTP üst bilgisini, yani modeli ve sürümü belirten bilgiyi gösteren bir etikete sahiptir. Dağıtım 1 model-x-v1'i, Dağıtım 2 ise model-x-v1.1'i gösterir. Ağ geçidi, model-x-v1 ve model-x-v1.1 (6 etiketli) modeline bağlanır. Düzenleyici, bilgi veritabanına bağlanan bir API'ye veya aracıya bağlanır.

Aşağıdaki akışta, bir düzenleyicinin farklı dağıtımlarının bir ağ geçidi üzerinden doğru modeli nasıl çağırdığı açıklanmaktadır. Her dağıtımın, kendi model yapılandırma sürümü ve bir istemi vardır.

1. Kullanıcı akıllı bir uygulamadan istek gönderir ve bu istek bir yönlendiriciye gönderilir.

2. Yönlendirici, mantığına bağlı olarak Dağıtım 1 veya Dağıtım 2'ye yönlendirir.

3. Her dağıtımın kendi istem versiyonu vardır.

4. Orkestratör, belirli bir model ve sürümle yapılandırılır. Çağrılacak doğru modeli ve sürümü gösteren bir HTTP üst bilgisi ayarlamak için bu bilgileri kullanır.

5. Orkestratör ağ geçidini başlatır. İstek, kullanılacak modelin adını ve sürümünü gösteren HTTP üst bilgisini içerir.

6. Ağ geçidi, isteği uygun modele ve sürüme yönlendirmek için HTTP üst bilgisini kullanır. Ağ geçidinde tanımlanan yapılandırmayı da uygulayabilir.

Yapılandırmayı dışlaştırma

Dış Yapılandırma Deposu bulut tasarım düzeni, istemleri ve yapılandırmayı depolamak için iyi bir yoldur. Bazı model değişiklikleri kapsamları için, düzenleyicinizin veya aracınızın kodunun dışında güncelleştirilebilir bir konumda depolanıyorlarsa, model dağıtımını sistem istemi ve yapılandırma değişiklikleriyle koordine edebilirsiniz. Ayarlayacak düzenleme mantığınız varsa bu yaklaşım çalışmaz, ancak daha küçük kapsam modeli güncelleştirmelerinde kullanışlıdır.

Hesaplama seçimi

MaaP barındırma için modeller genellikle konak tarafından sağlanan işlem kaynaklarının bir alt kümesiyle sınırlıdır. Tüm işlem kotalara, kullanılabilirlik kısıtlamalarına ve kullanım süresi sonu duyurularına tabidir. Geçerli donanımınız artık desteklenmediğinde veya ek ölçeği genişletmeyi engelleyen kısıtlamalar olduğunda yeni donanıma geçişi desteklemek için yönlendirme desenlerini kullanın.

Kullanım süresi sonu duyurusunun bir örneği , NC A100 v4 işlem duyurusu serisidir. Modelleri bu donanımda barındıracaksanız, kullanım süresi dolmayan ve daha fazla kullanılabilirliğe sahip başka bir desteklenen SKU'ya geçmeniz gerekir. Yeni SKU geçerli modelinizi desteklemiyorsa bu geçiş aynı anda model değişikliği gerektirebilir.

Öneriler

• İş yükünüzün belirli alanlarında denetimli değişiklikler yapmak için soyutlama ve dolaylılık katmanları ekleyin. Bu alanlar arasında istemci, akıllı uygulama API'si, düzenleme, model barındırma ve temel alma bilgileri yer alır.

• Model sürümlerinde, istemlerde, yapılandırmalarda, düzenleme mantığında ve temel bilgi alımında yapılan tüm değişiklikler üretimde kullanılmadan önce test edilmelidir. Test edilen birleşimlerin üretimde birbirine sabitlendiğinden emin olun; bu da dağıtıldığında sıkı bir şekilde bağlı kaldıkları anlamına gelir. A/B testi, yük dengeleme ve mavi-yeşil dağıtımlar, kullanıcıları test edilmemiş birleşimlere maruz bırakmamak için bileşenleri karıştırmamalıdır.

• Otomatik işlem hatlarını kullanarak yeni sürümleri ve yeni modelleri test edin ve değerlendirin. İstediğiniz sonuçları aldığınızdan emin olmak için sonuçları temelinizin sonuçlarıyla karşılaştırmanız gerekir.

• Modelleri güncelleştirme konusunda bilinçli olun. Test etme fırsatı olmadan üretim modellerini otomatik olarak yeni sürümlere yükselten platform özelliklerini kullanmaktan kaçının. Her model güncelleştirmesinin iş yükünüzü nasıl etkilediğini bilmeniz gerekir. Azure AI Foundry Models API'sini kullanıyorsanız dağıtımlarınızı belirli bir sürümle ayarlayın ve yükseltme ilkesi sağlamayın. Bu kurulum, yeni bir sürüm yayınlandığında el ile yükseltme gerektirir. Azure OpenAI için, otomatik yükseltmeleri kapatmak için dağıtımları Otomatik Yükseltme Yok olarak ayarlayın.

• Gözlemlenebilirlik ve günlüğe kaydetme çözümünüzün gözlemlenen davranışı ilgili istem, yapılandırma, model ve veri alma çözümüyle ilişkilendirmek için yeterli meta veri topladığından emin olun. Bu bağıntı, sistem performansındaki beklenmeyen regresyonları belirlemenizi sağlar.

Özet

Oluşturucu iş yükünüzün temel modelini güncelleştirmenin çeşitli nedenleri vardır. Bu nedenler, modeller kullanımdan kaldırıldığında gerekli sürüm yükseltmelerinden farklı bir modele geçme kararına kadar değişir. Model güncelleştirmesinin kapsamına bağlı olarak, istem, model yapılandırması, düzenleme mantığı veya veri işlem hattı değişiklikleri dahil olmak üzere modeldeki değişiklikleri uygulamanız ve değerlendirmeniz gerekebilir. Çözümünüzün farklı yönleri için otomatik iş akışları oluşturmak için MLOps, DataOps ve GenAIOps yönergelerini izlemeniz gerekir. Otomatik iş akışları yeni sürümleri test etmenizi, değerlendirmenizi ve dağıtmanızı sağlar. Ayrıca mimarinizin, her sürümün yapılandırma ve istem sürümünü belirli bir model sürümüne bağladığı bir düzenleyicinin birden çok sürümünü çalıştırmayı desteklediğinden de emin olmanız gerekir.

Mimariniz, akıllı uygulamada veya kullanıcı deneyiminde değişiklik yapılmasına gerek kalmadan yeni veya farklı modellerde yapılan güncelleştirmeleri ve istem veya model yapılandırmasında yapılan gerekli değişiklikleri desteklemelidir. Bu güncelleştirmeler uygun bileşenleri içinde kapsüllenmeli ve işlemleriniz bu değişikliklerin testini, değerlendirmesini ve dağıtımını otomatikleştirmelidir.

Katkıda Bulunanlar

Microsoft bu makaleyi korur. Bu makaleyi aşağıdaki katkıda bulunanlar yazdı.

• Ritesh Modi | Baş Yazılım Mühendisi

Nonpublic LinkedIn profillerini görmek için LinkedIn'de oturum açın.

Sonraki adım

• Azure OpenAI modelinin kullanımının azaltılması ve emekliye ayrılması

İlgili kaynaklar

• Baseline AI Foundry sohbet referans mimarisi
• MLOps
• MLOps uygulayıcıları için GenAIOps