المجلد الخامس — البنية التحتية ومسرعات التعلم الآلي

عندما تبدأ رحلتك في تدريب نماذج التعلم الآلي، يصادفك أول سؤال: هل أحتاج CPU أم GPU أم شيء آخر؟ الإجابة تعتمد على طبيعة المهمة. لفهم ذلك، يجب أن نتعمق في الفروقات المعمارية بين كل معالج.

المقارنة المعمارية

🧠 CPU (Central Processing Unit)

المعالج المركزي هو العقل المدبر لأي جهاز. صُمم للعمليات المتسلسلة التي تتطلب زمن استجابة منخفضًا جدًا. يحتوي CPU على عدد قليل من النوى (cores) القوية التي تعمل بترددات عالية (3-5 GHz)، مع ذاكرة كاش ضخمة (L1/L2/L3) لتقليل زمن الوصول إلى الذاكرة. في سياق التعلم الآلي، الـ CPU مسؤول عن التحكم في تدفق البيانات، تحميل البيانات (data loading)، والتنسيق بين الأجهزة الأخرى. لكنه غير مناسب لتدريب النماذج الكبيرة بسبب محدودية التوازي.

🎮 GPU (Graphics Processing Unit)

GPU هو بطل عالم التعلم الآلي. صُمم في الأصل لرسومات الألعاب، لكن اكتُشف أن معمارية SIMT (Single Instruction Multiple Threads) مثالية لضرب المصفوفات وعمليات التعلم العميق. يحتوي GPU على آلاف النوى الصغيرة — في H100 هناك 18,432 CUDA core و576 Tensor Core. كل نوى GPU تعمل معًا على نفس العملية لكن ببيانات مختلفة (SIMD). الميزة الحقيقية هي Tensor Cores — وحدات متخصصة بضرب المصفوفات بدقة منخفضة (FP16, BF16, INT8, FP8) تؤدي عمليات بحجم 4×4 matrix multiply-add في دورة ساعة واحدة.

☁️ TPU (Tensor Processing Unit)

TPU هو ASIC (Application-Specific Integrated Circuit) — شريحة مصممة خصيصًا لمهمة واحدة: ضرب المصفوفات الضخمة. قلب TPU هو MXU (Matrix Multiply Unit)، وهو عبارة عن systolic array بأبعاد 128×128 تقوم بضرب مصفوفتين في دورة ساعة واحدة. MXU يعمل على الـ BF16 بشكل أساسي. الفرق الجوهري: GPU يجب أن يكون متعدد الاستخدامات (ألعاب + ML + render)، بينما TPU مخلص لمهمة واحدة — وهذا يجعله أكثر كفاءة في استهلاك الطاقة لكل عملية FLOP.

📱 NPU (Neural Processing Unit)

NPU هو معالج عصبي مدمج في SoC (System on Chip) للأجهزة المحمولة. أشهرها Apple Neural Engine (منذ iPhone X/A11 Bionic) و Qualcomm Hexagon. NPU مصمم لـ الاستدلال (inference) فقط — تشغيل النماذج المدربة مسبقًا على الجهاز باستهلاك طاقة ضئيل (5-15W). لا يمكن تدريب النماذج على NPU. لكن ميزته: خاص (private) — لا ترسل بيانات المستخدم للسحابة، وزمن استجابة فوري (لأنه محلي). أحدث إصدار من Qualcomm Hexagon (Snapdragon 8 Gen 3) يقدم ~45 TOPS (INT8) — وهو رقم مذهل لشريحة جوال!

الأرقام والمواصفات

GPU الحديثة هي أعجوبة هندسية. لفهمها، يجب أن نبدأ من المعمارية الأساسية لـ NVIDIA CUDA، ثم نتابع التطور عبر الأجيال: Volta → Ampere → Hopper → Blackwell.

CUDA Cores و Tensor Cores و Streaming Multiprocessors

كل GPU من NVIDIA يتكون من مجموعة من Streaming Multiprocessors (SMs). كل SM يحتوي على:

• CUDA Cores: وحدات حسابية للأعداد الصحيحة والفاصلة العائمة (FP32/INT32)
• Tensor Cores: وحدات متخصصة لضرب المصفوفات بدقة منخفضة — FP16, BF16, TF32, FP8, INT8
• Shared Memory: ذاكرة مشتركة داخل SM (تصل إلى 228KB في H100)
• Register File: 65,536+ سجل 32-bit لكل SM
• Warp Scheduler: كل 32 خيطًا (thread) تشكل warp — يقرر أي warp ينفذ بعد ذلك

