مدل های قابل اجرا روی ASUS Ascent GX10، واقعیت محدودیت 200B

مدل های قابل اجرا روی ASUS Ascent GX10 کدام‌اند؟

مدل های قابل اجرا روی ASUS Ascent GX10 از مدل‌های سبک 7B و 8B تا مدل‌های 70B و نمونه‌های کوانتیزه بزرگ‌تری مانند GPT-OSS-120B را شامل میشوند. ASUS و NVIDIA سقف رسمی یک دستگاه را «تا 200 میلیارد پارامتر» اعلام کرده‌اند، اما این عدد به معنی اجرای سریع هر مدل 200B با هر دقت، طول Context و تعداد کاربر نیست. ظرفیت واقعی به حجم وزن‌ها، Quantization، حافظه KV Cache، Runtime و فضای اشغال‌شده توسط سیستم‌عامل بستگی دارد.

برای نمونه، راهنماهای رسمی NVIDIA اجرای مدل‌هایی مانند Llama 3.3 70B با NVFP4، GPT-OSS-120B با MXFP4، Qwen3 در اندازه‌های 8B، 14B و 32B، Phi-4 و چند مدل چندوجهی را روی سخت‌افزار DGX Spark تأیید کرده‌اند. ورک استیشن هوش مصنوعی ایسوس مدل Ascent GX10 نیز بر پایه همان NVIDIA GB10 Grace Blackwell، حافظه یکپارچه 128GB و پشته نرم‌افزاری DGX ساخته شده است. بااین‌حال، «مدل اجرا میشود» با «مدل برای کاربرد من سرعت و ظرفیت کافی دارد» دو گزاره متفاوت‌اند.

در این مقاله به‌جای تکرار معرفی کلی محصول، یک پرسش فنی را پاسخ میدهیم: چگونه قبل از دانلود ده‌ها یا صدها گیگابایت فایل بفهمیم یک LLM، VLM یا مدل تولید تصویر روی GX10 جا میشود و چه عملکردی میتوان از آن انتظار داشت؟ برای آشنایی با خود تراشه، خبر عرضه NVIDIA GB10 Grace Blackwell زمینه اولیه را ارائه میکند.

پاسخ سریع؛ هر رده مدل روی GX10 چه وضعیتی دارد؟

این جدول یک راهنمای ظرفیت است، نه Benchmark. دو مدل با تعداد پارامتر برابر میتوانند به‌دلیل معماری Attention، تعداد Expertها، قالب وزن، پشتیبانی Kernel و طول Context رفتار متفاوتی داشته باشید. همیشه نام دقیق Repository و فایل Quantized را مبنای محاسبه قرار دهید.

چرا عدد پارامتر به‌تنهایی کافی نیست؟

پارامترها وزن‌های آموخته‌شده مدل‌اند. برای استنتاج، این وزن‌ها باید در حافظه قرار بگیرند، اما تنها مصرف‌کننده حافظه نیستند. Runtime، بافرهای محاسباتی، CUDA Context، حافظه سیستم‌عامل، Tokenizer، Cache و در مدل‌های چندوجهی Encoder تصویر یا صوت نیز فضا میخواهند. بنابراین فرمول «تعداد پارامتر ضربدر بیت هر وزن» فقط نقطه شروع است.

همچنین بعضی مدل‌ها Dense و برخی Mixture of Experts یا MoE هستند. در مدل Dense تقریباً همه پارامترها در هر Token درگیر میشوند. در MoE ممکن است فقط چند Expert برای هر Token فعال شوند؛ در نتیجه محاسبه کمتر میشود، اما وزن Expertهای غیرفعال نیز معمولاً باید جایی در حافظه نگهداری شوند. عبارت‌هایی مانند 235B-A22B یعنی تعداد کل و تعداد تقریبی پارامتر فعال یکی نیستند.

این تفاوت همان دلیلی است که اجازه نمیدهد فقط با شنیدن «200B» درباره سرعت نتیجه بگیریم. همان‌طور که در مقاله فریب بازاریابی هوش مصنوعی در پردازنده‌ها توضیح داده شده، اعداد محاسباتی باید همراه با نوع بار کاری خوانده شوند.

