GPU, mixed precision আর গতি — device, AMP আর profiling

মডিউল ২-এর আগের পর্বগুলোতে পর্ব ০৭-এ tensor-এর device আর .to(), পর্ব ১০-এ পুরো training loop, আর পর্ব ১১-এ DataLoader-এর গতি মেপেছেন। এই পর্বের প্রশ্ন: একই loop GPU-তে কত দ্রুত চলে, কেন, আর সেই “কত” সৎভাবে কীভাবে মাপবেন? PyTorch পাতায় চলে না, তাই GPU-র সব সংখ্যা ডেস্কটপের সত্যিকারের run থেকে নেওয়া। গোপনীয়তার নিয়মে যন্ত্রের মডেল বা memory-র মাপ দেওয়া হয়নি, শুধু “GPU-তে” আর “CPU-তে” সময় আর program-এর ব্যবহার করা MB. পাতার চারটি ব্লক ব্রাউজারের Python আর NumPy-তে চলে; প্রথমবার প্যাকেজ নামতে কয়েক সেকেন্ড লাগে।

১ · GPU কেন দ্রুত — অনেক ছোট কর্মী আর matrix গুণ

Matrix গুণ ঠিক “একই ধরনের অনেক কাজ”: C = AB-তে n × n ফলের প্রতিটি ঘর আলাদা একটি dot product, আর একটি ঘরের হিসাব অন্যটির অপেক্ষা করে না। মোট কাজ প্রায় 2n³ FLOP (প্রতিটি ঘরে n গুণ আর n যোগ)। GPU এই ঘরগুলো হাজার হাজার ছোট হিসাব-এককে ভাগ করে দেয়, আর আধুনিক NVIDIA GPU-তে Tensor Core নামের বিশেষ একক ছোট matrix-এর গুণ-যোগ এক ধাপে করে। GPU-তে সাধারণ হিসাব চালানোর প্ল্যাটফর্মের নাম CUDA. GPU-র ভেতরের গঠন (SIMT, memory hierarchy) কম্পিউটার আর্কিটেকচার কোর্সের পর্ব ৫৫-এ আছে; এখানে আমরা শুধু ব্যবহারকারীর দিক দেখব।

CPU-তেও একই নীতি কাজ করে, ছোট মাপে: Python-এর লুপে প্রতিটি গুণ আলাদা interpreter-এর কাজ, আর NumPy-র A @ B পুরো কাজ একবারে compiled BLAS library-কে দেয়, যা SIMD আর cache ঠিকমতো ব্যবহার করে। একে বলে vectorization (AI-এর ভিত্তি কোর্সের পর্ব ১৯)। নিচের ব্লক একই 64 × 64 গুণ দুভাবে করে, তারপর বড় মাপে NumPy-র GFLOP/s মাপে।

import time
import numpy as np

rng = np.random.default_rng(42)
n = 64
A, B = rng.normal(size=(n, n)), rng.normal(size=(n, n))

def matmul_loop(A, B):             # প্রতিটি গুণ-যোগ আলাদা Python কাজ
    C = [[0.0] * n for _ in range(n)]
    for i in range(n):
        for j in range(n):
            s = 0.0
            for k in range(n):
                s += A[i, k] * B[k, j]
            C[i][j] = s
    return np.array(C)

def per_call(fn, reps):            # ব্রাউজারের ঘড়ি মোটা দাগের, তাই অনেকবার চালিয়ে গড়
    fn()                           # warm-up
    t = time.perf_counter()
    for _ in range(reps): fn()
    return (time.perf_counter() - t) / reps

t_loop = per_call(lambda: matmul_loop(A, B), 2)
t_vec = per_call(lambda: A @ B, 2000)
print(f"64x64 matmul: {2 * n**3:,} floating-point operations (গুণ আর যোগ)")
print(f"Python loop: {t_loop * 1e3:8.1f} ms")
print(f"NumPy  A @ B: {t_vec * 1e3:8.3f} ms")
print(f"একই ফল? {np.allclose(matmul_loop(A, B), A @ B)} | loop / vectorised ≈ {t_loop / t_vec:,.0f} গুণ")
for m in (128, 256, 512):
    X = rng.normal(size=(m, m)); t = per_call(lambda: X @ X, 5)
    print(f"NumPy {m}x{m}: {t * 1e3:7.2f} ms, {2 * m**3 / t / 1e9:5.2f} GFLOP/s")

64x64 matmul: 524,288 floating-point operations (গুণ আর যোগ)
Python loop:     76.8 ms
NumPy  A @ B:    0.121 ms
একই ফল? True | loop / vectorised ≈ 634 গুণ
NumPy 128x128:    1.20 ms,  3.50 GFLOP/s
NumPy 256x256:   10.64 ms,  3.15 GFLOP/s
NumPy 512x512:  273.52 ms,  0.98 GFLOP/s

২ · Device-এর নিয়ম — একটি device চলক, model আর batch সরানো

PyTorch-এ প্রতিটি tensor একটি device-এ থাকে, আর একটি কাজের সব tensor একই device-এ থাকতে হয়। কোড পরিষ্কার রাখার প্রচলিত ধাঁচ তিনটি: (১) শুরুতে একবার device ঠিক করা; (২) model একবার model.to(device); (৩) প্রতিটি batch লুপের ভেতরে xb.to(device). কোথাও .cuda() ছড়িয়ে লিখলে CPU-তে চালাতে গেলে সব জায়গায় বদলাতে হয়। ডেস্কটপে CUDA-সহ PyTorch install করা হলো (PyTorch-এর CUDA wheel index pyproject.toml-এ, CPU index-এর মতোই; ঠিক কোন CUDA version তা নিজের driver দেখে PyTorch-এর install পাতা থেকে বেছে নিতে হয়):

