LLM serving — batching, KV cache, throughput আর খরচ

এই পর্ব মডিউল ১৩-এর (production আর ক্যাপস্টোন) প্রথম ধাপ। আগে দরকার: KV cache-এর ধারণা (পর্ব ৩৭), TTFT আর prefill (পর্ব ৬৫), আর quantization (পর্ব ৫৯)। পাতার তিনটি ব্লক ব্রাউজারের Python আর NumPy-তে চলে; প্রথমবার প্যাকেজ নামতে কয়েক সেকেন্ড লাগে। transformers আর llama.cpp-এর সব আউটপুট ডেস্কটপের সত্যিকারের run থেকে নেওয়া, একটি যন্ত্রে, এক run-এর; এগুলো সাধারণ নিয়ম নয়।

১ · একজন থেকে অনেকজন — serving-এর প্রশ্ন আর মাপকাঠি

এ পর্যন্ত আমরা model চালিয়েছি একজনের জন্য, একটি prompt করে। LLM serving মানে একই model দিয়ে একসঙ্গে অনেক মানুষের অনুরোধের উত্তর দেওয়া। একটি অনুরোধের দুই ধাপ আপনি পর্ব ৬৫-এ দেখেছেন: prefill, যেখানে পুরো prompt একবারে চলে, আর decode, যেখানে এক এক করে token লেখা হয়। এই পর্বের প্রশ্ন: অনেক অনুরোধ একসঙ্গে এলে GPU বা CPU-কে কীভাবে ভাগ করবেন, যাতে সবাই দ্রুত উত্তর পায় আর যন্ত্রও অলস না থাকে?

আগে মাপকাঠিগুলো ঠিক করে নিই। এগুলো ছাড়া “দ্রুত” কথাটির কোনো অর্থ নেই।

এদের মধ্যে একটি সরল সম্পর্ক আছে। N-টি output token-এর একটি অনুরোধে:

E2E = TTFT + (N − 1) × TPOT

আর গড় নয়, percentile দেখুন। p50 মানে অর্ধেক অনুরোধ এর চেয়ে দ্রুত; p95 মানে ১০০ জনের ৯৫ জন এর মধ্যে পেয়েছেন। বাকি ৫ জনের ধীর অভিজ্ঞতাই tail latency. Percentile আর tail-এর ভিত্তি আছে সিস্টেম ডিজাইন কোর্সের পর্ব ৪-এ; model serving-এর সাধারণ কাঠামো মেশিন লার্নিং কোর্সের পর্ব ৬৮-এ। LLM-এ নতুন হলো: উত্তরের দৈর্ঘ্য আগে জানা নেই, আর প্রতিটি অনুরোধ চলার পুরো সময় memory দখল করে রাখে।

২ · Prefill বনাম decode — compute-bound আর memory-bound

কেন batching এত জরুরি, তা বুঝতে একটি decode ধাপের ভেতরে তাকান। নতুন একটি token বানাতে model-এর সব weight memory থেকে একবার আনতে হয়। ০.৫B parameter-এর model bf16-এ প্রায় ১ GB. অথচ এক token-এর জন্য গুণ হয় প্রতি parameter-এ মোটামুটি দুটি (একটি গুণ, একটি যোগ)। আনা প্রতি byte-এ গণনা প্রায় এক: arithmetic intensity খুব কম। GPU-র গুণের ক্ষমতা পড়ে থাকে, অপেক্ষা চলে memory-র জন্য। এ কারণে decode memory-bound (পর্ব ১২)।

এখন batch-এ ১৬টি অনুরোধ নিন। Weight একবারই আনা হয়, কিন্তু সেই weight দিয়ে ১৬টি token-এর গুণ হয়। আনা byte প্রায় একই, কাজ ১৬ গুণ। তাই ধাপের সময় সামান্য বাড়ে, কিন্তু প্রতি ধাপে token ১৬টি। Prefill-এ এই কাজ আপনা-আপনি হয়: ৫০০ token-এর prompt মানে এক pass-এ ৫০০ token-এর গুণ, তাই prefill সাধারণত compute-bound.

সত্যিকারের মাপ: Qwen2.5-0.5B-Instruct (Apache 2.0, model card দেখে নিশ্চিত), transformers-এর generate(), greedy, প্রতিটি অনুরোধে ঠিক ৬৪টি নতুন token, বাজারঘরের ১৬টি বাংলা প্রশ্ন, বাঁয়ে padding. প্রতিটি ধাপের সময় একটি ছোট LogitsProcessor দিয়ে লেখা (ধাপের শেষে synchronize-সহ)। প্রতিটি batch-এ একবার warm-up, তারপর তিনবারের median.

~/bazarghar-dl$ uv run python hf_batch.py cuda    # সত্যিকারের run, GPU-তে
torch 2.15.0+cu132 | transformers 5.22.2 | device cuda
…
layers=24 kv_heads=2 head_dim=64 dtype=torch.bfloat16 bytes=2
weights: 494,032,768 params, 942 MiB
B= 1 prompt_len(padded)=111 real_prompt_tokens=111/111 TTFT=   18.3ms TPOT= 17.02ms total=  1.10s agg=   58.0 tok/s per_req=  58.8 tok/s peak=  964.5MiB
      KV cache measured=2,138,112 B formula 2*L*kvh*hd*T*B*bytes=2,138,112 B (T=174)
      first answer: এই পদ্ধতি আমি মনে হয় যে, একটি বাইরে ডেলিভারি চার্জ (স্ট্রোড) ক
