Multi-GPU Parallelism Techniques

CTO @ Invergent | Frontier AI Development | AI & Tech Solutions

Most people hitting GPU limits are solving the wrong problem. They scale compute. The real issue is they picked the wrong parallelism strategy — and there isn't just one. After building the multi-GPU layer in Surogate, I've come to the conclusion that in production you need all four combined. Each has a different failure mode. DP (Data Parallelism) is the default. You replicate the model on every GPU, each gets a different data shard, gradients are averaged via AllReduce. Clean, works — until your model no longer fits on a single device. On large transformers, AllReduce becomes the bottleneck, not compute. FSDP fixes this by sharding optimizer states, gradients, and parameters across GPUs — materializing them only during the compute step. TP (Tensor Parallelism) slices individual weight matrices — each GPU holds a horizontal shard of a layer and communicates mid-forward-pass via AllReduce. You can fit enormous layers, but TP requires NVLink: the latency is too tight for cross-node setups. In practice, TP degree is bounded by your intra-node GPU count (8 on a DGX). Beyond that, it hurts. PP (Pipeline Parallelism) splits the model by depth — GPU 0 runs layers 1–8, GPU 1 runs 9–16, micro-batches flow through like an assembly line. The fundamental problem is pipeline bubbles: at the start and end of each batch, GPUs sit idle. The 1F1B schedule reduces the overhead, but bubble fraction is (p-1)/(m+p-1) — you want m >> p. PP also complicates checkpoint recomputation across stage boundaries. EP (Expert Parallelism) is for MoE architectures. Each GPU holds a subset of experts, the router sends each token to top-k experts via All-to-All. The problem: load balancing. If the router consistently sends tokens to the same experts, some GPUs are overloaded, others idle. Auxiliary loss terms push the router toward uniform dispatch — a soft constraint, not a guarantee. This is why MoE is so efficient per FLOP: you scale the number of experts without scaling compute per token. In practice, a large-scale run looks like: TP=8 intra-node, PP=4 inter-node, DP=N across pipeline replicas, EP=8 across expert groups. 4D parallelism. The engineering challenge isn't understanding each strategy in isolation — it's orchestrating the communication patterns so they don't interfere, and configuring the cluster so bandwidth matches the parallelism topology. In Surogate we built this on Ray: you configure declaratively, the runtime manages process groups, and you actually hit near-SOL throughput instead of spending weeks tuning NCCL environment variables. (The diagram below maps the communication pattern for each technique.)

AI Infra Strategy & Solutions | Founder, AI_Infrastructure_Media | Building Meaningful Connections | **Love is my religion** |

As models grow in size and datasets expand into terabytes and beyond, training can no longer rely on a single machine. Modern AI requires distributing computation across multiple GPUs and servers, coordinating memory, data flow, and synchronization in real time. This is where distributed training becomes foundational - enabling teams to train larger models faster, efficiently utilize hardware, manage communication overhead, and maintain model consistency across thousands of parallel workers. Here are the 10 core concepts behind distributed training, covering everything from parallel execution strategies to synchronization, fault tolerance, and elastic scaling in production environments: 1. Data Parallelism Run the same model on multiple GPUs with different data batches, then synchronize gradients each step. 2. Model Parallelism Split a large model across GPUs by layers or tensors to enable training models that do not fit on a single device. 3. Pipeline Parallelism Divide the model into stages and execute them sequentially across GPUs to improve utilization for very large architectures. 4. Mixture of Experts (MoE) Activate only parts of the model per input, enabling massive parameter scaling while reducing compute per token. 5. Gradient Synchronization Aggregate gradients across workers to keep replicas aligned — often the primary driver of network traffic and training speed. 6. Parameter Servers Centralized or sharded services that manage model parameters, simplifying coordination but potentially becoming bottlenecks at scale. 7. Ring AllReduce Peer-to-peer gradient exchange without a central server, commonly used for high-bandwidth GPU communication. 8. Batch Size Scaling Increase batch sizes as GPU count grows to maintain efficiency, while carefully tuning learning rates to preserve convergence. 9. Checkpoint Sharding Distribute checkpoints across nodes instead of writing a single massive file, improving recovery speed and reducing storage pressure. 10. Elastic Training Dynamically adjust worker counts during training to handle failures and enable flexible cluster scaling. The takeaway: Distributed training is not just about adding more GPUs. It is about coordinating compute, communication, storage, and fault tolerance as a single system. When done well, it enables faster training, larger models, higher hardware utilization, and production-ready reliability. Without it, scaling AI quickly becomes a bottleneck.