🧬 كيف يعمل Warp؟

GPU ينفذ التعليمات على مجموعات من 32 thread تسمى warp. كل thread في نفس warp ينفذ نفس التعليمات لكن على بيانات مختلفة (SIMT). إذا كانت threads تحتاج مسارًا مختلفًا (if/else)، يحدث warp divergence — حيث ينفذ كلا المسارين بشكل متسلسل، مما يقلل الأداء إلى النصف. تجنب if-else في kernel functions لضمان أقصى أداء.

🔥 Tensor Cores — سلاح NVIDIA السري

Tensor Cores تؤدي عملية D = A × B + C حيث A و B مصفوفات 4×4 (FP16/BF16/INT8) والناتج FP32. في H100 مع FP8 (بفضل Transformer Engine)، الأداء يقفز إلى 4,000 TFLOPS — أي 6 أضعاف FP16 وأسرع 60 مرة من FP32!

خط GPU: من V100 (Volta) إلى B200 (Blackwell)

📅 V100 (Volta, 2017) — الثورة الأولى

أول GPU مع Tensor Cores. غيرت قواعد اللعبة تمامًا. V100 كانت أول من قدم FP16 Tensor Cores مع 125 TFLOPS. كانت بطاقة $10K أصبحت معيار الصناعة لتدريب النماذج حتى 2020. ذاكرة 32GB HBM2 بسعة 900 GB/s.

📅 A100 (Ampere, 2020) — منصة التدريب

A100 ضاعفت كل شيء: 312 TFLOPS (TF32)، 624 TFLOPS (FP16)، ذاكرة 80GB HBM2e بعرض نطاق 2,039 GB/s. قدمت Multi-Instance GPU (MIG) التي تسمح بتقسيم GPU إلى 7 أجزاء مستقلة — مثالية للسحابة لتأجير نصف GPU. AMD بدأت بالمنافسة مع MI250X لكنها بقيت بعيدة.

📅 H100 (Hopper, 2022) — وحش التدريب

H100 هي طفرة هائلة. قدمت Transformer Engine الذي يختار ديناميكيًا أفضل دقة (FP8/FP16) لكل طبقة، مما يضاعف الأداء. قدمت NVLink 4.0 بـ 900 GB/s بين GPUs. الذاكرة: 80GB HBM3 بعرض نطاق 3,350 GB/s. TDP: 700W. السعر: ~$25K-30K.

📅 B200 (Blackwell, 2024) — مستقبل التدريب

B200 تربط شريحتين (die) في حزمة واحدة عبر NVLink. هذا يعطي 80GB × 2 = 160GB HBM3e. الأداء FP8: ~9,000 TFLOPS. تقدم FP4 لأول مرة — مما يضاعف الأداء النظري أكثر. السعر المتوقع: $30K-50K. متوفرة في NVIDIA DGX B200 كـ 8 GPUs.

جدول مقارنة شامل

⚔️ المنافسون: AMD MI300X و Intel Gaudi 3

في 2015، أدركت Google أن نماذج Transformer تتطلب قوة حسابية هائلة، وأن GPUs المتاحة لم تكن مثالية لهذه المهمة. بدلاً من انتظار NVIDIA، قررت Google تصميم شريحتها الخاصة — وهكذا وُلد TPU (Tensor Processing Unit).

لماذا TPU؟ — قصة Transformer

عندما نشرت Google ورقة "Attention is All You Need" في 2017، كانت قد اختبرت بالفعل الجيل الأول من TPU داخليًا لمشاريع أخرى مثل ترجمة Google Translate. أدركت Google أن Transformer — الذي يعتمد بالكامل على ضرب المصفوفات الكبيرة — هو التطبيق المثالي لـ TPU. بينما GPUs تصمم لألعاب الفيديو حيث التنوع هو الأساس، TPU هو آلة ضرب مصفوفات خالصة. النتيجة: كفاءة أعلى بـ 2-3x لكل واط مقارنة بـ GPU لنفس المهمة.

أجيال TPU: من v1 إلى v5p

🔬 MXU (Matrix Multiply Unit) — قلب TPU

MXU هو systolic array بأبعاد 128×128 في TPU v2/v3 و 128×256 في v4. يعمل كالتالي:

1. تغذية المصفوفة A من اليسار إلى كل عمود من MXU
2. تغذية المصفوفة B من الأعلى إلى كل صف من MXU
3. كل خلية (PE — Processing Element) تحتوي على مضاعف (multiplier) + مُجمّع (accumulator)
4. النتيجة: ضرب مصفوفة 128×128 في دورة ساعة واحدة