محاسبه تقریبی حافظه وزن‌های مدل

برای برآورد اولیه میتوان تعداد پارامتر را در تعداد بایت هر پارامتر ضرب کرد. FP16 و BF16 تقریباً دو بایت، INT8 حدود یک بایت و قالب 4-bit حدود نیم بایت برای هر پارامتر نیاز دارند. این محاسبه Metadata، Scaleهای Quantization، Alignment، Cache و سربار Runtime را حساب نمیکند؛ پس عدد نهایی همیشه بیشتر است.

جدول روشن میکند چرا یک مدل Dense با 200B پارامتر در FP16 روی حافظه 128GB جا نمیشود، ولی ورژن 4-bit ممکن است از نظر وزن خام جا شود. بااین‌حال، باقی‌ماندن حدود 28GB اسمی به معنی دراختیاربودن کامل آن برای Context نیست؛ سیستم‌عامل و Runtime نیز از همان حافظه یکپارچه استفاده میکند.

Quantization چه چیزی را تغییر میدهد؟

Quantization دقت نمایش وزن‌ها را کاهش میدهد تا مدل حافظه کمتر و گاهی محاسبه سریع‌تری بخواهد. قالب‌هایی مانند INT8، INT4، FP8، NVFP4 و MXFP4 یکسان نیستند. کیفیت، سرعت و پشتیبانی آن‌ها به مدل، ابزار تبدیل و Kernelهای سخت‌افزار بستگی دارد. ورژن‌ای که برای GB10 و Tensor Coreهای Blackwell بهینه شده، میتواند نتیجه بهتری از یک فایل عمومی با همان تعداد بیت بدهد.

کاهش دقت همیشه افت محسوس کیفیت ایجاد نمیکند، اما تضمینی نیز وجود ندارد. مدل‌های حساس، وظایف عددی، زبان فارسی، کدنویسی یا Function Calling باید جداگانه ارزیابی شوند. بهترین روش این است که مجموعه سؤال و پاسخ واقعی سازمان را روی دو یا سه Quantization اجرا کنید و کیفیت را کنار Token/s و مصرف حافظه بسنجید.

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

KV Cache؛ مصرف حافظه‌ای که بعد از بارگذاری مدل شروع میشود

مدل زبانی هنگام پردازش Prompt و تولید پاسخ، اطلاعات کلید و مقدار لایه‌های Attention را در KV Cache نگه میدارد تا مجبور نباشد همه Tokenهای قبلی را دوباره محاسبه کند. هرچه Context بلندتر، تعداد کاربر هم‌زمان بیشتر و Batch بزرگ‌تر باشد، این Cache نیز رشد میکند. به همین دلیل یک مدل ممکن است با Context دو هزار Token بدون مشکل اجرا شود اما در 32K یا 128K با خطای کمبود حافظه روبه‌رو شود.

نوع داده KV Cache نیز مهم است. بعضی Runtimeها امکان FP8 یا قالب فشرده‌تر برای Cache را میدهند و بعضی مدل‌ها معماری بهینه‌تری مانند Grouped-Query Attention دارند. در نتیجه نمیتوان یک عدد ثابت برای همه مدل‌ها ارائه کرد. برای خرید یا استقرار، Context تبلیغ‌شده مدل را با Context عملی سرویس اشتباه نگیرید.

اگر کاربرد شما تحلیل قراردادهای طولانی یا RAG روی اسناد بزرگ است، بهتر است متن را Chunk کنید، بازیابی را بهینه سازید و فقط بخش‌های مرتبط را به مدل بدهید. ارسال کل آرشیو به Prompt نه‌فقط حافظه را هدر میدهد، بلکه میتواند کیفیت پاسخ را نیز کاهش دهد.

مدل‌های 7B تا 14B؛ بهترین نقطه شروع