Distinguished Chief Architect, Red Hat CTO Office | Previously at Google, Verizon and Canonical-Ubuntu

 📖 "The Ultra-Scale Playbook" by 🤗 Hugging Face Team 👏 👏 👏 >> The Challenge: How do you train massive LLMs (7B-405B parameters) efficiently across 100s of GPUs when a single model doesn't even fit in memory? >> The Research: 4,100+ distributed experiments on up to 512 H100 GPUs, testing every possible configuration to find what actually works. >> Key Insights: * 5D Parallelism Framework: Data, Tensor, Pipeline, Sequence, and Expert parallelism - each solving different bottlenecks. * Memory > Compute: Your first bottleneck is always memory (70B model needs 1.4TB!), not FLOPS. (That very very true! As things do not necessary get broken being slow but having lack of memory). * 10x Speed Difference: Intra-node (NVLink) vs inter-node communication drives architecture decisions. * ZeRO-2 Sweet Spot: Best memory/communication tradeoff for most scenarios. * Flash Attention Revolution: 72% memory reduction, 1.5x speedup - now standard in all transformers. >> Practical Takeaway: No silver bullet exists. Optimal configuration depends on model size, cluster topology, and batch size targets. The playbook provides the decision tree: * > Why This Matters: Previously, this knowledge was locked within OpenAI, Google, and Meta. Now it's open source with working code (Nanotron framework). The democratization of large-scale AI training knowledge continues. #AI #MachineLearning #DistributedComputing #LLM #Engineering #HuggingFace Ref: https://lnkd.in/gmtv5vrP

The largest AI Community 14 Million Members | Advisor @ Fortune 500 | Keynote Speaker

🚀 DeepSeek Just Dropped 3 Powerful Open-Source Releases – Here’s Why They Matter They’re rewriting the rulebook on efficient LLM training and deployment. Today, they open-sourced three incredibly small (yet powerful) repositories, each addressing a key bottleneck in large-scale AI infrastructure.👇 1️⃣ Profiling Data for AI Training Efficiency On the surface, this might not seem groundbreaking, but this dataset is a goldmine. It provides a real-world breakdown of how DeepSeek keeps GPUs fully utilized during training and inference, ensuring that every single compute cycle contributes to efficiency. ✅ Optimized scheduling = faster, cheaper AI training ✅ Helps teams visualize GPU workload distribution (viewable in Chrome tracing tools) ✅ A rare, transparent look into state-of-the-art AI scaling techniques I wish more open-source teams would release this kind of data, because training efficiency is the #1 challenge at massive scales. 2️⃣ Load Balancing for Mixture of Experts (MoE) Mixture of Experts (MoE) is a major reason why AI models can scale efficiently, but there’s always been one major problem: some GPUs get overloaded while others sit idle. DeepSeek’s Expert Parallelism Load Balancer (EPLB) solves this by: ✅ Duplicating and redistributing heavyloaded experts across GPUs ✅ Minimizing internode traffic, reducing delays ✅ Ensuring balanced workloads, preventing bottlenecks This is huge! MoE models are notoriously tricky to optimize, and this tool simplifies deployment for anyone working with expert-based architectures. If you’re serious about scaling efficient MoE models, this is an absolute must-try. 3️⃣ The Game-Changer: DualPipe – Zero-Bubble Parallelism 🔥 This is THE most exciting part of today’s release. Pipeline Parallelism (PP) is used to split LLM training across GPUs, but it comes with inefficiencies—idle time (bubbles) between forward and backward passes. DualPipe eliminates these bubbles, achieving a “zero-bubble regime” for the first time ever in large-scale AI training. 💡 Why this is huge? - Full computation-communication overlap (no wasted cycles) - Reduces training time and cost significantly - First-of-its-kind implementation, never reported before in SOTA training If you work with distributed AI training, this could dramatically improve efficiency and lower costs across the board. Final Thoughts DeepSeek is doing open-source right. Instead of just releasing models, they’re sharing the critical tools and techniques that power SOTA AI training. - GPU efficiency matters, profiling data like this is rare and invaluable. - Mixture of Experts isn’t magic, it needs proper balancing. EPLB makes it easy. - Zero-bubble training is a reality. DualPipe might become the new standard! How do you see AI training evolving? links in the comments.

