ساخت پایپ‌لاین کامل LLM: از داده تا سرویس‌دهی نهایی

توسعه‌ی یک مدل زبانی بزرگ تنها به اجرای چند نوت‌بوک مجزا برای آموزش توکنایزر، پیش‌آموزش یا تیونینگ محدود نمی‌شود. در عمل، اتصال این اجزا بدون خطای انسانی، خرابی داده‌ها و هدررفت بودجه، نیازمند معماری یکپارچه‌ای است که تمام مراحل را از داده تا سرو مدل به شکلی پایدار هدایت کند.

در این درس پایانی، اسکلت مهندسی و ارکستراسیون یک پایپ‌لاین سرتاسری LLM را بر پایه‌ی مانیفست‌های بازتولیدپذیر، ردگیری دقیق آرتیفکت‌ها بر اساس هش محتوا و گیت‌های سنجش کیفیت پیاده می‌کنید؛ چارچوبی که تیم‌های پیشرو هوش مصنوعی برای جلوگیری از خطاهای پرهزینه به کار می‌برند.

هر آنچه از درس 01 تا 12 آموختید، تنها یک مرحله از یک پایپ‌لاین بود. این درس نقش داربستی را دارد که آن مراحل را به یک اجرای یکپارچه‌ی سرتاسری (end-to-end) تبدیل می‌کند: توکنایز، پیش‌آموزش، مقیاس‌پذیری، SFT، هم‌راستاسازی، ارزیابی، کوانتایز و سرو. شما قرار نیست یک مدل 70B را روی لپ‌تاپ آموزش دهید؛ بلکه لایه‌ی هماهنگ‌کننده (orchestration layer)، مانیفست (manifest)، گیت ارزیابی (eval gate) و طرح بازگشت به عقب (rollback plan) را می‌سازید؛ یعنی همان ابزارهایی که یک تیم پیشرو در سال 2026 برای تصمیم‌گیری درباره‌ی انتشار مدل به کار می‌برد. این پروژه‌ی پایانی (capstone) است.

اهداف یادگیری

• ترکیب دوازده درس پیشین (دو درس توکنایزر، داده، پیش‌آموزش، مقیاس‌پذیری، SFT، RLHF، DPO، CAI، ارزیابی، کوانتایز و استنتاج) در قالب مشخصات یک پایپ‌لاین بازتولیدپذیر واحد
• تعریف قرارداد آرتیفکت (artifact contract) بین مراحل: ورودی هر مرحله چیست، چه خروجی‌ای تولید می‌کند و مرحله‌ی بعد چگونه ورودی را اعتبارسنجی می‌کند
• ساخت یک هماهنگ‌کننده (orchestrator) که آزمایش‌ها را ردگیری، آرتیفکت‌ها را هش‌گذاری و تصمیم‌های انتشار را بر اساس آستانه‌های ارزیابی کنترل می‌کند
• طراحی طرح بازگشت به عقب: اجرای مجدد کدام آرتیفکت‌ها ارزان و کدام‌یک گران است، و یک چک‌پوینت خراب چقدر هزینه روی دست تیم می‌گذارد

صورت مسئله

کدهای درس‌های قبلی به‌تنهایی کار می‌کنند. توکنایزر آموزش دیده؛ مدل Tiny GPT پیش‌آموزش دیده؛ مجموعه‌داده‌ی SFT سرهم شده؛ مدل پاداش آموزش دیده؛ DPO اجرا شده؛ ارزیابی‌ها اندازه‌گیری شده‌اند؛ وزن‌های کوانتایزشده خروجی گرفته شده‌اند و سرور استنتاج بالا آمده است. اما هر کدام در قالب یک نوت‌بوک مجزا بودند. هر یک قراردادهای نام‌گذاری، مسیرهای خروجی و seed تصادفی خاص خود را داشتند.

یک فرایند آموزش مدل‌های پیشرو (frontier training run) شبیه یک نوت‌بوک نیست. آموزش Llama 3 405B حدود 30 میلیون ساعت H100 در طول تقریباً 54 روز زمان برد. مدل DeepSeek-V3 حدود 2.8 میلیون ساعت H800 مصرف کرد. در این بازه، یک چک‌پوینت خراب، یک بار نشت داده (data contamination) یا یک افت عملکرد در ارزیابی می‌تواند یک هفته زمان تقویمی و یک ماه بودجه‌ی پردازنده‌ی گرافیکی یک تیم را بر باد دهد. راه‌حل تیم‌ها برای نجات از این فجایع، رعایت بهداشت پایپ‌لاین (pipeline hygiene) است: هر مرحله ورودی قطعی، خروجی قطعی، یک مانیفست، یک هش و یک گیت نظارتی دارد.

این درس پروژه‌ی پایانی است. قرار نیست کل این پایپ‌لاین را روی لپ‌تاپ اجرا کنید؛ بلکه هماهنگ‌کننده‌ای می‌نویسید که مراحل را مدیریت کند، مانیفستی که جزئیات اجرا را ثبت کند، مدل اعتبارسنجی که شرط‌های انتشار را بسنجد، و طرح بازپخشی (replay plan) که به فردی ثالث اجازه دهد کار شما را از روی یک فایل منفرد دوباره اجرا کند. حجم کد کم است، اما انضباط مهندسی بالایی می‌طلبد.

این الگو بدون هیچ تغییری از 100M تا 1T پارامتر مقیاس‌پذیر است. همان چهار مؤلفه یعنی مانیفست، هماهنگ‌کننده، گیت ارزیابی و مخزن آرتیفکت (artifact store)، هم Llama 3 را اجرا می‌کنند و هم مدل آزمایشی کوچک شما را. تفاوت فقط در بزرگی اعداد داخل پیکربندی هر مرحله است، نه در ساختار کلی پایپ‌لاین.

مفاهیم پایه

دوازده مرحله

هر درس از فاز 10 یک مرحله است. گراف کامل وابستگی‌ها به این صورت است:

مراحل 07 و 08 می‌توانند موازی اجرا شوند؛ اما بقیه‌ی مراحل وابستگی قطعی دارند. تغییر در مرحله‌ی 02 (توکنایزر)، تمام آرتیفکت‌های پایینی را باطل می‌کند؛ اما تغییر در مرحله‌ی 10 (ارزیابی)، فقط تصمیم انتشار را بی‌اعتبار می‌سازد.

مانیفست

مانیفست فایلی منفرد است که اجرای فرایند را به‌قدری کامل توصیف می‌کند که اجرای دوباره‌ی دقیق آن ممکن باشد. هیچ خروجی‌ای در پایپ‌لاین نباید به وضعیتی بیرون از مانیفست متکی باشد. فیلدهای آن ساده ولی کاملاً اجباری هستند.

pipeline_version: 1.2.3
seed: 42
git_commit: a1b2c3d4
stages:
  01_tokenizer:
    recipe: bpe_32k
    input_hash: sha256:...
    output_hash: sha256:...
    wall_clock_sec: 3600
    cost_usd: 12

هش خروجی مرحله‌ی N دقیقاً هش ورودی مرحله‌ی N+1 است. با کوچک‌ترین مغایرتی، پایپ‌لاین متوقف می‌شود. این سازوکار مانع از نادیده گرفتن خرابی داده‌ها در مراحل ابتدایی می‌شود و به هم‌تیمی شما در قاره‌ای دیگر امکان می‌دهد بررسی کند که بازپخش فرایندش، آرتیفکتی عیناً مشابه خروجی شما تولید کرده است یا خیر.

در عمل، تیم‌ها از یک شمای کوچک YAML به همراه یک ابزار بررسی مانیفست استفاده می‌کنند که تغییرات را نسبت به آخرین اجرای موفق مقایسه می‌کند. هر تغییری فراتر از فیلدهای مورد انتظار (مانند هزینه یا زمان تقویمی)، هشداری جدی به شمار می‌آید.

نوع‌بندی آرتیفکت‌ها

خروجی هر مرحله یک آرتیفکت دارای نوع (typed artifact) است؛ نه یک پوشه‌ی درهم‌برهم و نه یک فایل pickle، بلکه یک نوع مشخص با ساختار داده‌ای معین.

این نوع‌بندی مانع از شایع‌ترین حالت خرابی می‌شود: یعنی فرستادن خروجی مرحله‌ی 08 به عنوان ورودی مرحله‌ی 06، یا فرستادن اشتباهی یک مدل آموزش‌دیده با DPO به مسیر SFT برای انتشار. استفاده از آرتیفکت‌های نوع‌بندی‌شده و امضاهای مشخص برای هر مرحله باعث می‌شود این خطاها همان ابتدا و در لحظه‌ی بررسی پایپ‌لاین متوقف شوند، نه اینکه بعد از پنج روز آموزش مشخص شوند.