~/bazarghar-dl$ uv add torch numpy
 …
 + numpy==2.5.4
 + torch==2.15.0+cu132
 …

import torch
from torch import nn
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
print("device:", device)

model = nn.Linear(16, 1).to(device)              # model একবার সরানো
xb = torch.randn(8, 16)                           # batch এখনো CPU-তে
try:
    model(xb)
except RuntimeError as e:
    print("RuntimeError:", str(e).splitlines()[0][:160])
out = model(xb.to(device))
print("ok:", out.device, out.shape, "| param on", next(model.parameters()).device)
print("tensor .to() returns a copy:", xb.to(device) is xb, "| module .to() in place:",
      model.to(device) is model)

সত্যিকারের run (ডেস্কটপ, Python 3.14.4, PyTorch 2.15.0 CUDA build, NumPy 2.5.4; লেখার সময়ের সংস্করণ):

~/bazarghar-dl$ uv run python device_threads.py
device: cuda
RuntimeError: Expected all tensors to be on the same device, but got mat1 is on cpu, different from other tensors on cuda:0 (when checking argument in method wrapper_CUDA_add …
ok: cuda:0 torch.Size([8, 1]) | param on cuda:0
tensor .to() returns a copy: False | module .to() in place: True
…

Error-টি নিজেই বলে দেয় কোন tensor (mat1, অর্থাৎ input) কোথায় আছে। শেষ লাইনের পার্থক্য খুব কাজের: nn.Module-এর .to() নিজের parameter-গুলোকেই সরায় আর একই object ফেরত দেয়, তাই model.to(device) আলাদা করে লিখলেও চলে। কিন্তু tensor-এর .to() নতুন tensor ফেরত দেয়; xb.to(device) লিখে ফল কোথাও না রাখলে xb CPU-তেই থাকে। এটি AI-এর লেখা কোডের একটি চেনা বাগ। Optimizer তৈরির আগেই model সরানো ভালো অভ্যাস, যাতে optimizer সঠিক parameter ধরে।

GPU-তে প্রথম কাজটি অস্বাভাবিক ধীর হয়। নিচের stepper একই run-এর gpu_timing.py-র প্রথম লাইনের সংখ্যা ধরে দেখায় কেন।

৩ · সঠিকভাবে সময় মাপা — asynchronous execution, synchronize আর CUDA event

CPU যখন C = A @ B লাইনে আসে, GPU-কে একটি ছোট প্রোগ্রাম (kernel) চালানোর নির্দেশ একটি সারিতে (CUDA stream) রেখেই পরের লাইনে চলে যায়; একে বলে kernel launch. ফলে CPU-র ঘড়ি দিয়ে মাপলে শুধু পাঠানোর সময় আসে। torch.cuda.synchronize() CPU-কে থামিয়ে রাখে যতক্ষণ না GPU-র সারি খালি হয়। কোনো ফল CPU-তে আনলে (.item(), .cpu(), print) সেটাও লুকিয়ে synchronize করে; তাই training loop-এ প্রতি ধাপে loss.item() ছাপা loop-কে ধীর করতে পারে।

n = 4096
A = torch.randn(n, n, device=device); B = torch.randn(n, n, device=device)
for _ in range(3): A @ B                                  # warm-up
torch.cuda.synchronize()
t0 = time.perf_counter(); C = A @ B; t1 = time.perf_counter()
print(f"without synchronize: {1e3*(t1-t0):.3f} ms  (শুধু কাজ queue-তে পাঠানোর সময়)")
torch.cuda.synchronize()
t0 = time.perf_counter(); C = A @ B; torch.cuda.synchronize(); t1 = time.perf_counter()
print(f"with synchronize:    {1e3*(t1-t0):.3f} ms")
start, end = torch.cuda.Event(enable_timing=True), torch.cuda.Event(enable_timing=True)
start.record(); C = A @ B; end.record(); torch.cuda.synchronize()
print(f"cuda.Event timing:   {start.elapsed_time(end):.3f} ms")

সত্যিকারের run (GPU-তে, float32):

~/bazarghar-dl$ uv run python gpu_timing.py
Python 3.14.4 | torch 2.15.0+cu132 | numpy 2.5.4
CUDA available: True
first CUDA call (context): 71 ms | first matmul: 102.3 ms | second matmul: 1.29 ms
without synchronize: 0.190 ms  (শুধু কাজ queue-তে পাঠানোর সময়)
with synchronize:    20.126 ms
cuda.Event timing:   16.997 ms
…

একই কাজ, তিনটি উত্তর। Synchronize ছাড়া ০.১৯০ ms: এটি শুধু launch-এর সময়, আসল কাজের প্রায় একশো ভাগের এক ভাগ। এই সংখ্যা দিয়ে CPU-র সঙ্গে তুলনা করলে হাজার গুণের ভুয়া “speedup” পাওয়া যেত। Synchronize-সহ ২০.১ ms সঠিক, তবে এতে CPU-র ঘড়ি পড়া আর synchronize-এর ছোট খরচও আছে। CUDA event দুটি GPU-র সারিতেই বসে, তাই GPU যখন সত্যিই সেখানে পৌঁছায় তখনকার সময় লেখে: ১৭.০ ms. একটি মাপে ৩ ms-এর পার্থক্য স্বাভাবিক ওঠানামাও হতে পারে; তাই নিয়ম হলো কয়েকবার মেপে median নেওয়া, যা পরের অংশের টেবিলে করা হয়েছে।

৪ · CPU বনাম GPU — matmul-এর আকার, একটি training ধাপ আর ডেটা কপি

এবার নিয়ম মেনে মাপ: প্রতিটি আকারে দুবার warm-up, তারপর পাঁচবার মেপে median. CPU-তে PyTorch-এর default thread-সংখ্যা ব্যবহার হয়েছে, অর্থাৎ CPU-কেও পূর্ণ সুযোগ দেওয়া হয়েছে।

~/bazarghar-dl$ uv run python gpu_timing.py
…
 n     CPU ms     GPU ms   GPU TFLOP/s  speedup
   64     0.013     0.023       0.02      0.6x
  256     0.076     0.050       0.68      1.5x
 1024     3.337     0.293       7.33     11.4x
 2048    25.546     2.128       8.07     12.0x
 4096   205.244    17.571       7.82     11.7x

64 × 64-এ GPU CPU-র চেয়ে ধীর: কাজ মাত্র ৫ লাখ FLOP, অথচ launch আর synchronize-এর স্থির খরচই কয়েক microsecond. আকার বাড়লে GPU-র অর্জিত গতি ০.০২ থেকে প্রায় ৮ TFLOP/s-এ ওঠে, তারপর থিতিয়ে যায়: তখন GPU-র float32 হিসাবের ক্ষমতাই সীমা। Speedup তাই আকারের function, একটি সংখ্যা নয়। (এক যন্ত্রের এক run; অন্য যন্ত্রে অনুপাত অনেক আলাদা হবে।)

এবার বাজারঘরের একটি সত্যিকারের training ধাপ: ১৬টি feature থেকে ডেলিভারির সময় (seed দিয়ে বানানো ৬৫,৫৩৬টি কাল্পনিক অর্ডার), model 16 → 1024 → 1024 → 1, AdamW, প্রতি ধাপে forward, backward আর step. ধাপের ভেতরে প্রতিবার batch .to(device, non_blocking=True) দিয়ে পাঠানো হয়।

~/bazarghar-dl$ uv run python train_step.py
model 16 -> 1024 -> 1024 -> 1, AdamW, ms per training step
batch    64: CPU     2.68 ms | GPU   1.17 ms |   2.3x
batch  1024: CPU    14.27 ms | GPU   1.65 ms |   8.7x
batch  8192: CPU    92.67 ms | GPU   8.37 ms |  11.1x
batch 8192, data resident: GPU   8.30 ms
batch 8192, data pageable: GPU   8.09 ms
batch 8192, data pinned  : GPU   8.08 ms

Batch ৬৪-এ GPU মাত্র ২.৩ গুণ দ্রুত: প্রতি ধাপে কয়েক ডজন ছোট kernel, আর Python ও launch-এর খরচই প্রধান, GPU-র বেশির ভাগ একক খালি বসে থাকে। Batch ৬৪ থেকে ১০২৪-এ, অর্থাৎ ১৬ গুণ ডেটায়, GPU-র সময় বেড়েছে মাত্র ১.১৭ থেকে ১.৬৫ ms: বাড়তি কাজ খালি এককগুলোতে ঢুকে গেছে। এজন্যই GPU-তে বড় batch প্রায় “বিনা খরচে” আসে, যতক্ষণ memory আর শেখার মান অনুমতি দেয় (batch আকার আর learning rate-এর সম্পর্ক পর্ব ১৫-তে)।

শেষ তিন লাইন ডেটা কপির প্রশ্ন: পুরো ডেটা আগে থেকে GPU-তে (resident), সাধারণ RAM থেকে প্রতি ধাপে কপি (pageable), আর pinned memory থেকে কপি। এখানে তিনটি প্রায় সমান, কারণ একটি batch মাত্র 8192 × 16 × 4 byte = ০.৫ MB, যা হিসাবের তুলনায় নগণ্য। ছবি বা লম্বা টেক্সটের batch অনেক বড়, তখন pinned memory আর non_blocking=True কপিকে হিসাবের সঙ্গে একসঙ্গে চালাতে সাহায্য করে; DataLoader-এ pin_memory=True আর num_workers পর্ব ১১-এর অংশ ৭-এ মাপা হয়েছে। সত্যিকারের প্রকল্পে প্রায়ই bottleneck GPU নয়, ডেটা: ছবি decode, টেক্সট tokenize বা disk থেকে পড়া। GPU খালি বসে থাকলে দ্রুততর GPU কিছুই বদলায় না।

৫ · Memory কোথায় যায় — parameter, gradient, optimizer state আর activation

GPU-র memory CPU-র RAM-এর চেয়ে সাধারণত অনেক কম, আর “CUDA out of memory” error-ই নতুনদের সবচেয়ে চেনা দেয়াল। Training-এ চার ধরনের জিনিস memory নেয়: parameter (weight আর bias); gradient, প্রতিটি parameter-এর সমান আকারের; optimizer state, momentum-সহ SGD-তে প্রতি parameter-এ একটি, AdamW-এ দুটি moment (মেশিন লার্নিং কোর্সের পর্ব ১৪); আর activation, backward-এর জন্য জমিয়ে রাখা forward-এর মাঝের মান (পর্ব ০৪-এর অংশ ৭)। প্রথম তিনটি batch-এর ওপর নির্ভর করে না, শেষটি batch আর স্তরের সঙ্গে বাড়ে।

float32 training-এ: মোট ≈ P × (4 + 4 + 4k) byte + activation

এখানে P হলো parameter-এর সংখ্যা আর k হলো parameter-প্রতি optimizer state-এর সংখ্যা (SGD ০, momentum ১, AdamW ২)। AdamW-এ তাই প্রতি parameter-এ ১৬ byte. PyTorch-এ মাপার হাতিয়ার torch.cuda.memory_allocated() (এই মুহূর্তে tensor-এর জন্য ব্যবহৃত) আর max_memory_allocated() (শেষ reset-এর পর সর্বোচ্চ)। একটি 1024 → 4096 → 4096 → 1024 MLP, batch ২৫৬, তিনটি optimizer, দ্বিতীয় ধাপে মাপা (প্রথম ধাপে optimizer state তৈরি হয়):

~/bazarghar-dl$ uv run python gpu_memory.py
SGD           params 25.18 M (96.0 MB float32) | model 98.0 | after forward 108.0 | after backward 196.1 | after step+zero_grad 100.0 | peak 208.2 MB
SGD+momentum  params 25.18 M (96.0 MB float32) | model 98.0 | after forward 204.1 | after backward 292.1 | after step+zero_grad 196.1 | peak 304.2 MB
AdamW         params 25.18 M (96.0 MB float32) | model 98.0 | after forward 300.1 | after backward 388.1 | after step+zero_grad 292.1 | peak 484.2 MB

লাইন ধরে পড়ুন। model ৯৮.০: ৯৬ MB weight আর ২ MB input ও target. after forward: SGD-তে +১০ MB activation; momentum-এ আরও ৯৬ MB, AdamW-এ আরও ১৯২ MB, যা আগের ধাপের optimizer state. after backward: +৮৮ MB, অর্থাৎ ৯৬ MB gradient এসেছে আর প্রায় ৮ MB activation মুক্ত হয়েছে। after step+zero_grad: set_to_none=True gradient মুছে দেয়, তাই SGD-তে আবার ১০০ MB. peak: SGD-তে ২০৮ MB, প্রায় weight + gradient + activation. AdamW-এর peak ৪৮৪ MB, হাতের হিসাবের (৯৮ + ৯৬ + ১৯২ + ১০ ≈ ৩৯৬) চেয়ে প্রায় ৮৮ MB বেশি; সম্ভবত step-এর সময় PyTorch-এর দ্রুত (foreach) রূপ কিছু অস্থায়ী tensor বানায়। তাই হাতের হিসাব নিচের সীমা, আসল সংখ্যা মেপেই জানতে হয়।

নিচের ব্লকটি একই হিসাবের একটি calculator. প্রথম অংশ ঠিক এই MLP-এর জন্য, যাতে মাপার সঙ্গে মেলানো যায়; দ্বিতীয় অংশ ১০০ কোটি parameter-এর একটি model-এর জন্য, তিনটি precision-এর ধাঁচে। Activation-এর হিসাবে প্রতিটি স্তরের Z আর H দুটিই ধরা হয়েছে, তাই এটি উপরের সীমার দিকে।

MB = 2 ** 20
BYTES = {"float32": 4, "float16": 2, "bfloat16": 2}
OPT_STATES = {"SGD": 0, "SGD+momentum": 1, "AdamW": 2}    # parameter-প্রতি কতটি float32 state

def mlp_params(sizes):             # nn.Linear(i, o): i*o weight + o bias
    return sum(i * o + o for i, o in zip(sizes[:-1], sizes[1:]))

def train_memory(P, opt, act_count=0, dtype="float32", master=False):
    p = P * BYTES[dtype]                       # model-এর weight
    g = P * BYTES[dtype]                       # gradient, weight-এর dtype-এ
    m = P * 4 if master else 0                 # mixed precision: float32 master copy
    s = P * 4 * OPT_STATES[opt]                # optimizer state সাধারণত float32
    a = act_count * BYTES[dtype]               # backward-এর জন্য জমা activation
    return {k: v / MB for k, v in dict(param=p, grad=g, master=m, opt=s, act=a).items()}

sizes = [1024, 4096, 4096, 1024]; P = mlp_params(sizes)
B = 256; acts = B * (1024 + 4096 * 2 + 4096 * 2 + 1024)   # x, Z1, H1, Z2, H2, out
print(f"MLP {sizes}: {P:,} parameter, batch {B}")
for opt in OPT_STATES:
    r = train_memory(P, opt, acts)
    print(f"{opt:13s}", " ".join(f"{k} {v:6.1f}" for k, v in r.items()),
          f"| মোট {sum(r.values()):6.1f} MB")

print("\n১০০ কোটি (1B) parameter-এর model, AdamW, activation বাদে:")
for name, dt, master in [("সব float32", "float32", False),
                         ("bf16 weight + fp32 master", "bfloat16", True),
                         ("শুধু bf16 weight (inference)", "bfloat16", False)]:
    r = train_memory(10**9, "AdamW", 0, dt, master)
    if name.startswith("শুধু"): r = {"param": r["param"]}
    print(f"{name:30s} {sum(r.values()) / 1024:6.1f} GB  ({', '.join(f'{k} {v/1024:.1f}' for k, v in r.items() if v)})")

MLP [1024, 4096, 4096, 1024]: 25,175,040 parameter, batch 256
SGD           param   96.0 grad   96.0 master    0.0 opt    0.0 act   18.0 | মোট  210.1 MB
SGD+momentum  param   96.0 grad   96.0 master    0.0 opt   96.0 act   18.0 | মোট  306.1 MB
AdamW         param   96.0 grad   96.0 master    0.0 opt  192.1 act   18.0 | মোট  402.1 MB

১০০ কোটি (1B) parameter-এর model, AdamW, activation বাদে:
সব float32                       14.9 GB  (param 3.7, grad 3.7, opt 7.5)
bf16 weight + fp32 master        14.9 GB  (param 1.9, grad 1.9, master 3.7, opt 7.5)
শুধু bf16 weight (inference)      1.9 GB  (param 1.9)

৬ · float16 আর bfloat16 — পরিসর বনাম নির্ভুলতা

একটি দশমিক সংখ্যা তিন ভাগে রাখা হয়: চিহ্নের ১ bit, মাপের (exponent) কয়েক bit আর অঙ্কের (mantissa) কয়েক bit; বিস্তারিত কম্পিউটার আর্কিটেকচার কোর্সের পর্ব ২৩-এ। Exponent ঠিক করে পরিসর, অর্থাৎ কত বড় বা কত ছোট সংখ্যা ধরা যায়; mantissa ঠিক করে নির্ভুলতা, অর্থাৎ পাশাপাশি দুটি সংখ্যার ফাঁক কত। ১৬ bit-এ দুটিকেই পুরো পাওয়া যায় না, তাই দুটি ভিন্ন আপস জনপ্রিয়: float16 আর bfloat16.

NumPy-তে float16 আছে, bfloat16 নেই। কিন্তু bfloat16 যেহেতু float32-এর ওপরের ১৬ bit, তাই float32-এর bit-গুলো একটি পূর্ণসংখ্যা হিসেবে পড়ে নিচের ১৬ bit শূন্য করলেই তার নকল পাওয়া যায় (এখানে সবচেয়ে কাছের মানে rounding-সহ, যেমন hardware সাধারণত করে)। নিচের ব্লক দুটি format-এর সীমা, কয়েকটি মান, আর একটি ছোট সংখ্যা বারবার যোগের ফল দেখায়।

import numpy as np

def to_bf16(x):                    # bfloat16-এর নকল: float32-এর নিচের ১৬ bit বাদ (round to nearest even)
    b = np.asarray(x, dtype=np.float32).view(np.uint32).astype(np.uint64)
    b = (b + 0x7FFF + ((b >> 16) & 1)) & 0xFFFF0000
    return b.astype(np.uint32).view(np.float32)

f16 = np.finfo(np.float16)
print(f"float16 : max {float(f16.max):.0f}, smallest normal {float(f16.tiny):.2e}, eps {float(f16.eps):.2e}")
bf_max = np.array([0x7F7F0000], dtype=np.uint32).view(np.float32)[0]
print(f"bfloat16: max {float(bf_max):.4g}, smallest normal {float(np.finfo(np.float32).tiny):.2e}, eps {2.0**-7:.2e}")

vals = np.array([70000.0, 1 / 3, 1e-8, 1001.0, 3.14159265], dtype=np.float32)
print("\n     মান        float16        bfloat16")
with np.errstate(over="ignore"):            # desktop-এ overflow warning চুপ রাখতে
    h = vals.astype(np.float16)
for v, a, b in zip(vals, h, to_bf16(vals)):
    print(f"{v:11.6g} {float(a):12.6g} {float(b):14.6g}")

# ছোট ধাপ বারবার যোগ: accumulator-এর dtype কেন গুরুত্বপূর্ণ
s16, s_bf, s32 = np.float16(0), np.float32(0), np.float32(0)
for _ in range(10000):
    s16 = np.float16(s16 + np.float16(0.01))
    s_bf = to_bf16(s_bf + to_bf16(0.01))
    s32 = np.float32(s32 + np.float32(0.01))
print(f"\n0.01 দশ হাজার বার যোগ (সঠিক 100): float16 {float(s16):.4g} | bfloat16 {float(s_bf):.4g} | float32 {float(s32):.6g}")

float16 : max 65504, smallest normal 6.10e-05, eps 9.77e-04
bfloat16: max 3.39e+38, smallest normal 1.18e-38, eps 7.81e-03

     মান        float16        bfloat16
      70000          inf          70144
   0.333333     0.333252       0.333984
      1e-08            0    1.00117e-08
       1001         1001           1000
    3.14159      3.14062        3.14062

0.01 দশ হাজার বার যোগ (সঠিক 100): float16 32 | bfloat16 4 | float32 100.003

Training-এ দুটি ঝুঁকি তাই আলাদা। float16-এ সমস্যা পরিসর: gradient প্রায়ই 10⁻⁶ থেকে 10⁻⁹-এর ঘরে, যা float16-এ শূন্য (underflow), আর বড় activation 65504 পেরোলে inf (overflow). bfloat16-এ পরিসরের ঝুঁকি প্রায় নেই, কিন্তু নির্ভুলতা কম। দুটির ক্ষেত্রেই সমাধানের মূল কথা: যোগফল, loss আর weight-এর আপডেট float32-এ রাখা। float16-এর পরিসরের সমস্যার জন্য আছে loss scaling: backward-এর আগে loss-কে বড় একটি সংখ্যা S দিয়ে গুণ করলে chain rule-এ প্রতিটি gradient-ও S গুণ হয়, ছোট gradient শূন্যে পড়ে না; তারপর float32-এ S দিয়ে ভাগ করে আপডেট। নিচের ব্লক এই কৌশলটি NumPy-তে নকল করে।

import numpy as np

rng = np.random.default_rng(42)    # ছোট-বড় মেশানো ১০ লাখ gradient (float32-এ "সত্যি" মান)
g = (rng.choice([-1, 1], 10**6) * 10.0 ** rng.uniform(-10, -2, 10**6)).astype(np.float32)

def through_fp16(g, scale):        # GradScaler-এর নকল: scale করে float16, তারপর float32-এ unscale
    with np.errstate(over="ignore"):
        h = (g * np.float32(scale)).astype(np.float16)
    return h.astype(np.float32) / np.float32(scale), h

print(" scale     শূন্য হয়ে গেছে   inf   গড় আপেক্ষিক ভুল")
for scale in (1, 2.0**10, 2.0**16, 2.0**24):
    back, h = through_fp16(g, scale)
    ok = np.isfinite(back) & (back != 0)
    rel = np.abs(back[ok] - g[ok]) / np.abs(g[ok])
    print(f"{scale:>9.0f} {np.mean(h == 0):12.1%} {np.isinf(h).sum():7d} {rel.mean():12.2e}")

# dynamic loss scaling: inf দেখলে scale অর্ধেক, ধাপ বাদ; নির্দিষ্ট সংখ্যক ভালো ধাপের পর দ্বিগুণ
scale, good, log = 2.0**24, 0, []
for step in range(8):
    _, h = through_fp16(g, scale)
    if np.isinf(h).any():
        log.append(f"{step}: inf, skip, scale {scale:.0f} -> {scale / 2:.0f}"); scale /= 2; good = 0
    else:
        good += 1; log.append(f"{step}: ok, scale {scale:.0f}")
        if good == 3: scale *= 2; good = 0
print("\n".join(log))

 scale     শূন্য হয়ে গেছে   inf   গড় আপেক্ষিক ভুল
        1        30.9%       0     4.30e-02
     1024         0.0%       0     7.45e-03
    65536         0.0%       0     2.65e-04
 16777216         0.0%   51107     1.76e-04
0: inf, skip, scale 16777216 -> 8388608
1: inf, skip, scale 8388608 -> 4194304
2: ok, scale 4194304
3: ok, scale 4194304
4: ok, scale 4194304
5: inf, skip, scale 8388608 -> 4194304
6: ok, scale 4194304
7: ok, scale 4194304

৭ · Mixed precision — autocast আর GradScaler, সত্যিকারের গতি আর loss

Mixed precision-এর ধারণা: ভারী কাজ (matmul, convolution) ১৬ bit-এ, কারণ সেখানে Tensor Core অনেক দ্রুত আর memory-র যাতায়াত অর্ধেক; সংবেদনশীল কাজ (softmax, log, loss, যোগফল, weight আপডেট) float32-এ। PyTorch-এ পুরো model হাতে বদলাতে হয় না: torch.autocast-এর ভেতরে প্রতিটি কাজ নিজের তালিকা দেখে dtype ঠিক করে। নিচের stepper একটি Linear স্তরের ভেতরে কী হয় তা দেখায়; dtype-গুলো সত্যিকারের run থেকে।

এবার পুরো training: বাজারঘরের একই ডেলিভারি ডেটা, model 16 → 2048 → 2048 → 2048 → 1, batch ৪০৯৬, AdamW, ৩০০ ধাপ, একই seed. তিনটি precision, আর চতুর্থ সারিতে float32 matmul-এ TF32 চালু করে। মূল লুপ:

scaler = torch.amp.GradScaler("cuda", enabled=(mode == "float16"))
for i in range(steps):
    xb, yb = next_batch(i)
    with torch.autocast("cuda", dtype=dtype, enabled=dtype is not None):
        loss = nn.functional.mse_loss(model(xb), yb)
    opt.zero_grad(set_to_none=True)
    scaler.scale(loss).backward()    # float16: loss × scale; অন্যথায় কিছুই করে না
    scaler.step(opt)                 # unscale, inf থাকলে এই ধাপ বাদ
    scaler.update()                  # পরের ধাপের scale ঠিক করা

সত্যিকারের run (GPU-তে; প্রতি ধাপের সময় প্রথম ২০ ধাপ বাদ দিয়ে median, প্রতি ধাপে synchronize; eval হলো শেষ ৮১৯২ সারিতে float32-এ loss):

~/bazarghar-dl$ uv run python amp_train.py
bf16 supported: True
weight torch.float32 | linear out torch.float16 | softmax torch.float32 | mse_loss torch.float32 | weight.grad torch.float32
float16(70000) = inf | bfloat16(70000) = 70144.0 | float16(1e-8) = 0.0
float32 :  28.03 ms/step | last loss 0.00423 | eval (float32) 0.00421 | peak 266 MB
float16 :  12.36 ms/step | last loss 0.00459 | eval (float32) 0.00451 | peak 262 MB | final scale 16384
bfloat16:  11.90 ms/step | last loss 0.00429 | eval (float32) 0.00424 | peak 262 MB
matmul precision 'high' (TF32) -> float32 :  20.83 ms/step | last loss 0.00430 | eval (float32) 0.00421 | peak 266 MB

গতি: float16 আর bfloat16 দুটিতেই ধাপ প্রায় ২.৩ গুণ দ্রুত (২৮.০ থেকে ১২.৪ ও ১১.৯ ms). TF32 মাঝামাঝি, ২০.৮ ms: input float32-ই থাকে, শুধু matmul-এর ভেতরে mantissa ছেঁটে Tensor Core ব্যবহার। নির্ভুলতা: bfloat16-এর eval loss ০.০০৪২৪, float32-এর ০.০০৪২১-এর প্রায় সমান; float16-এ ০.০০৪৫১, সামান্য বেশি। এক seed-এর এক run থেকে বলা যায় না যে float16 সাধারণভাবে খারাপ; বলা যায় শুধু, এই কাজে তিনটিই কাছাকাছি, আর পার্থক্য আছে কি না তা কয়েকটি seed-এ যাচাই করতে হবে (পর্ব ১৯-এ experiment-এর পদ্ধতি)। Scale: GradScaler-এর শুরুর scale 2¹⁶ = 65536 (এই version-এর default); ৩০০ ধাপ শেষে 16384, অর্থাৎ পথে অন্তত দুবার inf পেয়ে ধাপ বাদ দিয়ে অর্ধেক হয়েছে। Default নিয়মে টানা ২০০০টি ভালো ধাপ হলে তবেই দ্বিগুণ হয়, তাই এত ছোট run-এ আর বাড়েনি।

Memory: পুরো run-এর peak প্রায় একই (২৬৬ বনাম ২৬২ MB). আলাদা একটি মাপ (amp_mem.py) কারণ দেখায়:

~/bazarghar-dl$ uv run python amp_mem.py
float32 : saved by forward   96.0 MB | peak in backward + 165.0 MB | peak in optimizer step  161.1 MB (absolute)
bfloat16: saved by forward   64.1 MB | peak in backward + 110.1 MB | peak in optimizer step  161.1 MB (absolute)

forward-এর জমা activation ৯৬ থেকে ৬৪ MB-এ নেমেছে (পুরো অর্ধেক নয়, কারণ weight-এর ১৬-bit কপিও জায়গা নেয়), আর backward-এর peak ১৬৫ থেকে ১১০ MB. কিন্তু parameter, gradient আর AdamW state autocast-এ float32-ই থাকে; এই ছোট model-এ সেগুলোই মোটের বড় অংশ। Activation-ভারী model-এ (বড় batch, লম্বা sequence, বড় ছবি) সঞ্চয় অনেক বেশি চোখে পড়ে।

৮ · torch.compile আর profiler — কোথায় সময় যায়

Eager মোডে প্রতিটি কাজ আলাদা kernel: matmul, তারপর bias যোগ, তারপর GELU, প্রতিবার ফল memory-তে লেখা আর আবার পড়া। torch.compile (PyTorch 2.0, ২০২৩ থেকে) কোড চলার সময় graph ধরে, তারপর TorchInductor নামের compiler দিয়ে কয়েকটি কাজ জুড়ে নতুন kernel বানায় (kernel fusion); GPU-তে সেই kernel লেখা হয় Triton ভাষায়। পর্ব ০৫-এর define-by-run আর static graph-এর আলোচনার এটি আধুনিক মিশ্রণ। এই Windows যন্ত্রে প্রথম চেষ্টার সৎ ফল:

~/bazarghar-dl$ uv run python compile_try.py
W1106 … torch\utils\flop_counter.py:113] triton not found; flop counting will not work for triton kernels
eager:    first call     63.6 ms | then 7.361 ms per forward
torch.compile failed: TritonMissing
Cannot find a working triton installation. Either the package is not installed or it is too old. More information on installing Triton can be found at: https://github.com/triton-lang/triton