مدل‌های این رده برای راه‌اندازی اولیه، آزمون سلامت سیستم و ساخت محصول واقعی بسیار مناسب‌اند. Llama 3.1 8B، Qwen3 8B و 14B و مدل‌های هم‌اندازه میتوانند برای چت، خلاصه‌سازی، استخراج موجودیت، ترجمه آزمایشی، RAG و Agent سبک استفاده شوند. NVIDIA در Playbookهای رسمی خود ورژن‌های FP8 و NVFP4 برخی از این مدل‌ها را برای DGX Spark فهرست کرده است.

مزیت اصلی فقط سرعت نیست. بعد از بارگذاری مدل فضای زیادی برای Context، Embedding Model، Reranker، پایگاه برداری و چند Container باقی میماند. برای یک دستیار اسناد، مجموع کیفیت Pipeline معمولاً مهم‌تر از بزرگ‌کردن LLM است. یک مدل 8B با بازیابی دقیق میتواند از مدل بزرگ بدون منبع قابل‌اعتماد مفیدتر باشد.

مدل‌های 20B تا 35B؛ تعادل کیفیت و ظرفیت

در این بازه، مدل‌هایی مانند GPT-OSS-20B، Qwen3 32B، Phi-4 و Qwen3.6-35B-A3B قرار میگیرند. NVIDIA برای vLLM، SGLang، NIM و Ollama نمونه‌های رسمی یا مدل‌های توصیه‌شده در این رده ارائه کرده است. این اندازه برای دستیار کدنویسی، ابزار Agent، پاسخ تخصصی و مدل چندوجهی جذاب است، زیرا هنوز حاشیه حافظه مناسبی برای سرویس باقی میگذارد.

Qwen3.6-35B-A3B نمونه خوبی از تفاوت پارامتر کل و فعال است. ساختار MoE میتواند محاسبه هر Token را کاهش دهد، ولی فایل مدل و سازگاری Runtime همچنان باید بررسی شوند. برچسب A3B به معنی آن نیست که مدل از نظر حافظه دقیقاً مانند یک مدل Dense سه‌میلیاردی رفتار میکند.

اجرای مدل 70B روی ASUS Ascent GX10

مدل 70B در FP16 از ظرفیت 128GB عبور میکند، اما ورژن 4-bit وزن خامی نزدیک 35GB دارد. همین موضوع اجرای مدل‌هایی مانند Llama 3.3 70B با NVFP4 را عملی میکند. در این حالت بخش قابل‌توجهی از حافظه برای KV Cache و Runtime باقی میماند، هرچند سرعت بهینه فقط با Backend و Kernel سازگار به دست میآید.

NVIDIA در معرفی رسمی DGX Spark از Fine-tuning محلی مدل‌های تا 70B نام برده است. این ادعا را نباید آموزش کامل مدل 70B از صفر تفسیر کرد. روش‌های Parameter-Efficient مانند LoRA و QLoRA حافظه بسیار کمتری از Full Fine-tuning میخواهند. Optimizer State و Gradientها در آموزش کامل میتوانند چند برابر وزن مدل حافظه مصرف کند.

برای مدل 70B سه Benchmark بگیرید: سرعت Prefill روی Prompt طولانی، سرعت Decode یا Token/s و حافظه در بیشترین Context واقعی. یک عدد Token/s روی Prompt کوتاه، وضعیت RAG سنگین یا چند کاربر را نشان نمیدهد.

آیا GPT-OSS-120B روی GX10 اجرا میشود؟

Playbook رسمی SGLang شرکت NVIDIA، GPT-OSS-120B با قالب MXFP4 را در فهرست مدل‌های اعتبارسنجی‌شده DGX Spark قرار داده است. این مثال نشان میدهد رده 120B با Quantization مناسب میتواند روی یک دستگاه 128GB عملی باشد. همچنین راهنمای Speculative Decoding از اجرای همین مدل روی یک Spark در سناریوی مشخص نام میبرد.

اما 120B همچنان مدل بزرگی است. Context طولانی، چند Session هم‌زمان، Speculative Draft Model یا سرویس‌های جانبی میتوانند حاشیه حافظه را کم کند. برای استفاده تولیدی، حداکثر ظرفیت تبلیغ‌شده را هدف نگیرید؛ فضایی برای جهش مصرف حافظه و به‌روزرسانی Runtime باقی بگذارید.

