Falcon modellerinin performansını Amazon SageMaker ile iyileştirin | Amazon Web Hizmetleri

Metin üreten üretken yapay zeka uygulamalarına yönelik büyük dil modellerini (LLM'ler) barındırmak için en uygun çerçeve ve yapılandırma nedir? Yüksek Lisans'lara hizmet etme seçeneklerinin çokluğuna rağmen, modellerin boyutu, değişen model mimarileri, uygulamaların performans gereksinimleri ve daha fazlası nedeniyle bu cevaplanması zor bir sorudur. Amazon Adaçayı Yapıcı Büyük Model Çıkarımı (LMI) kapsayıcısı Yüksek Lisans'ların dağıtımını optimize eden bir dizi farklı çerçeve ve tekniği bir araya getirerek Yüksek Lisans'lara hizmet etmeyi basitleştirir. LMI kabı, adı verilen güçlü bir servis yığınına sahiptir. DJL servisi bu, temeldeki LLM'den bağımsızdır. Belirli bir LLM için barındırma altyapısının en iyi performansını elde etmek üzere ayarlanabilen sistem düzeyinde yapılandırma parametreleri sağlar. Aynı zamanda, yinelemeli toplu işlem veya yuvarlanan toplu işlem olarak da bilinen sürekli toplu işlem gibi en yeni optimizasyonları da destekler ve bu da üretimde önemli iyileştirmeler sağlar.

Daha erken bir saatte Facebook postFalcon model ailesini SageMaker'da dağıtmak için LMI konteynerini nasıl kullanabileceğinizi gösterdik. Bu yazıda, sürekli harmanlama gibi tekniklerle Falcon-40B'ye hizmet vermenin verimini ve gecikmesini nasıl iyileştirebileceğimizi gösteriyoruz. Ayrıca, gerçek dünyadaki uygulamanız için en iyi konfigürasyonu bulmanıza yardımcı olabilecek, SageMaker LMI konteyneri tarafından sağlanan konfigürasyon parametrelerinin sezgisel bir şekilde anlaşılmasını sağlıyoruz.

Yüksek Lisans için metin üreten çıkarımın temelleri

Öncelikle metin oluşturmaya yönelik Yüksek Lisans (LLM) çıkarımlarının nasıl gerçekleştirileceğine ilişkin birkaç temel noktaya bakalım.

İleri geçiş, etkinleştirmeler ve KV önbelleği

Belirteçlerin bir giriş dizisi verildiğinde, bunlar bir forward pass Bir sonraki jetonu oluşturmak için LLM'nin tüm katmanları boyunca (Falcon gibi). A forward pass Bir çıktı üretmek için girdi verilerinin bir sinir ağından geçirilmesi sürecini ifade eder. Metin oluşturma durumunda ileri geçiş, dil modeline bir başlangıç ​​tohumu veya bağlamı beslemeyi ve dizideki bir sonraki karakter veya simgeyi üretmeyi içerir. Bir metin dizisi oluşturmak için süreç genellikle yinelemeli olarak yapılır; bu, çıktı dizisindeki her adım veya konum için tekrarlandığı anlamına gelir. Her yinelemede model, oluşturulan metnin parçası haline gelen bir sonraki karakteri veya belirteci üretir ve bu süreç, istenen metin uzunluğu oluşturulana kadar devam eder.

Falcon veya GPT gibi dil modelleriyle metin oluşturma autoregressive. Bu, modelin önceden oluşturulmuş tokenları şartlandırırken her seferinde bir token ürettiği anlamına gelir. Başka bir deyişle, her yinelemede model, önceden oluşturulan metni girdi olarak alır ve bu bağlama dayalı olarak bir sonraki jetonu tahmin eder. Bahsedildiği gibi vLLM: PagedAttention ile Kolay, Hızlı ve Ucuz LLM HizmetiBu otoregresif kod çözme sürecinde, LLM'ye gelen tüm giriş belirteçleri kendi dikkat anahtarı ve değer tensörlerini üretir ve bu tensörler, sonraki belirteçleri oluşturmak için GPU belleğinde tutulur. Bu önbelleğe alınmış anahtar ve değer tensörlerine genellikle KV cache.

Önceden doldurma ve kod çözme aşamaları

Falcon gibi dil modelleriyle metin oluşturmada kullanılan otoregresif kod çözme sürecinde genellikle iki ana aşama vardır: prefill faz ve decode faz. Bu aşamalar tutarlı ve bağlamsal olarak alakalı metin oluşturmak için çok önemlidir.

Ön doldurma aşaması aşağıdakileri içerir:

• Başlangıç ​​bağlamı – Ön doldurma aşaması, kullanıcı tarafından sağlanan bir başlangıç ​​bağlamı veya başlangıç ​​metniyle başlar. Bu başlangıç ​​bağlamı bir cümle, bir ifade, hatta tek bir kelime bile olabilir. Metin oluşturmanın başlangıç ​​noktasını belirler ve bundan sonra olacaklar için bağlam sağlar.
• Model koşullandırma – Sağlanan bağlam, dil modelini koşullandırmak için kullanılır. Model, bu bağlamı girdi olarak alır ve bağlamı anlamasına bağlı olarak dizideki bir sonraki simgeyi (kelime veya karakter) üretir.
• jeton üretimi – Model, metinde bir sonraki adımın ne olması gerektiğini tahmin ederek her seferinde bir simge üretir. Bu belirteç bağlama eklenir ve onu etkili bir şekilde genişletir.
• Yinelemeli süreç – Token oluşturma süreci tekrarlanarak tekrarlanır. Model, her adımda, artık önceki adımlarda oluşturulan jetonları içeren güncellenmiş bağlamı dikkate alarak bir jeton oluşturur.

Ön dolum aşaması, önceden belirlenmiş bir durdurma koşulu sağlanana kadar devam eder. Bu koşul, oluşturulan metin için maksimum uzunluk, metnin sonunu belirten belirli bir belirteç veya kullanıcı ya da uygulama tarafından belirlenen herhangi bir başka kriter olabilir.

Kod çözme aşaması aşağıdakileri içerir:

• Sürecin Tamamlanması – Ön doldurma aşamasından sonra, bir noktada tamamlanmamış veya kesilmiş olabilecek, kısmen oluşturulmuş bir metniniz olur. Kod çözme aşaması, metni tutarlı ve dilbilgisi açısından doğru hale getirecek şekilde tamamlamaktan sorumludur.
• Son jetonun devamı – Kod çözme aşamasında model, ön doldurma aşamasında oluşturulan son jetondan başlar. Bu belirteci başlangıç ​​bağlamı olarak kullanır ve metne devam etmek için bir sonraki belirteci oluşturur.
• Yinelemeli tamamlama – Ön doldurma aşamasında olduğu gibi, jeton oluşturma süreci de yinelemelidir. Model, dizideki önceki jetonları koşullandırarak her seferinde bir jeton üretir.
• Durdurma koşulu – Kod çözme aşamasının ayrıca, maksimum uzunluğa ulaşma veya metin sonu belirteciyle karşılaşma gibi ön doldurma aşamasındakiyle aynı olabilecek bir durma koşulu da vardır. Bu koşul karşılandığında üretim süreci durur.

Ön doldurma ve kod çözme aşamalarının birleşimi, otoregresif modellerin başlangıç ​​bağlamı üzerine inşa edilen ve tutarlı, bağlamsal olarak ilgili ve bağlamsal olarak tutarlı metin dizileri üreten metinler üretmesine olanak tanır.

Bakın Trafo Tabanlı Üretken Modeller için Dağıtılmış Hizmet Sistemi Sürecin ayrıntılı bir açıklaması için.

Dinamik toplu işlem kullanarak verimi optimize etme

Şu ana kadar sadece tek bir girdiden bahsettik. Uygulamada, uygulama istemcilerinden çıkarım için rastgele gelen birden fazla isteğin aynı anda veya kademeli olarak ele alınmasını bekliyoruz. Geleneksel şekilde, GPU'nun bilgi işlem kaynaklarının kullanımını ve verimi artırmak için temel toplu işlem kullanılabilir. Toplu işleme, birden fazla isteğin sayısal temsillerinin bir toplu işte etkili bir şekilde birleştirilmesi ve otoregresif ileri geçişlerin paralel çalıştırılmasının gerçekleştirilmesidir. Bu akıllı gruplama servis tarafında yapılır. SageMaker LMI'nın DJLServing sunucusu, aşağıdaki parametreleri ayarlayarak birden fazla isteği paralel olarak işlemek üzere bir araya getirecek şekilde yapılandırılabilir. porsiyon.özellikleri:

• max_batch_delay = 100 – Toplu birleştirme için milisaniye cinsinden maksimum gecikme. Varsayılan değer 100 milisaniyedir.
• Parti boyutu = 32 – Dinamik toplu iş boyutu. Varsayılan 1'dir.

Bu, temel olarak DJLServing'in istekleri bir seferde 100 milisaniye boyunca sıraya koyacağını veya sıraya alınan isteklerin sayısı belirtilenbatch_size kadarsa, grubun çıkarım için arka uçta çalışacak şekilde programlanacağını gösterir. Bu şu şekilde bilinir: dynamic batching. Dinamiktir çünkü toplu iş boyutu, söz konusu süre içinde kaç isteğin eklendiğine bağlı olarak gruplar arasında değişebilir. Bununla birlikte, istekler farklı özelliklere sahip olabileceğinden (örneğin, bazı istekler 20 jetonluk giriş ve 500 jetonluk çıkış şeklinde olabilirken, diğerleri tersine çevrilebilir, 500 jetonluk giriş ve yalnızca 20 jetonluk çıkış şeklinde olabilir), bazı istekler İşlemi aynı partideki diğerlerinden daha hızlı tamamlayın. Bu, kuyrukta işlenmeyi bekleyen ek istekler olsa bile toplu iş içindeki tüm hareket halindeki isteklerin kod çözme aşamasını tamamlamasını beklerken GPU'nun gereğinden az kullanılmasına neden olabilir. Aşağıdaki diyagram bu süreci göstermektedir.

Sürekli toplu işlem kullanarak verimi optimize etme

İle continuous batching, Ayrıca şöyle bilinir iterative or rolling toplulaştırmada, ön doldurma ve kod çözme aşamaları arasındaki farklardan yararlanırız. Sürekli gruplamayı etkinleştirmek için DJServing, serve.properties'e göre aşağıdaki ek yapılandırmaları sağlar:

• motor=MPI – Sürekli toplu işlem için MPI motorunu kullanmanızı öneririz.
• option.rolling_batch=auto veya lmi-dist – Gelecekte diğer optimizasyonlarla birlikte en uygun yuvarlanan toplu algoritmayı otomatik olarak seçeceğinden auto kullanmanızı öneririz.
• option.max_rolling_batch_size=32 – Bu, eşzamanlı isteklerin sayısını sınırlar. Varsayılan 32'dir.

Sürekli toplu işlemle, sunum yığını (DJLServing), toplu iş içindeki tüm hareket halindeki isteklerin kod çözme aşamasını tamamlamasını beklemez. Bunun yerine, mantıksal kesintilerde (kod çözme aşamasındaki bir yinelemenin sonunda), geçerli toplu iş hala işlenirken kuyrukta bekleyen ek istekleri çeker (dolayısıyla adı da budur). haddeleme toplu). Bu kontrolü, kod çözme aşamasının her yinelemesinin sonunda bekleyen istekler için yapar. Her istek için, ön doldurma aşamasını ve ardından sıralı kod çözme aşamasını çalıştırmamız gerektiğini unutmayın. Bir isteğin ilk isteminden itibaren tüm belirteçleri, ön doldurma aşamasına paralel olarak işleyebildiğimiz için, yeni bir istek alındığında, toplu işlemin hareket halindeki isteklerinin kod çözme aşamasını geçici olarak duraklatırız; KV önbelleğini geçici olarak kaydederiz. ve aktivasyonları bellekte saklar ve yeni isteklerin ön doldurma aşamasını çalıştırır.