گیت ارزیابی

پایان کار به معنای «اتمام آموزش» نیست؛ تحویل نهایی زمانی است که «آموزش تمام شده باشد و گیت ارزیابی هم پاس شود». شرایط این گیت قبل از شروع اجرا تعیین می‌شود.

gates:
  mmlu:      >= baseline + 0.5   # no regression
  humaneval: >= baseline + 1.0
  truthfulqa: >= baseline         # no drop
  safety_refusal_rate: <= 0.05
  kl_from_reference: <= 25.0
  cost_total_usd: <= 50000

همه‌ی گیت‌ها آستانه‌های عددی دارند. هیچ معیاری بر اساس «به نظر خوب می‌رسد» یا تأیید سلیقه‌ای وجود ندارد. اگر همه‌ی گیت‌ها پاس شوند، آرتیفکت قابل انتشار شناخته می‌شود. اگر حتی یک گیت رد شود، فرایند متوقف می‌ماند تا زمانی که بازبین مشخصی مستقیماً آن را تأیید کند که این تأییدیه نیز در مانیفست ثبت می‌شود.

دو گیت اصلی جلوی اغلب فجایع را می‌گیرند: یک گیت افت عملکرد (regression) (مدل جدید روی محک‌های اصلی باید دست‌کم هم‌سطح مدل قبلی باشد) که باگ‌های حین آموزش را شکار می‌کند؛ و یک گیت بودجه‌ی KL (سیاست هم‌راستاشده نباید بیشتر از مقدار X از مدل مرجع خود دور شود) که مانع از اعمال بیش از حد هم‌راستاسازی می‌شود. هر پایپ‌لاین پروداکشن به هر دوی این گیت‌ها مجهز است.

هماهنگ‌کننده

قطعه کد کوچکی که مانیفست را می‌خواند، مراحل را اجرا می‌کند، آرتیفکت‌ها را زیر نظر می‌گیرد و با بروز اولین تناقض در قراردادها متوقف می‌شود. قرار نیست سراغ Airflow یا Kubeflow بروید؛ برای حفظ بهداشت پایپ‌لاین، بهتر است ابزاری ساده باشد که خودتان نوشته‌اید.

وظیفه‌ی هماهنگ‌کننده بسیار مشخص و محدود است:

1. گراف جهت‌دار بدون دور (DAG) را از روی مانیفست استخراج کند.
2. برای هر مرحله بررسی کند که آیا خروجی مورد انتظار از قبل با هش معتبر وجود دارد یا نه (در این صورت از آن عبور کند).
3. مرحله را اجرا کند، لاگ‌های stdout و stderr را بگیرد و زمان واقعی و هزینه را اندازه بگیرد.
4. هش خروجی را با هش ورودی مورد انتظار در مرحله‌ی بعدی مطابقت دهد.
5. در صورت بروز خطا، یک مانیفست ناقص به همراه نام مرحله‌ی خطا ثبت کند و با کد خروجی غیرصفر خارج شود.

این منطق در 200 سطر پایتون جا می‌شود؛ شبیه فایل code/main.py در همین درس. در عمل، پایپ‌لاین‌های واقعی از torchrun یا ray برای اجرای مراحل روی کلاسترها کمک می‌گیرند، اما خود هماهنگ‌کننده روی یک سیستم منفرد اجرا می‌شود.

ردگیری آزمایش‌ها و ذخیره‌سازی آرتیفکت‌ها

دو سیستم خارجی پایه‌ی اصلی این پایپ‌لاین هستند:

ابزار ردگیری آزمایش‌ها (مانند wandb، neptune یا mlflow). این سیستم منحنی‌های تابع زیان (loss)، معیارهای ارزیابی و اطلاعات تله‌متری سیستم را در هر مرحله ثبت می‌کند. اینجا جایی است که اگر سه هفته بعد بخواهید اجرای A را با B مقایسه کنید، به آن رجوع خواهید کرد. تیم‌ها تقریباً همیشه از سرویس‌های مدیریت‌شده (hosted) برای این کار استفاده می‌کنند؛ چرا که ساخت ابزار اختصاصی، وقت باارزش آموزش را تلف می‌کند.