واقعیت سقف 200B در یک GX10

سقف 200B از طرف ASUS و NVIDIA رسمی است، اما تعریف آن «پشتیبانی از مدل‌های تا 200 میلیارد پارامتر» است، نه فهرست تضمین‌شده هر مدل. محاسبه ساده نشان میدهد وزن خام مدل 200B در 4-bit نزدیک 100GB میشود. در بهترین حالت تنها بخشی از 128GB برای سیستم‌عامل، Cache و بافرها باقی میماند؛ بنابراین تنظیمات باید محافظه‌کارانه باشید.

مدل 200B با معماری MoE، Context کوتاه و Runtime بهینه ممکن است قابل‌استفاده باشد، درحالی‌که مدل Dense دیگری با همان پارامتر، Metadata بیشتر یا Kernel ناسازگار ممکن است اجرا نشود. حتی اگر بارگذاری موفق باشد، پهنای باند 273GB/s و توان محاسباتی GB10 سرعت نهایی را تعیین میکند. جا شدن وزن‌ها فقط شرط لازم است.

به همین دلیل، فروشنده یا تیم فنی باید نام کامل مدل، Commit یا Revision، Quantization، Backend، ورژن Container، طول Context، Batch و نتیجه Benchmark را ثبت کند. عبارت کلی «GX10 مدل 200B اجرا میکند» برای طراحی ظرفیت کافی نیست.

چرا Qwen3-235B روی یک GX10 همیشه جا نمیشود؟

NVIDIA در راهنمای رسمی Speculative Decoding توضیح میدهد که Qwen3-235B-A22B همراه با وزن‌ها، KV Cache و Draft Head حتی با FP4 از 128GB عبور میکند و برای سناریوی نمونه به دو دستگاه نیاز دارد. این مثال بسیار آموزنده است: تعداد پارامتر 235B از سقف رسمی یک دستگاه بالاتر است و مؤلفه‌های جانبی نیز حافظه میخواهند.

MoE بودن مدل محاسبه فعال را کم میکند، ولی کل وزن‌ها ناپدید نمیشوند. اگر هدف شما یک مدل MoE بزرگ است، اندازه فایل‌های واقعی و مستندات Runtime را بررسی کنید؛ از روی Active Parameters درباره ظرفیت حافظه قضاوت نکنید.

دو GX10 و مدل 405B؛ امکان فنی با محدودیت روشن

ASUS و NVIDIA اتصال دو دستگاه از طریق ConnectX-7 را برای مدل‌هایی مانند Llama 3.1 405B مطرح کرده‌اند. راهنمای رسمی vLLM نیز یک نمونه دو Node برای ورژن AWQ-INT4 این مدل نشان میدهد. در مثال رسمی، Context و تعداد Sequence بسیار محدود تنظیم شده‌اند؛ این جزئیات نشان میدهند عبارت 405B بیشتر بیانگر امکان فنی است تا یک سرویس پرترافیک آماده.

اتصال دو سیستم به معنی جمع ساده همه منابع نیست. Tensor Parallelism، Ray یا Backend توزیع‌شده، کابل 200Gbps، تأخیر شبکه و تقسیم وزن‌ها سربار ایجاد میکند. اگر هدف اصلی شما 405B است، هزینه دو GX10 را با یک سرور GPU، DGX Station یا Cloud مقایسه کنید. نمونه‌های مقیاس بسیار بزرگ مانند زیرساخت دیتاسنتری OpenAI و Oracle یادآوری میکند که سرویس‌دهی مدل عظیم مسئله‌ای فراتر از ظرفیت خام حافظه است.

LLM تنها مدل قابل اجرا نیست

GX10 برای مدل زبانی طراحی شده، اما به آن محدود نیست. Playbookهای رسمی NVIDIA اجرای Workflowهای تولید تصویر و ویدئو با ComfyUI و مدل‌هایی مانند FLUX، Stable Diffusion، Wan و HunyuanVideo را نیز پوشش میدهند. مدل‌های چندوجهی مانند Phi-4 Multimodal میتوانند متن، تصویر یا صوت را ترکیب کند.

