درون سیستم مسیریابی مدل‌های اسپاتیفای برای بهینه‌سازی توکن‌ها

اگر امروز برای ابزارهای کدنویسی هوش مصنوعی هزینه پرداخت می‌کنید، احتمالاً متوجه شده‌اید که بخش بزرگی از بودجه شما صرف کارهای پیش‌پاافتاده می‌شود، نه استدلال‌های پیچیده. پیش‌بینی می‌شود که تا سال ۲۰۲۸، هزینه‌های کدنویسی با هوش مصنوعی از میانگین حقوق توسعه‌دهندگان پیشی بگیرد. اسپاتیفای برای مقابله با این تهدید مقیاس‌پذیری، رویکرد جدیدی را در استفاده از عامل‌های کدنویسی هوش مصنوعی اتخاذ کرده است. این شرکت با تفکیک استدلال‌های سطح بالا از کارهای یدی و تکراری، توانست مصرف توکن‌ها را تا ۹۰٪ کاهش دهد.

بسیاری از عامل‌های هوش مصنوعی (AI Agents) — شبیه دستیارهایی که برای هر دستور ساده، کل کتابخانه را می‌گردند — بیشتر توکن‌های خود را صرف عملیات ورودی و خروجی (I/O) می‌کنند. برای مثال، خواندن چندین فایل حجیم برای پاسخ به یک سؤال ساده یا تولید کدهای تکراری (Boilerplate)، به جای تفکر واقعی، توکن‌ها را می‌بلعد. این ناکارآمدی باعث شده است که برخی از مدیران مهندسی، ماهانه بین ۲۰۰ تا ۲,۰۰۰ دلار به‌ازای هر برنامه‌نویس صرف خرید توکن کنند. این چالش مالی در مقیاس‌های بزرگتر نیز دیده شده است؛ برای نمونه، بررسی هزینه‌های توکن در اوبر نشان داد که چگونه هزینه‌های عملیاتی عامل‌ها می‌تواند بودجه‌های سالانه را به سرعت تخلیه کند. همان‌طور که در تحلیل قبلی ما درباره‌ی نحوه استفاده کارآفرینان تک‌نفره از ابزارهایی مانند n8n و Claude برای ساخت سیستم‌های بهینه اشاره کردیم، کلید بهره‌وری در تفکیک لایه‌های عملیاتی است؛ اسپاتیفای اکنون همین منطق ماژولار را در مقیاس سازمانی و در گردش‌کار کدنویسی پیاده کرده است.

به نقل از گزارش ۴ سپتامبر ۲۰۲۶ اسپاتیفای انجینیرینگ (Spotify Engineering)، این راهکار بر پایه پلتفرم داخلی پورتال (Portal) و قابلیت AiKA Modes بنا شده است. این مودها در واقع عامل‌های اعلامی (Declarative Agents) هستند که روی محیط‌های اجرای موقت (Ephemeral Runtimes) — شبیه به AWS Lambda — اجرا می‌شوند. این ساختار به توسعه‌دهندگان اجازه می‌دهد بدون درگیری با مدیریت زیرساخت، دستورالعمل‌های خاص را تعریف کرده و ابزارهای مورد نیاز را به عامل متصل کنند. پورتال مدیریت کلیدهای API و سرورهای با اجرای طولانی را بر عهده می‌گیرد و باعث می‌شود این مودها از طریق رابط خط فرمان (CLI) یا API پورتال قابل فراخوانی باشند.

هزینه توکن‌های مدل‌های پیشرو

برای بسیاری از توسعه‌دهندگان، هزینه اصلی نه لایسنس نرم‌افزار، بلکه توکن‌ها هستند. یک عامل معمولی ممکن است برای پاسخ به سؤالی درباره یک متد خاص، ۵ فایل را به طور کامل بخواند، یا فایلی برای تست تولید کند که صرفاً الگوی ۲۰ تست موجود در پروژه را تکرار می‌کند. این وظایف تقریباً به هیچ استدلال پیچیده‌ای نیاز ندارند اما هزاران توکن مصرف می‌کنند. در واقع، بسیاری از سازمان‌ها با تله‌های پنهان در صورت‌حساب‌های API مواجه شده‌اند که هزینه‌های نهایی را تا چندین برابر افزایش می‌دهد.

