Lecture 01 · Introduction
المحاضرة 01 · المقدمة
Generative models and LLMs outgrow memory
النماذج التوليدية وLLMs تتجاوز سعة الذاكرة
P3 SKIMFive case studies with one recipe: find the block that dominates the cost and attack only that block. Then one conversion you must be able to do in your sleep: parameters to bytes to GPUs.
خمس دراسات حالة بوصفة واحدة: ابحث عن الجزء الذي يهيمن على التكلفة وهاجمه وحده. ثم تحويل واحد يجب أن تتقنه تماماً: من عدد المعاملات إلى البايتات إلى عدد وحدات GPU.
The arithmetic on these slides is the exam material: bytes = params × bits / 8, GPUs = ceil(bytes / GPU memory), fps to frame time, and a speedup compared against a MAC ratio. The one concept to state in words: generative compute follows tokens × steps, not parameters.
الحسابات في هذه الشرائح هي مادة الامتحان: bytes = params × bits / 8، وGPUs = ceil(bytes / GPU memory)، وتحويل fps إلى زمن الإطار، ومقارنة speedup بنسبة MACs. والمفهوم الوحيد الذي يُطلب بالكلمات: حساب النماذج التوليدية يتبع tokens × steps لا عدد المعاملات.
Segment Anything, slides 9 and 10
Segment Anything، الشريحتان 9 و10
SAM is a promptable segmenter: give it a point, box or phrase and it returns the mask of the object. It has three blocks. The image encoder (ViT-H, 641M parameters, 2973 GMACs) runs once per image and dominates the cost. The prompt encoder and the lightweight mask decoder together run in about 50 ms on a browser CPU, once per prompt.
SAM نموذج تجزئة قابل للتوجيه (promptable): أعطه نقطة أو مربعاً أو عبارة فيُرجع قناع الجسم المقصود. يتكون من ثلاثة أجزاء. image encoder (ViT-H، 641M معامل، 2973 GMACs) يعمل مرة واحدة لكل صورة ويهيمن على التكلفة. أما prompt encoder وmask decoder الخفيف فيعملان معاً في نحو 50 ms على معالج متصفح، مرة لكل توجيه.
EfficientViT-SAM keeps SAM's prompt encoder and mask decoder and replaces only the image encoder with EfficientViT (distilled from SAM's ViT-H, then trained end to end on SA-1B). The headline model, EfficientViT-SAM-L2, runs 538 images/s versus 11 for SAM-ViT-H on an A100 with TensorRT: 538 / 11 = 48.9x, at 46.6 versus 46.5 zero-shot COCO mAP. Zero-shot means the models were never trained on COCO.
EfficientViT-SAM يُبقي prompt encoder وmask decoder كما هما، ويستبدل image encoder فقط بـ EfficientViT (مُقطَّر من ViT-H ثم مُدرَّب بالكامل على SA-1B). النموذج الرئيسي EfficientViT-SAM-L2 يعالج 538 صورة في الثانية مقابل 11 لـ SAM-ViT-H على A100 مع TensorRT: 538 / 11 = 48.9x، بدقة 46.6 مقابل 46.5 zero-shot COCO mAP. وzero-shot تعني أن النماذج لم تُدرَّب على COCO أصلاً.
MAC ratio versus measured speedup for SAM-ViT-H to L2:
نسبة MACs مقابل التسريع المقاس من SAM-ViT-H إلى L2:
encoder MACs: 2973 G / 69 G ≈ 43.1x fewer throughput: 538 / 11 ≈ 48.9x more images per second accuracy: 46.6 vs 46.5 mAP (equal)
MACs predict the direction of a speedup, not its exact size: memory access and kernel quality change the real number.
MACs تتنبأ باتجاه التسريع لا بحجمه الدقيق: أنماط الوصول للذاكرة وجودة kernels تغيّر الرقم الحقيقي.
Diffusion: training bill and inference cost, slides 11 and 12
الانتشار (Diffusion): فاتورة التدريب وتكلفة الاستدلال، الشريحتان 11 و12
Slide 11: training Stable Diffusion used 256 A100s, about 150,000 GPU-hours, about $600,000.
الشريحة 11: تدريب Stable Diffusion استخدم 256 وحدة A100 لنحو 150,000 ساعة GPU وبتكلفة نحو $600,000.
150,000 GPU-hours / 256 GPUs ≈ 586 h ≈ 24 days of wall clock $600,000 / 150,000 GPU-hours = $4 per A100-hour
الحساب أعلاه: 150,000 / 256 ≈ 586 ساعة، أي نحو 24 يوماً من الزمن الفعلي، والسعر الضمني $4 لكل ساعة A100.
Slide 12 compares MACs for one pass on a log axis. The surprise is that the ordering does not follow parameters.
تقارن الشريحة 12 عدد MACs لتمرير واحد على محور لوغاريتمي. المفاجأة أن الترتيب لا يتبع عدد المعاملات.
| Modelالنموذج | Paramsالمعاملات | Workloadحمل العمل | MACs | Ratioالنسبة |
|---|---|---|---|---|
| ViT-H | 0.6B | 518×518 imageصورة 518×518 | 1.02T | 1x |
| Llama 3 | 8B | 1024 context, 512 outputسياق 1024، ومخرجات 512 | 11.2T | 11x ViT-H |
| FLUX.1 | 12B | 1K×1K image, single stepصورة 1K×1K، خطوة واحدة | 37.2T | 3.3x Llama 3, 36x ViT-H |
| CogVideoX | 5.6B | 480×720, 49 frames, single step480×720، 49 إطاراً، خطوة واحدة | 332T | 8.9x FLUX.1 |
لاحظ في الجدول أن CogVideoX بـ 5.6B معامل يحتاج إلى 332T MACs في الخطوة الواحدة، أي 8.9x ما يحتاجه FLUX.1 بـ 12B معامل (37.2T). نصف المعاملات وتسعة أضعاف الحساب، لأن الفيديو يعالج عدداً أكبر بكثير من tokens في كل خطوة.
The rule: compute is roughly parameters × tokens for the linear layers, plus an attention term that grows with tokens squared, and a diffusion model repeats the whole pass once per denoising step.
القاعدة: الحساب يساوي تقريباً parameters × tokens للطبقات الخطية، زائد حد attention ينمو مع مربع عدد tokens، ونموذج diffusion يكرر التمرير كاملاً مرة لكل خطوة denoising.
الصيغة: MACs لكل تمرير تساوي تقريباً عدد المعاملات في عدد tokens، زائد ثابت في مربع عدد tokens في البُعد d، ثم تُضرب في عدد الخطوات في نماذج diffusion.
The right half of slide 12 holds FLUX.1 fixed and grows the side from 1024 to 4096. Pixels (and tokens) grow 4² = 16x, but MACs grow from about 37T to about 1950T, roughly 52x. That is super-quadratic in side length: the linear part grows 16x, the attention part 16² = 256x, and the blend lands near 52x.
النصف الأيمن من الشريحة 12 يثبّت FLUX.1 ويكبّر الضلع من 1024 إلى 4096. البكسلات (وعدد tokens) تنمو 4² = 16x، لكن MACs تنمو من نحو 37T إلى نحو 1950T، أي تقريباً 52x. هذا نمو أسرع من التربيعي (super-quadratic) في طول الضلع: الجزء الخطي ينمو 16x، وجزء attention ينمو 16² = 256x، والمزيج يستقر قرب 52x.
DistriFusion, slide 13
DistriFusion، الشريحة 13
SDXL at high resolution takes 12.3 s on one GPU (907T MACs). Cutting the image into 4 independent patches on 4 GPUs is 3.9x faster (190T MACs per device, 3.14 s) but produces duplicated subjects: four ships, because no patch sees the others. DistriFusion lets each patch attend to its neighbours' activations from the previous denoising step (consecutive steps are similar), keeping the full computation: 227T per device (4.0x less), 4.16 s (3.0x faster), no artifacts.
نموذج SDXL بدقة عالية يستغرق 12.3 s على GPU واحدة (907T MACs). تقسيم الصورة إلى 4 أجزاء مستقلة على 4 وحدات أسرع بـ 3.9x (190T MACs لكل جهاز، 3.14 s) لكنه ينتج أجساماً مكررة: أربع سفن، لأن أي جزء لا يرى الأجزاء الأخرى. أما DistriFusion فيسمح لكل جزء بالانتباه إلى activations جيرانه من خطوة denoising السابقة (الخطوات المتتالية متشابهة)، مع الحفاظ على الحساب كاملاً: 227T لكل جهاز (أقل بـ 4.0x)، و4.16 s (أسرع بـ 3.0x)، بلا تشوهات.
Why 4.0x less work but only 3.0x faster:
لماذا عمل أقل بـ 4.0x لكن تسريع 3.0x فقط:
naive: 190 T × 4 = 760 T < 907 T (cross-patch attention skipped) DistriFusion: 227 T × 4 = 908 T ≈ 907 T (full work, split four ways) latency: 12.3 / 4.16 ≈ 3.0x parallel efficiency 3.0 / 4 = 75%
The missing 25% is communication between GPUs and the synchronous warm-up steps.
الـ 25% المفقودة هي تكلفة الاتصال بين وحدات GPU وخطوات الإحماء المتزامنة (warm-up).
Fast-LiDARNet, slide 14
Fast-LiDARNet، الشريحة 14
Convert every frame rate to a frame time: t = 1000 ms / fps. A 30 fps budget is 33.3 ms per frame. MinkowskiNet at 5 fps is 200 ms. Optimised sparse kernels (a systems lever, 3.6x) reach 18 fps = 55.6 ms, still 22 ms over. A hardware-aware model redesign (an algorithm lever, 2.6x) reaches 47 fps = 21.3 ms, inside the budget. 3.6 × 2.6 ≈ 9.4 = 47 / 5. Neither lever alone crosses the line: this is algorithm and system co-design.
حوّل كل معدل إطارات إلى زمن إطار: t = 1000 ms / fps. ميزانية 30 fps تعني 33.3 ms لكل إطار. MinkowskiNet بمعدل 5 fps يحتاج 200 ms. تحسين sparse kernels (رافعة أنظمة، 3.6x) يصل إلى 18 fps = 55.6 ms، أي ما زال متجاوزاً بـ 22 ms. وإعادة تصميم النموذج مع مراعاة العتاد (رافعة خوارزمية، 2.6x) تصل إلى 47 fps = 21.3 ms، داخل الميزانية. 3.6 × 2.6 ≈ 9.4 = 47 / 5. لا تعبر أي رافعة وحدها الخط: هذا هو التصميم المشترك للخوارزمية والنظام (co-design).
LLMs outgrow GPU memory, slides 15 and 16
نماذج LLMs تتجاوز ذاكرة GPU، الشريحتان 15 و16
Slide 15 plots model size and GPU memory on one axis by assuming FP16 data (2 bytes per parameter), so 16 GB is drawn as 8B parameters and 80 GB as 40B. Model size went from 0.05B (Transformer, 2017) to 530B (MT-NLG), about 10,000x, while GPU memory went from 16 GB to 80 GB, 5x.
ترسم الشريحة 15 حجم النموذج وذاكرة GPU على محور واحد بافتراض بيانات FP16 (2 بايت لكل معامل)، فتُرسم 16 GB على أنها 8B معامل، و80 GB على أنها 40B. حجم النماذج ارتفع من 0.05B (Transformer، 2017) إلى 530B (MT-NLG)، أي نحو 10,000x، بينما ارتفعت ذاكرة GPU من 16 GB إلى 80 GB، أي 5x فقط.
الصيغة: بايتات الأوزان = عدد المعاملات × عدد البتات / 8، وعدد وحدات GPU = تقريب للأعلى لقسمة بايتات الأوزان على ذاكرة الوحدة الواحدة.
Slide 16 gives three reasons to run LLMs at the edge anyway: local copilot services on laptops, cars and robots; resource-constrained, low-power devices that are not always connected; and privacy of user data.
تعطي الشريحة 16 ثلاثة أسباب لتشغيل LLMs على الأطراف رغم ذلك: خدمات copilot محلية على الحواسيب والسيارات والروبوتات، وأجهزة محدودة الموارد منخفضة الطاقة ليست متصلة دائماً، وخصوصية بيانات المستخدم.
A parameter is not a byte. bytes = params × bits / 8, and FP16 is 16 / 8 = 2 bytes. So 530B FP16 parameters are 1,060 GB, not 530 GB (530 GB is the INT8 answer). Then divide by device memory and round up: 13.25 becomes 14 GPUs, not 13. Say "for weights alone", because activations and the KV cache come on top. Second trap: parameters do not set compute. CogVideoX has fewer parameters than FLUX.1 and 8.9x the MACs per step.
المعامل ليس بايتاً. bytes = params × bits / 8، وFP16 تساوي 16 / 8 = 2 بايت. إذن 530B معامل بصيغة FP16 تساوي 1,060 GB لا 530 GB (فـ 530 GB هي إجابة INT8). ثم اقسم على ذاكرة الجهاز وقرّب للأعلى: 13.25 تصبح 14 وحدة لا 13. وقل "للأوزان فقط"، لأن activations وKV cache تأتي فوق ذلك. والفخ الثاني: المعاملات لا تحدد الحساب. CogVideoX له معاملات أقل من FLUX.1 ويحتاج 8.9x من MACs في الخطوة.
"Params set the memory bill, tokens set the compute bill." And for precision: 32, 16, 8, 4 bits is 4, 2, 1, 0.5 bytes.
"المعاملات تحدد فاتورة الذاكرة، وtokens تحدد فاتورة الحساب." وللدقة: 32, 16, 8, 4 بت تساوي 4, 2, 1, 0.5 بايت.
Check yourself
اختبر نفسك
A 530B-parameter model is stored in FP16. How many A100 80 GB GPUs are needed just to hold the weights?
نموذج بـ 530B معامل مخزّن بصيغة FP16. كم وحدة A100 80 GB نحتاج فقط لاستيعاب الأوزان؟
C. 530 × 10⁹ × 2 B = 1,060 GB; 1,060 / 80 = 13.25, rounded up to 14. B forgets to round up. A treats FP16 as 1 byte (the INT8 answer). D treats it as 4 bytes (the FP32 answer).
الجواب C. 530 × 10⁹ × 2 B = 1,060 GB، و1,060 / 80 = 13.25 تُقرَّب للأعلى إلى 14. الخيار B ينسى التقريب للأعلى. والخيار A يعامل FP16 كأنها بايت واحد (إجابة INT8). والخيار D يعاملها كأربعة بايتات (إجابة FP32).
Why does one CogVideoX step (5.6B params) cost about 8.9x the MACs of one FLUX.1 step (12B params)?
لماذا تكلف خطوة واحدة من CogVideoX (5.6B معامل) نحو 8.9x من MACs خطوة واحدة من FLUX.1 (12B معامل)؟
B. A video latent stacks many frames of tokens, roughly four times FLUX.1's token count, and the attention term grows quadratically. C is wrong because the slide compares a single step for both. Precision (D) changes bytes, not MAC count.
الجواب B. الـ latent في الفيديو يكدّس إطارات كثيرة من tokens، أي نحو أربعة أضعاف عدد tokens في FLUX.1، وحد attention ينمو تربيعياً. والخيار C خاطئ لأن الشريحة تقارن خطوة واحدة للاثنين. والدقة الرقمية (D) تغير البايتات لا عدد MACs.
DistriFusion on 4 GPUs cuts MACs per device 4.0x but latency only 3.0x. What explains the gap?
DistriFusion على 4 وحدات GPU يخفض MACs لكل جهاز بـ 4.0x لكن زمن الاستجابة بـ 3.0x فقط. ما الذي يفسر الفرق؟
A. The full 907T is kept (227T × 4 ≈ 908T) and split, but patches exchange activations, giving 75% parallel efficiency. B and C describe the naive split, which skips cross-patch attention (190T × 4 = 760T) and produces duplicated subjects.
الجواب A. الحساب الكامل 907T محفوظ (227T × 4 ≈ 908T) ومقسّم، لكن الأجزاء تتبادل activations، فتصبح الكفاءة المتوازية 75%. والخياران B وC يصفان التقسيم الساذج، الذي يتجاهل attention بين الأجزاء (190T × 4 = 760T) وينتج أجساماً مكررة.
Optimised kernels take MinkowskiNet from 5 fps to 18 fps. Why is that still not real time on slide 14?
تحسين kernels يرفع MinkowskiNet من 5 fps إلى 18 fps. لماذا لا يزال ذلك غير كافٍ للزمن الحقيقي في الشريحة 14؟
D. 1000 / 18 = 55.6 ms against 1000 / 30 = 33.3 ms. Only the redesigned Fast-LiDARNet at 47 fps (21.3 ms) fits. C has the comparison backwards.
الجواب D. 1000 / 18 = 55.6 ms مقابل 1000 / 30 = 33.3 ms. وحده Fast-LiDARNet المعاد تصميمه بمعدل 47 fps (21.3 ms) يدخل في الميزانية. والخيار C يعكس المقارنة.
What does EfficientViT-SAM change in SAM to reach 48.9x throughput at equal mAP?
ما الذي يغيّره EfficientViT-SAM في SAM للوصول إلى 48.9x في الإنتاجية بدقة mAP متساوية؟
B. The image encoder runs once per image at 2973 GMACs and dominates. The prompt encoder and decoder are already about 50 ms on a CPU, so speeding them up would buy almost nothing.
الجواب B. image encoder يعمل مرة لكل صورة بـ 2973 GMACs ويهيمن على التكلفة. أما prompt encoder وdecoder فيستغرقان أصلاً نحو 50 ms على المعالج، فتسريعهما لا يكاد يفيد شيئاً.