للمقارنة: ضرب مصفوفة 128×128 على GPU يحتاج إلى العديد من التعليمات والعديد من الساعات. على MXU يكتمل في دورة ساعة واحدة لكل خطوة (حتى 128 خطوة للنتيجة الكاملة).

مقارنة: TPU vs GPU للتدريب

من يختار TPU ومن يختار GPU؟

# مثال: تدريب على TPU مع JAX
import jax
import jax.numpy as jnp
from jax.sharding import PartitionSpec, NamedSharding

# تقسيم النموذج عبر الأجهزة
mesh = jax.make_mesh((8, 4), ('data', 'model'))
sharding = NamedSharding(mesh, PartitionSpec('data', 'model'))

@jax.jit
def train_step(params, batch):
    def loss_fn(p):
        logits = model_forward(p, batch['x'])
        return jnp.mean(softmax_cross_entropy(logits, batch['y']))
    loss, grads = jax.value_and_grad(loss_fn)(params)
    params = jax.tree_map(lambda p, g: p - lr * g, params, grads)
    return loss, params

امتلاك GPU واحد هو شيء. امتلاك 10,000 GPU هو عالم مختلف تمامًا. تدريب نموذج GPT-4 (1.8T parameters) أو LLaMA 3 (405B) يتطلب بنية تحتية على مستوى مراكز البيانات. هنا تظهر التحديات الحقيقية: ربط هذه الأجهزة، تبريدها، تزويدها بالطاقة، والتعامل مع أعطالها.

ربط الأجهزة داخل العقدة وبين العقد

🔗 NVLink و NVSwitch — الربط داخل العقدة (Node)

في خادوم واحد، توضع 8 GPUs. كيف تتحدث مع بعضها؟ الجواب هو NVLink — ناقل عالي السرعة يصل كل GPU بجيرانه. في H100، NVLink 4.0 يوفر 900 GB/s (اتجاهين) لكل GPU. لكن التحدي: في 8 GPUs، ربط كل GPU مع كل GPU يحتاج إلى 56 وصلة! هنا يأتي NVSwitch — وهو عبارة عن محول (switch) يسمح لأي GPU بالتحدث مع أي GPU آخر بأقصى سرعة. في DGX H100، يوجد 4 × NVSwitch تربط 8 GPUs ببعضها بشبكة كاملة (full bisection bandwidth).

🌐 InfiniBand — ربط العقد (Nodes)

عندما يكون لديك 1,000+ GPU عبر مئات الخوادم، لا يمكن الاعتماد على NVLink (يعمل داخل العقدة فقط). هنا يأتي دور InfiniBand — البروتوكول القياسي لربط العقد في HPC والتعلم الآلي. سرعة NDR InfiniBand: 400-800 Gbps لكل منفذ. في كلاستر كبير (~16,000 GPU)، تُستخدم طوبولوجيا Fat Tree أو Dragonfly+ لتقليل زمن الوصول وزيادة عرض النطاق.

🌐 Ethernet: RoCEv2

بديل InfiniBand هو RoCE (RDMA over Converged Ethernet) — بروتوكول يسمح بـ RDMA (Remote Direct Memory Access) على شبكات Ethernet العادية. أرخص من InfiniBand، لكن أداء أقل بنسبة ~10-20%. مناسب للشركات التي تمتلك بنية تحتية Ethernet ولا تريد الاستثمار في InfiniBand.

التبريد والطاقة

🔥 استهلاك الطاقة — الأرقام المرعبة

كل H100 GPU تستهلك 700W. في خادوم DGX H100 ب 8 GPUs: 8 × 700W + CPUs + ذاكرة + fans = ~7kW لكل خادوم. كلاستر بـ 30,000 GPU يستهلك ~30-35MW مستمرة. لنحسب التكلفة السنوية:

❄️ التبريد: هواء vs ماء

30-40kW لكل رف (rack) مع 4 خوادم. هذا يعني أن كل رف يولّد حرارة تعادل 30-40 مدفأة كهربائية تعمل بكامل طاقتها! تبريد الهواء التقليدي لا يكفي فوق 20kW/rack. الحل: التبريد السائل (Liquid Cooling).

☠️ فشل الأجهزة — حقيقة مرعبة

في كلاستر بـ 1,000 GPU، تتوقع 1-2 GPU تفشل يوميًا. ليس كل GPU — لكن في كلاستر بـ 10,000 GPU، تتوقع 10-20 فشلًا في الأسبوع. لهذا:

