«تست سریع مدل‌ها»؛ هدف جدید زیرساخت‌های خصوصی هگینگ‌فیس

اگر ساعت‌ها وقت خود را صرف پیکربندی سرورهای GPU یا کلنجار رفتن با کلاستر‌های کوبرنتیز می‌کنید، باید بدانید که دوران انتظار برای استقرار مدل‌ها به پایان رسیده است. اکنون می‌توانید تنها با یک دستور متنی، یک نقطه انتهایی استنتاجی خصوصی و سازگار با OpenAI را فعال کنید و بلافاصله مدل خود را به API متصل کنید. طبق اعلام رسمی Hugging Face، این قابلیت که در ۲۶ ژوئن ۲۰۲۶ عرضه شد، اجازه می‌دهد مدل‌های زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری هستند که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهند — را در محیط‌های ابری به صورت موقت و سریع پیاده‌سازی کنید. این ویژگی به شما امکان می‌دهد به محض فعال شدن مدل، آن را از طریق یک نوت‌بوک، لپ‌تاپ شخصی یا هر مکان دیگری مورد پرس‌وجو قرار دهید.

همان‌طور که در تحلیل قبلی ما درباره‌ی OpenKnowledge و اهمیت همگام‌سازی محلی مدل‌ها اشاره کردیم، این رویکرد جدید تمرکز را از همگام‌سازی محلی به سمت انعطاف‌پذیری ابری و محیط‌های گذرا (Ephemeral) می‌برد. برای اکثر توسعه‌دهندگان، دردسرهای راه‌اندازی یک سرور GPU معمولاً شامل کنسول‌های پیچیده ابری یا تنظیمات دشوار داکر است، اما Hugging Face Jobs زیرساخت را به سادگی یک فراخوانی تابع تبدیل کرده است. در واقع، این سریع‌ترین راه برای راه‌اندازی یک مدل جهت انجام تست‌ها، ارزیابی‌ها (Evals) یا تولیدات دسته‌ای (Batch Generation) است.

بر اساس مستندات huggingface.co، این سامانه از مدل پرداخت ثانیه‌ای بر اساس سخت‌افزار استفاده می‌کند. این ویژگی آن را به یک محیط آزمایشگاهی (Sandbox) ایده‌آل تبدیل می‌کند؛ جایی که توسعه‌دهندگان می‌توانند بدون تعهد به اجاره بلندمدت یک نمونه (Instance)، مجموعه‌ای از ارزیابی‌ها را اجرا کرده یا نسخه جدیدی از مدل را تست کنند.

مکانیسم استقرار

استقرار بر پایه دستور hf jobs run است که در واقع یک پوشش (Wrapper) برای داکر روی زیرساخت‌های هگینگ‌فیس محسوب می‌شود. برای شروع، کاربر به نسخه ۱.۲۰.۰ یا بالاتر از huggingface_hub نیاز دارد که با دستور pip install -U "huggingface_hub>=1.20.0" قابل نصب است. همچنین داشتن یک روش پرداخت معتبر یا داشتن موجودی مثبت در حساب پیش‌پرداخت و ورود به سیستم از طریق دستور hf auth login در محیط محلی ضروری است.

• انتخاب سخت‌افزار: نوع GPU از طریق پرچم --flavor تعیین می‌شود (مثلاً a10g-large).
• باز کردن پورت: پرچم --expose 8000 پورت داخلی کانتینر را از طریق یک پروکسی عمومی جاب‌ها به بیرون می‌برد. برای جزئیات بیشتر در این مورد، می‌توان به راهنمای Serve Models مراجعه کرد.
• منبع تصویر: برای تضمین سازگاری کامل با APIهای OpenAI، این فرآیند از تصویر رسمی vllm/vllm-openai استفاده می‌کند.

به‌عنوان مثال، برای اجرای مدل Qwen/Qwen3-4B، دستور زیر را به همراه پرچم timeout (برای جلوگیری از هزینه‌های پیش‌بینی نشده در صورت فراموشی در بستن جاب) به کار می‌برند:
hf jobs run --flavor a10g-large --expose 8000 --timeout 2h vllm/vllm-openai:latest vllm serve Qwen/Qwen3-4B --host 0.0.0.0 --port 8000

