مدل‌های زبانی بزرگ با وزن‌های باز (Open-weight)، نحوه تفکر تیم‌های مهندسی درباره زیرساخت‌های هوش مصنوعی را تغییر داده‌اند. برخلاف APIهای بسته که در آن‌ها ارائه‌دهنده کنترل سخت‌افزار، وزن‌های مدل و برنامه انتشار را در دست دارد، مدل‌های با وزن باز این تصمیمات را به شما بازمی‌گردانند. شما انتخاب می‌کنید که مدل کجا مستقر شود، چگونه تنظیم (tune) شود و چه زمانی — اگر اصلاً لازم باشد — به یک چک‌پوینت (checkpoint) جدید به‌روزرسانی شود. این سطح از مالکیت بسیار قدرتمند است، اما به این معناست که کارِ یکپارچه‌سازی مستقیماً بر عهده شماست.

اگر از یک API مدیریت‌شده مانند GPT-4 شرکت OpenAI یا Claude شرکت Anthropic می‌آیید، خبر خوب این است که بسیاری از ارائه‌دهندگان میزبانی مدل‌های با وزن باز و موتورهای استنتاج (inference engines)، اکنون از زبان مشترکی استفاده می‌کنند: HTTP POST، پیلودهای (payloads) JSON و احراز هویت با توکن حامل (bearer token). مکانیسم‌ها آشنا به نظر می‌رسند، اما جزئیات اهمیت بیشتری دارند، زیرا شما هستید که نه ارائه‌دهنده، مسئول قابلیت اطمینان، کنترل هزینه و شکل‌دهی به رفتار مدل هستید.

اصول اولیه فراخوانی API

در هسته خود، این یکپارچه‌سازی یک درخواست POST است. شما با یک توکن حامل استاندارد در هدر Authorization احراز هویت می‌کنید. بدنه درخواست یک شیء JSON است و مهم‌ترین فیلد آن آرایه messages است. آن آرایه از قالب آشنای چت پیروی می‌کند: به صورت متناوب از نقش‌های system (سیستم)، user (کاربر) و assistant (دستیار) استفاده می‌کند.

ساختار یک درخواست حداقلی در عمل به این صورت است:

  • هدر Authorization را روی Bearer <your-token> تنظیم کنید.
  • یک JSON payload شامل حداقل یک شناسه model و یک لیست messages ارسال کنید.
  • اگر کنترل قطعی (deterministic) یا خلاقانه می‌خواهید، max_tokens و temperature را نیز لحاظ کنید.

پاسخ با یک آرایه choices و یک شیء usage باز می‌گردد. بخش usage را نادیده نگیرید. این بخش شامل prompt_tokens ،completion_tokens و مجموع آن‌هاست. اگر خودتان میزبانی می‌کنید (self-hosting)، این بخش سیگنالی است که به شما می‌گوید آیا یک تعامل خاص با کاربر هزینه‌بر بوده است یا خیر. اگر به یک ارائه‌دهنده استنتاج شخص ثالث هزینه پرداخت می‌کنید، این داده‌های صورت‌حساب شماست. در هر صورت، از روز اول آن را لاگ (log) کنید.

استریمینگ (Streaming) و دلیل استفاده از آن

هیچ‌کس دوست ندارد سه ثانیه به یک چرخنده بارگذاری (loading spinner) خیره شود تا زمانی که اولین تکه از متن ظاهر شود. استریمینگ این مشکل را حل می‌کند. به جای اینکه منتظر بمانید تا مدل کل پاسخ را کامل کند، سرور توکن‌ها را به محض تولید شدن ارسال می‌کند. کلاینت شما رویدادهای ارسال‌شده توسط سرور (Server-Sent Events) یا پاسخ‌های HTTP تکه‌تکه (chunked) را دریافت کرده و می‌تواند کلمات را به محض رسیدن نمایش دهد.

استریمینگ را با تنظیم پرچم stream: true در JSON payload خود فعال کنید. در سمت کلاینت، معمولاً استریم را خط به خط تجزیه می‌کنید و منتظر پیشوندهای data: می‌مانید. اگر اتصال در میانه‌ی استریم قطع شد، آماده اتصال مجدد یا بازگشت به حالت غیر استریمینگ (non-streaming) باشید. تأخیر ادراک‌شده (perceived latency) در اپلیکیشن چت شما به شدت کاهش می‌یابد و کاربران احساس می‌کنند سیستم با آن‌ها در حال فکر کردن است، نه اینکه درخواست آن‌ها را به صورت دسته‌ای (batch-processing) پردازش کند.

فراخوانی تابع (Function Calling) برای جریان‌های کاری دنیای واقعی