• Checkpointing إلزامي: حفظ checkpoint كل 1-2 ساعة. خسارة 4 ساعات تدريب على 30,000 GPU = خسارة $30,000+ في طاقة ضائعة.
• Elastic Training: يجب أن يستمر التدريب حتى عند فشل GPU. DeepSpeed, PyTorch FSDP, و Slurm تدعم هذا.
• Hot-swappable: الخوادم يجب أن تسمح بتغيير GPU دون إيقاف التشغيل.

# مثال: تقرير صحة GPU باستخدام nvidia-smi (تشغيل دوري كل 5 دقائق)
watch -n 300 nvidia-smi --query-gpu=index,name,temperature.gpu,utilization.gpu,power.draw --format=csv

# مثال: مراقبة درجة حرارة GPU والتنبيه
while true; do
  TEMP=$(nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader)
  if [ "$TEMP" -gt 85 ]; then
    echo "ALERT: GPU temperature $TEMP°C exceeds 85°C threshold!"
    # إرسال تنبيه (PagerDuty, Slack, Telegram)
  fi
  sleep 60
done

واحد من أكثر القرارات صعوبة في أي مشروع تعلم آلي: هل أستأجر GPU من السحابة أم أشتري الخوادم وأديرها بنفسي؟ الإجابة تعتمد على: حجم التشغيل، مدة التشغيل، نموذج العمل، وفريقك.

أسعار GPU في السحابة

لاحظ الفرق الصارخ بين RunPod ($1.19) و AWS ($3.20) لنفس GPU A100! نفس العتاد، نفس RAM، نفس الأداء — لكن السعر يختلف 3x بسبب الخدمات الإضافية (IAM, VPC, ELB, دعم فني, وفواتير معقدة). منصات مثل RunPod و Lambda تقدم GPU بأسعار تنافسية جدًا، لكن بخدمات أقل. CoreWeave تقدم أفضل توازن بين السعر والأداء.

التكلفة المحلية (On-Premise)

💰 تفصيل تكلفة خادوم 8×H100

📊 مقارنة: سحابة vs محلي — متى تختار ماذا؟

📐 معادلة القرار: Cloud vs On-Prem

🏢 Hybrid — الأفضل للشركات المتوسطة

الواقع أن معظم الشركات تختار حلًا هجينًا:

• Own cluster للتدريب الأساسي (أقل تكلفة على المدى الطويل)
• Cloud burst عندما تحتاج طاقة إضافية فجأة (مثلاً تدريب نموذج كبير)
• Cloud للـ inference المتغير — حيث يتوسع الطلب وينخفض

بعد أن حصلت على GPU القوية وأسلاك InfiniBand، تحتاج البرمجيات التي تجعل كل هذه الأجهزة تعمل معًا كفريق واحد. هذه الطبقة من البرمجيات هي ما يسمى Middleware للتدريب الموزع — وهي المسؤولة عن توزيع البيانات، مزامنة التدرجات (gradients)، والتواصل بين GPUs.

مكتبات الاتصال بين GPUs

📡 NCCL — نبض نظام الاتصال

NVIDIA NCCL (NVIDIA Collective Communications Library) هو قلب كل تدريب موزع. هو ليس شيئًا تستخدمه مباشرة — بل كل المكتبات الأخرى (PyTorch DDP, DeepSpeed, Megatron-LM) تبني فوقه. NCCL يوفر عمليات اتصال جماعية (collective operations):

• AllReduce — جمع التدرجات من كل GPUs وتوزيع المجموع (الأكثر استخدامًا)
• AllGather — جمع البيانات الموزعة على كل GPUs
• ReduceScatter — تقليل ثم توزيع — أساسي لـ ZeRO و FSDP
• Broadcast — إرسال بيانات من GPU واحد للكل

🚀 DeepSpeed — Microsoft ZeRO, MoE, Flash Attention

DeepSpeed من Microsoft هي أشهر مكتبة للتدريب الموزع على نطاق واسع. أبرز ميزاتها:

• ZeRO (Zero Redundancy Optimizer): يقسم حالة المحسن (optimizer states)، التدرجات، والأوزان بين GPUs — بدلاً من تخزين نسخة كاملة على كل GPU. يوفر 8x ذاكرة!
  • ZeRO-1: تقسيم optimizer states فقط — يوفر 4x ذاكرة
  • ZeRO-2: تقسيم التدرجات أيضًا — يوفر 8x ذاكرة
  • ZeRO-3: تقسيم الأوزان أيضًا — يمكن تدريب نماذج أكبر من ذاكرة GPU الواحد