Bu önbelleğin boyutu aşağıdaki seçenekle yapılandırılabilir:

Ön doldurma tamamlandığında, yeni istekleri ve eski duraklatılmış istekleri, kod çözme aşamasına paralel olarak ilerleyebilecek yeni bir sürekli grupta birleştiririz. Eski duraklatılmış isteklerin kod çözme aşamasına kaldıkları yerden devam edebileceğini ve yeni isteklerin ilk yeni belirteçlerinden başlayacağını unutmayın.

Sürekli gruplamanın, günlük hayatımızdaki görevleri doğal olarak paralelleştirdiğimiz neredeyse benzer bir yaklaşım olduğunu zaten fark etmiş olabilirsiniz. Rastgele zamanlarda gelen mesajlarımız, e-postalarımız, telefon bildirimlerimiz (potansiyel olarak yeni istekler) var (GPU'lar için birden fazla isteğin rastgele, kademeli bir şekilde gelmesine benzer). Tüm bunlar, e-posta oluşturma, kodlama, toplantılara katılma (GPU'larda şu anda işlenen görevlere benzer şekilde) uçuş sırasındaki görevlerimizi tamamlarken oluyor. Mantıksal molalarda, bizim tarafımızdan yapılması gereken bir işlem olup olmadığına karar vermek için uçuş içi görevlerimizi duraklatır ve bildirimlerimizi kontrol ederiz ve eğer varsa bunu uçuş içi görevlerimize ekleriz (gerçek hayatta devam eden toplu iş) veya yapılacaklar listesine (kuyruğa) koyun.