PyTorch-এর Windows wheel-এর সঙ্গে Triton আসে না, আর লেখার সময়ে Triton-এর মূল প্রকল্প Windows-এর জন্য অফিশিয়াল build দেয় না। একটি community-রক্ষিত রূপ আছে, triton-windows (লেখার সময়ে 3.9.0.post30). সেটি একই project-এ যোগ করে, compile cache project-এর ভেতরে রেখে আবার চালানো হলো:

~/bazarghar-dl$ uv add triton-windows
 …
 + triton-windows==3.9.0.post30
~/bazarghar-dl$ uv run python compile_try.py
… UserWarning: TRITON_DEFAULT_FP_FUSION is unset: defaulting to FP fusion ENABLED … (এক লাইনের সতর্কবার্তা)
eager:    first call     53.5 ms | then 7.335 ms per forward
compiled: first call   1510.8 ms | then 7.036 ms per forward
max |eager - compiled| = 1.430511474609375e-06
~/bazarghar-dl$ uv run python compile_try.py      # দ্বিতীয়বার, cache থেকে
 …
compiled: first call    516.3 ms | then 7.021 ms per forward

Model 512 → 2048 → GELU → 2048 → GELU → LayerNorm → 512, batch ৪০৯৬, inference. প্রথম call-এ compile-এর জন্য ১.৫ s, cache থাকলে ০.৫২ s; তারপর প্রতি forward ৭.৩৪ থেকে ৭.০৪ ms, মাত্র প্রায় ৪% লাভ, কারণ এখানে সময়ের বেশির ভাগ বড় matmul-এ, যা compile-এর আগেও cuBLAS-এর দ্রুত kernel-এ চলত; জোড়া লাগানোর মতো কাজ (GELU, LayerNorm) অল্প। ফলের পার্থক্য 1.4 × 10⁻⁶, float32-এর rounding-এর মাপ। শিক্ষা: compile-এর লাভ model আর platform-এর ওপর নির্ভর করে; অনেক ছোট উপাদান-ধরে কাজ থাকলে লাভ বেশি, লম্বা training-এ compile-এর এককালীন খরচ উঠে আসে, ছোট script-এ নাও আসতে পারে। Windows-এ বাড়তি package লাগবে, এটিও মাথায় রাখুন।