Founder & CEO, Fast Code AI | Research-grade AI for enterprises with hard problems | Dad

𝗘𝘅𝗽𝗹𝗮𝗶𝗻 𝗧𝗵𝗶𝘀: 𝗟𝗹𝗮𝗺𝗮 𝟯 𝗡𝗲𝗲𝗱𝘀 𝟮.𝟰𝗧𝗕. 𝗬𝗼𝘂𝗿 𝗚𝗣𝗨 𝗛𝗮𝘀 𝟴𝟬𝗚𝗕. 𝗜𝘁 𝗦𝘁𝗶𝗹𝗹 𝗧𝗿𝗮𝗶𝗻𝘀. Training Llama-3 405B needs ~2.4TB with BF16 + 8-bit Adam: • Weights: 810GB • Gradients: 810GB • Optimizer: 810GB (vs 3.24TB with standard Adam!) • Total: ~2.4TB (Illustrative budget—config-dependent; FP32 masters, ZeRO stage, and offload change totals) Your H100? 80GB. You'd need 30+ GPUs just to hold everything. 𝗧𝗵𝗿𝗲𝗲 𝗧𝗿𝗶𝗰𝗸𝘀 𝗧𝗵𝗮𝘁 𝗠𝗮𝗸𝗲 𝗜𝘁 𝗪𝗼𝗿𝗸 𝟭. 𝗗𝗮𝘁𝗮 𝗣𝗮𝗿𝗮𝗹𝗹𝗲𝗹: Split batch. Problem: Each GPU needs 2.4TB. Fix: ZeRO splits it across N GPUs. 𝟮. 𝗠𝗼𝗱𝗲𝗹 𝗣𝗮𝗿𝗮𝗹𝗹𝗲𝗹: Split layers. Problem: Sequential bottleneck. Fix: Pipeline batches. 𝟯. 𝗦𝗲𝗾𝘂𝗲𝗻𝗰𝗲 𝗣𝗮𝗿𝗮𝗹𝗹𝗲𝗹: Split tokens. This is the game changer. 8K tokens → 8 GPUs → 1K each. But attention needs every token to see all others. 𝗧𝗵𝗲 𝗠𝗮𝗴𝗶𝗰 𝗠𝗼𝗺𝗲𝗻𝘁: Instead of moving the 2.4TB model, GPUs only exchange attention keys/values (K,V). Each GPU: • Computes K,V for its 1K tokens (32MB) • Sends to others via all-to-all • Receives 7×32MB = 224MB total • Computes attention, deletes copies 𝟮𝟮𝟰𝗠𝗕 𝗺𝗼𝘃𝗲𝗱 𝗶𝗻𝘀𝘁𝗲𝗮𝗱 𝗼𝗳 𝟮.𝟰𝗧𝗕. That's 10,000x less. 𝗧𝗵𝗲 𝗥𝗲𝘀𝘂𝗹𝘁: Combine all three (ZeRO + tensor + pipeline + sequence parallel). Each GPU holds ~75GB instead of 2.4TB. This exact choreography powers ChatGPT, Claude, and every frontier model. Without it? 10K token limits. With it? Entire books in one context. Not magic. Just brilliant engineering making the impossible routine.

ML @ Zomato