مخزن آرتیفکت (مانند S3، R2 یا GCS). فضای ذخیره‌سازی شیء (object store) تغییرناپذیر برای چک‌پوینت‌ها، مجموعه‌داده‌ها، توکنایزرها و گزارش‌های ارزیابی. دسترسی به این آرتیفکت‌ها بر اساس هش آن‌ها صورت می‌گیرد نه نام فایل. نام‌هایی مثل latest.pt به‌شدت مستعد خطا هستند؛ در حالی که نامی مثل ckpt-7b-step-20000-sha256:abc123.safetensors یک قرارداد روشن و بدون ابهام است.

هماهنگ‌کننده داده‌هایش را در هر دوی این سیستم‌ها می‌نویسد: ابزار ردگیری برای بررسی نمودارها توسط انسان‌هاست و مخزن آرتیفکت برای بازیابی ورودی‌های مراحل بعدی.

برآورد هزینه‌ها

فرایند آموزش یک مدل پیشرو برچسب قیمت دلاری مشخصی دارد. انضباط مالی در دو نقطه اعمال می‌شود:

تخمین پیش از اجرا. با استفاده از مانیفست، حجم محاسبات بر حسب FLOPs تخمین زده می‌شود (برای پیش‌آموزش: فرمول 6 × پارامترها × توکن‌ها)، سپس ساعت‌های کاری GPU محاسبه می‌شود (FLOPs تقسیم بر نرخ پردازش اوج تقسیم بر ضریب بهره‌وری) و در نهایت هزینه‌ی دلاری بر اساس نرخ اجاره‌ی لحظه‌ای محاسبه می‌شود. اگر این برآورد از گیت بودجه فراتر برود، پایپ‌لاین اصلاً شروع به کار نمی‌کند.

ردگیری در حین اجرا. در طول اجرا، زمان تقویمی و هزینه‌ی هر مرحله در مانیفست ثبت می‌شود. پس از پایان هر بخش، باقی‌مانده‌ی بودجه بررسی خواهد شد. اگر مرحله‌ای هزینه‌ی بیش از حد تراشیده باشد، گیت مرحله‌ی بعد با بودجه‌ی جدید ارزیابی می‌شود. نباید زمانی که سرمایه‌گذار زنگ می‌زند تازه متوجه اتمام بودجه شوید!

هزینه‌ی گزارش‌شده برای آموزش Llama 3 حدود 61 میلیون دلار و برای اجرای اصلی پیش‌آموزش DeepSeek-V3 تقریباً 5.6 میلیون دلار بود. این تفاوت عمدتاً ناشی از بهره‌وری سخت‌افزاری و معماری مخلوط کارشناسان (MoE) است؛ با این حال، ارقام مشخص هزینه‌ها به این دلیل شفاف است که هر دو تیم آن را به تفکیک مراحل ردگیری کرده‌اند، نه کلی به ازای کل اجرا.

بازتولیدپذیری در مقابل قطعیت

این دو مفهوم یکسان نیستند. بازتولیدپذیر (Reproducible) یعنی استفاده از همان مانیفست، همان کد و همان زیرساخت، چک‌پوینتی تولید کند که معیارهای ارزیابی نهایی معادلی داشته باشد. اما قطعی (Deterministic) یعنی داده‌های خروجی روی بیت‌به‌بیت فایل‌ها کاملاً یکسان باشند.

آموزش مدل‌های زبانی امروزی بازتولیدپذیر است، اما قطعی نیست. ترتیب reduce در آموزش توزیع‌شده، رفتار غیرقطعی کرنل‌های GPU (مثل cuBLAS یا flash-attn) و خطاهای گرد کردن در دقت ترکیبی دست‌به‌دست هم می‌دهند تا مقادیر ممیز شناور بین دو اجرای مختلف در سطح 1e-5 تفاوت پیدا کنند. این مسئله برای معیارهای نهایی که تغییری نمی‌کنند کاملاً بی‌خطر است؛ اما اگر بخواهید با مقایسه‌ی بیتی دیباگ کنید، کار را خراب می‌کند. چاره‌ی کار این است که هش ورودی و خروجی هر مرحله به همراه مهم‌ترین معیارهای ارزیابی ثبت شوند؛ در صورتی که این داده‌ها تطابق داشته باشند، فرایند «بازتولیدشده» به شمار می‌رود، حتی اگر وزن‌ها بیت‌به‌بیت یکسان نباشند.