• ZeRO-Offload: ينقل جزءًا من الذاكرة إلى CPU RAM — لنماذج ضخمة على GPU محدود
• MoE (Mixture of Experts): تدريب نماذج بـ 1T+ parameters باستخدام خبراء متفرقين
• Flash Attention kernel fusion: دمج عمليات الانتباه لتقليل زمن الوصول

# DeepSpeed ZeRO-3 — تدريب نموذج 70B على 8 GPU
import deepspeed

ds_config = {
    "train_batch_size": 256,
    "gradient_accumulation_steps": 4,
    "zero_optimization": {
        "stage": 3,                     # ZeRO-3
        "offload_param": {
            "device": "cpu"             # وزع الأوزان على CPU إذا كانت 80GB غير كافية
        },
        "offload_optimizer": {
            "device": "cpu"
        }
    },
    "fp16": {
        "enabled": True,
        "auto_cast": True
    },
    "flops_profiler": {
        "enabled": True
    }
}

model_engine, optimizer, trainloader, _ = deepspeed.initialize(
    model=model,
    model_parameters=model.parameters(),
    config=ds_config
)

📐 Megatron-LM — 3D Parallelism من NVIDIA

Megatron-LM يوفر ثلاثة أنواع من التوازي:

1. Tensor Parallelism (TP): يقسم طبقة Transformer الواحدة عبر GPUs
   كل GPU يحسب جزءًا من الانتباه أو MLP. يتطلب اتصالًا سريعًا (NVLink داخل العقدة).
2. Pipeline Parallelism (PP): يقسم طبقات النموذج عبر GPUs
   GPU 1: layers 1-10, GPU 2: layers 11-20, إلخ. يقلل زمن الانتظار بين GPUs.
3. Data Parallelism (DP): نسخ النموذج على كل GPU مع بيانات مختلفة
   التقليدي — كل GPU لديه نسخة كاملة من النموذج لكن بيانات مختلفة.

المزيج 3D Parallelism يوزع TP داخل العقدة (NVLink)، PP بين مجموعات (InfiniBand)، وDP بين كل شيء. هذا ما استخدمته NVIDIA لتدريب GPT-3 و Megatron-Turing NLG.

🔄 PyTorch FSDP — سهولة ZeRO

PyTorch FSDP (Fully Sharded Data Parallelism) هو تطبيق ZeRO-3 داخل PyTorch الأصلي. أسهل استخدامًا من DeepSpeed ZeRO لكن بنفس المبدأ:

from torch.distributed.fsdp import (
    FullyShardedDataParallel as FSDP,
    MixedPrecision,
    ShardingStrategy,
)

torch.cuda.set_device(rank)
model = FSDP(
    model,
    sharding_strategy=ShardingStrategy.FULL_SHARD,  # ZeRO-3
    mixed_precision=MixedPrecision(
        param_dtype=torch.bfloat16,
        reduce_dtype=torch.bfloat16,
        buffer_dtype=torch.bfloat16
    ),
    device_id=rank,
)

🌐 Horovod — البديل المفتوح المصدر

طورته Uber في 2017 كبديل مفتوح المصدر لـ NCCL. يستخدم Ring AllReduce بشكل أصل. ورغم أن PyTorch DDP و DeepSpeed أصبحا أكثر شيوعًا، Horovod لا يزال مستخدمًا في بعض الشركات لأنه يعمل مع أي إطار (TensorFlow, PyTorch, MXNet).

إدارة الكلاستر — Kubernetes, Ray, SLURM, والحاويات

# مثال: إرسال مهمة تدريب على SLURM مع 8 GPU
#!/bin/bash
#SBATCH --job-name=train-llama
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=8
#SBATCH --gres=gpu:8
#SBATCH --time=48:00:00
#SBATCH --output=/checkpoint/jobs/%j.log

export MASTER_ADDR=$(scontrol show hostnames $SLURM_JOB_NODELIST | head -n 1)
export MASTER_PORT=29500

srun torchrun \
    --nnodes=$SLURM_NNODES \
    --nproc_per_node=8 \
    --rdzv_id=$SLURM_JOB_ID \
    --rdzv_backend=c10d \
    --rdzv_endpoint=$MASTER_ADDR:$MASTER_PORT \
    train.py --config configs/llama-70b.yaml

