Türkçe altyazı Turkish subtitles
0:00 Bugünkü en büyük yapay zeka modelleri bir trilyondan fazla parametreye sahip olabilir ve bunları saklamak yaklaşık iki terabaytlık bellek gerektirir. Ancak piyasadaki en büyük GPU yaklaşık 288 GB bellek içerir ki bu, bu devasa sınır modellerini saklamak için kesinlikle yeterli değildir. The largest AI models today can have over a trillion parameters, which would take something like two terabytes of memory to store. But the largest GPU on the market holds about 288GB, which is nowhere near enough to store these huge frontier models. 0:18 Peki, milyonlarca insanın güvenilir şekilde kullandığı sohbet robotlarının arkasındaki bu modelleri nasıl çalıştırıyoruz? Gerçek şu ki, her gün konuştuğunuz yapay zeka modellerini barındıran tek bir süper bilgisayar yok. Bunlar, onlarca, bazen yüzlerce GPU'dan oluşan koordineli bir sistem üzerinde çalışıyor. So how are we running these models behind the chatbots everyone uses reliably for millions of people? The truth is, there is no single mega computer hosting the AI models you talk to every day. They're running on a coordinated system of dozens, sometimes hundreds of GPUs. 0:37 Modellerin saklanması, çalıştırılması ve üretim ortamında gerçek kullanıcı trafiğini desteklemesi gerekiyor. Bu sürecin tamamını tek bir GPU'ya sınırlamak, sisteminize hızla gerçek kısıtlamalar, darboğazlar ve gecikme ekler. Bu yüzden dağıtık çıkarım ile bunu düzeltelim. Dağıtık çıkarım, hesaplama yükünü birbirine bağlı birden fazla cihaz veya sunucu arasında bölerek bir yapay zeka modelini çalıştırma sürecidir. Models need to be stored, run and support real user traffic in production. Confining this whole process to one GPU quickly introduces real constraints, bottlenecks and latency to your system. So let's fix this with distributed inference. The process of running an AI model by 0:54 Bir model, "ağırlıkları" veya modelin bilgisini saklayan katmanlardan oluşur. Bir modeli çalıştırmak için tüm ağırlıkların başlangıçta bellekte saklanması gerekir. Bunun üzerine, model çalıştıkça, önceki konuşulanları hatırlamasına izin veren ek bilgiler birikir. splitting the computational load across multiple interconnected devices or servers. A model is composed of layers, all storing "weights", or the knowledge of the model. To run a model, all the weights need to be initially stored in memory. On top of that, as the model runs, it accrues 1:13 Buna çalışma belleği diyoruz. Bu bağlamı, yani KV önbelleğini, modelin kendisinin yanı sıra bellekte tutarız. Son olarak, her istek bir GPU üzerinden geçmek için belirli bir süre alır. what we call working memory. Additional information about the conversation that allows it to remember what was previously said. This context, which we call the KV cache, is held in memory as well on top of the model itself. And lastly, every request takes a set amount of time to move 1:30 Aynı anda çok fazla istek gelirse, bunlar bir kuyrukta birikir ve her kullanıcı yanıt için daha uzun süre bekler. Bunu gerçek kullanıcılar için barındırıyorsak, aynı anda modele ulaşmaya çalışan yüzlerce veya binlerce insan olabilir. Bu nedenle, through a GPU. If there are too many requests coming in at once, they get backed up in a queue and every user waits longer for a response. If we're hosting this for real users, we might have hundreds or thousands of people trying to reach the model at once. So we need to be able to 1:47 birçok kullanıcıya eş zamanlı hizmet verebilmemiz gerekir. Bir modeli üretim ortamında sunmak, bu üç kısıtlamayı aynı anda çözmek demektir. Model bellek ayak izi, yani ağırlıkların donanıma fiziksel olarak sığıp sığmadığı; KV önbelleği büyümesi, yani hizmet verirken sürekli artan içerik; ve istek concurrently serve many users. Serving a model in production means solving these three constraints at the same time. Model memory footprint. Whether the weights physically fit on the hardware, you have, KV cache growth, the content that keeps growing while you're serving and requests 2:04 geçirgenliği, yani kaç eş zamanlı kullanıcıya hizmet verebileceğiniz. O halde küçük başlayalım. Diyelim ki modelimiz ve KV önbelleği tek bir GPU'ya rahatça sığıyor, ancak hepsine aynı anda hizmet verecek kadar çok kullanıcı var. Yapabileceğimiz şey, modelin tamamını birden fazla GPU'ya kopyalamak ve ardından throughput, how many concurrent users you can serve. So let's start small. Let's say our model and its KV cache fits fine on one GPU, but we still have too many users to serve them all at once. What we can do is copy the entire model onto multiple GPUs, and then route 2:23 istekleri, her GPU'nun şu anki yük durumu veya hangi replikanın zaten ilgili önbellek bağlamına sahip olduğu gibi kriterlere göre akıllıca yönlendirmektir. Buna veri paralelliği denir. Her replika, modelin tam ve özdeş bir kopyasıdır. Aralarında koordinasyona gerek yoktur. Sadece request to them intelligently based on things like how loaded each GPU currently is, or which replica already has relevant cached context. This is data parallelism. Every replica is a full identical copy of the model. There's no coordination needed between them. You're just 2:40 her isteğin hangi kapıdan geçeceğini belirliyorsunuz. Ancak gerçekçi olmak gerekirse, en akıllı modellerin çoğu tek bir GPU'ya sığamaz. Bir modelin aslında bireysel bilgiyi tutan bir dizi katman olduğunu hatırlayın. Çıkarımı çalıştırmak, girdinizi bu katmanlardan tek tek geçirmek demektir, tıpkı deciding which door each request walks through. But realistically, many of the smartest models can't fit on a single GPU. Recall that a model is really just a series of layers holding individual knowledge. Running inference means passing your input through these layers one at a time, kind of 2:58 bir montaj hattı gibi. Bu yüzden tüm modelimiz sığmayacak kadar büyükse, modeli katmanlara göre bölebilir veya parçalayabiliriz. Diyelim ki birinci ve ikinci katmanlar ilk GPU'da, üçüncü ve dördüncü katmanlar like an assembly line. So if our whole model is too big to fit, we can split or shard the model by layers. Say layers one and two live on the first GPU, layers three and four live 3:12 ikinci GPU'da ve böylece devam eder. Gerçek modeller çok daha fazla katmana sahip olacaktır, ama fikri anlıyorsunuz. Buna boru hattı paralelliği denir. Her GPU, belleğine rahatça sığabilen modelin yalnızca belirli katmanlarını tutar. on the second and so on. Real models will have a lot more layers, but you guys get the idea. This is pipeline parallelism. Every GPU holds only certain layers of the model that can comfortably fit in 3:25 Şimdi, aynı anda yalnızca bir istek gönderirsek, GPU'ların çoğu sırasını beklerken boşta kalır. Boru hattı paralelliğinden tam olarak yararlanmak için, montaj hattını düşünün. İsteklerin sürekli akmasını sağlayın, böylece her istasyon öncekini beklemek yerine meşgul kalsın. its memory. Now, if we send only one request through at a time, most of the GPUs sit idle, waiting for their turn to take full advantage of pipeline parallelism. Think assembly line. Keep requests continuously flowing through so every station stays busy instead of waiting on the one 3:42 Modeli dikey olarak böldük. Şimdi yatay olarak bölme durumuna bakalım. Tensör paralelliği, modeli katmanlara bölmek yerine her bir katmanın kendisini böler. Her GPU, aynı katmanın bir dilimini alır, katmanın matematiğinin kendi parçasını hesaplar ve ardından before it. We split the model vertically Now let's look at splitting it horizontally. Tensor parallelism divides each individual layer itself rather than dividing the model by layers. Every GPU gets a slice of the same layer, computes its piece of the layer's math, and then communicates 4:00 kısmi sonuçları birleştirmek için diğerleriyle iletişim kurar. Bu süreci her tekil katman için tekrarlarlar. Bu birleştirme adımı kolektif operasyon olarak adlandırılır ve her katman için engellenir, çünkü GPU'lar hesaplama sırasında sürekli iletişim halinde olmak zorundadır. Bu yalnızca with the others to combine their partial results back together. They then repeat that process for every single layer. That combining step is called a collective operation and its blocking for each layer because the GPUs have to constantly communicate mid computation. This only works when 4:19 yüksek bant genişliğine ve düşük gecikme süresine sahip bir GPU bağlantısıyla bağlı olduklarında çalışır, tipik olarak aynı sunucunun içinde bulunurlar. Bu trafiği daha yavaş bir ağ üzerinden göndermek, optimizasyon olmak yerine bizi darboğaza dönüştürebilir. Ayrıca daha uzmanlaşmış bir durum vardır, bir model türü olan they're connected by a high bandwidth, low latency GPU interconnect, typically sitting inside the same server. Sending that chatter across a slower network could actually cause us to become a bottleneck rather than an optimization. There's also a more specialized case, a type of model 4:38 uzman karışımı veya MoE modeli. Bu model, her girdi için çalışan tek bir ağırlık bloğu tutmak yerine, yanıt üretiminin farklı kısımlarında uzmanlaşmak üzere tasarlanmış daha küçük alt ağlara veya uzmanlara sahiptir. Biri called a mixture of experts or MoE model. This model, instead of holding one block of weights that runs for every single input, holds smaller subnetworks or experts that are meant to specialize in different parts of response generation. One could lean 4:56 kod örneklerine, diğeri noktalama işaretlerine, belki biri de sayılara eğilebilir, çünkü çok sayıda alt ağ bir arada toplanmıştır. MoE modelleri genellikle genel olarak devasa boyutlardadır. towards code samples. One could do punctuation. Maybe one does numbers because you've got so many subnetworks bundled together. MoE models tend to be humongous overall. 5:09 Uzman paralelliği bu uzmanları GPU'lar arasında dağıtır, böylece her biri tüm modelin kopyası yerine uzmanların bir dilimini tutar. Her MoE katmanında, her token yönlendiricinin seçtiği az sayıdaki Expert parallelism spreads those experts across GPUs, so they each hold a slice of experts instead of a copy of the entire model. At every MoE layer, each token gets dispatched to the handful 5:23 uzmana yönlendirilir. Modern modeller 256 uzmandan yaklaşık sekizini seçer ve ardından hepsi geri birleştirilir. Bu, token başına çok daha az hesaplama anlamına gelir, ancak bunun bedeli of experts its router picked. Modern models will pick about eight experts out of 256, and then it'll all be combined back. This means far less computation per token, but paid for 5:37 Bireysel tokenlerin dağıtılması ve ardından bilgilerin birleştirilmesi sırasında oluşan bu yoğun GPU-GPU ağ trafiğinde. Son bir optimizasyona bakalım: Önyükleme ve çözüm ayrıştırması. Çıkarım sırasında iki ana aşamadan geçersiniz: Önyükleme in all this GPU to GPU network traffic of dispatching the individual tokens and then combining the information afterward. Let's look at one last optimization. Prefilled decode disaggregation. During inference, you'll go through two main stages. Prefill 5:56 ve çözüm. Önyükleme, modelin girdinizi okuyup anladığı aşamadır. Sabit bir model ağırlığı seti üzerinde çalışır ve and decode. And Prefill is where the model reads and understands your input. It operates on a fixed set of model weights and 6:10 aynı anda çok fazla paralel hesaplama gerektirir. Hesaplama sınırlıdır, yani bu adımın hızı, o matematiği ne kadar hızlı yapabildiğine bağlıdır. Bu adım, işlediği her token için KV önbelleğini, yani çalışma requires a lot of parallel computations at once. Its compute-bound, meaning the speed of this step is determined by how fast it can perform that math. This step builds the KV cache, our bank 6:23 belleğimiz bankasını oluşturur. Çözüm ise modelin kullanıcıya yanıtını oluşturduğu aşamadır. Yanıtı token token üretir ve her adımda of working memory with each token it processes. Decode is where the model builds its response to the user. It generates a reply one token at a time, and it has to 6:37 tüm KV önbelleğini çekmek zorundadır. Model ağırlıklarının aksine KV önbelleği sabit değildir, bu nedenle bellek talebi çözümün her adımıyla birlikte artar. Çözüm, bellek bant genişliği sınırlıdır, pull the entire KV cache for every step. Unlike these models weights, the KV cache is not fixed, so the demand for memory grows with every step of decode. Decode is memory-bandwidth-bound, 6:50 yani hızı, verinin bellekten ne kadar hızlı aktarılabildiğine bağlıdır. Eğer aynı konumda ise, çözüm aşamasının artan bellek talebi, bu KV önbelleği büyüdükçe önyükleme aşamasının alanını yemeye başlar. Çünkü bu iki aşama donanımın tamamen farklı meaning its speed is determined by how fast the data can be transferred from the memory. If co-located the decode phase's, increasing demand for memory can start to eat into the prefilled stage's territory as this KV cache grows. Because these two phases stress completely different 7:07 kısımlarına baskı yapar, bu yüzden onları kendi darboğazları için ayrı ayrı optimize edilmiş kendi GPU havuzlarına ayırmak aslında daha verimlidir. Bununla birlikte, bu ayrımın kârlı olması, bu devralışın kendisinin süper hızlı olmasına bağlıdır. Tüm KV önbelleğinin parts of the hardware, it's actually more efficient to split them onto their own separate pools of GPUs, each one individually optimized for its own bottleneck. That said, this split only pays off if this handoff itself is super fast. The whole KV cache has to 7:25 önyükleme havuzundan çözüm havuzuna taşınması gerekir. Yani iki havuz arasındaki bağlantı çok yavaşsa, az önce kazandığınız zamanı harcarsınız. Pratikte bu, iki havuzun, hesaplama move from the prefill pool to the decode pool. So if the connection between the two pools is too slow, you'll burn through the time you just saved. In practice, that means the two pools need to sit on dedicated, low latency networking designed for high throughput data movement between compute 7:42 düğümleri arasında yüksek veri taşıma için tasarlanmış, özel ve düşük gecikmeli ağ altyapısında bulunması gerektiği anlamına gelir, sadece standart bir ağ bağlantısı değil. Standart Ethernet üzerinde düz TCP genellikle bu ayrımı değerli kılmak için yeterince hızlı değildir, bu yüzden trafik daha fazla replika ile çözülür. Aşırı model, ağırlıkların katman, tensör veya uzman bazında bölünmesiyle çözülür ve aşırı büyüyen bellek nodes, not just a regular network link. Plain TCP over standard Ethernet usually isn't fast enough to make this split worth it, so traffic gets solved with more replicas. Too much model gets solved by splitting the weights by layer, by tensor, or by expert and too much growing memory 8:00 iki farklı türde iş görmesiyle çözülür, her aşamaya kendi özel donanım havuzu verilir. Üretimde, gerçek dağıtımlar birden fazla tekniği aynı anda katmanlar. Bir sunucu içinde tensör paralelliği. Sunucular arasında boru hattı paralelliği. Replikalar arasında veri paralelliği. doing two different kinds of work gets solved by giving each phase its own dedicated pool of hardware. In production, real deployments layer multiple techniques together at once. Tensor parallelism within a server. Pipeline parallelism across servers. Data parallelism across replicas. 8:19 Uzman karışımı modeller için uzman paralelliği ve ayrıştırma, sunum hattını aşamaya göre bölme. Buna çok boyutlu paralellik denir. Ve tüm bunların üzerinde bir orkestrasyon katmanı oturur. Her isteği doğru GPU havuzuna yönlendirme. Yükü Expert parallelism for mixture of expert models and disaggregation, splitting the serving pipeline by phase. This is called multi-dimensional parallelism. And on top of it all sits an orchestration layer. Routing every request to the right pool of GPUs. Balancing 8:38 dengeleme ve istekleri düşürmeden donanım arızalarını yönetme. Bu süper karmaşık bir konu, bu yüzden takip sorularınızı yorumlara bırakın veya dağıtık çıkarımla model dağıtımlarınızı nasıl optimize ettiğinizi bana bildirin. load and handling hardware failures without dropping requests. This is a super complex topic, so drop any follow up questions in the comments or let me know how you're optimizing your model deployments with distributed inference. Altyazı bilgisayarımda üretildi ve videoyla ilerler; bir satıra tıklayın, o ana atlasın. Subtitles generated on my computer; they follow the video — click a line to jump there.
Milyarlarca parametreye sahip büyük dil modellerinin (LLM) tek bir GPU'da çalıştırılamaması nedeniyle, çıkarım iş yükü dağıtık sistemler üzerinden birden fazla cihaz arasında paylaştırılarak verimli hale getiriliyor. Because large language models (LLMs) with billions of parameters cannot be run on a single GPU, inference workloads are distributed across multiple devices via distributed systems to be made efficient.
Bu video youtube.com üzerinde yayımlandı; buradaki oynatıcı YouTube’undur. Türkçe özet ve altyazı AiPulse için hazırlanmıştır. This video is published on youtube.com ; the player here is YouTube’s. The Turkish summary and subtitles are prepared for AiPulse .
YouTube’da izle Watch on YouTube AI Kritik → AI Critique →