اگر امروز برای کاهش هزینههای استنتاج (Inference) — که در واقع همان لحظهی تولید جواب توسط مدل است، شبیه به خودِ آشپزی و نه دورهی آموزش آشپز — به دنبال مدلهای ارزانتر میگردید، باید بدانید که ارزانترین گزینه لزوماً بهینهترین انتخاب نیست.
تیم Codens سرویسی به نام Purple را مدیریت میکند که تصمیم میگیرد هر وظیفهی کدنویسی توسط کدام مدل انجام شود. آنها برای اینکه به یک فروشنده وابسته نباشند، یک «مسیر اجرای» سوم را به سیستم خود اضافه کردند. همانطور که در تحلیل قبلی ما دربارهی چالشهای استقرار عاملهای هوش مصنوعی اشاره کردیم، مدیریت چندین مدل برای کاهش ریسک ضروری است.
عامل (Agent) — مثل کارمندی است که نه تنها دستور میگیرد، بلکه خودش تصمیم میگیرد چه ابزاری را برای انجام کار به کار ببرد — در این سیستم باید با دقت بالا عمل کند. طبق گزارش منتشر شده در dev.to، این تیم در تاریخ ۲۳ و ۲۴ مه ۲۰۲۶، مدل Cursor Composer 2.5 را جایگزین Claude Opus کرد. این ابزار در حالی مورد بررسی قرار گرفته که رقابت برای تسلط بر ابزارهای کدنویسی هوشمند شدت یافته است؛ چنانکه پیشتر به تلاشهای جسورانه اسپیساکس برای ورود به این بازار اشاره کردیم. هدف آنها ساده بود: حفظ دقت Opus اما با ۹۰٪ هزینه کمتر.
اما نتایج تکاندهنده بود. در یک تست اولیه با ۲۵ تلاش، تنها ۹ مورد با موفقیت به پایان رسید. این یعنی نرخ موفقیت ۳۶ درصدی، در حالی که Opus نرخ موفقیت بالای ۸۰ درصد داشت. طبق بررسیهای فنی، دو دلیل اصلی این شکست وجود داشت:
- پل ارتباطی SDK (Software Development Kit) — که شبیه جعبهابزاری است که شرکت سازنده به برنامهنویس میدهد تا نرمافزارش را به سرویس وصل کند — در وظایف طولانی قطع میشد و تغییرات محیط کاری را از دست میداد.
- پیامهای خطا بیش از حد مبهم بودند و عیبیابی را در زمان رسیدن به سقف تلاشهای مجدد، غیرممکن میکردند.
تیم Codens همچنین یک حفره امنیتی بحرانی را بست. آنها اطمینان حاصل کردند که سیستم برای دسترسی به اسرار (Secrets)، از نقش IAM در ECS استفاده کند و نه از اعتبارنامهی مشتریان.
این تجربه ثابت میکند که نمرات بنچمارک، اعداد واقعیِ محیط تولید نیستند. برای توسعهدهندگان، پیروزی واقعی در یافتن ارزانترین مدل نیست، بلکه در ایجاد «قابلیت جایگزینی» است. با ساخت یک سیستم چندمسیره، میتوانید به محض اینکه ارائهدهندهای قیمت را تغییر داد یا مدلی خراب شد، مدل خود را عوض کنید.
گام بعدی شما
- حالتهای شکست (Failure Modes) عاملهای خود را دوباره بررسی کنید.
- به جای تکیه بر یک مدل، یک ساختار چندمسیره برای جایگزینی سریع مدلها بسازید.
- هزینهی ساعتهای مهندسی برای رفع باگهای مدلهای ارزان را با هزینهی API مقایسه کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو