شروع پروژه

چیت‌شیت

متریک‌های استنتاج و آزمون بار

Inference Metrics and Load Testing

چرا نتایج آزمون بار فریبنده است؟ TTFT، TPOT، نرخ پردازش موثر، P99، پرامپت‌های واقعی، طوفان‌های تلاش مجدد و خواندن‌های پوششی (hedged reads).

  • ۱۱ بخش
  • ۲ درس مرتبط
  • کد و دستورها عیناً از دوره‌ی اصلی
فهرست مطالب
  1. نشانه‌ها، علت‌ها، راه‌حل‌ها
  2. فرمول‌های متریک
  3. پروفایل‌های SLO در main.py
  4. چهار الگوی بارگذاری
  5. موارد کاربرد هر ابزار
  6. اجرای آزمایش‌ها
  7. مقادیر پیش‌فرض فلگ‌های آزمایش
  8. رشته‌های خطای آزمایش
  9. یک خواندن پوششی (hedged read)
  10. محاسبات عددی نمونه
  11. اعداد مرجع و گیت‌های کنترلی

نشانه‌ها، علت‌ها، راه‌حل‌ها

عیب‌یابی

  • تست روی 500 کاربر دوام آورد، پروداکشن روی 200 شکست خورد

    علت
    پرامپت‌های یکسان به کش پیشوند (prefix cache) برخورد کردند
    راه‌حل
    --mean-input-tokens به همراه --stddev-input-tokens

  • مقدار ITL در Locust بالا است، سرور مشکلی ندارد

    علت
    تله قفل سراسری مفسر: انباشت توکن‌سازی در کلاینت
    راه‌حل
    LLM-Locust یا یک بستر آزمایشی کامپایل‌شده

  • مقدار TPOT در GenAI-Perf برابر 6 میلی‌ثانیه، در LLMPerf برابر 11 میلی‌ثانیه

    علت
    ابزار GenAI-Perf مقدار TTFT را از ITL حذف می‌کند
    راه‌حل
    نام ابزار و تعریف دقیق آن را مشخص کنید

  • نرخ پردازش بالا، خروج کاربران

    علت
    نرخ پردازش موثر پایین، دم توزیع SLO را نقض می‌کند
    راه‌حل
    اعمال گیت‌های کنترلی برای دیپلوی بر اساس نرخ پردازش موثر

  • میانگین TPOT برابر 9 میلی‌ثانیه، نارضایتی کاربران

    علت
    دم توزیع با چولگی به راست، مقدار P99 TPOT برابر 65 میلی‌ثانیه
    راه‌حل
    گزارش P50، P90، P99

  • جهش لحظه‌ای TPOT به 50 میلی‌ثانیه

    علت
    پیش‌پرکنی طولانی در توالی همسایه
    راه‌حل
    پیش‌پرکنی تکه‌ای

  • تلاش مجدد هم‌زمان تمام کلاینت‌ها

    علت
    زمان‌های انتظار نمایی همگام‌شده
    راه‌حل
    --jitter=true و یک --budget مشترک

  • پوشش درخواست‌ها به ظاهر بدون هزینه است

    علت
    لغو درخواست کار سرور را متوقف نمی‌کند
    راه‌حل
    محاسبه کار مجموعه‌داده‌ی نمونه در کنار تاخیر

فرمول‌های متریک

کد
text
TTFT = queue_time + network_request + prefill_time                   # پیش از آغاز استریمینگ
TPOT = (decode_forward_time + scheduler_overhead) / tokens_produced  # مشابه ITL
E2E = TTFT + TPOT * output_tokens + network_response                 # غلبه TPOT در بالای 500 توکن
throughput = total_output_tokens / elapsed_time                      # صرفاً کارایی ناوگان سرور
goodput = fraction of requests meeting (TTFT <= a) AND (TPOT <= b) AND (E2E <= c)

پروفایل‌های SLO در main.py