سپردن این «کارهای یدی» به مدل‌های پیشرو (Frontier Models)، یعنی استفاده از ابزاری که برای این سطح از کار بیش از حد متخصص و گران است. با ارجاع این وظایف پیش‌بینی‌پذیر و خروجی‌محور به مدل‌های ارزان‌تر، شرکت‌ها می‌توانند از سوزاندن توکن‌های گران‌قیمت برای کارهایی که نیاز به هوش سطح بالا ندارند، جلوگیری کنند.

مکانیزم مسیریابی (Routing)

اسپاتیفای برای بهینه‌سازی هزینه‌ها، دو مود کارگری (Worker Mode) خاص با استفاده از جمینای ۲.۵ فلش (Gemini 2.5 Flash) ایجاد کرد. اگرچه در مثال‌ها از جمینای استفاده شده، اما فیلد مدل در پورتال هر مدل پیکربندی‌شده‌ای را می‌پذیرد:

• bulk-reader: این مود برای زمانی طراحی شده که مدلی مثل کلود مجبور است چندین فایل بزرگ را بخواند تا به یک سؤال پاسخ دهد. به این مود دستور داده شده که یک تحلیل‌گر دقیق کد باشد و فقط خروجی‌های ساختاریافته در قالب گلوله‌ای (Bullet points) ارائه دهد. همچنین صراحتاً به آن گفته شده که از هرگونه سلام، احوالپرسی، نثر اضافی و مقدمه بپرهیزد و هر مورد را با نام دقیق، نوع یا شماره خط شروع کند. این کار مانع از آن می‌شود که مدل توکن‌ها را صرف جملات پرکننده و محاوره‌ای کند.
• code-writer: این مود کدهای تکراری، ساختارهای اولیه پیکربندی (Config scaffolding) و استاب‌های تایپ (Type stubs) را بر اساس الگوهای موجود می‌سازد. دستورالعمل این مود این است که دقیقاً با کنوانسیون‌ها، نام‌گذاری‌ها و استایل موجود در پروژه مطابقت داشته باشد. نکته حیاتی این است که این مود فقط کد خروجی می‌دهد — بدون هیچ‌گونه علامت Markdown یا توضیحات متنی — تا مدل اصلی مجبور نباشد متون غیرضروری را پارس و تحلیل کند.

پیاده‌سازی در سه لایه

اسپاتیفای ابتدا سعی کرد این مسیریابی را از طریق مجموعه‌ای از قوانین در فایل CLAUDE.md مدیریت کند، اما متوجه شد که این قوانین صرفاً جنبه توصیه‌ای دارند و اغلب توسط مدل نادیده گرفته می‌شوند. برای اجبار مدل به این رفتار، آن‌ها افزونه‌ای به نام شانت (shunt) برای کلود کد (Claude Code) توسعه دادند. این افزونه با هر نمونه از پورتال که افزونه AiKA در آن از طریق رجیستری اکشن‌های CLI فعال شده باشد، کار می‌کند.

لایه اول: هوک‌ها (Hooks)
سیستم از هوک‌های PreToolUse استفاده می‌کند که قبل از هر فراخوانی ابزار اجرا می‌شوند. شانت دو هوک خاص را ثبت می‌کند:

