سرویس‌دهی مدل‌های هوش مصنوعی با NVIDIA Triton و مکانیزم دسته‌بندی پویا

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

NVIDIA Triton Inference Server دقیقاً همین مشکل را حل می‌کند؛ این ابزار مانند یک لایه سازمان‌دهنده با سرعت بالا عمل می‌کند که نحوه برخورد درخواست‌ها با سخت‌افزار شما را مدیریت می‌کند. طبق راهنمای فنی منتشر شده در ۱۲ اوت ۲۰۲۶، تریتون به توسعه‌دهندگان اجازه می‌دهد مدل‌هایی از چارچوب‌های مختلف را روی یک سرور واحد اجرا کنند، بدون اینکه نیاز باشد با ابزارهای استقرار مجزا دست‌وپنجه نرم کنند.

بسیاری از تیم‌های هوش مصنوعی با دنیایی تکه‌تکه روبرو هستند؛ جایی که یک مدل PyTorch به ابزاری نیاز دارد و یک مدل TensorFlow به ابزاری دیگر. این پراکندگی باعث ایجاد بدهی فنی شدید می‌شود و انتقال از مرحله پژوهش به تولید را کند می‌کند. مدل هوش مصنوعی شما را مثل یک ماشین مسابقه‌ای تصور کنید؛ خودِ مدل موتور است، اما تریتون مانند یک تیم فنی حرفه‌ای در گاراژ است که تضمین می‌کند ماشین در ترافیک سنگین، بدون نقص و با حداکثر توان حرکت کند.

معماری مستقل از چارچوب

قدرت اصلی تریتون در مستقل بودن از چارچوب‌هاست. این ابزار مانند یک کنترل از راه دور جهانی برای نیازهای استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه به خودِ آشپزی و نه دوره آموزش آشپز — عمل می‌کند و استقرار مدل‌ها را روی سخت‌افزارهای متنوع، از جمله CPU و GPU، ساده می‌سازد. تریتون یک نرم‌افزار متن‌باز برای سرویس‌دهی است که توسط انویدیا توسعه یافته و برای مقیاس‌پذیری بالا، کارایی بهینه و ادغام آسان در گردش‌کارهای موجود طراحی شده است.

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

• TensorFlow
• PyTorch
• ONNX Runtime
• TensorRT
• OpenVINO

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

مکانیزم‌های بهینه‌سازی عملکرد

تریتون از چندین تکنیک خاص برای به حداکثر رساندن بهره‌وری سخت‌افزار و بیرون کشیدن آخرین قطره سرعت از مدل‌ها استفاده می‌کند. اثرگذارترین این تکنیک‌ها، دسته‌بندی پویا (Dynamic Batching) است. به‌جای پردازش تک‌تک درخواست‌ها، مدیر صفِ هوشمند تریتون، درخواست‌هایی را که در یک بازه زمانی مشخص (Timeout) می‌رسند، در یک دسته واحد گروه‌بندی می‌کند. این کار به GPU اجازه می‌دهد چندین ورودی را به‌طور موازی پردازش کند و توان عملیاتی (Throughput) کلی را به‌شدت افزایش دهد.

توسعه‌دهندگان می‌توانند در فایل config.pbtxt با تنظیم پارامتر max_queue_delay_microseconds (مثلاً ۱۰,۰۰۰ میکروثانیه)، حداکثر تأخیر برای تشکیل یک دسته را تعیین کنند. پارامترهای دیگری مانند max_batch_size و preserve_batch_consistency نیز برای کنترل دقیق‌تر در دسترس هستند.

برای مدل‌های عظیمی که حافظه یک دستگاه را پر می‌کنند و از ظرفیت تک‌تراشه فراتر می‌روند، تریتون از موازی‌سازی مدل (Model Parallelism) و موازی‌سازی تنسور (Tensor Parallelism) پشتیبانی می‌کند. این ویژگی‌ها بار کاری استنتاج را بین چندین GPU توزیع می‌کنند. وقتی این قابلیت‌ها با TensorRT — بهینه‌ساز و محیط اجرای استنتاج یادگیری عمیق انویدیا — ترکیب شوند، افزایش سرعت بسیار چشمگیرتر و دراماتیک‌تر می‌شود.

مدیریت منابع و اجرا

تریتون همچنین امکان اجرای هم‌زمان مدل (Concurrent Model Execution) را فراهم می‌کند. این قابلیت اجازه می‌دهد چندین مدل به‌طور هم‌زمان روی یک سخت‌افزار اجرا شوند تا هیچ چرخه پردازشی از GPU هدر نرود. برای مدیریت این مدل‌ها، تریتون از یک مخزن مدل (Model Repository) سلسله‌مراتبی استفاده می‌کند.