مقایسه
فاکتورآسان‌گیر (loose)هدف (target)سخت‌گیر (tight)
TTFT به میلی‌ثانیه800500300
TPOT به میلی‌ثانیه251510
E2E به میلی‌ثانیه300020001500
حکم ارزیابیSHIPPABLE در 99٪DEGRADED در 95٪FAILING پایین‌تر از آن

چهار الگوی بارگذاری

مقایسه
فاکتورحالت پایدار (Steady-state)شیب صعودی (Ramp)جهش لحظه‌ای (Spike)آزمون استقامت (Soak)
شکل الگوRPS ثابتاز 0 تا RPS هدفافزایش ناگهانی 3 تا 10 برابری RPS و بازگشتحالت پایدار
مدت زمان30 تا 60 دقیقه15 دقیقه2 دقیقه4 تا 8 ساعت
موارد شناساییپسرفت‌های خط مبنانقطه شکست ظرفیت، ناهنجاری‌های راه‌اندازی اولیه (warm-up)تاخیر مقیاس‌پذیری خودکار، اشباع صف، شروع سردنشت حافظه، دریفت مخزن اتصالات (connection-pool)

موارد کاربرد هر ابزار

مفهوم‌ها
LLMPerf
اجرای بنچمارک. توکن‌سازی مبتنی بر Rust، پرامپت‌های دارای میانگین/انحراف معیار.
GenAI-Perf
نیاز به مرجع NVIDIA. مقدار ITL شامل TTFT نمی‌شود.
LLM-Locust
تیم شما از Locust استفاده می‌کند. تله قفل سراسری مفسر را رفع می‌کند.
guidellm
بنچمارک ترکیبی و مصنوعی در مقیاس بالا.
k6 v2026.1.0
گیت‌های کنترلی CI/CD و آزمون‌های SLA. سازگار با استریمینگ، بدون GIL.
k6 Operator
آزمون‌های توزیع‌شده با CRDهای TestRun / PrivateLoadZone.
Vegeta
اشباع یک درگاه (gateway) یا محدودیت نرخ درخواست با نرخ ثابت.
نسخه پیش‌فرض Locust 2.43.3
هرگز به تنهایی برای LLMها استفاده نشود. دچار تله قفل سراسری مفسر است.

اجرای آزمایش‌ها

کد
bash
python3 scripts/project_test.py retry-storm-lab --init /tmp/retry-storm-lab-work
python3 scripts/project_test.py retry-storm-lab --all --solution --strict
cd projects/retry-storm-lab/solution
go run . --clients 20 --budget 60 --jitter=false --out /tmp/synchronized.json      # انتظارهای همگام‌شده
go run . --clients 20 --budget 60 --jitter=true --seed 7 --out /tmp/jittered.json  # پراکندگی بر اساس seed
go run . --local-http --clients 20 --budget 12 --out /tmp/retry-wire.json          # درخواست HTTP لوپ‌بک واقعی
node --experimental-strip-types cli.ts /tmp/retry-wire.json                        # اعتبارسنجی شمارنده‌ها
cd projects/hedged-request-lab/solution
go run . --samples 3 --delay-ms 10 --out /tmp/hedge-report.json                    # درخواست اولیه 80 میلی‌ثانیه، ثانویه 5 میلی‌ثانیه

مقادیر پیش‌فرض فلگ‌های آزمایش

پیش‌فرض‌ها
تنظیمپیش‌فرضنکته
--clients20کلاینت‌های هم‌روند
--budget12تلاش‌های مجدد اشتراکی
--base-ms10عقب‌گرد اولیه
--max-ms80حداکثر زمان انتظار تلاش مجدد
--attempts4حداکثر دفعات تلاش به ازای هر کلاینت
--capacity5ظرفیت شبیه‌سازی‌شده به ازای هر میلی‌ثانیه دقیق
--delay-ms10تاخیر درخواست پوششی (hedge delay)
--samples3نمونه‌ها به ازای هر سیاست

رشته‌های خطای آزمایش

دستورها
دستورعملکرد
invalid bounded policyپایه کمتر از 1، سقف کمتر از پایه، یا دفعات تلاش بیشتر از 10
non-retryable HTTP statusوضعیت مغایر با 429، 502، 503 یا 504 است
server delay exceeds policy capمقدار Retry-After بیش از سقف سیاست است
retry attempts or shared budget exhaustedهیچ تلاش یا بودجه‌ای باقی نمانده است
winner requires HTTP 200یک خطای سریع نمی‌تواند برنده درخواست پوششی شود
body exceeds 64 KiBحجم بدنه پاسخ بیش از حد مجاز خواندن است
no valid responseهر دو تلاش پوششی شکست خوردند
samples must be 1..100تعداد نمونه خارج از محدوده است

یک خواندن پوششی (hedged read)

گام‌به‌گام
  1. Clientدرخواست GET اولیه و زمان‌سنج تاخیر را شروع می‌کند.
  2. Clientپاسخ معتبر اولیه قبل از اتمام زمان‌سنج، مانع ارسال درخواست پوششی می‌شود.
  3. Clientدر غیر این صورت حداکثر یک درخواست ثانویه ارسال می‌کند. تاخیر بین 0 تا 1 ثانیه است.
  4. Validatorفقط وضعیت HTTP 200 با مقدار JSON غیرخالی برنده است.
  5. Clientدرخواست بازنده را لغو کرده و حداکثر 100ms آن را زیر نظر می‌گیرد.
  6. Receiptتلاش‌های دیرهنگام، رصدنشده و تاخیر برنده را ثبت می‌کند.
  7. Fixtureکار سرور را که پس از لغو ادامه دارد محاسبه می‌کند.

محاسبات عددی نمونه

پرسش و پاسخ
مقدار TTFT برابر 500 میلی‌ثانیه، رمزگشایی 100 توکن در 700 میلی‌ثانیه؟
در GenAI-Perf مقدار ITL = 700/99 = 7.07 ms. در LLMPerf مقدار ITL = 1200/100 = 12.00 ms.
20 کلاینت، 4 تلاش، بودجه 12؟
حداکثر 32 فراخوانی در کل.
پایه 10، سقف 25، بدون نوسان تصادفی؟
زمان‌های انتظار 10,20,25,25.
سه نمونه خط مبنا و سه نمونه پوششی؟
3 فراخوانی در برابر 6 فراخوانی. مجموعه‌داده‌ی نمونه 9 مورد را ثبت می‌کند.
نمونه‌های [2,4,10,20,80]؟
P50=10، P95=80، حداکثر=80.
درخواست اولیه HTTP 500 در 1ms، درخواست ثانویه معتبر در 15ms؟
درخواست ثانویه برنده می‌شود. خطای سریع برنده نخواهد بود.

اعداد مرجع و گیت‌های کنترلی

نکته‌ها
  • مدل Llama-3.1-8B-Instruct روی TRT-LLM: میانگین TTFT برابر 162 ms، میانگین TPOT برابر 7.33 ms.
  • معیار SLO برای مدل 70B کاربران عادی: TTFT P99 <= 800 ms، TPOT P99 <= 25 ms، نرخ پردازش موثر >= 99%.
  • اجرا با 2 برابر حداکثر هم‌روندی. تکرار بین 30 تا 50 بار.
  • استفاده از --mean-input-tokens 800 --stddev-input-tokens 300 --mean-output-tokens 150.
  • گیت CI: تاخیر P50/P95 TTFT، خطای 5xx کمتر از 5٪، TPOT زیر آستانه. شکست بیلد در صورت نقض.
  • انتشار نام ابزار، نسخه ابزار، مدل، سخت‌افزار، هم‌روندی و توزیع پرامپت.

درس‌هایی که این موضوع را از صفر می‌سازند