“Just rent a GPU for training” Until you need: - Multi-node training for 70B+ models - $5/hour per GPU (not $30/hour) - 90%+ GPU utilization Then you build your own ml infra. Here’s the reality: Most ML engineers think training infrastructure = - Rent some A100s - Install PyTorch - Run training script - Scale with more GPUs The pain starts around 8 GPUs. Remember: You’re not training ONE model on ONE GPU. You’re orchestrating DOZENS of experiments across hundreds of GPUs with checkpointing, fault tolerance, and resource sharing. That’s a scheduling problem, not a training problem. What you actually need: > Job scheduler that understands GPU topology > Distributed checkpoint manager that doesn’t waste bandwidth > Network fabric optimized for all-reduce > Elastic training that handles node failures This is the actual platform. Your training cost breakdown at scale: > Compute: $10/GPU-hour (you pay $30 on cloud) > Data transfer: $2/TB (kills you with large datasets) > Storage: $0.02/GB-month (checkpoints add up fast) > Network: Included (but becomes bottleneck) The hidden cost? Idle GPU time while debugging. The first principle of distributed training: Bandwidth >> Compute for models over 10B params Ring all-reduce needs 2(N-1)/N bandwidth efficiency. With 64 GPUs on 3.2 Tbps InfiniBand, you max out at 200GB/sec actual throughput. This is why “just add more GPUs” plateaus. Training Llama 70B: - 140GB model weights - Optimizer states: 280GB - Checkpoints every 1K steps - 30 checkpoints = 12.6TB One training run = $250 in storage. You run 50 experiments/month. “We need to train 10 models simultaneously with different hyperparameters” Now your platform needs: > Gang scheduling for multi-GPU jobs > Spot instance preemption handling > Shared dataset caching across jobs > Priority queues with fairness 90% of DIY platforms can’t do this. > Use cloud when you’re training Build your own when you train 20+ models/month, need 70B+ params, want #ml #gpu #llm #infra #cloud #nvidia #inference #aws #cloud #ai

Senior HPC & AI Infrastructure Engineer | Disaggregated LLM Inference | 10,000+ GPU Scale | Building Europe’s First Sovereign Industrial AI Cloud

One of the clearest visuals I have seen of the GPU↔GPU data path across nodes. Every box on it is also a place the transfer can quietly degrade by 10–100× without throwing an error. Stage 1 — GPU memory ↔ NIC, same node. The red "Host Memory" arrow is the default: the DMA engine bounces through pinned host memory, crossing PCIe twice and touching DRAM once before reaching the NIC. To skip it you need `gdrcopy` — kernel module (`gdrdrv`) and userspace library (`libgdrapi`), major-minor versions matched. Mismatch and `gdr_open()` silently fails; the transport falls back to the red path with no louder signal than a single WARN. Stage 2 — NIC ↔ NIC, across the fabric. With `nvidia_peermem` loaded, the NIC registers the GPU buffer as peer memory and pushes VRAM→VRAM over RDMA with zero host staging. To make it fast you need an RDMA-capable fabric (InfiniBand or RoCE), peer-memory support on the NIC driver, and a transport (UCX, NCCL, libfabric) built with `--with-gdrcopy` and `--with-verbs` so it picks the `rc_mlx5` device-verbs path, not a host-copy fallback. Multiple NICs? The transport needs to know about them (e.g. `UCX_NET_DEVICES`) to stripe across rails in parallel. Stage 3 — everything else (PCIe and host staging). Anywhere the bulk path touches the PCIe root-complex beyond what is needed, or host DRAM, you have lost. Levers: pin GPU + NIC to the same PCIe switch (peer-to-peer, no root hop); use NVLink instead of PCIe for intra-node GPU↔GPU (900+ GB/s vs ~64); on Grace Hopper / Grace Blackwell, NVLink-C2C replaces the PCIe CPU↔GPU link with a coherent ~900 GB/s path — "host staging" is no longer a cliff on those SKUs; let the transport pick `cuda_ipc` for same-node GPU↔GPU so the copy never leaves the device fabric. The short version: for every arrow, ask "is this going through a fast path, or did it silently fall back?" There are only a few fast paths, and each one has a small set of things that must all be true at once. Miss one and the transfer still works — at 1% of what the hardware can do. #GPUInfrastructure #RDMA #NVLink #HPC #AIInfrastructure