قانون مور يتباطأ، لكن الطلب على قدرة الحوسبة للتعلم الآلي ينمو بمعدل 4x سنويًا. هذه الفجوة تدفع الابتكار في عدة اتجاهات ثورية.

🔦 الحوسبة الضوئية (Optical Computing / Photonics)

شركات مثل Lightmatter و Lightelligence تطور شرائح تستخدم الضوء بدلاً من الكهرباء لإجراء العمليات الحسابية. الفكرة الأساسية: ضرب المصفوفات يمكن تنفيذه بسرعة الضوء عبر Mach-Zehnder interferometers التي تعمل بتداخل الموجات الضوئية. المزايا المتوقعة:

• سرعة هائلة: النتائج تنتقل بسرعة الضوء — زمن استجابة <1 ns
• استهلاك طاقة أقل: 10-100x أقل من الإلكترونيات التقليدية لكل عملية
• توازي طبيعي: أطوال موجية مختلفة (WDM) يمكنها حمل عمليات مختلفة

التحدي: لا تزال هذه التكنولوجيا في مرحلة البحث والتطوير — Lightmatter's Envise متاح حاليًا لكن بكميات محدودة جدًا.

🔮 Analog AI Chips — Mythic, IBM

بدلاً من العمليات الرقمية (0 و 1)، تستخدم Analog AI التيار والجهد لإجراء العمليات الحسابية. المفهوم الأساسي هو Computing-in-Memory (CiM) أو Processing-in-Memory (PIM): بدلاً من نقل البيانات بين الذاكرة والمعالج (Von Neumann bottleneck)، تجري العمليات الحسابية داخل خلايا الذاكرة نفسها عبر RRAM (Resistive RAM).

ميزتها: ضرب مصفوفات كامل داخل مصفوفة الذاكرة دون أي نقل بيانات خارجي. هذا يقلل استهلاك الطاقة 100x مقارنة بـ GPU. تحدياتها: الدقة محدودة (حاليًا INT4-INT8)، والأخطاء التناظرية (noise) تحتاج تعويضًا.

🔳 Cerebras Wafer-Scale Engine (WSE-3)

Cerebras تفعل شيئًا جنونيًا: بدلاً من تقطيع رقاقة السيليكون (wafer) إلى شرائح صغيرة (dies)، تترك الرقاقة كاملة — بحجم طبق بيتزا — وتصنع منها معالجًا واحدًا عملاقًا. WSE-3 يحتوي على:

ميزة WSE-3: كل النوى على شريحة واحدة — لا حاجة لـ NVLink أو InfiniBand للتواصل داخل المعالج. عيبه: التبريد صعب جدًا (TDP ~15kW لشريحة واحدة!)، والتكلفة هائلة.

⚡ Groq LPU — Language Processing Unit

Groq (تأسست من مهندسين سابقين في Google TPU team) تبني LPU (Language Processing Unit). فلسفتها: بدلاً من تسريع ضرب المصفوفات (TPU) أو التوازي العام (GPU)، تركز LPU على تقليل زمن الاستجابة (latency) للـ LLM inference.

تستخدم LPU معمارية Temporal Processor — حيث تكون البيانات محلية دائمًا ولا تتنقل بين الذاكرة والمعالج. النتيجة: أسرع LLM inference في العالم — Llama 2 70B يشتغل بسرعة 1,200 tokens/second على LPU (مقابل ~200 tokens/s على H100). لكن: البرمجة عليها تحتاج SDK خاص (لا CUDA ولا PyTorch مباشر).

🏭 عمليات التصنيع: 3nm, 2nm ومستقبل الترانزستورات

TSMC و Samsung يتسابقان نحو عقد أصغر:

🧩 ASICs المخصصة — كل شركة تبني شريحتها الخاصة

بعد نجاح Google TPU، كل شركة كبرى تبني شريحتها الخاصة:

🪐 Quantum ML — البدايات فقط

الحوسبة الكمومية للتعلم الآلي ما زالت في مراحلها المبكرة جدًا. الشركات مثل IBM و Google (Sycamore/Willow) تحاول استخدام الكيوبتات (qubits) لتحسين بعض خوارزميات ML مثل SVM و K-Means. لكن التحديات هائلة:

• الكيوبتات حساسة جدًا للضوضاء — تحتاج تبريدًا إلى 15 millikelvin
• عدد الكيوبتات محدود (<1,000 qubit مفيدة حاليًا مقابل ملايين المطلوبة)
• تصحيح الأخطاء الكمومية (error correction) يأكل معظم الكيوبتات