‏OpenRouter اونقدرا هم ساده نیست

نویسنده که سازندهٔ یه دستیار هوش مصنوعی به اسم Olly روی iMessage‌ه و بیش از ۱۸ میلیون پیام رو از طریق OpenRouter رد کرده (یه سرویس واسط که درخواست‌ها رو بین دهها ارائه‌دهندهٔ مدل باز مسیر می‌کنه)، لیستی از دردسرهای واقعی این کار رو نوشته. نکتهٔ اول: وقتی یه مدل باز مثل DeepSeek رو از OpenRouter می‌خوای، در واقع یکی از ده‌ها شرکت میزبان (provider) بهت جواب می‌ده که وزن‌های مدل یکیه ولی سخت‌افزار و دقت محاسباتی و حتی parserهاشون فرق داره؛ یعنی روی کاغذ یه مدلن ولی تو عمل مدل‌های متفاوتی حساب میان.

طبق بنچمارک‌های خود OpenRouter، همون مدل DeepSeek V4 Flash روی provider اصلی نمرهٔ ۹۰ درصد GPQA و ۸۱ درصد TAU-Bench می‌گیره (یعنی یه تست عملکرد تماس با ابزار)، ولی روی یه provider دیگه همین اعداد به ۷۵ و ۵۸ درصد می‌رسه. نویسنده میگه باید قبل از اعتماد به یه provider، بنچمارک نزدیک به کاربردت رو چک کنی و با عوض‌شدن مدل دوباره چک کنی، چون رتبه‌بندی providerها بین مدل‌ها ثابت نمی‌مونه.

چند مشکل دیگه هم هست: بعضی providerهای مدل‌های تصویری اصلاً عکس رو درست نمی‌بینن ولی بازم جواب موفق برمی‌گردونن؛ فیلتر کردن provider بر اساس دقت محاسباتی مثلاً fp8 تضمین کیفیت نمی‌ده. یه مشکل رایج دیگه اینه که parser سمت provider گاهی نمی‌تونه یه فراخوانی ابزار رو درست تشخیص بده و به‌جاش متن خام قالب‌بندی‌نشده برمی‌گردونه:

<use_skills><parameters>{"skills":["search"]}</parameters></use_skills>

که باید خودت تو کد یه پارسر پشتیبان هم داشته باشی تا این حالت‌ها رو دستی تشخیص بدی.

دو مشکل جدی‌تر هم هست: بعضی مدل‌های استدلالی همه‌چیز رو تو فیلد reasoning میذارن و content رو خالی برمی‌گردونن، با این‌حال کد HTTP موفقه؛ نویسنده میگه این حالت باید failure حساب بشه و دوباره تلاش بخوره. بعضی providerهای دیگه هم اصلاً جواب کامل نمی‌دن؛ مثلاً یه ماه یه provider خاص ۹۲ درصد جواب‌های خالی رو تولید می‌کرد. حتی pin کردن سه provider «مطمئن» هم تضمین نیست: نویسنده تعریف می‌کنه یه بار هر سه‌تاشون همزمان یا rate-limit شدن یا مدل رو پشتیبانی نکردن و کل سرویسش قطع شد.

نکات کلیدی:

• همون مدل رو providerهای مختلف OpenRouter می‌تونن با نمرهٔ بنچمارک کاملاً متفاوت، تا ۲۰ درصد اختلاف، اجرا کنن
• بعضی providerهای مدل‌های تصویری، ورودی عکس رو اصلاً پردازش نمی‌کنن ولی جواب موفق برمی‌گردونن
• فیلتر کردن بر اساس دقت محاسباتی مثل fp4 یا fp8 تضمین کیفیت نمی‌ده
• جواب HTTP موفق با content خالی باید failure حساب بشه، نه جواب معتبر
• pin کردن چند provider «مطمئن» هم ریسک قطعی کامل سرویس رو از بین نمی‌بره