مدلی که فقط متن ساده برمی‌گرداند مفید است، اما مدلی که می‌تواند ابزارها را فراخوانی کند، بسیار کاربردی‌تر است. فراخوانی تابع به شما اجازه می‌دهد یک JSON schema تعریف کنید که عملیات‌های موجود — مثلاً search_orders یا update_profile — را توصیف می‌کند و مدل تصمیم می‌گیرد چه زمانی از آن‌ها استفاده کند. مدل به جای پرسیدن سوال بعدی از کاربر، یک فراخوانی تابع ساختاریافته را همراه با آرگومان‌های استخراج‌شده از گفتگو ارسال می‌کند.

به عنوان مثال، اگر کاربری بپرسد: «آخرین سفارش من چه بود؟»، طرحواره شما ممکن است تابعی به نام get_recent_orders با پارامتر limit تعریف کند. مدل یک فراخوانی ابزار (tool call) برمی‌گرداند، بک‌اند شما پرس‌وجو را در پایگاه داده اجرا می‌کند و شما نتیجه را به عنوان یک پیام پاسخِ تابع (function response message) به مدل برمی‌گردانید. سپس مدل یک پاسخ به زبان طبیعی ترکیب و ارائه می‌کند.

برای پیاده‌سازی این مورد:

  • یک آرایه tools یا functions در پیلود خود ارائه دهید.
  • هر ابزار را با یک name (نام)، description (توضیحات) و طرحواره parameters تعریف کنید.
  • پاسخ را برای بررسی دلیل پایان فراخوانی ابزار (tool-calls finish reason) یا سیگنال‌های مشابه بررسی کنید.
  • تابع را در بک‌اند خود با اعتبارسنجی دقیق اجرا کنید. هرگز به خروجی‌های خام مدل برای دسترسی بدون فیلتر به پایگاه داده خود اعتماد نکنید.
  • نتیجه تابع را به تاریخچه پیام‌ها اضافه کنید و یک درخواست پیگیری ارسال کنید تا مدل بتواند پاسخ نهایی را تولید کند.

این الگو شکاف بین متن مولد و سیستم‌های تعیین‌پذیر (deterministic) را پر می‌کند. هوش مصنوعی شما می‌تواند تقویم‌ها را بخواند، APIها را پرس‌وجو کند یا وب‌هوک‌ها (webhooks) را بدون نیاز به کدنویسی سخت (hard-coding) تمام شاخه‌ها، فعال کند.

مقاوم‌سازی برای محیط عملیاتی (Production)

اجرای مدل‌های با وزن باز در محیط عملیاتی، شما را در معرض همان حالت‌های شکست (failure modes) سیستم‌های توزیع‌شده قرار می‌دهد، به علاوه چند حالت منحصر‌به‌فرد دیگر. استنتاج مدل بسیار محاسبات‌محور (compute-intensive) است و اندپوینت‌ها (endpoints) ممکن است تحت فشار بار (load) از کار بیفتند. در اینجا نحوه پایدار نگه داشتن اپلیکیشن خود آورده شده است.

خطاها و تلاش‌های مجدد (Retries)

  • 429 Too Many Requests: این یک سیگنال محدودیت نرخ (rate-limit) است. از روش backoff نمایی همراه با jitter استفاده کنید. با یک تأخیر کوتاه شروع کنید، در صورت تکرار خطای 429 آن را دو برابر کنید و برای جلوگیری از فشار بیش از حد به سرور، آن را در چند ثانیه محدود کنید.
  • 5xx Server Errors: این خطاها معمولاً گذرا هستند، به‌ویژه اگر درخواست‌ها را به مجموعه‌ای از پردازنده‌های گرافیکی (GPU workers) هدایت می‌کنید. آن‌ها را مجدداً تلاش (retry) کنید، اما برای تعداد تلاش‌ها سقف مشخصی تعیین کنید؛ سه بار یک مقدار پیش‌فرض رایج است.
  • 4xx Client Errors: این خطاها را کورکورانه دوباره تلاش نکنید. خطای 400 به معنای ساختار نادرست داده‌های ارسالی (payload) شماست، 401 به معنای اشتباه بودن توکن شماست و 404 به این معناست که شناسه مدل (model ID) در آن نقطه پایانی (endpoint) وجود ندارد. به جای ایجاد حلقه تکرار، درخواست را اصلاح کنید.

زمان‌بندی‌ها (Timeouts) و فرآیندهای معلق