B= 4 prompt_len(padded)=115 real_prompt_tokens=441/460 TTFT=   28.7ms TPOT= 20.89ms total=  1.38s agg=  186.1 tok/s per_req=  47.9 tok/s peak=  983.9MiB
      KV cache measured=8,749,056 B formula 2*L*kvh*hd*T*B*bytes=8,749,056 B (T=178)
B=16 prompt_len(padded)=117 real_prompt_tokens=1733/1872 TTFT=   90.8ms TPOT= 21.18ms total=  1.44s agg=  709.7 tok/s per_req=  47.2 tok/s peak= 1072.2MiB
      KV cache measured=35,389,440 B formula 2*L*kvh*hd*T*B*bytes=35,389,440 B (T=180)
--- prefill time vs prompt length (B=1, median of 3) ---
T=  128 prefill=    17.2 ms      7445 prompt tok/s
T=  512 prefill=    34.1 ms     15017 prompt tok/s
T= 1024 prefill=    62.4 ms     16400 prompt tok/s
T= 2048 prefill=   120.5 ms     16999 prompt tok/s

পড়ুন, আর সৎভাবে পড়ুন:

• Batch-এর জাদু: B = ১ থেকে ১৬-এ প্রতি ধাপ মাত্র ২৪% লম্বা (১৭.০২ থেকে ২১.১৮ ms), কিন্তু মোট throughput ১২.২ গুণ (৫৮ থেকে ৭১০ token/s). একজন ব্যবহারকারীর গতি কমেছে সামান্য, ৫৮.৮ থেকে ৪৭.২ token/s.
• Prefill কত সস্তা: ২,০৪৮ token-এর prompt ১২০.৫ ms-এ, প্রায় ১৭,০০০ token/s. Decode-এ B = ১-এ ৫৮.৮ token/s. প্রতি token-এ prefill প্রায় ২৯০ গুণ দ্রুত, কারণ সব token একসঙ্গে গুণ হয়।
• সতর্কতা: ১২৮ token-এর prefill (১৭.২ ms) আর একটি decode ধাপ (১৭.০ ms) প্রায় সমান। এত ছোট model-এ GPU-তে সময়ের বড় অংশ kernel পাঠানোর স্থির খরচ (পর্ব ১২ আর ৩৭-এ দেখা), শুধু memory-র গতি নয়। বড় model-এ memory-র ভাগ বাড়ে; দিক একই থাকে, অনুপাত বদলায়। GPU তখন অন্য কাজেও ব্যবহৃত হচ্ছিল।
• গতি মান নয়: B = ১-এর উত্তরের শুরু “এই পদ্ধতি আমি মনে হয় যে…”: ০.৫B model-এর বাংলা দুর্বল। Serving দ্রুত করে, উত্তর ভালো করে না; মান মাপার কাজ পর্ব ৫৮-এর।

৩ · KV cache-এর হিসাব — প্রতি token, প্রতি অনুরোধ

Batch বাড়ালে throughput বাড়ে, তাহলে batch ১,০০০ কেন নয়? কারণ প্রতিটি অনুরোধ চলার পুরো সময় নিজের KV cache ধরে রাখে। পর্ব ৩৭-এ সূত্রটি দেখেছেন; এখন সেটি আসল model-এর config.json দিয়ে, GQA-সহ:

KV byte = 2 × L × H_kv × d_h × bytes × T × B

এখানে 2 মানে K আর V, L স্তর, H_kv KV head-এর সংখ্যা (GQA-তে query head-এর চেয়ে কম), d_h এক head-এর মাত্রা, bytes এক সংখ্যার মাপ (bf16-এ ২), T token সংখ্যা (prompt আর উত্তর মিলিয়ে), B একসঙ্গে চলা অনুরোধ। এবার Qwen2.5-1.5B-Instruct-এর আসল config থেকে, হাতে:

হাতের হিসাব আর বাস্তব মেলে কি? ০.৫B model-এ batch ১৬-এর run শেষে transformers-এর cache-এর প্রতিটি tensor-এর byte যোগ করা হয়েছে: B = ১৬, T = ১৮০ (pad-সহ prompt ১১৭ + ৬৪ − ১; শেষ token-এর K, V তখনো লেখা হয়নি): মাপা ৩,৫৩,৮৯,৪৪০ byte, আর সূত্রে 2 × 24 × 2 × 64 × 2 × 180 × 16 = ৩,৫৩,৮৯,৪৪০ byte. হুবহু এক। B = ১ আর ৪-এও তাই (২১,৩৮,১১২ আর ৮৭,৪৯,০৫৬ byte). লক্ষ করুন, T-তে pad-এর ঘরও আছে: cache pad-এর জন্যও জায়গা রাখে।