🚀 𝗜𝗻𝘀𝗶𝗱𝗲 vLLM: 𝘄𝗵𝗮𝘁 𝗺𝗮𝗸𝗲𝘀 𝗶𝘁 𝗼𝗻𝗲 𝗼𝗳 𝘁𝗵𝗲 𝗯𝗲𝘀𝘁 𝗳𝗼𝗿 𝗟𝗟𝗠 𝘀𝗲𝗿𝘃𝗶𝗻𝗴 vLLM Is my favorite inference engine for self-hosting LLMs. It feels snappier because its design keeps GPUs busy and memory tidy. Here are the parts that matter when you’re shipping real apps. 🔩 𝗖𝗼𝗿𝗲 𝗲𝗻𝗴𝗶𝗻𝗲 𝗶𝗱𝗲𝗮𝘀  • 𝗣𝗮𝗴𝗲𝗱𝗔𝘁𝘁𝗲𝗻𝘁𝗶𝗼𝗻 treats the KV cache like virtual memory: fixed-size pages that can be allocated, compacted, and reused—less copying/fragmentation and higher GPU utilization under bursty traffic.  • 𝗖𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝗯𝗮𝘁𝗰𝗵𝗶𝗻𝗴 admits new requests at token boundaries so GPUs don’t idle for the slowest prompt; throughput rises without hurting p50/p95 latency.  • 𝗣𝗿𝗲𝗳𝗶𝘅 𝗰𝗮𝗰𝗵𝗶𝗻𝗴 shares overlapping headers (system prompts, RAG/tool preambles) to cut repeat compute and speed time-to-first-token.  • 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗲𝗱 𝗸𝗲𝗿𝗻𝗲𝗹𝘀 & graphs reduce launch overhead; prefill/decode paths are tuned for chats and long contexts. 𝗦𝗰𝗮𝗹𝗶𝗻𝗴 𝗲𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻  • Tensor & pipeline parallelism split weights/layers across GPUs so larger models fit and tokens stay in lockstep.  • Multi-node scheduling preserves batching/paging across machines—scale out without giving up efficiency.  • One-model-per-process keeps blast radius small; run many vLLM servers and route via a gateway. 🧰 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿-𝗳𝗿𝗶𝗲𝗻𝗱𝗹𝘆 𝘀𝗲𝗿𝘃𝗶𝗻𝗴  • 𝗢𝗽𝗲𝗻𝗔𝗜-𝘀𝘁𝘆𝗹𝗲 𝗲𝗻𝗱𝗽𝗼𝗶𝗻𝘁𝘀 (chat/completions/embeddings) ease migrations.  • 𝗤𝘂𝗮𝗻𝘁𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗯𝘂𝗳𝗳𝗲𝘁 (INT8/INT4, GPTQ/AWQ/AutoRound, FP8) trades tiny quality for big cost/latency wins.  • 𝗖𝗿𝗼𝘀𝘀-𝘃𝗲𝗻𝗱𝗼𝗿 𝗯𝗮𝗰𝗸𝗲𝗻𝗱𝘀 keep options open across accelerators and clouds.  • Streaming first with SSE for faster perceived latency. 💡 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀  • Lower $/token via better GPU saturation.  • Tighter tail latency keeps SLOs green.  • Operational simplicity—paging, caching, batching reduce custom CUDA and brittle schedulers. ⚙️ 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹 𝘁𝗶𝗽𝘀 • Keep prompts DRY so prefix caching hits often. • Use shorter max_tokens + streaming; request more if needed. • Right-size KV blocks and batch sizes to traffic shape. • Measure prefill vs decode throughput; long contexts are often prefill-bound. 🧪 𝗪𝗵𝗲𝗿𝗲 𝘃𝗟𝗟𝗠 𝘀𝗵𝗶𝗻𝗲𝘀 • Agent platforms with many short turns. • RAG APIs with shared system prompts. • Consumer chat with unpredictable spikes. • Enterprise multi-tenant backends needing strong isolation. 🔮 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆 vLLM’s speed comes from the combo of paged KV memory, continuous batching, smart caching, and lean kernels—turning GPUs into well-fed token factories with speed, cost control, and predictability. Aleksa Gordić’s deep-dive blog is the clearest explanation of the vLLM engine I’ve seen 👉 https://lnkd.in/gRgiC_45  🔗 #vLLM #LLM #SelfHosting #AIInfrastructure #Inference #GPU #CUDA #SystemsDesign #AIAgents #Latency #Throughput #Quantization #KVCache #PagedAttention

Senior Data Scientist | Agentic AI | ML, NLP & LLM Expert | AI Content Creator | 10K+ Followers