Profiler — অনুমান না করে দেখা

“কোথায় সময় যাচ্ছে” প্রশ্নে অনুমান প্রায়ই ভুল হয়। torch.profiler কয়েকটি ধাপ চালিয়ে প্রতিটি কাজের CPU আর GPU সময় মাপে। schedule(wait=1, warmup=2, active=5) মানে প্রথম ধাপ উপেক্ষা, পরের দুটি warm-up, তারপর পাঁচটি মাপা। PyTorch-এর নিজের টেবিলে GPU kernel-এর পুরো নামও আসে, যাতে hardware-এর প্রজন্ম বোঝা যায়; গোপনীয়তার জন্য এখানে key_averages() থেকে শুধু aten:: কাজগুলো একই কলামে ছাপা হয়েছে। Model 16 → 1024 → 1024 → 1, batch ৪০৯৬, AdamW:

~/bazarghar-dl$ uv run python profile_steps.py
Name                            Self CPU  CPU total  Self CUDA      %  Calls
aten::mm                          0.37ms     0.61ms    11.91ms  39.1%     25
aten::addmm                       0.37ms     0.57ms     6.27ms  20.6%     15
aten::threshold_backward          0.07ms     0.13ms     1.46ms   4.8%     10
aten::clamp_min                   0.08ms     0.15ms     1.00ms   3.3%     10
aten::sum                         0.15ms     0.28ms     0.62ms   2.0%     15
aten::_foreach_mul_               0.06ms     0.19ms     0.27ms   0.9%     10
aten::_foreach_addcdiv_           0.03ms     0.06ms     0.27ms   0.9%      5
aten::_foreach_addcmul_           0.03ms     0.06ms     0.20ms   0.7%      5
26 distinct GPU kernels | 234 kernel launches
GPU kernel time total: 30.45 ms over 5 active steps