• check-file-size: این هوک در هر فراخوانی Read اجرا می‌شود. اگر تعداد خطوط یک فایل از حد مجاز (پیش‌فرض ۳۵۰ خط) بیشتر باشد، هوک عملیات خواندن را مسدود کرده و کلود را هدایت می‌کند تا از مهارت /bulk-reader استفاده کند. البته خواندن‌های هدفمند (با استفاده از offset/limit) همچنان مجاز هستند.
• check-bash-read: این هوک دستوراتی مانند cat ،head ،tail ،less و more را روی فایل‌های حجیم شناسایی و مسدود می‌کند. با این حال، دستورات لوله‌کشی شده (مانند cat file | grep) مجاز هستند زیرا خواندن هدفمند محسوب می‌شوند.

توسعه‌دهندگان می‌توانند این حد آستانه را با استفاده از متغیر محیطی SHUNT_MIN_LINES در پروفایل شل خود یا در فایل .claude/settings.json (مثلاً { "env": { "SHUNT_MIN_LINES": "500" } }) تغییر دهند.

لایه دوم: اسکریپت‌ها
دو اسکریپت Bash فراخوانی‌های CLI پورتال را در بر می‌گیرند. کلود این اسکریپت‌ها را با آرگومان‌های نام‌گذاری شده فراخوانی می‌کند و اسکریپت‌ها وظیفه ساخت درخواست، اجرای اکشن و باز کردن خطاهای احتمالی را بر عهده دارند. آن‌ها همچنین میزان مصرف توکن را به stderr گزارش می‌کنند.

• bulk-read: این اسکریپت فایل‌ها را در تگ‌های XML قرار می‌دهد تا مرزهای آن‌ها مشخص باشد و سپس آن‌ها را به مدل کارگر می‌فرستد. چون فراخوانی موقت است و چیزی در سمت سرور ذخیره نمی‌شود، ارسال مجدد فایل‌ها در سؤالات بعدی «رایگان» است، زیرا محتوا هرگز وارد پنجره متنی (Context Window) مدل کلود نمی‌شود.
• code-write: این اسکریپت یک مشخصات (Spec) و یک فایل مرجع مورد نیاز را به مدل کارگر می‌فرستد. سپس علامت‌های Markdown را حذف کرده و می‌تواند خروجی را مستقیماً روی دیسک بنویسد. بدون وجود فایل مرجع برای تطبیق الگوها، مدل کارگر کدی بدون زمینه تولید می‌کرد که با پروژه سازگار نبود.

لایه سوم: مهارت‌ها (Skills)
فایل‌های Markdown سینتکس دقیق و مثال‌های کاربردی مورد نیاز برای فراخوانی اسکریپت‌ها را در اختیار کلود قرار می‌دهند. وقتی یک هوک خواندن گران‌قیمت را مسدود می‌کند، پیام مسدودسازی مستقیماً کلود را به مهارت /bulk-reader ارجاع می‌دهد. این امر تضمین می‌کند که سیستم به صورت نرم (Gracefully) عمل کند؛ حتی اگر کلود مهارت را نادیده بگیرد، هوک همچنان از خواندن گران‌قیمت جلوگیری می‌کند.

عملکرد و محدودیت‌ها

در بنچ‌مارک‌های انجام شده روی یک مخزن کد جاوا (Java monorepo)، میانگین صرفه‌جویی در وظایف خواندن حجیم به ۹۰٪ رسید. در تولید کد، این صرفه‌جویی حتی چشمگیرتر است زیرا کد تولید شده مستقیماً روی دیسک نوشته می‌شود و به این معناست که کلود هرگز توکنی برای خروجی نهایی مصرف نمی‌کند. با این حال، باید مراقب بود که این بهینه‌سازی‌ها منجر به توهم بهره‌وری نشود، جایی که کاهش هزینه توکن با کاهش کیفیت استدلال یا اتکای بیش از حد به مدل‌های کوچک‌تر جایگزین شود.

با این حال، این سیستم مرزهای مشخصی دارد:

• عدم ویرایش تفویضی: مدل‌های کارگر خلاصه‌ها را ارائه می‌دهند اما در ارائه شماره خطوط دقیق قابل اعتماد نیستند. اگر کلود نیاز به ویرایش‌های خاص داشته باشد، همچنان باید آن بخش را مستقیماً بخواند.
• عدم استدلال تفویضی: در تست‌ها، یک مدل کارگر یک باگ ظریف در ایمنی رشته‌ها (Thread-safety) را نادیده گرفت، در حالی که کلود آن را در چند ثانیه شناسایی کرد. بنابراین، مسیریابی صراحتاً شامل دیباگینگ، تصمیمات معماری و کدهای حساس به ایمنی نمی‌شود.
• تأخیر (Latency): هر تفویض یک رفت و برگشت شبکه است (Claude Code $ \rightarrow $ Portal backend $ \rightarrow $ worker model $ \rightarrow $ back) که معمولاً ۱۰ تا ۳۰ ثانیه زمان می‌برد. پورتال تک‌فراخوانی‌ها را به ۳۰ ثانیه محدود می‌کند، به این معنی که تولیدات بسیار حجیم باید تقسیم شوند. به همین دلیل حد آستانه خطوط وجود دارد؛ برای فایل‌های کوچک، هزینه زمانی تفویض بیشتر از صرفه‌جویی در توکن است.

مقیاس‌پذیری معماری

این تغییر، مسیریابی مدل را از یک مسئله پیچیده مهندسی سیستم به یک تسک ساده پیکربندی تبدیل می‌کند. با جداسازی تصمیم مسیریابی از مدل کارگر، تیم‌ها می‌توانند Gemini Flash را با مدل‌های ارزان‌تر جایگزین کنند یا پرامپت‌های سیستم را بدون تغییر در کد افزونه به‌روزرسانی کنند.

مودهای AiKA چندین مزیت استراتژیک دارند:

• قابلیت استفاده مجدد: همان مودها در تمام پروژه‌ها و هر ابزاری که بتواند با CLI پورتال ارتباط برقرار کند، کار می‌کنند.
• قابلیت اشتراک‌گذاری: مودها می‌توانند عمومی (در سطح شرکت) یا خصوصی باشند. کاربران می‌توانند مودهای عمومی را فورک کرده و نسخه‌های سفارشی بسازند که در اولویت اجرا قرار می‌گیرند.
• ترکیب‌پذیری: تیم‌ها می‌توانند به راحتی مودهای جدیدی برای کارهای خاص بسازند، مانند doc-writer برای مستندات، reviewer برای خلاصه‌های بررسی کد، یا translator برای بین‌المللی‌سازی (i18n).

برای توسعه‌دهندگان، این بدان معناست که «سوزاندن توکن» دیگر هزینه اجتناب‌ناپذیر استفاده از مدل‌های پیشرو نیست. توانایی اشتراک‌گذاری این مودها در سطح شرکت اجازه می‌دهد تا کل سازمان مهندسی از یک پرامپت بهینه شده برای خواندن یا نوشتن کد بهره‌مند شود.

برای پیاده‌سازی این سیستم، توسعه‌دهندگان می‌توانند spotify/portal-ai-plugins را از مارکت‌پلیس با دستور claude plugin marketplace add spotify/portal-ai-plugins نصب کنند و سپس افزونه‌های خاص را با دستورات claude plugin install portal@portal و claude plugin install shunt@portal فعال نمایند. در یک نشست جدید Claude Code، اجرای دستور /portal:setup برای احراز هویت CLI پورتال در برابر نمونه مربوطه لازم است.

گام بعدی شما

• اگر از Claude Code استفاده می‌کنید، بررسی کنید کدام ابزارها (مانند Read) بیشترین توکن را مصرف می‌کنند.
• برای کارهای تکراری (مانند تولید تست یا مستندسازی)، از مدل‌های کوچک‌تر و ارزان‌تر (SLM) به صورت مجزا استفاده کنید.
• ساختار «مدل استدلالی برای تصمیم‌گیری + مدل سریع برای اجرا» را در گردش‌کار خود پیاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.