Hepsini bir araya getirmek: GPU'ların bellek kullanımı hakkında nasıl düşünülmeli?

İş kullanımınız için hangi yapılandırmanın en uygun maliyetli olduğunu görmek amacıyla modelinize yük testi yapmanız önerilir. Anlamak için, model yüklenirken ve ardışık istekler sürekli bir toplu iş halinde işlenirken GPU'ların bellek ayak izini görselleştirelim. Bu yazı için Falcon-40B modelini, her biri 5 GB belleğe sahip NVIDIA A10G GPU'larla kurulu G24 bulut sunucusu türlerinden birine yüklediğimizi varsayalım. V3, A4 ve H5 GPU serisiyle birlikte gelen p100, p100 ve p100 bulut sunucusu türleri için de benzer bir anlayışın geçerli olduğunu unutmayın.

Falcon-40B'ye hizmet vermek için gereken toplam belleğin yaklaşık değerini elde etmeye ilişkin genel bakış aşağıda verilmiştir:

• Model boyutu = Model parametresi sayısı (Falcon-40B için 40 milyar) x parametre başına 4 bayt (FP32 için) = 160 GB
• Çıkarım amacıyla Falcon-40B'yi yüklemek için gereken yaklaşık toplam bellek = Model boyutu (=160 GB) + KV Önbellek (Dikkat Önbelleği) (=*20 GB) + ML Çerçeveleri tarafından sağlanan ek bellek (yaklaşık 2 GB)