ساختار مخزن مدل

مخزن مدل‌ها را در ساختار دایرکتوری خاصی سازمان‌دهی می‌کند تا مدیریت نسخه‌ها (Revisions) آسان شود. یک چیدمان معمولی به این شکل است:

• /models
  • /your_tensorflow_model
    • /1 (دایرکتوری نسخه شامل saved_model.pb و variables/)
    • config.pbtxt
  • /your_pytorch_model
    • /1 (دایرکتوری نسخه شامل model.pt)
    • config.pbtxt
  • /your_onnx_model
    • /1 (دایرکتوری نسخه شامل model.onnx)
    • config.pbtxt

بخش حیاتی در اینجا فایل config.pbtxt است. این فایل متنی از نوع Protocol Buffer، پلتفرم مدل (مثلاً tensorflow_saved_model)، ابعاد ورودی/خروجی (مانند dims: [ 224, 224, 3 ] برای تصویر)، نوع داده (مانند TYPE_FP32) و پارامترهای خاصی مثل max_batch_size را تعریف می‌کند.

یکپارچه‌سازی و دسترسی به API

توسعه‌دهندگان از طریق دو نقطه اتصال (Endpoint) اصلی با تریتون تعامل دارند که انعطاف‌پذیری لازم را برای موارد استفاده مختلف فراهم می‌کند:

۱. HTTP/1.1: یک API آشنای RESTful که برای یکپارچه‌سازی سریع، توسعه و درخواست‌های ساده با کتابخانه‌هایی مثل requests در پایتون ایده‌آل است. برای مثال، درخواستی به آدرس http://localhost:8000/v2/models/your_tensorflow_model/infer می‌تواند با یک Payload از نوع JSON شامل نام تنسور ورودی، شکل (Shape) و داده‌ها ارسال شود.

۲. gRPC: یک چارچوب متن‌باز با عملکرد بالا برای ارتباطات بین‌پردازشی که تأخیر کمتر و توان عملیاتی بیشتری دارد و به همین دلیل انتخاب اول برای محیط‌های عملیاتی (Production) است.

برای گردش‌کارهای پیچیده، تریتون مجموعه‌های مدل (Model Ensembles) را ارائه می‌دهد. این قابلیت اجازه می‌دهد خروجی یک مدل (مثلاً پیش‌پردازشگر متن) مستقیماً وارد مدل دیگر (مثلاً تحلیل‌گر احساسات) شود، بدون اینکه نیاز به مدیریت پیچیده در سطح اپلیکیشن باشد. همچنین برای نیازهای بسیار خاص، تریتون از بک‌اِندهای سفارشی (Custom Backends) پشتیبانی می‌کند تا پیشگامان این حوزه بتوانند فناوری‌های استنتاج اختصاصی یا پژوهش‌های لبه را که توسط بک‌اِندهای پیش‌فرض پوشش داده نمی‌شوند، ادغام کنند.

استقرار و نظارت

استقرار معمولاً از طریق کانتینرهای Docker انجام می‌شود تا یکپارچگی محیط در مراحل مختلف خط لوله (Pipeline) تضمین شود. یک تنظیمات استاندارد شامل دریافت ایمیج تریتون (مثلاً nvcr.io/nvidia/tritonserver:23.10-py3) و متصل کردن مخزن مدل محلی به کانتینر با استفاده از فلگ -v است.

هنگام اجرای کانتینر، توسعه‌دهندگان پورت‌های خاص میزبان را به پورت‌های کانتینر مپ می‌کنند: پورت ۸۰۰۰ برای HTTP، ۸۰۰۱ برای gRPC و ۸۰۰۲ برای متریک‌ها. فلگ --gpus all برای اعطای دسترسی سرور به تمام سخت‌افزارهای انویدیا در دسترس استفاده می‌شود. یک دستور اجرای معمولی شامل -d برای حالت Detached (پس‌زمینه) و --rm برای حذف کانتینر پس از خروج است.

برای حفظ سلامت سیستم در محیط عملیاتی، تریتون متریک‌های سازگار با Prometheus را ارائه می‌دهد. این متریک‌ها نظارت بر موارد زیر را ممکن می‌کنند:

• تأخیر استنتاج (Inference latency)
• توان عملیاتی (Throughput)
• بهره‌وری GPU (GPU utilization)
• زمان بارگذاری مدل (Model loading times)

این شفافیت برای شناسایی گلوگاه‌ها، مدیریت نسخه‌های مدل بدون توقف سیستم (Downtime) و اتخاذ تصمیمات آگاهانه برای مقیاس‌بندی (Scaling) ضروری است. همچنین با فراهم کردن امکان بازگشت آسان به نسخه‌های قبلی مدل، از یک خط لوله CI/CD قدرتمند پشتیبانی می‌کند.