নিচের ব্লক একটি ছোট calculator. ৮ GiB memory-র একটি কাল্পনিক যন্ত্রে weight রাখার পর (১০% অন্য কাজের জন্য ছেড়ে) কয়টি অনুরোধ একসঙ্গে ধরে, prompt-এর দৈর্ঘ্য আর KV-এর dtype বদলে দেখুন। Parameter সংখ্যাও config থেকে হিসাব করা।

import numpy as np

# config.json থেকে পড়া আসল মান (Qwen2.5 Instruct, ডেস্কটপে পড়া)
MODELS = {"Qwen2.5-0.5B": dict(L=24, q_heads=14, kv_heads=2, head_dim=64, params=494_032_768),
          "Qwen2.5-1.5B": dict(L=28, q_heads=12, kv_heads=2, head_dim=128, params=1_543_714_304)}
BYTES = {"bf16": 2, "int8": 1}

def kv_per_token(m, kv_heads=None, dtype="bf16"):
    return 2 * m["L"] * (kv_heads or m["kv_heads"]) * m["head_dim"] * BYTES[dtype]

MiB, GiB = 2**20, 2**30
for name, m in MODELS.items():
    per = kv_per_token(m)
    print(f"{name}: {per:,} B/token | 2,048 tok: {per*2048/MiB:.0f} MiB"
          f" | x16: {per*2048*16/MiB:,.0f} MiB | no GQA x{m['q_heads']//m['kv_heads']}:"
          f" {kv_per_token(m, m['q_heads'])*2048/MiB:.0f} MiB")

