Performans ve gecikme süresi

Makale
11/23/2024

Bu makale, Azure OpenAI ile gecikme süresi ve aktarım hızının nasıl çalıştığına ve performansı geliştirmek için ortamınızı nasıl iyileştirdiğinize yönelik arka plan bilgileri sağlar.

Aktarım hızını ve gecikme süresini anlama

Bir uygulamayı boyutlandırırken dikkate alınacak iki temel kavram vardır: (1) Dakika başına belirteçlerle ölçülen sistem düzeyinde aktarım hızı (TPM) ve (2) Çağrı başına yanıt süreleri (gecikme süresi olarak da bilinir).

Sistem düzeyinde aktarım hızı

Bu işlem, dağıtımınızın genel kapasitesine (dakikada kaç istek ve işlenebilen toplam belirteç sayısı) bakar.

Standart dağıtım için dağıtımınıza atanan kota, elde edilebilecek aktarım hızı miktarını kısmen belirler. Ancak kota yalnızca dağıtıma yapılan çağrılar için erişim mantığını belirler ve aktarım hızını doğrudan zorlamaz. Çağrı başına gecikme süresi varyasyonları nedeniyle kotanız kadar yüksek aktarım hızı elde edemeyebilirsiniz. Kotayı yönetme hakkında daha fazla bilgi edinin.

Sağlanan dağıtımda, uç noktanıza belirli bir model işleme kapasitesi miktarı ayrılır. Uç noktada elde edilebilecek aktarım hızı miktarı, giriş belirteci miktarı, çıkış miktarı, çağrı hızı ve önbellek eşleştirme hızı gibi iş yükü şeklinin bir faktörüdür. eş zamanlı çağrıların ve işlenen toplam belirteçlerin sayısı bu değerlere göre farklılık gösterebilir.

Tüm dağıtım türleri için sistem düzeyinde aktarım hızını anlamak, performansı iyileştirmenin önemli bir bileşenidir. Belirli bir model, sürüm ve iş yükü birleşimi için sistem düzeyinde aktarım hızını göz önünde bulundurmanız önemlidir, bu nedenle aktarım hızı bu faktörler arasında farklılık gösterir.

Sistem düzeyinde aktarım hızını tahmin etme

Azure İzleyici ölçümleriyle TPM tahmini

Belirli bir iş yükü için sistem düzeyinde aktarım hızını tahmin etmeye yönelik bir yaklaşım, geçmiş belirteç kullanım verilerini kullanmaktır. Azure OpenAI iş yükleri için tüm geçmiş kullanım verilerine Azure OpenAI içinde sunulan yerel izleme özellikleriyle erişilebilir ve görselleştirilebilir. Azure OpenAI iş yükleri için sistem düzeyinde aktarım hızını tahmin etmek için iki ölçüm gerekir: (1) İşlenmiş İstem Belirteçleri ve (2) Oluşturulan Tamamlama Belirteçleri.

bir araya getirildiğinde, İşlenen İstem Belirteçleri (giriş TPM) ve Oluşturulan Tamamlama Belirteçleri (çıktı TPM) ölçümleri, gerçek iş yükü trafiğine göre sistem düzeyinde aktarım hızının tahmini bir görünümünü sağlar. Bu yaklaşım, istemi önbelleğe almanın avantajlarını hesaba bağlamaz, bu nedenle muhafazakar bir sistem aktarım hızı tahmini olacaktır. Bu ölçümler, çok haftalık bir zaman ufukta 1 dakikalık pencereler üzerinde minimum, ortalama ve maksimum toplama kullanılarak analiz edilebilir. Değerlendirilecek yeterli veri noktası olduğundan emin olmak için bu verileri çok haftalık bir zaman ufku içinde analiz etmek önerilir. Aşağıdaki ekran görüntüsünde Azure İzleyici'de görselleştirilmiş ve doğrudan Azure portalı üzerinden kullanılabilen İşlenmiş İstem Belirteçleri ölçümünün bir örneği gösterilmektedir.

modele ve sürüme göre bölünmüş İşlenmiş İstem Belirteçleri ölçümünü gösteren Azure İzleyici grafiğinin ekran görüntüsü.

İstek verilerinden TPM tahmini

Tahmini sistem düzeyinde aktarım hızına yönelik ikinci bir yaklaşım, API istek verilerinden belirteç kullanımı bilgilerinin toplanmasıdır. Bu yöntem, istek başına iş yükü şeklini anlamak için daha ayrıntılı bir yaklaşım sağlar. İstek başına belirteç kullanım bilgilerini dakika başına istek sayısı (RPM) cinsinden ölçülen istek hacmiyle birleştirmek, sistem düzeyinde aktarım hızı için bir tahmin sağlar. İstekler ve istek hacmi genelinde belirteç kullanımı bilgilerinin tutarlılığı için yapılan tüm varsayımların sistem aktarım hızı tahminini etkileyeceğini unutmayın. Belirteç kullanımı çıkış verileri, belirli bir Azure OpenAI Hizmeti sohbet tamamlama isteği için API yanıt ayrıntılarında bulunabilir.

{
  "body": {
    "id": "chatcmpl-7R1nGnsXO8n4oi9UPz2f3UHdgAYMn",
    "created": 1686676106,
    "choices": [...],
    "usage": {
      "completion_tokens": 557,
      "prompt_tokens": 33,
      "total_tokens": 590
    }
  }
}

Belirli bir iş yüküne yönelik tüm isteklerin tekdüzen olduğunu varsayarsak, API yanıt verilerindeki istem belirteçleri ve tamamlama belirteçlerinin her biri, belirtilen iş yükü için giriş ve çıkış TPM'sini tanımlamak için tahmini RPM ile çarpılabilir.

Sistem düzeyinde aktarım hızı tahminlerini kullanma

Belirli bir iş yükü için sistem düzeyinde aktarım hızı tahmin edildikten sonra bu tahminler Standart ve Sağlanan dağıtımları boyutlandırmak için kullanılabilir. Standart dağıtımlarda, belirli bir dağıtıma atanacak toplam TPM'yi tahmin etmek için giriş ve çıkış TPM değerleri birleştirilebilir. Sağlanan dağıtımlar için, istek belirteci kullanım verileri veya giriş ve çıkış TPM değerleri, dağıtım kapasitesi hesaplayıcı deneyimiyle belirli bir iş yükünü desteklemek için gereken PTU sayısını tahmin etmek için kullanılabilir.

GPT-4o mini modeli için birkaç örnek aşağıda verilmiştir:

İstem Boyutu (belirteçler)	Oluşturma boyutu (belirteçler)	Dakika başına istek sayısı	TPM girişi	Tpm Çıktısı	Toplam TPM	GEREKLI PTU'lar
800	150	30	24,000	4.500	28,500	15
5.000	50	1.000	5,000,000	50,000	5,050,000	140
1.000	300	500	500,000	150,000	650,000	30

İş yükü dağıtımı sabit kaldığında PTU sayısı kabaca doğrusal olarak çağrı hızıyla ölçeklendirilir.

Gecikme süresi: Çağrı başına yanıt süreleri

Bu bağlamda gecikme süresinin üst düzey tanımı, modelden yanıt almak için gereken süredir. Tamamlama ve sohbet tamamlama istekleri için gecikme süresi büyük ölçüde model türüne, istemdeki belirteç sayısına ve oluşturulan belirteç sayısına bağlıdır. Genel olarak, her istem belirteci oluşturulan her artımlı belirteçle karşılaştırıldığında çok az zaman ekler.