Falcon-40B için modeli bfloat16 (2 byte) veri tipine quantize ederek sıkıştırırsak model boyutu yaklaşık 80 GB olur. Gördüğünüz gibi, bu hala tek bir hızlandırıcı cihazın desteklediği bellekten daha büyük olduğundan, özel bir yöntemle model bölümleme (parçalama) tekniğini benimsememiz gerekiyor. tensör paralelliği (TP) yaklaşımı ve modeli birden fazla hızlandırıcı cihaz arasında parçalayın. 5.24 adet A4G GPU cihazına sahip olan g10xlarge'ı seçtiğimizi varsayalım. DJLServing'i (serving.properties) aşağıdaki şekilde yapılandırırsak, 80 GB model ağırlığının 4 GPU'nun tümüne eşit olarak bölünmesini bekleyebiliriz:

İle tensor_parallel_degree 4'e ayarlandığında, 20 GB GPU belleğinin yaklaşık 24 GB'ı (yaklaşık %84'ü), tek bir istek işlenmeden önce bile zaten kullanılıyor. GPU'nun kalan %16'sı gelen istekler için KV önbelleği olarak kullanılacaktır. İş senaryonuz ve gecikme ile aktarım hızı gereksinimleriniz için kalan belleğin 2-3 GB'ının fazlasıyla yeterli olması mümkündür. Değilse, örnek boyutunu 5.48 GPU'ya sahip olan ve tensor_parallel_degree'yi 8'e ayarlanmış olan g8xlarge'a yükseltebilirsiniz. Böyle bir durumda, model ağırlıkları için her GPU'nun kullanılabilir 10 GB belleğinin yalnızca yaklaşık 24 GB'ı kullanılır ve biz etkinleştirmeler ve KV önbellek için kalan GPU'nun yaklaşık %60'ına sahip olun. Sezgisel olarak, bu konfigürasyonun daha yüksek bir verime sahip olmamızı sağlayabileceğini görebiliriz. Ek olarak, artık daha geniş bir ara belleğe sahip olduğumuz için, max_rolling_batch_prefill_tokens ve max_rolling_batch_size Verimi daha da optimize etmek için parametreler. Bu iki parametre birlikte, model için etkinleştirme ön doldurmalarının ve KV önbelleğinin ön tahsislerini kontrol edecektir. Bu iki parametre için daha büyük bir sayı, GPU belleğinde KV önbelleği için yeterli ara belleğe sahip olduğunuz varsayılarak, daha büyük bir verimle ilişkili olacaktır.

PagedAttention ile sürekli toplu işlem

PagedAttention, UC Berkeley tarafından geliştirilen ve sabit boyutlu sayfalara veya bloklara bellek ayırarak dikkat önbelleğinin (KV önbelleği) bitişik olmamasına izin vererek sürekli toplu işlem sürecini geliştiren yeni bir optimizasyon algoritmasıdır. Bu, işletim sistemleri tarafından kullanılan sanal bellek ve sayfalama kavramlarından ilham almıştır.

Göre vLLM kağıtta, her bir jeton dizisinin dikkat önbelleği bloklara bölünür ve bir blok tablosu aracılığıyla fiziksel bloklarla eşlenir. Dikkatin hesaplanması sırasında PagedAttention çekirdeği, blokları fiziksel bellekten verimli bir şekilde getirmek için blok tablosunu kullanabilir. Bu, bellek israfının önemli ölçüde azalmasına neden olur ve daha büyük toplu iş boyutuna, artan GPU kullanımına ve daha yüksek üretime olanak tanır.

Performans karşılaştırması

Dağıtım yapılandırmanızın etkili yük testini sağlamak için, iş senaryosunu dikkate alarak ve LLM tabanlı uygulamanın giriş ve çıkış özelliklerini açıkça tanımlayarak başlamanız önerilir. Örneğin, bir çağrı merkezi özetleme kullanım senaryosu üzerinde çalışıyorsanız, girdi, bir müşteri hizmetleri temsilcisi ile bir müşteri arasındaki 500 jetonluk bir sohbet metni gibi daha büyük bir metinden oluşabilir, ancak çıktı, 100 jeton civarında nispeten daha küçük olabilir. transkriptin bir özetini temsil eden jetonlar. Öte yandan, bir kod oluşturma senaryosu üzerinde çalışıyorsanız, girdi 15 jeton kadar kısa olabilir, örneğin "Sayfalandırma dahil tüm EC2 kaynaklarını tanımlamak için Python'da etkili bir uygulama yazın" gibi, ancak çıktı çok daha fazla olabilir. daha büyük, 500 jetona ulaşıyor. Özel senaryonuz için en önemli önceliğin daha düşük gecikme süresi elde etmenin mi yoksa verimi en üst düzeye çıkarmanın mı olduğunu düşünmek de önemlidir.

İş senaryosunu kapsamlı bir şekilde anladıktan sonra, barındırma ortamınız için en uygun yapılandırmayı analiz edebilir ve belirleyebilirsiniz. Bu bağlamda barındırma ortamı, örnek türü ve aşağıdaki gibi diğer yapılandırma parametreleri de dahil olmak üzere çeşitli temel öğeleri kapsar. tensor_parallel_degree, max_rolling_batch_size, max_rolling_batch_prefill_tokens, ve dahası. Amacımız yanıt süresi, verim ve model çıktı kalitesi gereksinimlerimizi destekleyecek en etkili kurulumu belirlemektir.

Analizimizde, sürekli harmanlamanın geleneksel dinamik harmanlamaya göre faydalarını göstermek için performansı karşılaştırdık. SageMaker'da bir LMI kapsayıcısı kullanarak dinamik toplu işlem ve yinelemeli toplu işlem için serve.properties dosyasında aşağıdaki tabloda ayrıntılı olarak açıklanan yapılandırmaları kullandık.

Dinamik Toplu İşleme	Sürekli Gruplama	PagedAttention ile Sürekli Toplu İşleme
motor=Python option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 seçenek.dtype=fp16 toplu_boyut=4 max_batch_delay=100 option.trust_remote_code = doğru	motor = MPI option.model_id = {{s3_url}} option.trust_remote_code = doğru seçenek.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = otomatik seçenek.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Yanlış	motor = MPI option.model_id = {{s3_url}} option.trust_remote_code = doğru seçenek.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = otomatik seçenek.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Doğru

İki konfigürasyon, gerçek dünya uygulamalarını temsil eden birkaç farklı senaryoda ml.g40xlarge üzerinde konuşlandırılan FP16 veri türüyle Falcon-5.48B için karşılaştırıldı:

• Az sayıda giriş tokenı ve çok sayıda token üretiliyor – Bu senaryoda girdi token sayısı 32 olarak sabitlendi ve 128 yeni token üretildi

Harmanlama Stratejisi	Verim (jeton/sn)	Gecikme p90 (sn)
Dinamik Toplu İşleme	5.53	58.34
Sürekli Gruplama	56.04	4.74
PagedAttention ile Sürekli Toplu İşleme	59.18	4.76

• Az sayıda jetonun üretildiği büyük bir girdi – Burada, giriş tokenlarının sayısını 256 olarak sabitliyoruz ve LLM'den girişi 32 token olarak özetlemesini istiyoruz

Harmanlama Stratejisi	Verim (jeton/sn)	Gecikme p90 (sn)
Dinamik Toplu İşleme	19.96	59.31
Sürekli Gruplama	46.69	3.88
PagedAttention ile Sürekli Toplu İşleme	44.75	2.67

PagedAttention ile sürekli toplu işlemenin, LMI konteynerini kullanırken SageMaker'da dinamik toplu işleme kullanmaya kıyasla senaryo 10'de 1 kat ve senaryo 2.3'de 2 kat daha fazla verim artışı sağladığını görebiliriz.

Sonuç

Bu yazıda, LLM'lerin belleği nasıl kullandığına baktık ve SageMaker'da bir LMI konteyneri kullanarak sürekli toplu işlemin verimi nasıl iyileştirdiğini açıkladık. Karşılaştırma sonuçlarını göstererek, SageMaker'da bir LMI konteyneri kullanarak Falcon-40B için sürekli harmanlamanın faydalarını gösterdik. Kodu şurada bulabilirsiniz GitHub repo.

---

Yazarlar Hakkında

Abhi Shivaditya AWS'de Yapay Zeka, dağıtılmış bilgi işlem, ağ iletişimi ve depolama gibi alanlarda AWS hizmetlerinin benimsenmesini kolaylaştırmak için stratejik küresel kurumsal kuruluşlarla birlikte çalışan Kıdemli Çözüm Mimarıdır. Uzmanlığı, Doğal Dil İşleme (NLP) ve Bilgisayarla Görü alanlarındaki Derin Öğrenmede yatmaktadır. Abhi, müşterilerin AWS ekosisteminde yüksek performanslı makine öğrenimi modellerini verimli bir şekilde dağıtmalarına yardımcı olur.

Dhaval Patel AWS'de Baş Makine Öğrenimi Mimarıdır. Dağıtılmış bilgi işlem ve Yapay Zeka ile ilgili sorunlar üzerinde büyük kuruluşlardan orta ölçekli girişimlere kadar çeşitli kuruluşlarla çalıştı. NLP ve Computer Vision alanları dahil olmak üzere Derin öğrenmeye odaklanmaktadır. Müşterilerin SageMaker'da yüksek performanslı model çıkarımı yapmasına yardımcı olur.

Pinak Panigrahi AWS'de stratejik iş sorunlarını çözmek için makine öğrenimi odaklı çözümler geliştirmek üzere müşterilerle birlikte çalışır. Makine öğrenimi ile meşgul olmadığı zamanlarda kendisini yürüyüşe çıkarken, kitap okurken ya da spor müsabakalarını izlerken bulabilirsiniz.

Abhi Sodhani AWS'de Kıdemli Yapay Zeka/Makine Öğrenimi Çözümleri Mimarı olarak görev yapıyor ve burada müşterilere Üretken Yapay Zeka ve Makine Öğrenimi çözümleri konusunda teknik uzmanlık ve rehberlik sunma konusunda uzmanlaşıyor. Öncelikli odak noktası, Dijital Yerli İşletmelerin Üretken Yapay Zeka ve ML teknolojilerinin tüm potansiyelini gerçekleştirmelerine yardımcı olarak iş hedeflerine etkili bir şekilde ulaşmalarını sağlamaktır. Abhi, mesleki çabalarının ötesinde, okuma gibi entelektüel uğraşlara ve ayrıca yoga, meditasyon gibi fiziksel ve zihinsel sağlığı destekleyen faaliyetlere de güçlü bir tutku sergiliyor.

Qing Lan AWS'de Yazılım Geliştirme Mühendisidir. Amazon'da yüksek performanslı ML çıkarım çözümleri ve yüksek performanslı günlük kaydı sistemi dahil olmak üzere birçok zorlu ürün üzerinde çalışıyor. Qing'in ekibi, Amazon Advertising'de çok düşük gecikme süresi gerektiren ilk Milyar parametre modelini başarıyla başlattı. Qing, altyapı optimizasyonu ve Derin Öğrenme hızlandırması hakkında derinlemesine bilgi sahibidir.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• PlatoSağlık. Biyoteknoloji ve Klinik Araştırmalar Zekası. Buradan Erişin.
• Kaynak: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/