# ৮ GiB memory-র যন্ত্রে কয়টি অনুরোধ একসঙ্গে ধরবে? weight bf16-এ, ১০% অন্য কাজে
budget = 8 * GiB
for name, m in MODELS.items():
    free = budget * 0.9 - m["params"] * 2
    for T in (512, 2048, 8192):
        n = [int(free // (kv_per_token(m, dtype=dt) * T)) for dt in ("bf16", "int8")]
        print(f"{name} T={T:5d}: KV bf16 {n[0]:5d} | KV int8 {n[1]:5d} requests")

# ডেস্কটপ run-এ মাপা byte বনাম সূত্র (0.5B, B = 16, T = 180)
measured = 35_389_440
print("formula:", kv_per_token(MODELS["Qwen2.5-0.5B"]) * 180 * 16, "| measured:", measured)

Qwen2.5-0.5B: 12,288 B/token | 2,048 tok: 24 MiB | x16: 384 MiB | no GQA x7: 168 MiB
Qwen2.5-1.5B: 28,672 B/token | 2,048 tok: 56 MiB | x16: 896 MiB | no GQA x6: 336 MiB
Qwen2.5-0.5B T=  512: KV bf16  1071 | KV int8  2143 requests
Qwen2.5-0.5B T= 2048: KV bf16   267 | KV int8   535 requests
Qwen2.5-0.5B T= 8192: KV bf16    66 | KV int8   133 requests
Qwen2.5-1.5B T=  512: KV bf16   316 | KV int8   632 requests
Qwen2.5-1.5B T= 2048: KV bf16    79 | KV int8   158 requests
Qwen2.5-1.5B T= 8192: KV bf16    19 | KV int8    39 requests
formula: 35389440 | measured: 35389440

৪ · একটি অনুরোধের জীবন — সারি, prefill, decode

Server-এ একটি অনুরোধ তিনটি জায়গায় সময় কাটায়: সারিতে, prefill-এ, আর decode-এ। নিচের সংখ্যাগুলো বানানো নয়। §৭-এর সত্যিকারের load test থেকে একটি অনুরোধ (নম্বর ১৬) নেওয়া হয়েছে: llama.cpp-এর server, ৪টি slot, CPU-তে ৩ thread, প্রতি সেকেন্ডে গড়ে ১টি অনুরোধ। সময় load test শুরুর ঘড়িতে। Client মেপেছে আগমন, প্রথম দৃশ্যমান লেখা আর শেষ; server নিজে জানিয়েছে prompt-এর token আর prefill-এর সময় (timings).

এই ভাঙন একটি গুরুত্বপূর্ণ কথা বলে: ব্যস্ত সময়ে TTFT-এর বড় অংশ prefill নয়, সারি। পর্ব ৬৫-এর prefix cache prefill কমায়, কিন্তু সারি কমায় না। সারি কমাতে লাগে বেশি slot, দ্রুত decode, বা বেশি যন্ত্র। Streaming-এ ব্যবহারকারী প্রথম লেখা দেখেন TTFT-এ, তাই chat-এ TTFT এত গুরুত্বপূর্ণ।

৫ · Static, dynamic আর continuous batching

অংশ ২ বলেছে batch বড় হলে decode-এর ধাপ প্রায় একই সময়ে বেশি token দেয়। কিন্তু LLM-এ batch বানানো ঝামেলার, কারণ কার উত্তর কত লম্বা, তা আগে জানা নেই। তিনটি কৌশল:

• Static batching: কয়েকটি অনুরোধ একসঙ্গে শুরু, আর সবচেয়ে লম্বাটি শেষ না হওয়া পর্যন্ত batch আটকে থাকে। পর্ব ৩৭-এর batched generate() এমনই।
• Dynamic batching: সারি থেকে একটি সর্বোচ্চ মাপ বা অল্প সময়ের সীমা পর্যন্ত জমিয়ে batch বানানো। Batch শুরু হলে তবু একসঙ্গে শেষ হয়।
• Continuous batching: প্রতিটি decode ধাপের পর batch নতুন করে সাজানো। শেষ হওয়া অনুরোধ সঙ্গে সঙ্গে বের হয়, নতুনটি খালি জায়গায় ঢোকে।

শেষ ধারণাটির সূত্র Yu ও সহকর্মীদের Orca প্রবন্ধ (OSDI ২০২২), যেখানে একে iteration-level scheduling বলা হয়েছে। নিচে তিনটি slot, পাঁচটি অনুরোধ। A, B, C শুরুতে আসে; D আসে ধাপ ১-এ, E ধাপ ২-এ। প্রয়োজনীয় token: A ৪, B ২, C ৩, D ২, E ১. “✓” মানে সেই অনুরোধের শেষ token, “··” মানে খালি slot.

এবার বড় পরিসরে। নিচের simulator একই seed-এ ৪০০টি অনুরোধ বানায় আর তিন পদ্ধতিতে চালায়, ৪টি slot-এ। ধাপের সময় কাল্পনিক নয়: §৭-এর llama.cpp-এর মাপ থেকে একটি সরলরেখা টেনে নেওয়া (decode ধাপ ≈ ৭.২৯ + ৪.৮৬ × b ms, prefill প্রতি token ৩.৪ ms). Static এখানে চার জন জমা হওয়া বা প্রথম জনের ০.৫ সেকেন্ড অপেক্ষা পর্যন্ত দাঁড়ায়; dynamic সারিতে যে কজন আছে, তাদের নিয়েই শুরু করে।

import numpy as np
# ধাপের সময় ডেস্কটপের সত্যিকারের মাপ থেকে (llama.cpp, CPU-তে ৩ thread, Q4_K_M):
# decode ধাপ ≈ 7.29 + 4.86 × b ms (b = batch-এ অনুরোধ), prefill ≈ 3.4 ms প্রতি prompt token
T0, T1, PF, P = 0.00729, 0.00486, 0.0034, 110

def simulate(mode, lam, N=400, SLOTS=4, WAIT=0.5, seed=83):
    rng = np.random.default_rng(seed)
    arr = np.cumsum(rng.exponential(1 / lam, N)); out = rng.choice([32, 64, 128], N)
    t, i, q, run = 0.0, 0, [], {}
    first, done = np.zeros(N), np.zeros(N)
    while i < N or q or run:
        while i < N and arr[i] <= t: q.append(i); i += 1
        if not run and not q: t = arr[i]; continue
        if mode == "static" and not run and len(q) < SLOTS and i < N and t < arr[q[0]] + WAIT:
            t = min(arr[i], arr[q[0]] + WAIT); continue            # batch ভরার অপেক্ষা
        if q and (mode == "continuous" or not run):              # কে কখন ঢুকতে পারে
            new, q = q[:SLOTS - len(run)], q[SLOTS - len(run):]
            t += PF * P * len(new)                                # নতুনদের prefill
            for r in new: run[r] = out[r] - 1; first[r] = t
        t += T0 + T1 * len(run)                                   # এক decode ধাপ
        for r in list(run):
            run[r] -= 1
            if run[r] <= 0: done[r] = t; del run[r]
    ttft, e2e = first - arr, done - arr
    return out.sum() / done.max(), np.percentile(ttft, [50, 95]), np.percentile(e2e, [50, 95])

print("mode         λ/s  tok/s  TTFT p50  p95   E2E p50  p95")
for lam in (0.5, 0.8, 1.0):
    for m in ("static", "dynamic", "continuous"):
        th, tt, ee = simulate(m, lam)
        print(f"{m:11s} {lam:4.1f} {th:6.1f}  {tt[0]:7.2f} {tt[1]:6.2f}  {ee[0]:6.2f} {ee[1]:6.2f}")

mode         λ/s  tok/s  TTFT p50  p95   E2E p50  p95
static       0.5   40.3     1.22   3.26    2.42   4.95
dynamic      0.5   40.3     0.80   2.98    1.92   4.85
continuous   0.5   40.3     0.38   0.98    1.91   4.79
static       0.8   64.3     2.39   7.57    3.97   9.12
dynamic      0.8   64.2     2.14   7.02    3.70   8.78
continuous   0.8   64.4     0.43   3.57    2.96   7.52
static       1.0   77.4    17.81  25.85   19.78  27.63
dynamic      1.0   77.7    16.91  25.05   18.64  27.08
continuous   1.0   80.3     3.49  12.10    6.63  15.79

৬ · PagedAttention আর prefix caching — KV memory-র অপচয় কমানো

Continuous batching-এ অনুরোধ আসে-যায়, আর প্রত্যেকের KV cache বাড়ে এক token করে। সরল বাস্তবায়ন প্রতিটি অনুরোধের জন্য সর্বোচ্চ দৈর্ঘ্যের একটি টানা জায়গা আগেই রেখে দেয়। ধরুন সীমা ২,০৪৮ token, অথচ বাজারঘরের গড় প্রশ্ন আর উত্তর মিলিয়ে ৩০০ token. তাহলে রাখা জায়গার প্রায় ৮৫% কখনো ব্যবহারই হয় না। Batch-এ padding-ও একই অপচয় করে: আমাদের batch ১৬-এর run-এ prompt-এর ১,৮৭২টি ঘরের ১৩৯টি ছিল pad (৭.৪%), যদিও বাজারঘরের প্রশ্নগুলো প্রায় সমান লম্বা। দৈর্ঘ্যের পার্থক্য বেশি হলে অপচয়ও বাড়ে।

PagedAttention (Kwon ও সহকর্মী, SOSP ২০২৩; vLLM-এর ভিত্তি) সমাধানটি নিয়েছে অপারেটিং সিস্টেম থেকে। KV cache ভাগ হয় ছোট, সমান মাপের block-এ, যেমন প্রতি block-এ ১৬টি token. প্রতিটি অনুরোধের একটি block table থাকে: “আমার ০ নম্বর block আছে memory-র ৭ নম্বর ঘরে, ১ নম্বর ১ নম্বর ঘরে …”। Block টানা জায়গায় থাকতে হয় না। নতুন block লাগে শুধু আগেরটি ভরে গেলে, তাই অপচয় প্রতি অনুরোধে বড়জোর একটি অসম্পূর্ণ block. ধারণাটি অপারেটিং সিস্টেম কোর্সের paging আর virtual memory-র পর্বে দেখা page table-এর মতোই।

এর দুটি বড় লাভ। এক, memory বাঁচে বলে একই GPU-তে বেশি অনুরোধ একসঙ্গে চলে, আর অংশ ২ অনুযায়ী বড় batch মানে বেশি throughput. প্রবন্ধটির সারাংশ দাবি করে, KV memory-র অপচয় “প্রায় শূন্য”, আর FasterTransformer ও Orca-র মতো ব্যবস্থার তুলনায় একই latency-তে throughput ২–৪ গুণ; এটি তাঁদের পরীক্ষার শর্তের ফল, সব ক্ষেত্রের নয়। দুই, block ভাগ করা যায়। একই system prompt-এর block দুটি অনুরোধ একসঙ্গে পড়তে পারে; কেউ লিখতে চাইলে তখন কপি হয়, অর্থাৎ copy-on-write. এটিই server-এর prefix caching-এর ভিত্তি, যার লাভ আপনি পর্ব ৬৫-এ নিজের যন্ত্রে মেপেছেন। SGLang-এর প্রবন্ধ (Zheng ও সহকর্মী, ২০২৩) এই পুনর্ব্যবহারকে একটি radix tree-তে সাজায়, নাম RadixAttention.

দামও আছে। Attention kernel-কে এখন ছড়ানো block থেকে পড়তে হয়, তাই kernel জটিল হয়। Block ছোট হলে অপচয় কম, কিন্তু table বড়; বড় হলে উল্টো। আর memory ফুরালে server-কে কাউকে থামাতে হয়: তার block মুছে পরে আবার prefill করা, বা CPU memory-তে সরিয়ে রাখা।

৭ · সত্যিকারের server — llama.cpp, quantization আর load test

এবার একটি আসল serving engine. llama.cpp-এর অফিসিয়াল Windows CPU binary (build 12211; প্রকল্পটি প্রায় প্রতিদিন নতুন build দেয়, আর GitHub-এ এগুলো pre-release হিসেবে চিহ্নিত), আর Qwen-এর নিজের প্রকাশ করা GGUF ফাইল (Qwen2.5-0.5B-Instruct-GGUF, Apache 2.0). সব run CPU-তে, ৩টি thread; মেশিনে একই সময়ে অন্য কাজও চলছিল।

ধাপ ১: quantization আর গতি. llama-bench দিয়ে prompt-এর গতি (pp) আর লেখার গতি (tg), তিনবারের গড় ± বিচ্যুতি:

(সত্যিকারের run-এর আউটপুট থেকে, কয়েকটি কলাম বাদ দিয়ে; সর্বোচ্চ RAM আলাদা একটি ছোট script process-টির peak working set পড়ে মেপেছে।) এখানে অংশ ২-এর তত্ত্বের সুন্দর প্রমাণ: Q4_K_M-এ লেখার গতি ৩৬% বেশি (৬২ থেকে ৮৪ token/s), কারণ decode-এ প্রতি ধাপে কম byte পড়তে হয়। কিন্তু prompt-এর গতিতে কোনো লাভ নেই, pp512-এ বরং কিছু কম, কারণ prefill compute-bound, আর ৪-bit থেকে সংখ্যা খুলতেও হিসাব লাগে।

ধাপ ২: CPU-তে batch. llama-batched-bench-এ ১২৮ token-এর prompt আর ৬৪ token-এর উত্তর, একসঙ্গে B-টি অনুরোধ (Q4_K_M):

প্রথম দুটি কলাম সত্যিকারের আউটপুটের S_TG আর T_TG থেকে (T_TG ÷ ৬৪ = এক ধাপ)। CPU-র ছবি GPU-র মতো নয়। B = ১৬-এ মোট গতি মাত্র ২.৪ গুণ, আর ধাপ সাড়ে ছয় গুণ লম্বা। তিনটি CPU thread-এর গণনার ক্ষমতা কম, তাই batch একটু বাড়তেই কাজ compute-bound হয়ে যায়। এই CPU-তে ৪–৮-এর পর লাভ সামান্য, অথচ প্রত্যেকের লেখা অনেক ধীর।

ধাপ ৩: load test. llama-server একটি OpenAI-compatible API দেয়, তাই একই client কোড অন্য engine-এও চলত। Server খোলা হয় শুধু 127.0.0.1-এ; কাজ শেষে নিজের process ID দিয়ে বন্ধ। Slot সংখ্যা --parallel-এ। প্রতি slot-এ ২,০৪৮ token-এর context. সংক্ষেপিত command (আসল run-এ অন্য একটি port, আর একটি Python script server চালু ও বন্ধ করেছে):

~/bazarghar-dl$ llama-server -m qwen2.5-0.5b-instruct-q4_k_m.gguf \
    --host 127.0.0.1 --port 8000 -t 3 --parallel 4 -c 8192 --no-webui

আমাদের load generator (Python, httpx) seed ৮৩-এ ২৪টি অনুরোধ বানায়: Poisson আগমন (Poisson arrivals), বাজারঘরের ৮টি বাংলা প্রশ্নের একটি, আর উত্তরের দৈর্ঘ্য ৩২, ৬৪ বা ১২৮ token. দৈর্ঘ্য স্থির রাখতে ignore_eos, আর ন্যায্য তুলনার জন্য prompt cache বন্ধ। প্রতিটি অনুরোধ streaming-এ চলে, আর client প্রতিটির TTFT, TPOT, E2E লেখে। এটি open-loop: server ধীর হলেও অনুরোধ নির্ধারিত সময়েই যায়। একই seed-এ পাঁচটি run:

• A বনাম B (λ = ১): ৪টি slot-এ TTFT-এর p95 ৭.৬৭ থেকে ২.২৬ s, E2E-এর p95 ৮.৫১ থেকে ৫.৭২ s. দাম: TPOT ১২ থেকে ৩৮ ms, কারণ প্রতিটি ধাপ চারজনে ভাগ। ৩৮ ms মানে সেকেন্ডে প্রায় ২৬টি token; বাংলায় একটি শব্দে প্রায়ই কয়েকটি token লাগে, তাই এই গতি পড়ার গতির কাছাকাছি হতে পারে। তবু ৭ সেকেন্ডের খালি পর্দার চেয়ে এটি অনেক কম চোখে লাগে।
• C, D, E (λ = ২, চাহিদা ক্ষমতার বেশি): একটি slot-এ সারি ফুলে ওঠে, TTFT p95 ১৫.৫ s. Continuous batching-সহ ৪টি slot-এ (E) throughput ৪০% বেশি, ৭৭.৯ token/s, আর TTFT p95 অর্ধেকেরও কম।
• D একটি আকর্ষণীয় ফল: ৪টি slot থাকলেও continuous batching বন্ধ করলে ফল প্রায় একটি slot-এর মতো। Server-এর help এই flag-কে শুধু continuous batching চালু বা বন্ধ বলে; ভেতরে ঠিক কী বদলায়, নথিতে বিস্তারিত পাইনি। তাই এটি আমাদের একটি run-এর পর্যবেক্ষণ, ব্যাখ্যা নয়।
• সাবধানে পড়ুন: λ = ১-এ token/s মূলত ট্রাফিকের মাপ: ২৪টি অনুরোধে মোট ১,৬৩২ token, যা আসতেই প্রায় ২৪ সেকেন্ড লাগে। যন্ত্রের সর্বোচ্চ ক্ষমতা জানতে ধাপ ২-এর batched-bench দেখুন। Server-এর সর্বোচ্চ RAM ১ slot-এ ৫২০ MiB, ৪ slot-এ ৬০৬–৬২৩ MiB; পার্থক্যের বড় অংশ বাড়তি context-এর KV cache হওয়ার কথা (f16 ধরে সূত্রে ৯৬ বনাম ২৪ MiB).
• সংখ্যা ছোট: ২৪টি অনুরোধ, একটি seed; p95 এখানে দু-একটি অনুরোধের ওপর দাঁড়িয়ে। সিদ্ধান্তের জন্য কয়েকশো অনুরোধ আর কয়েকটি seed লাগবে।

নিচের ব্লকে λ = ১-এর দুটি run-এর প্রতিটি অনুরোধের আসল সংখ্যা বসানো আছে। Percentile আবার হিসাব হয়, আর Little-এর সূত্র L = λ × W দুইভাবে যাচাই হয়: একবার সূত্রে, একবার প্রতিটি মুহূর্তে ভেতরে কয়টি অনুরোধ তা গুনে।

import numpy as np

# ডেস্কটপের সত্যিকারের load test: প্রতিটি অনুরোধের (আগমন s, TTFT s, E2E s, output token)
RUNS = {
 "slots=1": [(0.685, 0.479, 0.869, 32), (0.824, 1.117, 1.514, 32), (3.862, 0.426, 0.806, 32), (4.053, 0.978, 1.36, 32),
   (4.582, 1.185, 1.96, 64), (5.405, 1.508, 2.287, 64), (6.947, 1.121, 1.896, 64), (10.311, 0.434, 0.818, 32),
   (10.331, 1.165, 1.942, 64), (10.82, 1.847, 3.425, 128), (13.504, 1.091, 1.872, 64), (14.11, 1.618, 2.413, 64),
   (14.372, 2.515, 4.117, 128), (15.086, 3.79, 5.362, 128), (15.224, 5.572, 6.36, 64), (16.897, 5.077, 6.644, 128),
   (16.933, 6.97, 7.739, 64), (17.828, 7.211, 7.587, 32), (20.786, 5.008, 5.799, 64), (20.889, 6.081, 6.467, 32),
   (21.001, 6.707, 8.272, 128), (21.918, 7.74, 8.547, 64), (23.554, 7.3, 8.097, 64), (23.939, 8.083, 8.861, 64)],
 "slots=4": [(0.686, 0.426, 1.306, 32), (0.823, 0.682, 1.18, 32), (3.863, 0.427, 2.317, 32), (4.054, 0.621, 2.155, 32),
   (4.583, 0.464, 2.837, 64), (5.406, 0.422, 2.279, 64), (6.947, 0.442, 1.303, 64), (10.311, 0.446, 2.023, 32),
   (10.338, 0.802, 2.553, 64), (10.819, 0.733, 4.176, 128), (13.504, 0.415, 3.178, 64), (14.111, 0.411, 3.19, 64),
   (14.373, 0.541, 5.389, 128), (15.087, 0.468, 5.295, 128), (15.224, 1.845, 3.895, 64), (16.897, 0.808, 6.04, 128),
   (16.934, 2.568, 5.389, 64), (17.829, 2.328, 3.57, 32), (20.787, 0.456, 3.621, 64), (20.889, 0.901, 2.467, 32),
   (21.001, 1.704, 5.781, 128), (21.919, 1.436, 3.854, 64), (23.553, 0.442, 2.454, 64), (23.94, 0.87, 2.498, 64)],
}

for name, rows in RUNS.items():
    a = np.array(rows, dtype=float)
    arrive, ttft, e2e, n = a.T
    end = (arrive + e2e).max()
    tpot = (e2e - ttft) / (n - 1)
    lam, W = len(a) / end, e2e.mean()                               # জানালা: 0 থেকে শেষ উত্তর
    t = np.linspace(0, end, 2001)                                  # প্রতিটি মুহূর্তে কয়টি অনুরোধ ভেতরে
    inside = ((arrive[:, None] <= t) & (t < (arrive + e2e)[:, None])).sum(0)
    print(f"{name}: {n.sum() / end:5.1f} tok/s | TTFT p50 {np.percentile(ttft, 50):.2f} "
          f"p95 {np.percentile(ttft, 95):.2f} | TPOT p50 {np.percentile(tpot, 50) * 1000:.0f} ms "
          f"| E2E p95 {np.percentile(e2e, 95):.1f} s")
    print(f"   Little: lambda x W = {lam:.2f} x {W:.2f} = {lam * W:.2f} | time-average in system = {inside.mean():.2f}")

slots=1:  49.8 tok/s | TTFT p50 2.18 p95 7.67 | TPOT p50 12 ms | E2E p95 8.5 s
   Little: lambda x W = 0.73 x 4.38 = 3.20 | time-average in system = 3.20
slots=4:  60.9 tok/s | TTFT p50 0.58 p95 2.26 | TPOT p50 38 ms | E2E p95 5.7 s
   Little: lambda x W = 0.90 x 3.28 = 2.94 | time-average in system = 2.94

৮ · আরও কৌশল আর serving engine

Quantization দিয়ে serving. Decode memory-bound, তাই weight ছোট হলে প্রতি ধাপে কম byte আসে, আর ধাপ দ্রুত হয়। §৭-এর llama.cpp run-এ এটিই দেখা গেছে। Scale আর zero point-এর গণিত পর্ব ৫৯-এ; এখানে শুধু serving-এর দিক। KV cache-ও quantize করা যায় (যেমন ৮-bit), তখন প্রতি অনুরোধের memory অর্ধেক হয় আর একসঙ্গে বেশি অনুরোধ ধরে। দুই ক্ষেত্রেই উত্তরের মান নিজের eval set-এ (পর্ব ৫৮) যাচাই করতে হয়; বাংলা লেখায় ক্ষতি ইংরেজির চেয়ে আলাদা হতে পারে।

Chunked prefill. একটি ৮,০০০ token-এর prompt এলে তার prefill অনেক সময় নেয়, আর সেই সময় অন্যদের decode থেমে থাকতে পারে; তাদের ITL হঠাৎ লাফ দেয়। সমাধান: লম্বা prefill টুকরো করে প্রতিটি ধাপে decode-এর সঙ্গে মিশিয়ে চালানো। মোট কাজ একই, কিন্তু কেউ দীর্ঘক্ষণ আটকে থাকে না।

Speculative decoding. পর্ব ৩৭-এ নামটি এসেছিল: একটি ছোট খসড়া model k-টি token আগাম লেখে, আর বড় model এক pass-এ সেগুলো যাচাই করে। Leviathan ও সহকর্মীদের (২০২৩) বিশ্লেষণে, প্রতিটি খসড়া token গ্রহণের সম্ভাবনা α ধরলে বড় model-এর প্রতি pass-এ গড়ে (1 − α^k+1) ÷ (1 − α)-টি token মেলে। α = ০.৮, k = ৪ হলে (১ − ০.৮^৫) ÷ ০.২ = (১ − ০.৩২৭৭) ÷ ০.২ ≈ ৩.৩৬. তবে এটি গতির সরাসরি গুণ নয়: খসড়া model-এর নিজের সময় আছে। আর লাভটি আসে decode-এর অলস compute কাজে লাগিয়ে; batch বড় হয়ে GPU আগেই ব্যস্ত হলে লাভ কমে যেতে পারে। সঠিক rejection নিয়ম মানলে output-এর বণ্টন বড় model-এর সমান থাকে, প্রবন্ধটির দাবি অনুযায়ী।

Serving engine. নিজে scheduler আর kernel লেখার দরকার সাধারণত হয় না। নিচের তথ্য প্রতিটির নিজস্ব নথি বা README থেকে, লেখার সময়ে (নভেম্বর ২০২৬); এসব দ্রুত পরিবর্তন হতে পারে। এটি কোনো র‍্যাংকিং নয়।

Ollama-র নিয়মটি লক্ষ করুন: parallel অনুরোধ ৪ করলে context-এর memory চার গুণ। এটি §৩-এর সূত্রেরই প্রয়োগ। Engine বদলালেও KV cache-এর অঙ্ক বদলায় না।

৯ · খরচ — টাকা নয়, GPU-সেকেন্ডে ভাবা

দাম বদলায়, দেশ আর সরবরাহকারী ভেদে আলাদা; তাই এই পর্বে টাকার অঙ্ক নেই। কিন্তু খরচের কাঠামো স্থির: যন্ত্র যতক্ষণ চলে, ততক্ষণের দাম। তাই খরচ মাপুন যন্ত্র-সেকেন্ড প্রতি token-এ:

১০ লাখ token-এর যন্ত্র-সময় = ১০,০০,০০০ ÷ (মোট token/s)

আমাদের মাপা সংখ্যা বসাই (Qwen2.5-0.5B-Instruct, একটি local run):

একই GPU, একই model: B = ১৬-এ একই সংখ্যক token-এর যন্ত্র-সময় B = ১-এর বারো ভাগের এক ভাগ। শেষ সারিটি বাস্তবের সবচেয়ে বড় শিক্ষা: load test-এ যন্ত্র নিজের ক্ষমতার চেয়ে কম কাজ পেয়েছে, তাই হিসাবে খরচ বেশি দেখায়। যন্ত্র অলস বসে থাকলেও সময়ের দাম দিতে হয়, তাই ব্যবহারের হার (utilization) খরচের সবচেয়ে বড় চাবি। হিসাবে prompt-এর token ধরা হয়নি; লম্বা prompt-এর prefill-এরও যন্ত্র-সময় আছে, যা পর্ব ৬৫-এর prefix cache কমায়। আর এই GPU-র memory-র একটি অংশ মাত্র ব্যবহার হয়েছে, অন্য কাজও চলছিল।

পর্ব ৮৫-এ পুরো বাজারঘর সহায়কের capacity হিসাব হবে: দিনে কত অনুরোধ, প্রতি অনুরোধে কত token, তা থেকে প্রয়োজনীয় token/s আর যন্ত্রের সংখ্যা। সেখানে এই সারণির সংখ্যা একটি শুরুর বিন্দু হতে পারে, তবে নিজের model আর যন্ত্রে আবার মাপা ছাড়া নয়।

১০ · AI-এর যুগে — serving-এর কোড আর গতির দাবি যাচাই

AI assistant serving config বা benchmark মিনিটে লিখে দেয়; ভুল config-ও চলে, ভুল benchmark-ও সুন্দর সংখ্যা ছাপে।

AI-এর লেখা serving config বা benchmark হাতে পেলে — যাচাইয়ের চেকলিস্ট

• KV cache-এর হিসাব config.json-এর আসল সংখ্যায় হাতে মিলিয়েছি, আর একটি run-এ মাপা byte-এর সঙ্গে তুলনা করেছি
• প্রতিটি flag নিজের সংস্করণের --help বা README-তে খুঁজে পেয়েছি
• Benchmark-এ seed, আগমনের হার, output-এর দৈর্ঘ্য আর warm-up লিখে রেখেছি; কয়েকবার চালিয়েছি
• TTFT, TPOT, E2E আলাদা করে, percentile-সহ দেখেছি; Little-এর সূত্রে মিলিয়েছি
• Quantized বা নতুন config-এ উত্তরের মান নিজের eval set-এ যাচাই করেছি, শুধু গতি নয়
• Server শুধু 127.0.0.1-এ খুলেছি, কাজ শেষে নিজের process ID দিয়ে বন্ধ করেছি; গ্রাহকের আসল ডেটা বা key AI-কে পাঠাইনি