طرح بازگشت به عقب

قبل از شروع اجرا، برای خرابی هر مرحله پلن بازگشت تدوین کنید. مراحل به سه دسته تقسیم می‌شوند:

• ارزان برای اجرای دوباره (در حد چند ساعت): توکنایزر، ارزیابی، کوانتایز و سرور استنتاج؛ فقط کافی است دوباره اجرا شوند.
• متوسط (در حد چند روز): SFT، DPO و CAI. مدل پایه را دست‌نخورده نگه دارید و فقط مراحل هم‌راستاسازی را از نو اجرا کنید.
• گران‌قیمت (چندین هفته و میلیون‌ها دلار هزینه): پیش‌آموزش. راه‌حل اینجا «اجرای مجدد» نیست؛ بلکه «استفاده از آخرین چک‌پوینت سالم و اجرای دوباره‌ی مراحل ارزان‌تر پایینی با داده‌های اصلاح‌شده» است.

به دلیل ساختار نوع‌بندی‌شده و هش‌دار مراحل، هماهنگ‌کننده می‌تواند دامنه‌ی باطل‌شدن را خودکار محاسبه کند: یعنی مرحله‌ی شکست‌خورده به اضافه‌ی تمام مراحل پس از آن باطل می‌شوند. خرابی در مرحله‌ی 06 (SFT)، مراحل 06، 07، 08، 09، 10، 11 و 12 را از اعتبار می‌اندازد؛ اما خرابی در مرحله‌ی 11 (کوانتایز)، صرفاً مراحل 11 و 12 را لغو می‌کند. مشخص کردن این موارد از قبل، مانع از تصمیم‌گیری‌های فی‌البداهه در ساعت 4 صبح و اوج خستگی تیم می‌شود.

رویکردهای پروداکشن مشاهده‌شده در سال 2026

بیشتر تیم‌های پیشرو به اسکلت اجرایی یکسانی رسیده‌اند:

• توکنایزر: BPE با 128 هزار توکن به همراه سازوکار بایت رزرو (byte fallback). آموزش‌دیده روی برشی کوچک، متعادل و چندزبانه.
• پیش‌آموزش: بین 10 تا 20 تریلیون توکن، عمدتاً وب به همراه کد و داده‌های سنتتیک. بهینه‌سازهای Muon یا AdamW. راهبردهای FSDP2 یا DeepSpeed ZeRO-3. چک‌پوینت‌گذاری گرادیان. وزن‌های BF16 با نسخه‌ی اصلی FP32.
• هم‌راستاسازی با نظارت (SFT): بین 500 هزار تا 2 میلیون جفت دستورالعمل، ترکیبی از نمونه‌های انسانی و سنتتیک با حذف دقیق داده‌های تکراری نسبت به مجموعه‌ی ارزیابی.
• هم‌راستاسازی: DPO یا ترکیب CAI با GRPO؛ و محدود کردن RLHF تنها به نقاطی که سیگنال ترجیحات چندبُعدی‌تر از آن است که با DPO حل شود.
• ارزیابی: آزمون‌های MMLU-Pro، MATH، HumanEval+، GPQA، SWE-Bench Verified، LiveBench، به علاوه‌ی یک مجموعه‌ی تست اختصاصی نگه‌داشته‌شده (held-out) که عموم هرگز آن را نمی‌بینند.
• کوانتایز: تکنیک‌های 4 بیتی مثل GPTQ یا AWQ برای سرو، و 8 بیتی برای ارزیابی‌های ایمنی که افت دقت برایشان بسیار حساس است.
• سرو مدل: vLLM، TensorRT-LLM یا ابزارهای بهینه‌شده‌ی داخلی. دسته‌بندی پیوسته. دیکودینگ حدسی. حذف هوشمندانه‌ی محتوای کش کلید-مقدار.

شاید اعداد هر شش ماه جابه‌جا شوند، اما اسکلت پایپ‌لاین تغییری نمی‌کند.

پیاده‌سازی