استنتاج (Inference) می‌تواند زمانی که صف‌ها پر می‌شوند یا زمانی که یک پردازنده در میانه تولید پاسخ از کار می‌افتد، با تأخیر مواجه شود. همیشه یک زمان انتظار (timeout) برای درخواست تعیین کنید. اگر مقدار پیش‌فرض کلاینت HTTP شما بی‌نهایت است، آن را تغییر دهید. یک نقطه شروع منطقی برای تکمیل‌های استاندارد (standard completions) بین ۳۰ تا ۶۰ ثانیه و برای بررسی سلامت (health checks) زمان کوتاه‌تری است. اگر زمان انتظار تمام شد، با آن به عنوان یک شکست برخورد کنید، آن را ثبت (log) کنید و تصمیم بگیرید که آیا یک خطای ملایم به کاربر نشان دهید یا روی یک مدل جایگزین (fallback model) دوباره تلاش کنید.

کنترل بودجه

تعداد توکن‌ها مستقیماً به پول یا ساعات استفاده از GPU تبدیل می‌شود. برای هر درخواست، هم توکن‌های ورودی (prompt) و هم توکن‌های خروجی (completion) را ثبت کنید. آن‌ها را به تفکیک کاربر، ویژگی (feature) و نسخه مدل پیگیری کنید. مدل‌های با وزن باز (open-weight models) به شما اجازه می‌دهند چک‌پوینت‌ها را تعویض کنید، اما هر چک‌پوینت پروفایل هزینه و اندازه پنجره بافت (context-window) مخصوص به خود را دارد. بدون ثبت گزارش‌ها (logs)، متوجه نخواهید شد که کدام بخش از محصول شما در حال هدر دادن منابع محاسباتی است.

شکل‌دهی به رفتار با استفاده از پیام‌های سیستم (System Messages)

پیام سیستم اولین خط دفاعی و کنترلی شماست. از آن برای تعیین لحن، اعمال محدودیت‌ها و تزریق بافت ثابت (static context) که هر گفتگوی کاربر باید به آن احترام بگذارد، استفاده کنید. از آنجایی که مدل‌های با وزن باز بسته به تنظیمات دقیق (fine-tuning) و پیام‌های سیستم خود متفاوت رفتار می‌کنند، با این فیلد مانند یک متغیر برخورد کنید که باید آن را با تست A/B بسنجید. یک پیام سیستم مبهم، پاسخ‌های مبهم تولید می‌کند. یک پیام دقیق، مدل را در مسیر درست نگه می‌دارد؛ برای مثال، به دستیار بگویید که فقط امور مربوط به صورت‌حساب و مرجوعی را مدیریت می‌کند و باید با ادب از انجام هر کار دیگری خودداری کند.

آزادی زیرساختی و حاکمیت داده‌ها

یکی از آرام‌ترین مزایای مدل‌های با وزن باز، مالکیت و نگهداری (custody) است. پیام‌ها و پاسخ‌های شما نیازی به خروج از محیط شما ندارند. اگر مدل را در محل (on-premises) یا داخل یک ابر خصوصی مجازی (VPC) اجرا کنید، قراردادهای پردازش داده با شخص ثالث را حذف کرده و قرار گرفتن در معرض جنجال‌های مربوط به داده‌های آموزشی را کاهش می‌دهید. این موضوع برای حوزه‌های سلامت، امور مالی و هر حوزه‌ای که نشت داده در آن یک مسئله انطباق (compliance) محسوب می‌شود، اهمیت دارد.

حتی اگر از یک میزبان استنتاج خارجی استفاده می‌کنید، وزن‌های باز به شما قابلیت جابه‌جایی (portability) می‌دهند. اگر میزبان قیمت‌گذاری یا شرایط خود را تغییر داد، می‌توانید همان فایل‌های مدل را به ارائه‌دهنده دیگری منتقل کنید یا آن‌ها را به داخل سازمان خود بیاورید. شما در یک API واحد گیر نمی‌افتید، زیرا تنها یک شرکت وجود دارد که وزن‌ها را در اختیار دارد.

یک نقطه شروع کاربردی

اگر امروز در حال ادغام هستید، با یک مدل واحد و یک نقطه پایانی (endpoint) واحد شروع کنید. کلاینت HTTP خود را در یک لایه انتزاعی (abstraction layer) کوچک قرار دهید که احراز هویت، تلاش‌های مجدد و ثبت توکن‌ها را مدیریت کند. در مرحله بعد قابلیت استریمینگ (streaming) را اضافه کنید، زیرا بازدهی تجربه کاربری آن فوری است. سپس یک فراخوانی تابع (function call) برای یک گردش کار با ارزش بالا معرفی کنید؛ مانند جستجوی وضعیت، نظارت بر محتوا یا پر کردن فرم‌ها. قبل از گسترش عملیات، به مدت یک هفته تأخیر (latency)، نرخ خطا و هزینه توکن‌ها را نظارت کنید.

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

منابع و مطالعه بیشتر