Bu modellerde beklenen çağrı başına gecikme sürenizi tahmin etmek zor olabilir. Tamamlanma isteğinin gecikme süresi dört birincil faktöre göre farklılık gösterebilir: (1) model, (2) istemdeki belirteç sayısı, (3) oluşturulan belirteç sayısı ve (4) dağıtım ve sistem üzerindeki genel yük. Bir ve üç genellikle toplam süreye ana katkıda bulunanlardır. Sonraki bölümde, büyük bir dil modeli çıkarım çağrısının anatomisi hakkında daha fazla ayrıntıya girildi.

Performansı geliştirme

Uygulamanızın çağrı başına gecikme süresini geliştirmek için denetleyebileceğiniz çeşitli faktörler vardır.

Model seçimi

Gecikme süresi, kullandığınız modele göre değişir. Aynı istek için, sohbet tamamlama çağrısı için farklı modellerin farklı gecikme sürelerine sahip olmasını bekleyebilirsiniz. Kullanım örneğiniz en hızlı yanıt süresine sahip en düşük gecikme süresi modellerini gerektiriyorsa en son GPT-4o mini modelini öneririz.

Nesil boyutu ve Maksimum belirteçler

Azure OpenAI uç noktasına bir tamamlama isteği gönderdiğinizde, giriş metniniz daha sonra dağıtılan modelinize gönderilen belirteçlere dönüştürülür. Model giriş belirteçlerini alır ve ardından bir yanıt oluşturmaya başlar. Yinelemeli sıralı bir işlemdir ve her seferinde bir belirteçtir. Bunu düşünmenin başka bir yolu ile n tokens = n iterationsbir for döngüsü gibidir. Çoğu model için yanıt oluşturmak, işlemin en yavaş adımıdır.

İstek sırasında, istenen oluşturma boyutu (max_tokens parametresi) oluşturma boyutunun ilk tahmini olarak kullanılır. Tam boyutu oluşturmak için işlem süresi, istek işlenirken model tarafından ayrılır. Oluşturma tamamlandıktan sonra kalan kota serbest bırakılır. Belirteç sayısını azaltmanın yolları:

Her çağrıda parametresini max_tokens mümkün olduğunca küçük olarak ayarlayın.
Ek içerik oluşturulmasını önlemek için durdurma dizileri ekleyin.
Daha az yanıt oluşturun: best_of & n parametreleri birden çok çıkış oluşturduğundan gecikme süresini büyük ölçüde artırabilir. En hızlı yanıt için bu değerleri belirtmeyin veya 1 olarak ayarlayın.

Özetle, istek başına oluşturulan belirteç sayısını azaltmak, her isteğin gecikme süresini azaltır.

Akışlar

İstekteki ayar stream: true , hizmetin belirteçleri kullanılabilir oldukları anda döndürmesini sağlar, belirteçlerin tam sırasının oluşturulmasını beklemek yerine. Tüm belirteçleri alma süresini değiştirmez, ancak ilk yanıt süresini azaltır. Bu yaklaşım, son kullanıcılar oluşturuldukça yanıtı okuyabildiğinden daha iyi bir kullanıcı deneyimi sağlar.

Akışın işlenmesi uzun süren büyük çağrılarla da değerlidir. Birçok istemci ve aracı katmanında tek tek çağrılarda zaman aşımları olur. İstemci tarafı zaman aşımları nedeniyle uzun nesil çağrılar iptal edilebilir. Verileri geri akışla aktararak artımlı verilerin alındığından emin olabilirsiniz.

Akışın ne zaman kullanılacağına ilişkin örnekler:

Sohbet botları ve konuşma arabirimleri.

Akış algılanan gecikme süresini etkiler. Akış etkinleştirildiğinde belirteçleri kullanılabilir oldukları anda öbekler halinde geri alırsınız. Son kullanıcılar için bu yaklaşım genellikle isteği tamamlama süresi aynı kalsa bile modelin daha hızlı yanıt verdiğini hisseder.

Akış daha az önemli olduğunda örnekleri:

Yaklaşım analizi, dil çevirisi, içerik oluşturma.

Gerçek zamanlı yanıtı değil, yalnızca tamamlanmış sonucu önemsediğiniz toplu bir görev gerçekleştirdiğiniz birçok kullanım örneği vardır. Akış devre dışı bırakılırsa, model yanıtın tamamını tamamlayana kadar hiçbir belirteç almazsınız.

İçerik filtrelemesi

Azure OpenAI, çekirdek modellere uygun bir içerik filtreleme sistemi içerir. Bu sistem, zararlı içeriğin çıkışını algılamayı ve önlemeyi hedefleyen sınıflandırma modellerinin bir grubu aracılığıyla hem istem hem de tamamlama çalıştırarak çalışır.

İçerik filtreleme sistemi, hem giriş istemlerinde hem de çıkış tamamlamalarında zararlı olabilecek belirli içerik kategorilerini algılar ve üzerinde işlem gerçekleştirir.

İçerik filtrelemenin eklenmesi, güvenlikte artışla birlikte gecikme süresiyle birlikte gelir. Performans açısından bu dengenin gerekli olduğu birçok uygulama vardır, ancak performansı geliştirmek için içerik filtrelerini devre dışı bırakmanın keşfetmeye değebileceği bazı düşük riskli kullanım örnekleri vardır.

Varsayılan içerik filtreleme ilkelerinde değişiklik isteme hakkında daha fazla bilgi edinin.

İş yüklerinin ayrılması

Aynı uç noktada farklı iş yüklerinin karıştırılması gecikme süresini olumsuz etkileyebilir. Bunun nedeni, (1) çıkarım sırasında birlikte toplu olarak çalıştırılmaları ve kısa çağrıların daha uzun süre tamamlanmasını beklemesi ve (2) çağrıların karıştırılması, ikisi de aynı alan için rekabet ettiğinden önbellek isabet oranınızı düşürebilir. Mümkün olduğunda, her iş yükü için ayrı dağıtımlar olması önerilir.

İstem Boyutu

İstem boyutunun gecikme süresi üzerinde nesil boyutundan daha küçük bir etkisi olsa da, özellikle boyut büyüdükçe genel süreyi etkiler.

İşlem grubu oluşturma

Aynı uç noktaya birden çok istek gönderiyorsanız, istekleri tek bir çağrıda toplu işleyebilirsiniz. Bu, yapmanız gereken istek sayısını azaltır ve senaryoya bağlı olarak genel yanıt süresini iyileştirebilir. Yardımcı olup olmadığını görmek için bu yöntemi test etmenizi öneririz.

Aktarım hızınızı ölçme

Dağıtımdaki genel aktarım hızınızı iki ölçüyle ölçmenizi öneririz:

Dakika başına çağrı sayısı: Dakikada yaptığınız API çıkarım çağrılarının sayısı. Bu, Azure OpenAI İstekleri ölçümü kullanılarak Azure-monitor'da ölçülebilir ve ModelDeploymentName ile bölünebilir
Dakika başına toplam Belirteç sayısı: Dağıtımınız tarafından dakika başına işlenen toplam belirteç sayısı. Buna istem ve oluşturulan belirteçler dahildir. Bu genellikle dağıtım performansının daha derin bir şekilde anlaşılması için her ikisini de ölçmeye ayrılır. Bu, İşlenen Çıkarım belirteçleri ölçümü kullanılarak Azure İzleyici'de ölçülebilir.

Azure OpenAI Hizmetini İzleme hakkında daha fazla bilgi edinebilirsiniz.

Çağrı başına gecikme süresini ölçme

Her çağrının süresi modeli okumanın, çıkışı oluşturmanın ve içerik filtrelerini uygulamanın ne kadar sürdüğüne bağlıdır. Akış kullanıyorsanız veya kullanmıyorsanız saati ölçme yönteminiz farklılık gösterir. Her durum için farklı bir ölçü kümesi öneririz.