پیش‌نیازهای پیاده‌سازی

قبل از استقرار، کاربران باید «تجهیزات» زیر را در زرادخانه خود داشته باشند:

• مدل آموزش‌دیده: تریتون مدل‌ها را سرویس‌دهی می‌کند، نه آموزش. مدل‌ها باید در فرمت‌های پشتیبانی‌شده مثل ONNX، TensorFlow SavedModel یا PyTorch TorchScript باشند.
• تسلط به کانتینرسازی: مهارت در Docker برای نصب و مدیریت ضروری است تا یکپارچگی محیط‌ها تضمین شود.
• سخت‌افزار: اگرچه CPU پشتیبانی می‌شود، اما برای رسیدن به حداکثر عملکرد و ادغام با TensorRT، داشتن GPUهای انویدیا الزامی است.
• مهارت‌های فنی: آشنایی با خط فرمان (Command-line kung fu) برای تعامل با API و درک عمیق مفاهیم استنتاج مانند دسته‌بندی و زمان‌بندی درخواست‌ها.

موازنه‌های عملکرد بالا

با وجود قدرت زیاد، تریتون هزینه‌های جانبی (Overheads) خاص خود را دارد. یک منحنی یادگیری برای تسلط بر پیکربندی‌های Ensemble، بک‌اِندهای سفارشی و استراتژی‌های پیچیده زمان‌بندی وجود دارد. همچنین، در حالی که روی CPU اجرا می‌شود، چشمگیرترین دستاوردهای عملکردی — به‌ویژه موارد مربوط به ادغام با TensorRT — نیازمند GPUهای انویدیا هستند.

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

جزئیات عملیاتی پیاده‌سازی

برای درک جریان عملیاتی، فایل config.pbtxt یک مدل TensorFlow را در نظر بگیرید. این فایل پلتفرم را platform: "tensorflow_saved_model" تعریف کرده و تنسور ورودی را با نام name: "input_tensor" و نوع data_type: TYPE_FP32 و ابعاد dims: [ 224, 224, 3 ] مشخص می‌کند. خروجی نیز به همین ترتیب تعریف می‌شود، مثلاً dims: [ 1000 ] برای یک تسک طبقه‌بندی.

در پیاده‌سازی دسته‌بندی پویا، پیکربندی می‌تواند شامل یک instance_group باشد تا تعداد نمونه‌های مدل مشخص شود. برای مثال، تنظیم count: 2 و kind: KIND_GPU اجازه می‌دهد دو نمونه از مدل به‌طور هم‌زمان روی GPU اجرا شوند. سپس بلوک dynamic_batching با مدیریت max_queue_delay_microseconds تعادلی بین تأخیر و توان عملیاتی ایجاد می‌کند.

برای کسانی که از پایتون برای تعامل با نقطه اتصال HTTP استفاده می‌کنند، فرآیند شامل آماده‌سازی یک آرایه NumPy، تبدیل آن به یک لیست و ارسال آن از طریق یک درخواست POST است. Payload ارسالی باید به‌طور صریح name (نام)، shape (شکل) و datatype (نوع داده، مثلاً "FP32") ورودی‌ها را ذکر کند تا با پیکربندی سرور مطابقت داشته باشد.

این چرخش به سمت سرورهای استنتاج یکپارچه به این معناست که صنعت در حال فاصله گرفتن از استقرارهای وابسته به چارچوب است. انویدیا با جداسازی مدل از منطق سرویس‌دهی، الگوی «مدل به‌عنوان سرویس» (Model-as-a-Service) را به استاندارد شرکت‌های بزرگ تبدیل می‌کند. برای توسعه‌دهنده، این یعنی زمان کمتر برای لوله‌کشی زیرساختی و زمان بیشتر برای بهبود دقت مدل.

برای شروع، می‌توانید آخرین ایمیج تریتون را از NVIDIA Container Registry دریافت کنید و با یک مدل ساده ONNX، تفاوت توان عملیاتی که دسته‌بندی پویا ایجاد می‌کند را تجربه کنید.

گام بعدی شما

• ایمیج تریتون را از NVIDIA Container Registry دریافت کنید و با یک مدل ساده ONNX، تفاوت توان عملیاتی در حالت دسته‌بندی پویا را تست کنید.
• ساختار config.pbtxt را برای مدل‌های فعلی خود طراحی کنید تا بتوانید از اجرای هم‌زمان مدل‌ها بهره ببرید.
• اگر تأخیر (Latency) برای شما حیاتی است، تعامل با تریتون را از HTTP به gRPC تغییر دهید.

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