در بینایی ماشین، مدل‌های تشخیص و Segment، در علم داده RAPIDS و در حوزه زیستی Workflowهایی مانند تحلیل Single-cell نیز مطرح‌اند. معیار ظرفیت در هرکدام متفاوت است. برای Diffusion، رزولوشن، تعداد Frame و VAE مهم‌اند؛ برای ویدئو حافظه موقت رشد زیادی دارد؛ برای علم داده اندازه Dataset و عملیات میدرنج تعیین‌کننده‌اند.

کدام Runtime را انتخاب کنیم؟

Ollama و Open WebUI: برای شروع سریع، مدیریت مدل و رابط چت محلی مناسب‌اند. راهنمای رسمی NVIDIA برای GX10/DGX Spark این مسیر را پوشش میدهد. سادگی مزیت اصلی است، اما برای بیشترین Throughput شاید Backend تخصصی‌تر لازم شود.

vLLM: برای سرویس API سازگار با OpenAI، Continuous Batching و توان پاسخ‌گویی بالاتر کاربرد دارد. پشتیبانی واقعی مدل و Quantization را با ورژن Container بررسی کنید.

SGLang: برای Serving و Workflowهای Agent/Structured Generation گزینه مهمی است و NVIDIA فهرستی از مدل‌های اعتبارسنجی‌شده ارائه میکند.

TensorRT-LLM و NIM: برای بهینه‌سازی NVIDIA و استقرار Containerized ارزشمندند. NIM مسیر API آماده‌تری فراهم میکند، اما دسترسی، مجوز و مدل‌های موجود باید کنترل شوند.

PyTorch و Hugging Face: انعطاف بیشتری برای پژوهش و تغییر مدل دارند، ولی ممکن است بدون Kernel یا قالب بهینه از تمام توان سخت‌افزار استفاده نکند.

چگونه قبل از دانلود مدل سازگاری را بررسی کنیم؟

1. نام دقیق Model Repository و Revision را ثبت کنید.
2. معماری Dense یا MoE و تعداد پارامتر کل و فعال را جدا بنویسید.
3. حجم مجموع فایل‌های Weight و Quantization را ببینید.
4. پشتیبانی Arm64 و Compute Capability سخت‌افزار را در Runtime بررسی کنید.
5. ورژن CUDA، Driver، Container و Backend پیشنهادی را تطبیق دهید.
6. حداقل 15 تا 25 درصد حاشیه حافظه برای سیستم و Cache در نظر بگیرید؛ برای Context بلند بیشتر.
7. Context و تعداد Session واقعی را از قبل مشخص کنید.
8. ابتدا مدل کوچک هم‌خانواده را اجرا و سلامت Pipeline را تأیید کنید.
9. سپس مدل اصلی را با Promptهای واقعی فارسی Benchmark کنید.
10. کیفیت، Token/s، زمان اولین Token، مصرف حافظه و پایداری یک‌ساعته را ثبت کنید.

فضای SSD را نیز فراموش نکنید. مدل اصلی، چند Quantization، Container و Cache به‌سرعت ورژن 1TB را پر میکند. نوسان قیمت حافظه و قطعات که در گزارش کمبود جهانی RAM بررسی شده، انتخاب ظرفیت را به یک تصمیم اقتصادی نیز تبدیل میکند.

Benchmark درست برای GX10 چه اجزایی دارد؟

Benchmark خوب فقط یک عدد Token/s نیست. زمان اولین Token برای تجربه چت، Prefill برای اسناد طولانی، Decode برای پاسخ، Throughput برای چند کاربر و مصرف حافظه برای پایداری اهمیت دارند. کیفیت نیز باید با سؤال‌های واقعی و پاسخ مرجع اندازه‌گیری شود.

برای مدل فارسی، مجموعه‌ای از متن رسمی، محاوره، اعداد، نام‌های ایرانی، تاریخ شمسی و اسناد کسب‌وکار بسازید. اگر RAG دارید، دقت بازیابی و استناد را جدا از قدرت LLM بسنجید. اجرای محلی کنترل داده را بیشتر میکند، موضوعی که مقاله هوش مصنوعی و حفظ حریم خصوصی از زاویه مصرف‌کننده بررسی کرده است؛ اما Log و Dataset آزمون نیز باید امن نگهداری شوند.

