‏چرا باید پروکسی LLM خودت رو داشته باشی

نویسنده می‌گه بیشتر ما از طریق یه رابط کاربری که به اشتراک پولیِ یه سرویس‌دهنده وصله با LLMها کار می‌کنیم. این سرویس‌ها معمولاً یه نمودار ساده از مصرف نشونمون می‌دن، ولی به گفته‌ی نویسنده این آمار مصرف توکن با داده‌ی زمانی دقیق که یه مهندس لازم داره نیست و نمی‌شه باهاش تصمیم گرفت. حتی گزینه‌های خروجی OTel (یعنی OpenTelemetry، استاندارد جمع‌آوری لاگ و متریک) هم به نظرش جای خالی رو پر نمی‌کنه.

راه‌حلش یه پروکسی LLM هست، یعنی یه سرور واسط که همه‌ی درخواست‌هات به مدل‌ها از اون رد می‌شه. نویسنده پنج دلیل برای این کار میاره:

• چند سرویس‌دهنده و چند مدل پشت یه endpoint که خودت کنترلش می‌کنی.
• لاگ اینکه کدوم کلید، با کدوم کلاینت، کِی، کدوم مدل رو صدا زده و نتیجه‌اش چی بوده.
• کلیدهای مجازی، تا مجبور نباشی کلید اصلیت رو تو همه‌ی ایجنت‌ها و ابزارها پخش کنی.
• زیرساخت دست خودته.
• می‌تونی خیلی سریع مدل یا سرویس‌دهنده رو عوض کنی بدون اینکه همه‌چی رو از اول تنظیم کنی.

نویسنده عمداً هیچ پروکسی خاصی رو پیشنهاد نمی‌ده و فقط می‌گه هر چی انتخاب کردی، خودت جایی که کنترلش دستته اجراش کن. یادآوری می‌کنه که می‌شه پروکسی رو برای نیاز خودت تغییر داد. خودش نسخه‌اش رو برای دید بهتر، endpointهای سفارشی MCP و قابلیت‌های اضافه دستکاری کرده.

یه مثال عملی هم میاره: وقتی وسط کدنویسی یه cache miss (یعنی وقتی جواب از کش نمیاد و باید دوباره پردازش بشه) می‌بینه، با داده‌های پروکسی تو حدود ۲۰ ثانیه دستی دلیلش رو پیدا می‌کنه. این کارو هنوز خودکار نکرده، ولی چون پروکسیش API داره، شدنیه. حرف آخرش اینه که زیرساخت، دید روی اپلیکیشن، مسیر داده و ذخیره‌سازی رو خودت مالک باش. هم تو خونه برای یادگیری این کارو می‌کنه، هم سر کار چون به نظرش بدون اون کارش رو درست انجام نمی‌ده.

نکات کلیدی:

• داشبوردهای مصرف سرویس‌دهنده‌ها داده‌ی زمانی دقیق برای مهندس‌ها ندارن.
• پروکسی LLM چند مدل و چند سرویس‌دهنده رو پشت یه endpoint جمع می‌کنه.
• کلیدهای مجازی جلوی پخش شدن کلید اصلی API بین ابزارها و ایجنت‌ها رو می‌گیرن.
• با لاگ‌های پروکسی می‌شه دلیل یه cache miss رو تو حدود ۲۰ ثانیه پیدا کرد.
• نویسنده پروکسی خاصی معرفی نمی‌کنه و فقط تأکید داره که خودت میزبانش باشی.