বড় প্রকল্পে টেবিলের বদলে timeline দেখা আরও কাজের: prof.export_chrome_trace("trace.json") লিখে ব্রাউজারের trace viewer বা Perfetto-তে খুললে CPU আর GPU-র সারি পাশাপাশি দেখা যায়, আর GPU-র সারিতে ফাঁক মানে GPU কিছুর অপেক্ষায় বসে ছিল, প্রায়ই ডেটার।

৯ · GPU ছাড়া শেখা — CPU thread, ছোট model আর বিনামূল্যের notebook

এই কোর্সের মডিউল ১–৩-এর প্রায় সব কিছু CPU-তে শেখা যায়। প্রথম কৌশল CPU-র সব core কাজে লাগানো। PyTorch সাধারণত নিজেই কয়েকটি thread ব্যবহার করে, কিন্তু অন্য library বা পরিবেশ-চলক তা কমিয়ে দিতে পারে; torch.get_num_threads() দেখে নিন, দরকারে torch.set_num_threads(n). একই 2048 × 2048 matmul, thread বদলে (একই run-এর CPU অংশ):

~/bazarghar-dl$ uv run python device_threads.py
…
CPU threads 1:   127.2 ms per 2048x2048 matmul
CPU threads 2:    69.9 ms per 2048x2048 matmul
CPU threads 4:    37.5 ms per 2048x2048 matmul
CPU threads 8:    18.6 ms per 2048x2048 matmul