کد این درس یک هماهنگ‌کننده و یک ارزیاب مانیفست است، نه دوازده اسکریپت آموزش مدل. هر مرحله با یک تابع جایگزین شبیه‌سازی شده است که آرتیفکت خروجی را با شکل و هش صحیح تولید می‌کند. اجرای هماهنگ‌کننده به صورت سرتاسری نشان می‌دهد که زیرساخت پایپ‌لاین پیش از سوزاندن هزینه‌ی GPU روی مراحل واقعی، به‌درستی کار می‌کند.

برای بررسی پیاده‌سازی کامل به code/main.py مراجعه کنید. بخش‌های کلیدی آن عبارتند از:

• کلاس دادگانی Manifest: نسخه‌ی پایپ‌لاین، seed، کامیت git، مراحل و گیت‌ها.
• کلاس دادگانی Stage: نام، نوع، ورودی‌ها (هش‌ها)، خروجی (هش)، زمان اجرا و هزینه.
• متد Orchestrator.run(): استخراج گراف وابستگی‌ها، مدیریت اجرای مراحل، اعتبارسنجی هش‌ها و به‌روزرسانی مانیفست.
• متد EvalGate.check(): خواندن مقادیر آستانه، مقایسه با آخرین گزارش ارزیابی و اعلام قبولی یا رد.
• کلاس ArtifactStore (نسخه‌ی ساختگی درون‌حافظه‌ای): ذخیره و بازیابی بر اساس هش با شبیه‌سازی عملکرد S3.
• کلاس CostTracker: ثبت هزینه‌های تفکیکی هر مرحله و تجمیعی، و توقف در صورت عبور از سقف تعیین‌شده.

پایپ‌لاین ارائه‌شده در main.py دوازده مرحله‌ی نمادین را اجرا می‌کند، مانیفست مربوطه را می‌سازد و نحوه‌ی رد شدن در گیت ارزیابی را نمایش می‌دهد تا مشخص شود یک اجرای متوقف‌شده چه وضعیتی دارد. با جایگزینی هر تابع نمادین با اسکریپت واقعی درس مربوطه، اسکلتی را در اختیار خواهید داشت که یک پایپ‌لاین واقعی پیشرو از آن استفاده می‌کند.

استفاده از آن

این گردش کار استاندارد سه دستور اصلی دارد:

python code/main.py plan    # validate manifest, compute cost estimate, print DAG
python code/main.py run     # execute stages, writing to manifest.out.yaml
python code/main.py gate    # read manifest.out.yaml, apply eval gates, ship-or-hold

همیشه کار را با اجرای دستور plan آغاز کنید. بخش زیادی از باگ‌های پایپ‌لاین در این مرحله مشخص می‌شوند؛ مواردی مانند آستانه‌های تعریف‌نشده برای گیت‌ها، هش‌های نامعتبر و برآوردهای بیش از حد بودجه. اجرای plan هزینه‌ای ندارد؛ اما اجرای run بسیار گران است. با شناسایی زودهنگام باگ‌ها، هزینه‌ها را کاهش دهید.

خروجی دستور gate یا به صورت SHIP خواهد بود یا HOLD: <reason>. تعلیق اجرا نشانه شکست نیست؛ بلکه نقطه‌ی تصمیم‌گیری است. یک بازبین مشخص یا مستقیماً دستور نادیده‌گرفتن خطا را با ثبت در سیستم صادر می‌کند، یا طرح بازگشت به عقب را تأیید می‌کند.

تحویل نهایی

این درس فایل outputs/skill-llm-pipeline-reviewer.md را تولید می‌کند. کافی است مانیفست پیشنهادی پایپ‌لاین را به این ابزار بدهید تا تمام قراردادها از جمله نوع‌بندی مراحل، زنجیره‌ی هش‌ها، گیت‌ها، طرح بازگشت به عقب و تخمین هزینه‌ها را بررسی کند. این ابزار از تأیید مانیفست‌هایی که فاقد گیت ارزیابی هستند، بودجه‌ی KL نامحدود دارند، یا داده‌های ارزیابی را با داده‌های آموزش مخلوط کرده‌اند، خودداری می‌کند.

تمرین‌ها

1. هماهنگ‌کننده را طوری توسعه دهید که مراحل 07 و 08 به صورت موازی اجرا شوند. برای این کار از ماژول استاندارد concurrent.futures استفاده کنید. مطمئن شوید خروجی هر دو مرحله در مانیفست نهایی ثبت شود و هش ورودی مرحله‌ی 09 از ترکیب قطعی هر دوی آن‌ها به دست بیاید.