🚨 Top 4 Strategies for Multi-GPU Training🚨 When deep learning models continue to scale especially in LLMs and multimodal systems then single-GPU training quickly becomes a bottleneck due to memory limits and compute constraints. Multi-GPU training solves this by distributing model parameters, tensors, or data across multiple GPUs, enabling faster training and supporting models that otherwise wouldn’t fit into memory. 1️⃣ Model Parallelism Different layers (or blocks) of a neural network are placed on different GPUs. How it works: • GPU-1 processes early layers • GPU-2 processes deeper layers • Activations are passed between GPUs during forward and backward passes Strengths • Useful when the model itself is too large for a single GPU • Straightforward for sequential architectures Limitations • High inter-GPU communication overhead • GPUs may stay idle if layers are imbalanced Failure Case • Poor performance when layers have uneven compute loads, causing pipeline stalls. 2️⃣ Tensor Parallelism Instead of splitting layers, tensor operations (matrix multiplications) are split across GPUs. How it works: • Each GPU computes a shard of the same layer • Results are aggregated via communication Strengths • Efficient for very large dense layers • Widely used in large language model training Limitations • Heavy communication cost • Requires specialized implementation Failure Case • Network bandwidth becomes the bottleneck rather than compute. 3️⃣ Data Parallelism The model is replicated across GPUs, and each GPU processes a different subset of data. How it works: • Each GPU computes gradients locally • Gradients are synchronized across GPUs Strengths • Easy to implement • Scales well for most training pipelines Limitations • Model must fit into a single GPU • Gradient synchronization overhead Failure Case • Large batch sizes may reduce model generalization. 4️⃣ Pipeline Parallelism A hybrid approach where layers are split across GPUs and data is processed in micro-batches like an assembly pipeline. How it works: • GPU-1 processes batch-A layer-1 • GPU-2 simultaneously processes batch-B layer-1 or batch-A layer-2 Strengths • Improves GPU utilization • Enables training extremely large models Limitations • Pipeline bubbles • Complex scheduling Failure Case • Inefficient when micro-batch tuning is poor or interconnect latency is high. 💡 Thr Key Insights Production LLM systems typically combine data + tensor + pipeline parallelism to balance memory, compute, and communication. Found this helpful? Spread the knowledge 👍 React ♻️ Share 💬 Comment #ai #multigpu #deeplearning #aigents #rag #llm #distributedtraining #generativeai #agenticai #aiarchitecture #mlsystems #machinelearning #datascience #promptengineering

Member of Technical Staff @ Fastino Labs

Mixing parallelism strategies is often necessary for training massive models. But can be a nightmare to implement. TorchTitan wants to make this easier. TorchTitan is a minimal, clean-room implementation of PyTorch native scaling techniques that provides a flexible foundation for developers to build upon. Compared to writing pipelines entirely from scratch, TorchTitan requires minimal changes to your model code when applying multi-dimensional parallelism. It’s best features include: ⚡ Multi-dimensional Parallelism → including FSDP2, Tensor Parallel, Pipeline Parallel, and Context Parallel 🔥 Built on top of PyTorch and integrates with existing tools like torch.compile ☑️ Meta device initialization allows models to be loaded efficiently and selective and full activation checkpointing 8️⃣ Float8 support for massive memory savings and faster training speeds 🐛 Profiling tools help identify bugs and performance issues (like high CPU/GPU usage and excessive memory usage) TorchTitan is built for training MASSIVE models, and reports performance on up to 512 GPUs. It also includes several example scripts clearly showing how your parallelism techniques are applied. I learned about TorchTitan yesterday during Wanchao L.’s guest lecture in Scratch to Scale. Highly recommend checking it out if you’re interested in apply or learning more about multi-dimensional parallelism techniques! 🔗 GitHub: https://lnkd.in/gTeStKw7 📄 arXiv paper: https://lnkd.in/gyUmyYhF 📺 PyTorch Conference talk: https://lnkd.in/gNp_3RFr 👩💻 Fine-tune Llama-3.1 8b tutorial ([AMD]): https://lnkd.in/g6RWnzyc 🍎 Scratch to Scale: https://lnkd.in/gKKuzaaH