প্রায় পুরো রৈখিক লাভ: ৮ thread-এ ১ thread-এর প্রায় ৬.৮ গুণ দ্রুত। অংশ ৪-এর CPU-র সংখ্যা (default thread-এ ২৫.৫ ms) এর সঙ্গে তুলনা করুন; সেখানে GPU প্রায় ১২ গুণ দ্রুত ছিল, এক thread-এর CPU-র তুলনায় হলে দাবি হতো প্রায় ৬০ গুণ। ভাবনার প্রশ্ন ৩-এ এই ফাঁদের ইতিহাস আছে।

১০ · AI-এর যুগে — AI-এর দেওয়া গতির পরামর্শ আর benchmark যাচাই

“আমার training ধীর, দ্রুত করে দাও” বললে AI assistant এক নিঃশ্বাসে দশটি পরামর্শ দেয়: mixed precision, compile, বড় batch, num_workers, channels_last… কয়েকটি কাজে দেবে, কয়েকটি আপনার ক্ষেত্রে অর্থহীন, আর কয়েকটি পুরোনো API-তে লেখা। এই পর্বের মূল শিক্ষা এখানেই খাটে: আগে মাপুন, তারপর বদলান, তারপর আবার মাপুন।

AI-এর দেওয়া গতির পরামর্শ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• বদলের আগে আর পরে একই পদ্ধতিতে (warm-up, synchronize, median) মেপেছি
• Profiler দিয়ে দেখেছি সময় আসলে কোথায় যাচ্ছে, অনুমানে নয়
• Mixed precision-এর পর loss আর validation metric কয়েকটি seed-এ float32-এর সঙ্গে তুলনা করেছি
• API নিজের PyTorch version-এর docs-এ মিলিয়েছি, deprecated warning সারিয়েছি
• Memory-র হিসাবে parameter, gradient, optimizer state আর activation চারটিই ধরেছি
• একটি ভাগ্যবান run বা একটি batch আকার থেকে সাধারণ দাবি করিনি; hardware-এর নাম বা ব্যক্তিগত ডেটা AI-তে পেস্ট করিনি