2. یک گیت «بررسی نسبت آلودگی» (contamination check) اضافه کنید. با داشتن هش مجموعه‌داده‌ی ارزیابی و شارد‌های مجموعه‌داده‌ی آموزش، میزان هم‌پوشانی را (از طریق تطابق دقیق رشته‌ای یا تطابق 13-gram) اندازه بگیرید. اگر این هم‌پوشانی از 0.1% بیشتر بود، گیت باید رد شود. یک مجموعه‌داده‌ی آموزشی آلوده به آن بدهید و تأیید کنید که گیت جلوی ادامه‌ی اجرا را می‌گیرد.

3. ابزار تخمین هزینه را بر اساس اصول بنیادین پیاده‌سازی کنید. برای مرحله‌ی 04 (پیش‌آموزش)، میزان FLOPs را با رابطه‌ی 6 × پارامترها × توکن‌ها بسنجید. فرض را بر بهره‌وری 40% نسبت به توان پردازشی تئوری (MFU) روی H100 با نرخ 989 TFLOPs برای محاسبات BF16 و هزینه‌ی ساعتی 2.50 دلار برای هر GPU بگذارید. این هزینه را برای آموزش یک مدل 7B با 2T توکن محاسبه و با ارقام منتشرشده برای مدل Llama 2 مقایسه کنید.

4. یک سناریوی بازگشت به عقب ناقص بسازید. یک خرابی را در مرحله‌ی 09 (CAI) شبیه‌سازی کنید، سپس بدون دست زدن به مراحل کش‌شده‌ی 01 تا 08، مراحل 09 تا 12 را از نو اجرا کنید. هماهنگ‌کننده باید آرتیفکت‌های کش‌شده را بر اساس هش آن‌ها تشخیص دهد و از پردازش مجددشان عبور کند. زمان صرفه‌جویی‌شده نسبت به اجرای کامل از ابتدا را اندازه بگیرید.

5. امکانات مشاهده‌پذیری (observability) را اضافه کنید. برای هر مرحله اسپَن‌های OpenTelemetry ایجاد کنید و خصوصیاتی مثل پارامترها، توکن‌های دیده‌شده، تابع زیان (loss) و هزینه را در آن بگنجانید. این اسپَن‌ها را به یک جمع‌آوری‌کننده‌ی (collector) محلی بفرستید. هدف صرفاً ساخت داشبورد نیست؛ بلکه باید وضعیت سلامت هر مرحله با یک شناسه‌ی ردگیری (Trace ID) واحد، قابل رهگیری باشد.

اصطلاحات کلیدی

برای مطالعه‌ی بیشتر

• دوبی و همکاران، 2024 -- "The Llama 3 Herd of Models" -- کامل‌ترین توضیحات عمومی درباره‌ی پایپ‌لاین یک مدل پیشرو، شامل داده، آموزش، هم‌راستاسازی و ارزیابی
• تیم هوش مصنوعی DeepSeek، سال 2024 -- "DeepSeek-V3 Technical Report" -- پایپ‌لاینی با اولویت بهره‌وری حداکثری با هزینه‌ای نزدیک به یک‌دهم مدل‌های هم‌رده مانند Llama 3
• کاپلان و همکاران، 2020 -- "Scaling Laws for Neural Language Models" -- مقاله‌ی اصلی درباره‌ی قوانین مقیاس‌پذیری و رابطه‌ی توان پردازشی، داده و تعداد پارامترها
• هافمن و همکاران، 2022 -- "Training Compute-Optimal Large Language Models (Chinchilla)" -- اصلاحیه‌ای بر مقاله‌ی کاپلان که بودجه‌بندی داده‌های مدرن را برای ساخت مدل‌های بهینه از نظر توان پردازشی (Compute-optimal) بازتنظیم کرد
• مستندات PyTorch FSDP2 -- ساختار پایه‌ای آموزش توزیع‌شده که جایگزین FSDP1 در نسخه‌های PyTorch 2.4 به بعد شده است
• گزارش‌های LLM در Weights & Biases -- مانیفست‌های واقعی و خروجی‌های ابزارهای ردگیری آزمایش‌ها برای مدل‌های متن‌باز که می‌توان از آن‌ها به عنوان قالب استفاده کرد