پس از شروع، سامانه یک URL منحصربه‌فرد (مانند https://<job_id>--8000.hf.jobs) و یک Job ID (مانند 6a381ca1953ed90bfb947332) را چاپ می‌کند. پس از چند دقیقه زمان لازم برای دانلود وزن‌های باز (Open Weights) — یعنی همان دستور پخت مدل که علناً منتشر شده — و بوت شدن، عبارت "Application startup complete" در لاگ‌ها ظاهر می‌شود و سرور فعال می‌گردد. دسترسی به این سرور محافظت شده است؛ هر درخواست باید یک توکن HF را به عنوان Bearer Token ارسال کند، زیرا بازدیدهای ساده از طریق مرورگر رد می‌شوند.

پرس‌وجو از نقطه انتهایی

از آنجا که vLLM با پروتکل OpenAI صحبت می‌کند، تعامل با آن بسیار ساده است. کاربران می‌توانند با یک درخواست سریع به مسیر /v1/models وضعیت سلامت سرور را بررسی کنند.

• روش Curl: درخواست‌ها می‌توانند از طریق curl با استفاده از هدر Authorization: Bearer $(hf auth token) و یک بدنه JSON که مدل و پیام‌ها را مشخص می‌کند، ارسال شوند.
• یکپارچگی با پایتون: با استفاده از کتابخانه openai پایتون، کاربران مقدار base_url را به URL دریافتی از HF Jobs تغییر داده و توکن HF را از طریق تابع get_token() از کتابخانه huggingface_hub به عنوان api_key ارسال می‌کنند.
• پاسخ نمونه: یک درخواست ساده به Qwen3-4B با پیام "Hello!"، پاسخی در قالب JSON استاندارد OpenAI برمی‌گرداند که محتوای پاسخ در مسیر choices[0].message.content قرار دارد.

مقیاس‌پذیری برای مدل‌های بزرگ

برای مدل‌های سنگین‌تر با وزن‌های بیشتر، زیرساخت از طریق «Flavor»های قدرتمندتر و موازی‌سازی تنسور (Tensor Parallelism) مقیاس می‌یابد. برای اجرای مدل ۱۲۲ میلیارد پارامتری Qwen3.5-MoE (معماری ترکیب خبره‌ها)، راهنمای رسمی استفاده از h200x2 (دو GPU از نوع H200) و تنظیم مقدار --tensor-parallel-size روی ۲ را توصیه می‌کند.

• مدیریت حافظه: مدل Qwen3.5-122B از معماری ترکیبی Mamba/Attention با پنجره زمینه (Context Window) پیش‌فرض ۲۵۶ هزار توکن استفاده می‌کند؛ بنابراین کاربران باید طول زمینه را محدود کنند تا از خطاهای کمبود حافظه (OOM) جلوگیری شود.
• بهینه‌سازی: تنظیم --max-model-len 32768 و --max-num-seqs 256 مدل را در محدوده حافظه GPU نگه می‌دارد. اگر مدل با خطای cache-block مواجه شد، اولین گام توصیه‌شده، کاهش این دو مقدار است.
• بهره‌وری هزینه: مدل‌های H200 به عنوان بهترین ارزش خرید برای مدل‌های مقیاس بزرگ شناخته می‌شوند. البته توصیه می‌شود برای صرفه‌جویی در هزینه، کارهای فعال را صراحتاً با دستور hf jobs cancel <job_id> لغو کنید. در حالی که --timeout مانند یک شبکه ایمنی عمل می‌کند، لغو دستی ارزان‌تر است. برای مثال، هزینه یک نمونه a10g-large حدود ۱.۵۰ دلار در ساعت است.

یکپارچگی پیشرفته و عیب‌یابی

به جز فراخوانی‌های ساده API، این سامانه از شل‌های تعاملی و رابط‌های کاربری نیز پشتیبانی می‌کند. با افزودن پرچم --ssh در هنگام اجرا (که نیازمند ثبت یک کلید عمومی در مسیر huggingface.co/settings/keys است)، توسعه‌دهندگان می‌توانند با دستور hf jobs ssh <job_id> یک شل باز کنند.

در داخل کانتینر، کاربران می‌توانند دستور nvidia-smi را اجرا کنند تا مصرف حافظه GPU را زیر نظر بگیرند، فرآیندها را بررسی کنند یا مستقیماً با مدل تعامل داشته باشند. این امر عیب‌یابی خطاهای استقرار را بسیار ساده‌تر از خواندن لاگ‌های خارجی می‌کند. پشتیبانی از SSH به‌طور خاص مستلزم داشتن huggingface_hub >= 1.20.0 است.

برای کسانی که رابط بصری را ترجیح می‌دهند، چند خط کد Gradio می‌تواند به نقطه انتهایی متصل شود. اگر سرور با پرچم --reasoning-parser deepseek_r1 اجرا شود، رابط کاربری می‌تواند «زنجیره تفکر» (Chain-of-Thought) — شبیه وقتی شاگرد ریاضی پای تخته بلند بلند فکر می‌کند تا به جواب برسد — را از پاسخ نهایی جدا کرده و در یک پنل تاشو نمایش دهد. پیاده‌سازی Gradio از یک عنوان متادیتا به نام "💭 Thinking" در ChatMessage و وضعیت "pending" یا "done" برای استریم کردن استدلال‌ها استفاده می‌کند.

علاوه بر این، این نقطه انتهایی می‌تواند به عنوان بک‌اند برای عامل‌های کدنویسی مانند Pi عمل کند. برای این کار، سرور باید با پرچم --enable-auto-tool-choice و یک --tool-call-parser متناسب با خانواده مدل (مثلاً hermes برای Qwen3) اجرا شود.

• پیکربندی عامل: کاربران جاب را به عنوان یک ارائه‌دهنده سفارشی در فایل ~/.pi/agent/models.json تعریف می‌کنند و مقادیر baseUrl، apiKey و شناسه مدل را مشخص می‌نمایند.
• قابلیت‌ها: پس از پیکربندی، این عامل می‌تواند عملیات خواندن، نوشتن، ویرایش و اجرای دستورات Bash را در ترمینال، با بهره‌گیری از مدل میزبانی‌شده، انجام دهد.

تفاوت HF Jobs و Inference Endpoints

بسیار مهم است که این ابزار را از Inference Endpoints مدیریت‌شده هگینگ‌فیس متمایز کنیم. هدف HF Jobs حداکثر انعطاف‌پذیری و آزمایش‌های کوتاه‌مدت است؛ در واقع یک docker run مدیریت‌شده است که کاربر کنترل کامل روی تصویر، پرچم‌های دقیق vllm serve و سخت‌افزار دارد و هزینه را به صورت ثانیه‌ای می‌پردازد.

در مقابل، Inference Endpoints برای سرویس‌های آماده تولید (Production) طراحی شده‌اند و لایه‌های عملیاتی پیچیده‌تری دارند، از جمله:

• مقیاس‌دهی به صفر (Scale-to-Zero): حذف خودکار هزینه‌ها در زمان‌هایی که هیچ درخواستی ارسال نمی‌شود و سیستم غیرفعال است.
• کنترل دسترسی: گزینه‌های بسیار دقیق‌تر برای عمومی، محافظت‌شده (Protected) یا کاملاً خصوصی کردن نقطه انتهایی.

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

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

گام بعدی شما

• بررسی لیست سخت‌افزارهای در دسترس با دستور hf jobs hardware برای بهینه‌سازی هزینه‌ها.
• تست مدل‌های کوچک مانند Qwen3-4B برای ارزیابی سرعت استنتاج در محیط vLLM.
• پیاده‌سازی یک رابط Gradio ساده برای مشاهده زنجیره تفکر مدل‌های استدلالی.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.