پنج خطای رایج در انتخاب مدل برای GX10

• انتخاب فقط براساس پارامتر: معماری و Quantization نادیده گرفته میشود.
• مصرف کامل 128GB برای وزن: جایی برای KV Cache و سیستم باقی نمیماند.
• اعتماد به Context اسمی: هزینه حافظه و افت سرعت Context بلند سنجیده نمیشود.
• نادیده‌گرفتن Arm64: افزونه یا باینری موردنیاز بعد از خرید ناسازگار از آب درمیآید.
• یکی‌دانستن Prototype و Production: اجرای موفق یک Prompt با سرویس پایدار چندکاربره اشتباه گرفته میشود.

برای دیدن تفاوت مقیاس، مقاله‌های دیتاسنتر هوش مصنوعی Meta و انرژی زیرساخت xAI نشان میدهند چرا مدل‌های عمومی پرترافیک به طراحی کاملاً متفاوتی نیاز دارند.

سوال‌های متداول درباره مدل‌های قابل اجرا روی ASUS Ascent GX10

آیا هر مدل 200B روی GX10 اجرا میشود؟

خیر. 200B سقف رسمی کلی است. مدل باید با Quantization، Runtime و حافظه باقی‌مانده برای Cache سازگار باشد. عملکرد قابل‌قبول نیز جداگانه باید Benchmark شود.

بهترین اندازه مدل برای شروع چیست؟

مدل 8B یا 14B برای تأیید نصب و Pipeline مناسب است. پس از آن میتوان براساس کیفیت واقعی به 32B یا 70B رفت.

آیا مدل 70B بدون Quantization جا میشود؟

وزن خام 70B در FP16 نزدیک 140GB است و از حافظه 128GB عبور میکند. ورژن‌های 8-bit یا به‌ویژه 4-bit عملی‌ترند.

آیا دو GX10 برای Llama 3.1 405B کافی‌اند؟

راهنمای رسمی NVIDIA نمونه اجرای ورژن AWQ-INT4 را روی دو دستگاه ارائه میکند، اما Context و هم‌زمانی محدود است. این نمونه تضمین یک سرویس پرترافیک نیست.

آیا مدل بزرگ همیشه پاسخ بهتری میدهد؟

خیر. کیفیت به داده آموزشی، زبان، Prompt، RAG، ابزار و وظیفه بستگی دارد. مدل کوچک تخصصی یا Fine-tuned میتواند در مسئله محدود بهتر و سریع‌تر باشد.

کلام آخر

مدل‌های قابل اجرا روی ASUS Ascent GX10 فقط با عدد پارامتر تعیین نمیشوند. حافظه یکپارچه 128GB فضای مهمی برای مدل‌های 70B و حتی نمونه‌های کوانتیزه 120B یا نزدیک سقف 200B فراهم میکند، اما وزن‌ها باید کنار KV Cache، Context، Batch، Runtime و سیستم‌عامل محاسبه شوند.

مدل‌های 8B تا 35B معمولاً بیشترین آزادی را برای ساخت RAG و Agent میدهند. مدل 70B با FP4 یا INT4 نقطه جدی برای کیفیت بالاتر است. GPT-OSS-120B نمونه رسمی مدل بزرگ قابل اجراست و 200B را باید سقف وابسته به شرایط دانست. برای 405B، دو GX10 و تنظیم توزیع‌شده لازم است و حتی آنجا هم محدودیت Context و هم‌زمانی باقی میماند.

پیش از انتخاب نهایی، نام مدل و Quantization را دقیق ثبت کنید، روی Runtime موردنظر تست بگیرید و معیارهای واقعی فارسی را اندازه‌گیری کنید. اگر مدل در حافظه جا شد اما زمان پاسخ، کیفیت یا ظرفیت کاربر مناسب نبود، از نظر عملی «مدل قابل اجرا برای پروژه شما» محسوب نمیشود.