اگر امروز برای ابزارهای کدنویسی هوش مصنوعی هزینه میپردازید، احتمالاً متوجه شدهاید که رشد هزینهها سریعتر از رشد درآمدتان است. دیتابریکس با معرفی یک سامانه مسیریابی هوشمند، توانسته است میانگین هزینههای هر تسک را بیش از ۳۰٪ کاهش دهد.
طبق گزارش فنی مفصلی که در ۷ اوت ۲۰۲۶ منتشر شد، دیتابریکس (Databricks) توانسته است با حفظ کیفیت مدلهای گرانقیمت، هزینههای عملیاتی را بهشدت کاهش دهد. این اقدام پاسخی است به مشکلی که تقریباً تمام شرکتهای در حال استقرار ابزارهای کدنویسی در مقیاس بزرگ با آن دستوپنجه نرم میکنند: یک منحنی هزینهای که تهدید میکند از میزان درآمد پیشی بگیرد و سودآوری را از بین ببرد.
برای اکثر سازمانها، وعده کدنویسی عاملمحور (Agentic Coding) — که در آن عاملهای هوش مصنوعی میتوانند مخازن کد (Repositories) را بررسی کنند، فایلها را تغییر دهند و خطاها را عیبیابی کنند — منجر به جهشی در خروجی شده است که چندین برابر ظرفیت قبلی است. در دیتابریکس، کدنویسی عاملمحور بهطور ملموسی تمام معیارهای سرعت توسعه (Velocity Metrics) را که رصد میشدند، بهبود بخشیده است. اما این بهرهوری با یک تناقض همراه است؛ شرکتها میخواهند تحول هوش مصنوعی را به حداکثر برسانند و ابزارهای قدرتمند را در اختیار کارکنان قرار دهند، اما پروفایل مجموع هزینهها اغلب دستاوردهای بهرهوری را خنثی کرده یا حتی اثرات آن را معکوس میکند. در کنار مدیریت هزینهها، حفظ کیفیت ساختاری کدها نیز حیاتی است؛ به همین دلیل استفاده از قراردادهای معماری برای جلوگیری از بدهی فنی در کدهای تولید شده توسط عاملها به یکی از اولویتهای سازمانها تبدیل شده است.
برای حل این معضل، دیتابریکس با همکاری سایر شرکتهای بومی دیجیتال از جمله استرایپ (Stripe)، کوینبیس (Coinbase)، اوبر (Uber) و رمپ (Ramp) وارد عمل شد. آنها در کنار هم یک «مأموریت دوگانه» را شناسایی کردند: فراهم کردن دسترسی گسترده و بدون اصطکاک به ابزارهای هوش مصنوعی، در حالی که مجموع هزینهها در یک محدوده تقریباً ثابت برای هر کاربر باقی بماند.
مرز بهرهوری
بر اساس گزارش دیتابریکس، مهمترین اهرم کاهش هزینه، تغییر تمرکز از «مرز هوش» (Intelligence Frontier) به «مرز بهرهوری» (Efficiency Frontier) است. در حالی که آزمایشگاههای پیشرو روی رسیدن به بالاترین سطح هوش برای مسائل نوظهور ریاضی یا چالشهای پیچیده امنیت سایبری تمرکز دارند، اکثر کارهای روزمره کدنویسی به آن سطح از قدرت پردازشی نیاز ندارند.
مرز بهرهوری به عنوان مجموعهای از مدلها تعریف میشود که بهترین نقطه قیمتی را برای یک سطح مشخص از هوش ارائه میدهند. از آنجایی که این مرز سریعتر از «هوش حداکثری» پیش میرود — به طوری که مدلهای جدید تقریباً هر هفته عرضه میشوند — شرکتها میتوانند با پذیرش سریع مدلهای جدیدتر و ارزانتر که استانداردهای کیفی مهندسی نرمافزار را برآورده میکنند، صرفهجویی عظیمی به دست آورند.
برای شناسایی این مدلها، شرکتها در حال فاصله گرفتن از بنچمارکهای عمومی هستند، زیرا این آزمونها اغلب در انعکاس عملکرد واقعی کدنویسی در محیط عملیاتی شکست میخورند. در عوض، آنها در حال ساخت ارزیابیهای خودکار داخلی هستند که نماینده ترکیب واقعی توسعه در سازمانشان باشد. برای مثال، دیتابریکس با استفاده از بنچمارکهای داخلی مشاهده کرد که مدلهای GLM قیمت و عملکرد بسیار رقابتی دارند و همین موضوع منجر به استقرار داخلی آنها شد.
البته هر مدل جدیدی یک پیروزی محسوب نمیشود. ارزیابیها مکرراً نتایج منفی تولید میکنند. استرایپ دریافت که مدل Opus 4.7 بهبود کیفیت معناداری نسبت به Opus 4.6 ایجاد نکرده اما هزینهها را افزایش داده است؛ همین امر باعث شد آنها دسترسی داخلی به این مدل را مسدود کنند. به همین ترتیب، دیتابریکس هنگام مقایسه Opus 5.0 با نسخه 4.8، با پسروی در هزینهها (افزایش هزینه بدون بهبود) مواجه شد.
حل مشکل وابستگی با متا-هارنسها
تغییر مدل دشوار است زیرا مدلهای اختصاصی اغلب برای «هارنسهای» (Harnesses) خاصی (رابط کاربری و ابزارها) طراحی شدهاند. برخی هارنسها با مدلهای خاصی «بهتر کار میکنند». اگر توسعهدهندگان در یک هارنس خاص قفل شوند، شرکت نمیتواند بهراحتی به یک مدل ارزانتر مهاجرت کند، زیرا هزینههای جابجایی برای هر توسعهدهنده بسیار بالا خواهد بود.
دیتابریکس دو مسیر برای حفظ انعطافپذیری پیشنهاد میدهد:
- تغییر دستی: درخواست از کاربران برای جابجایی بین ابزارهایی مانند Claude Code، Codex یا Cursor. این روش به کاربران اجازه میدهد در هارنس مورد علاقه خود کار کنند، اما نقطه ضعف آن این است که خودِ هارنس به یک وابستگی دوفاکتو (de facto lock-in) به یک خانواده مدل تبدیل میشود.
- متا-هارنسها: استفاده از لایهای که یک تجربه کاربری مشترک فراهم میکند و در عین حال درخواستها را به هارنسهای مختلف زیربنایی (چه اختصاصی و چه متنباز) ارسال میکند. این کار هزینههای جابجایی توسعهدهنده را کاهش داده و استقلال مدل را حفظ میکند. دیتابریکس از Omnigent به عنوان متا-هارنس پیشفرض خود استفاده میکند، در حالی که شرکتهای دیگر متا-هارنسهای داخلی سفارشی ساختهاند که با زنجیره ابزارهای آنها یکپارچه شده است.
مکانیزمهای مسیریابی پویا
به جای تکیه بر انتخاب کاربر برای یافتن مدل مناسب، شرکتها در حال پیادهسازی مسیریابی خودکار هستند تا بهرهوری بیشتری از جریانهای کاری عاملمحور استخراج کنند. دیتابریکس اینها را به سه الگوی اصلی تقسیم میکند:
- مسیریابی در سطح درخواست (Request Level Routing): یک پروکسی وضعیتدار (Stateful Proxy) بین کلاینت و مدلهای پایه قرار میگیرد. این پروکسی هر درخواست استنتاج تک را به ارزانترین مدلی که قادر به پاسخگویی است هدایت میکند. این سیستم باید کش سمت سرور (Server-side caching) را در نظر بگیرد، زیرا برخورد با کش سرد (Cold cache hits) برای بارهای کاری با زمینه (Context) بزرگ بسیار گران است. نمونههایی از این سیستم عبارتند از: Cursor Router، AutoRouter در OpenRouter، Ramp’s Router و قابلیت Smart Routing در Unity AI Gateway.
- مسیریابی در سطح تسک (Task Level Routing): یک فرآیند در سمت کلاینت (متا-هارنس) پیچیدگی کل یک تسک را تحلیل میکند. برای مثال، یک درخواست ساده مانند «تغییر نام کامپوننت از X به Y» به یک مدل ارزان ارسال میشود، در حالی که یک تسک باز مانند «بررسی ملاحظات طراحی برای کاهش تأخیر» به یک مدل با هوش بالا تفویض میگردد. Omnigent از این الگو پشتیبانی میکند.
- ارتقا/تفویض (Escalation/Delegation): در این حالت، یک هارنس دو مدل را جفت میکند. در ابزار Advisor شرکت کلود، یک مدل کارگر ارزان فرآیند را اجرا میکند و هرگاه به قدرت پردازشی بیشتری نیاز باشد، تسک را به یک مدل گرانقیمت ارتقا میدهد. در مقابل، در Devin Fusion شرکت Cognition، مدل گرانقیمت به عنوان حلقه اصلی عمل میکند و بهصورت انتخابی کارها را به یک مدل ارزانتر برونسپاری میکند.
مدیریت هزینههای انسانی
بودجههای سخت توکن (Hard token budgets) — که در آن دسترسی در یک مبلغ دلاری خاص قطع میشود — عموماً اجتناب میشوند و تنها به عنوان آخرین راهکار به کار میروند. چنین محدودیتهایی ناکارآمد هستند زیرا قطع دسترسی، بهرهوری را بهشدت مختل میکند. علاوه بر این، کاربرانی که «هزینه بالایی» دارند، اغلب بهرهورترین کارکنانی هستند که به دستاوردهای عظیم در بهرهوری رسیدهاند.
به جای آن، دیتابریکس از یک مدل «اصطکاک تدریجی» (Progressive Friction) استفاده میکند:
- شفافیت (Visibility): داشبوردهای لحظهای که هزینههای جاری توسعهدهندگان را در تمام ابزارها نشان میدهد. این کار به کاربران اجازه میدهد انتخاب ابزار خود را بر اساس بازگشت سرمایه (ROI) تغییر دهند. بسیاری از شرکتها همچنین نکات خاصی را برای استفاده از مدلهای ارزانتر ارائه میدهند.
- دروازههای هزینه (Spend Gates): با افزایش هزینهها، توسعهدهندگان باید اقداماتی انجام دهند یا درخواست تأیید بگیرند. دروازههای ساده، هشدارهای خود-پاکشوندهای هستند تا از هزینههای تصادفی جلوگیری شود. دروازههای پیشرفتهتر نیازمند تأیید صریح بودجه از طریق سلسلهمراتب مدیریتی هستند.
- تغییر دنده (Downshifting): انتقال خودکار کاربر به یک مدل ارزانتر به جای تعلیق کامل دسترسی. از آنجایی که مدلهای ارزان بهطور چشمگیری ارزانتر از مدلهای Frontier هستند، کار بدون هزینههای هنگفت ادامه مییابد.
- تعلیق (Suspension): یک اقدام موقت به عنوان آخرین راهکار برای شروع گفتگو درباره نحوه بهرهبرداری بهینهتر از هوش مصنوعی.
کاهش تورم توکنها
هزینهها اغلب توسط زمینهای (Context) تسلط مییابند که کاربر بهطور صریح ارائه نکرده است. وقتی کاربر میخواهد «این باگ را رفع کن»، عامل مقدار زیادی زمینه را جمعآوری میکند، ابزارها را فراخوانی میکند و در کدها جستجو میکند. عبارت اولیه کاربر تنها بخش ناچیزی از دادههای تغذیه شده به LLM است.
دیتابریکس با تنظیم تنظیمات هارنس و کشینگ، بدون از دست دادن کیفیت، به کاهش تقریباً ۵۰ درصدی در توکنهای تولید شده و هزینهها دست یافت.
تکنیکهای کلیدی برای کاهش هزینههای سربار عبارتند از:
- فشردهسازی زمینه (Context Compaction): اجبار به فشردهسازی مکرر زمینه فعال.
- تنظیم هارنس (Harness Tuning): استفاده از هارنسهایی که «کمحرفتر» هستند یا بازرسی ابزارهای محبوب برای کاهش پرگویی (Verbosity) آنها.
- تجزیه تسک (Task Decomposition): تشویق توسعهدهندگان به شکستن تسکها به واحدهای کوچکتر برای کاهش دامنه زمینه.
- کشینگ پرامپت (Prompt Caching): تنظیم تنظیمات پیشفرض کش برای افزایش نرخ برخورد (Hit rate). اگرچه نوشتن در کش هزینه دارد، اما خواندن از کش هزینههای هر استنتاج را بهشدت کاهش میدهد.
معماری AI Gateway
برای پیادهسازی این اهرمها، شرکتها به یک مکان مرکزی برای مدیریت «منوی مدلها»، ارائه مشاهدهپذیری یکپارچه هزینهها و اعمال فشردهسازی زمینه نیاز دارند. این مشکل با الگوی طراحی AI Gateway حل میشود.
یک درگاه هوش مصنوعی، مانند Unity AI Gateway، به عنوان یک مرکز متمرکز برای موارد زیر عمل میکند:
- مدیریت ظرفیت: پروکسی کردن دسترسی به مدلهای اختصاصی و متنباز (OSS).
- اجرای بودجه: مدیریت سیاستهای پیچیده مانند اصطکاک تدریجی و تغییر دنده مدل.
- مدیریت پیکربندی: اعمال لیستهای مجاز مدلها (Allow-lists) و تنظیمات فشردهسازی برای ابزارهای کاربر نهایی.
- مشاهدهپذیری: ثبت ردپای (Traces) جلسات کدنویسی برای تحلیلهای بهرهوری پاییندستی و بنچمارکگذاری.
این تغییر نشان میدهد که هزینههای کدنویسی هوش مصنوعی، بیش از آنکه یک امر اجتنابناپذیر باشد، یک مشکل مهندسی و حاکمیتی است. سازمانها با تمرکز بر مرز بهرهوری و پیادهسازی یک درگاه متمرکز، میتوانند پذیرش هوش مصنوعی را بدون رشد خطی هزینهها گسترش دهند. برای کسانی که تیمهای توسعه بزرگی را مدیریت میکنند، گام بعدی بازرسی میزان «پر حرفی» عاملهای فعلی برای شناسایی نقاطی است که تورم توکنها در حال متورم کردن صورتحساب ماهانه آنهاست.
گام بعدی شما
- میزان «پر حرفی» (Verbosity) عاملهای فعلی خود را بررسی کنید تا متوجه شوید کجا توکنهای اضافی هزینه شما را بالا میبرند.
- یک لایه پروکسی یا Gateway برای مدیریت مدلها ایجاد کنید تا وابستگی به یک مدل خاص (Lock-in) از بین برود.
- برای تسکهای تکراری، مدلهای کوچکتر و ارزانتر را جایگزین مدلهای Frontier کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو