اگر یک توسعه‌دهنده هستید که با محدودیت حافظه در اجرای مدل‌های حجیم دست‌وپنجه نرم می‌کند، تصور کنید مدل ۳۰۴ میلیارد پارامتری را بدون هیچ‌گونه فشرده‌سازی یا کوانتش وزن‌ها روی یک تک‌کارت گرافیک اجرا کنید. این سناریو اکنون برای کاربران سخت‌افزارهای پیشرفته AMD محقق شده است.
طبق گزارش و مستنداتی که در یک مخزن گیت‌هاب در تاریخ ۴ اوت ۲۰۲۶ منتشر شد، مدل DeepSeek-V4-Flash-0731 را می‌توان در یک محیط عملیاتی (Production) روی یک پردازنده گرافیکی AMD MI300X مستقر کرد. این مدل که به دلیل توانایی استدلال سطح بالا و قیمت بسیار رقابتی مورد توجه قرار گرفته است، حالا با بهینه‌سازی‌های سخت‌افزاری در دسترس‌تر شده است. این استقرار، چالش‌های بحرانی ناسازگاری سخت‌افزاری-نرم‌افزاری را که پیش از این مانع عملکرد قابل اعتماد روی معماری CDNA3 می‌شد، حل کرده است. مدل دقیقاً به همان صورتی که عرضه شده اجرا می‌گردد و مجموع وزن‌های آن در حافظه HBM مقدار ۱۵۶.۶۷ گیگابایت را اشغال می‌کند.
اجرای مدل‌های عظیم «ترکیب خبره‌ها» (Mixture-of-Experts یا MoE) — که شبیه به تیمی از متخصصان است که هر سوال را به فرد لایق می‌سپارند — معمولاً نیازمند خوشه‌های چند-GPU یا فشرده‌سازی‌های تهاجم برای گنجاندن در حافظه است. برای درک بهتر زمینه، باید اشاره کرد که اکثر دستورالعمل‌های عملیاتی برای DeepSeek V4، سخت‌افزارهای انویدیا یا تراشه‌های جدیدتر AMD مانند MI325X یا MI355X را هدف قرار داده‌اند. این بهینه‌سازی در راستای بهره‌برداری از پتانسیل مدل‌های سری Flash است که به دلیل برابری با GPT-5.6 Luna با هزینه‌ای بسیار کمتر بحث‌های زیادی ایجاد کرده‌اند. اما حافظه ۱۹۲ گیگابایتی HBM3 در MI300X و پهنای باند حافظه ۵.۳ ترابایت بر ثانیه، فرصتی استثنایی ایجاد کرده است؛ چراکه این کارت ۲.۴ برابر بیشتر از H100 SXM5 ظرفیت HBM دارد. تحلیل‌های Doubleword تخمین می‌زند که قیمت لیست MI300X تقریباً نصف قیمت رقابت است.
این ظرفیت حافظه اجازه می‌دهد یک استقرار ساده تک-GPU صورت گیرد که در آن کل مدل بدون نیاز به استریمینگ وزن‌ها از طریق PCIe در HBM قرار می‌گیرد. با این حال، صرفاً داشتن حافظه کافی نیست. به گفته مالک مخزن، اجرای پایدار این مدل نیازمند اعمال مجموعه‌ای از اصلاحات جراحی‌گونه (Surgical Patches) در نسخه‌های شبانه‌روزی vLLM ROCm (نسخه 0.26.1rc1.dev229+g124154a88.rocm723) و کتابخانه کرنل AITER (نسخه 0.1.19) بود.
زمینه سخت‌افزاری و معماری
پردازنده MI300X (معماری CDNA3) دارای ۳۰۴ واحد پردازشی (CU) است و عملکرد پیک FP8 آن را به ۲.۶۱ PFLOPS می‌رساند. در حالی که معماری‌های جدیدتر مانند MI325X و MI355X از استاندارد OCP FP8 استفاده می‌کنند، MI300X گونه‌ی 'fnuz' از E4M3 (متعلق به AMD/Graphcore) را پیاده‌سازی می‌کند.
این تمایز بسیار حیاتی است؛ زیرا اگر یک کرنل فرض کند که روی MI300X با معناشناسی OCP طرف است، ممکن است در دامنه مقیاس (Scale Domain) تا دو برابر خطا کند که این امر صحت خروجی‌ها را کاملاً تخریب می‌کند. اولویت اول در این پروژه، تضمین صحت در پیاده‌سازی FP8 بود و تنظیمات عملکردی در اولویت دوم قرار گرفت. این مخزن بر اساس کارهای پیشین Fergus Finn در مورد MI300X و مخزن Doubleword بنا شده است که برای اولین بار ناسازگاری FP8، نبود مسیرهای سریع AITER در gfx942 و خطرات HIP-graph در رمزگشایی MLA پراکنده را شناسایی کردند.
جزئیات فنی و اصلاحات بهینه‌سازی
پشته عملیاتی این پروژه بر پایه یک ایمیج رسمی و پین‌شده از vLLM ROCm nightly است (sha256:e68d18b2ba50298661bfc49baf01158fbf036645c2362cccf3e8a7a79fe6c69a). برای پایدار کردن مدل، توسعه‌دهنده چندین لایه‌ی Python خواندنی (Read-only Overlays) و جداول تنظیم مقیاس بلوک A8W8 را برای معماری gfx942 پیاده کرد:
- مسیریابی MXFP4: یک اصلاحیه برای کرنل ماتریس بیت MoE مانع از آن می‌شود که لان‌های Padding باعث تخریب ماتریس مسیریابی شوند. در کرنل اصلی، لان‌های Padding بر اساس کران کلی تنسور ماسک شده بودند نه بر اساس اندازه بلوک منطقی؛ اصلاحیه جدید از فرمول
mask = (offs_local < BLOCK_SIZE) & (offs_global < nonzero_indx_size)استفاده می‌کند. این تغییر مانع از آن می‌شود که مدل در پرامپت‌های طولانی، طرح-واره‌ها (Schemas) را فراموش کند یا نام ابزارهایی با شباهت زیاد را اشتباه تولید کند. همچنین، لایه‌ی جدید شامل SiLU ادغامی و مسیریابی سریع DeepSeek برای خبره‌های گروهی MXFP4 از طریق فایل‌هایgpt_oss_triton_kernels_moe.pack128-fused-silu-fast-routing.pyوmxfp4.fused-silu.pyاست. - یکپارچگی FP8: کش Lightning Indexer در DeepSeek V4 از FP8 استفاده می‌کند. نویسنده استوک، بایت‌های OCP E4M3 را با ترتیب Row-major ارسال می‌کند، اما AITER در MI300X بایت‌های AMD FNUZ E4M3 را در یک چیدمان کاشی ۱۶×۱۶ پیش‌برشفل (Preshuffled) مصرف می‌کند. لایه‌ی
fused_compress_quant_cache.fnuz-shuffle.pyمقدارfloat8e4b8را باFP8_MAX=224.0و آفست‌های نوشتن برشفل شده در ROCm انتخاب می‌کند. - همگام‌سازی CPU-KV: این پشته شامل یک اصلاحیه برای حصارگذاری مسیر بارگذاری (Load-path Fencing) در بازیابی‌های KV از CPU به GPU است (
kv_offload_cpu_gpu_worker.load-war.py). این مورد یک شکاف شناخته‌شده در Issue #47282 در vLLM بود که اصلاحیه پیشنهادی در PR #47291 هرگز ادغام نشد. - تنظیمات AITER: توسعه‌دهنده جداول تنظیمی برای ۲۱ شکل تکرارشونده GEMM A8W8 به‌طور خاص برای معماری ۳۰۴-CU gfx942 اضافه کرد. علاوه بر این، فایل
triton-kernels-matmul-ogs-opt-flags.dsv4-mi300x.pyیک بازنویسی هندسه OGS برای خبره‌های MXFP4 فراهم می‌کند تا از افت عملکرد در ردیف‌های مسیریابی شده بالای ۷۶۸ جلوگیری کند (پشتیبانی تا ۱,۵۳۶ ردیف). - پیش‌پر کردن پراکنده (Sparse Prefill): گنجاندن
rocm_aiter_mla_sparse.prefill-bh64.pyباعث تضمین پیش‌پر کردن قطعیtorch.topkو پیش‌پر کردن پراکنده head-512 باBLOCK_H=64می‌شود که برای فراخوانی‌های ابزار (Tool Calls) بازتولیدپذیر، ضروری است. - لوجیت‌های MQA: لایه‌ی
aiter_pa_mqa_logits.i64.pyآفست‌های ۶۴ بیتی را در کرنل‌های paged-MQA با ChunkK=256 فراهم می‌کند؛ این مورد زمانی که آفست‌های KV از ۴ گیگابایت فراتر می‌روند، مورد نیاز است. - تأیید گمانه‌زنی (Speculative Verification): فایل
rocm_aiter_mla.dspark-causal.pyتأیید گمانه‌زنی چند-توکنی علّی را برای DSpark در ROCm با MLA سر کوچک پیاده‌سازی می‌کند.
اصلاحات دقیق صحت پاسخ‌ها
دو اصلاحیه خاص برای تضمین اینکه مدل در زیر بار عملیاتی دچار توهم نشود یا کرش نکند، در اولویت قرار گرفتند:
۱. اصلاح ماتریس بیت MoE: در مسیر مسیریابی MXFP4، کرنل ماتریس بیت، ستون‌های بلوک را به اندازه بلوک Triton پد می‌کند. اگر این لان‌های پدینگ به جای اندازه بلوک منطقی، در برابر کران کلی تنسور ماسک شوند، ماتریس مسیریابی را تخریب می‌کنند. این موضوع به‌ویژه در بارهای زیاد مشهود است، جایی که مدل ممکن است در پیروی از طرح-واره‌های پیچیده شکست بخورد. اصلاحیه تک-خطی ارائه شده در لایه، از کامیت c32932bb9 در Doubleword گرفته شده است.
۲. تراز مقیاس FP8: به دلیل استفاده MI300X از گونه FNUZ E4M3، تفسیر بایت‌های OCP E4M3 منجر به خطای مقیاس دو-برابری می‌شود. با انتخاب float8e4b8 و FP8_MAX=224.0 و پیاده‌سازی آفست‌های نوشتن برشفل شده، سیستم نویسنده کش Lightning Indexer را با آنچه AITER در MI300X انتظار دارد، تراز می‌کند.
تحلیل عملکرد و بنچمارک‌ها
با این بهینه‌سازی‌ها، تنظیمات تک-GPU توان عملیاتی در سطح حرفه‌ای ارائه می‌دهد. در سناریوی رمزگشایی تک-جریانی (DSpark-7)، سیستم به میانه ۱۶۸.۶ توکن در ثانیه می‌رسد. هنگام مقیاس‌بندی به ۸ جریان همزمان، توان عملیاتی کل به ۵۴۲ توکن در ثانیه می‌رسد (میانگین ۹۰.۳ توکن برای هر جریان).
برای بارهای کاری با جهش بالا (Burst)، سیستم تا ۶۴ جریان همزمان را مدیریت می‌کند و به سرعت مجموع ۸۳۰ توکن در ثانیه دست می‌یابد، بدون اینکه با خطاهای کمبود حافظه (OOM) یا کرش‌های انجین مواجه شود. نتایج دقیق برای پرامپت‌های ۴۰۰ کلمه‌ای (temp=1.0, top_p=0.95) به شرح زیر است:
- ۱ جریان: ۱۲۶.۲ توکن کل/ثانیه | ۱۶۸.۶ توکن میانه/ثانیه | TTFT p50: ۱.۰۲۶ ثانیه
- ۲ جریان: ۱۴۵.۴ توکن کل/ثانیه | ۱۵۲.۷ توکن میانه/ثانیه | TTFT p50: ۰.۹۳۹ ثانیه
- ۴ جریان: ۳۱۶.۸ توکن کل/ثانیه | ۱۰۸.۶ توکن میانه/ثانیه | TTFT p50: ۰.۳۶۹ ثانیه
- ۸ جریان: ۵۴۲.۳ توکن کل/ثانیه | ۹۰.۳ توکن میانه/ثانیه | TTFT p50: ۱.۰۲۷ ثانیه
- ۶۴ جریان: ۸۳۰.۲ توکن کل/ثانیه | ۱۶.۴ توکن میانه/ثانیه | TTFT p50: ۲.۱۹۰ ثانیه
تحلیل پیش‌پر کردن (Prefill)
سرعت‌های پیش‌پر کردن نیز به همان اندازه قدرتمند هستند. پیش‌پر کردن بدون کش (Uncached) با کرنل‌های تنظیم‌شده به ۷.۹ تا ۸.۵ هزار توکن در ثانیه می‌رسد. به‌طور دقیق‌تر، در سطح C1 با بودجه ۸,۱۹۲ توکنی به ۷.۹۰-۷.۹۹K و در C4 به ۸.۴۶-۸.۵۱K می‌رسد. پروفایل عملیاتی از بودجه ۲,۰۴۸ توکنی برای جداسازی تأخیر استفاده می‌کند که منجر به ۶,۹۸۸-۷,۰۱۹ توکن در ثانیه برای پرامپت‌های تازه می‌شود. با سقف پیش‌پر کردن طولانی ۱,۰۲۴ توکنی، یک پرامپت ۸.۹ هزار توکنی در C1 به ۵.۲۰-۵.۲۹K توکن در ثانیه می‌رسد. این پیکربندی باعث کاهش TTFT برای یک درخواست کوتاه که پشت یک پیش‌پر کردن سرد ۵۲ هزار توکنی قرار دارد، از ۸.۲ ثانیه به ۰.۵ ثانیه می‌شود.
فراخوانی گرم (Warm recall) برای ۳۸۰ هزار توکن کش شده، پس از یک پیش‌پر کردن سرد ۱۲۰-۱۲۵ ثانیه‌ای، تنها ۰.۶۴ تا ۲.۶۵ ثانیه زمان می‌برد. استفاده از ردپای توجه پراکنده BLOCK_H=64 زمان درخواست را از ۳۱۷ میلی‌ثانیه به ۱۴۲ میلی‌ثانیه کاهش می‌دهد.
رمزگشایی گمانه‌زنی و مدیریت حافظه
این پشته از رمزگشایی گمانه‌زنی DSpark-7 با پیش‌نویس احتمالی و رد بلوکی، با استفاده از K=7 استاتیک و تأیید گمانه‌زنی چند-توکنی علّی استفاده می‌کند. این تنظیمات اجازه استفاده از پنجره زمینه ۲۵۶ هزار توکنی را می‌دهد، اگرچه معماری به‌طور نظری تا ۱ میلیون توکن را پشتیبانی می‌کند. دو لایه‌ی Gumbel (dspark-speculator.independent-draft-gumbel.py و spec-decode-utils.independent-draft-gumbel.py) نویز پیشنهادهای پیش‌نویس را مستقل از نویز رد و بازیابی نگه می‌دارند.
برای مدیریت وضعیت عظیم، پیکربندی از یک استراتژی KV ترکیبی استفاده می‌کند: ۲۰ گیگابایت کش GPU از نوع fp8_ds_mla (با استفاده از FP8 مقیاس‌بندی شده بلوکی UE8M0 با بلوک‌های ۲۵۶ توکنی) به همراه یک لایه انتقال بومی ۹۶ گیگابایتی به CPU. این لایه CPU تقریباً ۱۰۳ گیگابایت را در /dev/shm برای ورودی‌های کش-پیشوند اخراج شده (Evicted) نگاشت می‌کند. این ترکیب اجازه ظرفیتی معادل ۱.۹۳ میلیون توکن را می‌دهد و سیستم را قادر می‌سازد هفت درخواست همزمان ۲۵۶ هزار توکنی را بپذیرد.
با این حال، فضای خالی حافظه GPU بسیار کم است. نقطه اوج گرم شده (High-water mark) ۲۰۴.۵ گیگابایت از مجموع ۲۰۵.۸ گیگابایت است. توسعه‌دهنده خاطرنشان می‌کند که تلاش برای استفاده از یک استخر KV ۳۰ گیگابایتی منجر به خطای HSA_STATUS_ERROR_OUT_OF_RESOURCES در هنگام ضبط گراف CUDA می‌شود.
گردش کار استقرار (Deployment Workflow)
پیاده‌سازی از یک پشته Docker Compose شامل vLLM و Caddy به عنوان یک پروکسی HTTPS با لیست سفید IP استفاده می‌کند. برای استقرار، میزبان به موارد زیر نیاز دارد: یک کارت MI300X (gfx942, 304 CUs)، حدود ۲۳۵ گیگابایت رم سیستم برای لایه KV CPU، و حدود ۵۰۰ گیگابایت فضای دیسک (کش مدل حدود ۱۵۶ گیگابایت است).
مراحل گردش کار شامل موارد زیر است:
۱. دریافت ایمیج پین‌شده vLLM و دانلود نسخه مدل 7872f01b1d1fe23eabc4c98b48bffcef5a386062.
۲. تأیید آرتیفکت‌ها از طریق SHA256SUMS.
۳. استفاده از vllm-entrypoint.sh برای حذف mmaps قدیمی CPU-KV از /dev/shm قبل از شروع.
۴. اجرا با فلگ‌های --trust-remote-code و VLLM_ROCM_USE_AITER=1 و --moe-backend triton (که در آن Triton OGS خبره‌های گروهی MXFP4 را مدیریت می‌کند).
برای تضمین پایداری، یک اجرای «گرم کردن» (warm-up) مورد نیاز است. نخستین پیش‌پر کردن، کرنل‌ها را مقداردهی اولیه می‌کند و ۵.۳ ثانیه برای ۸.۹ هزار توکن زمان می‌برد؛ اجراهای بعدی به ۱.۷ ثانیه کاهش می‌یابند. اعتبارسنجی شامل تست‌های فراخوانی ابزار دو-مرحله‌ای، زیرمجموعه‌ای از BFCL (۷۴-۷۶ فراخوانی دقیق از ۹۰ مورد)، بررسی‌های طرح-واره OpenCode و بازخوانی سوزن در انبار کاه برای ۳۸۰ هزار توکن است.
یادداشت‌های تنظیم عملیاتی (Production Tuning)
بهینه‌سازی‌های کلیدی در پیکربندی عملیاتی منجر به دستاوردهای زیر شده است:
- تنظیم A8W8 GEMM: تنظیم ۲۱ شکل تکرارشونده برای gfx942 با ۳۰۴ واحد پردازشی، سرعت رمزگشایی تک/دو جریانی را ۴۲ تا ۶۲ درصد و عملکرد ۸ تا ۶۴ جریان را ۱۰ تا ۳۵ درصد افزایش داد.
- بهینه‌سازی‌های مسیریابی: SiLU ادغامی و مسیریابی سریع DeepSeek، رمزگشایی Native C1 را از ۳۴.۵ به ۵۶.۶ توکن در ثانیه افزایش داد (۶۴٪ افزایش)، در حالی که زمان کرنل مسیریابی از ۴۲.۶ به ۱۱.۹ میکروثانیه در هر لایه کاهش یافت.
- بودجه زمان‌بندی (Scheduler Budget): بودجه ۲,۰۴۸ توکنی به علاوه سقف پیش‌پر کردن طولانی ۱,۰۲۴ توکنی، TTFT برای درخواست‌های کوتاه دیررس را بهینه می‌کند. با این حال، DSpark-7 اسلات‌های پیش‌نویس را از این بودجه رزرو می‌کند؛ افزایش آن باعث افزایش وضعیت پنجره لغزنده در جریان و کاهش ظرفیت قابل استفاده KV می‌شود.
این تنظیمات، معیار استنتاج محلی مدل‌های با پارامتر بالا را تغییر می‌دهد. با اثبات اینکه یک مدل ۳۰۰+ میلیارد پارامتری می‌تواند بدون کوانتش روی یک تک-GPU اجرا شود، «دیوار حافظه» برای آزمایشگاه‌های متوسط برداشته شد. همچنین، این موضوع شکاف قابل توجهی را در پشتیبانی رسمی سازندگان برای بازبینی‌های سخت‌افزاری خاص نشان می‌دهد، جایی که در حال حاضر پچ‌های جامعه‌محور تنها راه رسیدن به پایداری عملیاتی هستند. توسعه‌دهندگان باید مصرف HBM را به‌دقت نظارت کنند و از افزایش فلگ --kv-cache-memory-bytes اجتناب کنند، زیرا سیستم تا آخرین حد ظرفیت سخت‌افزاری MI300X تنظیم شده است.
گفتگو