مدل مجازی
مدل مجازی در گدارAI یک شناسه پایدار برای مصرف مدل است. اپلیکیشن شما همان شناسه را در فیلد model میفرستد و گدارAI پشت آن، مقصدهای واقعی، مسیریابی، تلاش دوباره، مسیر جایگزین و دسترسیها را مدیریت میکند.
اگر هنوز جایگاه درگاه را نمیشناسید، ابتدا معرفی درگاه مدلهای زبانی را بخوانید. اگر فقط میخواهید اولین درخواست را بفرستید، اولین درخواست به درگاه مستقیمتر است.
چه زمانی مدل مجازی بسازیم؟
مدل مجازی برای این سناریوها مناسب است:
- میخواهید نام مدل در کد محصول پایدار بماند، حتی اگر مقصد پشت آن تغییر کند.
- میخواهید یک مقصد اصلی و یک مقصد پشتیبان داشته باشید.
- میخواهید ترافیک را بین چند مقصد تقسیم کنید.
- میخواهید تلاش دوباره، مهلت پاسخ و مسیر جایگزین را در سطح درگاه تنظیم کنید.
- میخواهید دسترسی مصرف مدل را برای کاربران یا تیمها کنترل کنید.
برای یک تست سریع، میتوانید مستقیم از شناسه مدل فعال استفاده کنید. برای اتصال محصولی که قرار است در زمان رشد کند، مدل مجازی معمولاً انتخاب قابل نگهداریتری است.
مفاهیم اصلی
| مفهوم | توضیح |
|---|---|
| شناسه فنی | نام پایدار مدل مجازی؛ همان مقداری که اپلیکیشن در model میفرستد |
| مقصد | مدل واقعی یا مدل فعال در حساب ارائهدهنده که پشت مدل مجازی قرار میگیرد |
| استراتژی مسیریابی | روش انتخاب مقصد؛ «اولویتی» یا «وزنی» |
| تلاش دوباره | تکرار درخواست روی همان مقصد در خطاهای مشخص |
| مسیر جایگزین | رفتن به مقصد بعدی وقتی مقصد فعلی با کدهای مشخص ناموفق میشود |
| حالتهای قابل ارائه | حالتهایی که همه مقصدهای انتخابشده بهصورت مشترک پشتیبانی میکنند |
پیشنیازها
- حداقل یک حساب ارائهدهنده فعال داشته باشید.
- مدلهای موردنیاز روی حساب ارائهدهنده فعال باشند.
- مقصدهایی را انتخاب کنید که حالت مشترک معنادار دارند؛ برای نمونه، همه مقصدها برای چت مناسب باشند.
- بدانید چه کسانی باید مدل مجازی را مدیریت کنند و چه کسانی فقط مصرفکننده هستند.
ساخت مدل مجازی
در صفحه «مدلهای مجازی»، «مدل مجازی جدید» را انتخاب کنید و این بخشها را تکمیل کنید.
۱. شناسه فنی را تعیین کنید
شناسه فنی را طوری انتخاب کنید که برای کد محصول پایدار و قابل فهم باشد؛ برای نمونه:
support-chat
invoice-assistant
content-review
شناسه فنی فقط میتواند شامل حرف، عدد، خط تیره و آندرلاین باشد. اگر بعداً مقصدهای پشت مدل تغییر کنند، بهتر است این شناسه در کد محصول تغییر نکند.
۲. استراتژی مسیریابی را انتخاب کنید
دو استراتژی اصلی وجود دارد:
| استراتژی | کاربرد مناسب |
|---|---|
| اولویتی | یک مقصد اصلی دارید و فقط در خطاهای مشخص به مقصد بعدی میروید |
| وزنی | میخواهید ترافیک را بر اساس درصد بین چند مقصد تقسیم کنید |
در مسیریابی وزنی، جمع وزن مقصدها باید ۱۰۰ باشد.
۳. مقصدها را اضافه کنید
برای هر مقصد، ارائهدهنده و مدل ارائهدهنده را انتخاب کنید. هر مقصد باید از مدلهایی باشد که در حسابهای ارائهدهنده فعال و برای فضای کاری قابل مصرف هستند.
از ترکیب مقصدهایی با کاربرد متفاوت پرهیز کنید. برای نمونه، مدل چت و مدل امبدینگ را پشت یک مدل مجازی قرار ندهید، چون نقطه پایانی و شکل درخواست آنها متفاوت است.
۴. رفتار خطا را تنظیم کنید
برای هر مقصد میتوانید این مقدارها را تنظیم کنید:
| تنظیم | مقدار پیشفرض | توضیح |
|---|---|---|
| دفعات تلاش | 2 | تعداد تلاش دوباره روی همان مقصد |
| وقفه | 100ms | فاصله بین تلاشها |
| حداکثر مهلت | 60s | بیشترین زمان انتظار برای مقصد |
| کدهای تکرار | 408, 425, 429, 500, 502, 503, 504 | کدهایی که درخواست را روی همان مقصد دوباره امتحان میکنند |
| کدهای فالبک | 429, 500, 502, 503, 504 | کدهایی که درخواست را به مقصد بعدی میبرند |
این مقدارها را با رفتار محصول خودتان تنظیم کنید. برای مسیرهای حساس به زمان، مهلت پاسخ کوتاهتر بهتر است؛ برای مسیرهایی که پایداری مهمتر از سرعت است، مقصد پشتیبان میتواند مفید باشد.
۵. دسترسی را مشخص کنید
در «کنترل دسترسی» تعیین کنید چه کسانی میتوانند مدل مجازی را مدیریت یا مصرف کنند. اگر مدل برای همه کاربران نیست، مصرف را به تیم یا کاربران مشخص محدود کنید.
بررسی قبل از ذخیره
پیش از ذخیره، این موارد را بررسی کنید:
- مقصدها همان مدلهایی هستند که میخواهید در محصول استفاده شوند.
- حالتهای قابل ارائه با نقطه پایانی موردنظر شما سازگارند؛ برای چت، حالت
chatباید در مقصدها مشترک باشد. - در مسیریابی وزنی، مجموع وزنها ۱۰۰ است.
- کدهای تلاش دوباره و مسیر جایگزین با رفتار مورد انتظار شما سازگارند.
- دسترسی مصرفکنندگان بیش از حد باز نیست.
مثال: مقصد اصلی و پشتیبان
فرض کنید محصول شما برای پشتیبانی مشتری از یک مدل چت استفاده میکند و میخواهید در صورت خطای موقت، مقصد دیگری امتحان شود.
| ترتیب | مقصد | نقش |
|---|---|---|
| ۱ | openai:default:gpt-4o-mini | مقصد اصلی |
| ۲ | anthropic:default:claude-3-5-sonnet | مقصد پشتیبان |
با شناسه فنی support-chat، کد محصول همیشه همین مقدار را میفرستد:
{
"model": "support-chat",
"messages": [
{ "role": "user", "content": "سفارش من کجاست؟" }
]
}
اگر مقصد اصلی با یکی از کدهای مسیر جایگزین ناموفق شود، گدارAI مقصد بعدی را امتحان میکند. در گزارش رخداد و رد درخواست میتوانید ببینید کدام مقصد انتخاب شده و چند بار تلاش انجام شده است.
خطاهای رایج
هیچ حالت مشترکی وجود ندارد
این حالت زمانی رخ میدهد که مقصدهای انتخابشده برای یک نوع درخواست مشترک مناسب نیستند؛ برای نمونه یک مقصد چت و یک مقصد امبدینگ. مقصدهایی را انتخاب کنید که برای همان نقطه پایانی و کاربرد مشترک فعال شدهاند.
درخواست با شناسه فنی مدل مجازی خطا میگیرد
بررسی کنید مدل مجازی فعال باشد، دسترسی مصرفکننده به آن داده شده باشد، و توکنی که استفاده میکنید به مدل مجازی یا مقصدهای پشت آن دسترسی داشته باشد.
همه مسیرهای جایگزین تمام میشوند
اگر همه مقصدهای مجاز با خطا مواجه شوند، درخواست خطا میگیرد. در این حالت، کدهای مسیر جایگزین، وضعیت ارائهدهندهها و رد درخواست را بررسی کنید.
گام بعدی
- برای فراخوانی مدل مجازی از کد، اولین درخواست به درگاه را ببینید.
- برای کنترل نرخ یا هزینه مصرف مدل مجازی، محدودیت نرخ درخواست و محدودیت بودجه را بخوانید.
- برای بررسی مسیر اجرای درخواست، لاگ درخواستها و ردیابی درخواستها را دنبال کنید.
پرسشهای پرتکرار
آیا مدل مجازی فقط برای مسیر جایگزین است؟
خیر. مدل مجازی علاوه بر مسیر جایگزین، برای پایدار نگه داشتن شناسه مدل، تقسیم ترافیک، کنترل دسترسی و کاهش وابستگی کد محصول به مقصد واقعی هم استفاده میشود.
آیا میتوانم مدلهای متفاوت را پشت یک مدل مجازی بگذارم؟
فقط وقتی مقصدها حالت مشترک قابل اتکا داشته باشند. ترکیب مدل چت با مدل امبدینگ یا مدل تصویر معمولاً برای یک مدل مجازی مناسب نیست.
اگر شناسه فنی را تغییر بدهم چه میشود؟
کدهایی که از شناسه قبلی استفاده میکنند خطا میگیرند یا به مدل موردنظر نمیرسند. برای محیط عملیاتی، شناسه فنی را مثل یک قرارداد پایدار با محصول خودتان در نظر بگیرید.