درون معماری گیت‌وی‌های جدید برای مدیریت دقیق بودجهٔ کاربران

تصور کنید تیمی را مدیریت می‌کنید که حجم عظیمی از گزارش‌های لجستیکی را نظارت می‌کند؛ در اینجا ریسک اصلی، نرخ توکن‌های اعلام‌شده نیست، بلکه نبود دید کلی نسبت به این است که کدام کاربر هزینه‌ها را بالا می‌برد و چرا گزارش‌ها به ضرب‌الاجل بررسی نمی‌رسند. در چنین محیطی، استفاده از یک کلید API واحد شاید راحت باشد، اما به عنوان یک لایه کنترلی کاملاً شکست می‌خورد.

همان‌طور که در تحلیل قبلی ما درباره‌ی اثر Cache Missها بر جهش هزینه‌های مدل‌های زبانی اشاره کردیم، اکنون تمرکز از بهینگی مدل به حسابداری گیت‌وی منتقل شده است. در محیط‌های عملیاتی، یک داشبورد سبز رنگ که «در دسترس بودن» (Availability) را نشان می‌دهد، می‌تواند شکست‌های سیستمی را پنهان کند؛ وضعیتی که در آن گزارش‌ها تکمیل می‌شوند اما زمان بررسی انسانی در حال افزایش است. نرخ پایینِ اعلام‌شده توسط ارائه‌دهنده نمی‌تواند سیستمی را نجات دهد که نمی‌داند کدام کاربر هزینه ایجاد کرده یا چرا گزارش‌ها از ضرب‌الاجل عبور کرده‌اند. این چالش‌ها در ابزارهای تخصصی‌تر نیز دیده می‌شود؛ برای مثال، بررسی هزینه‌های پنهان در ابزارهای کدنویسی AI نشان می‌دهد که نرخ مصرف توکن‌ها همواره با تخمین‌های اولیه سازگار نیست.

به نقل از یک راهنمای فنی منتشر شده در dev.to در تاریخ ۴ اکتبر ۲۰۲۶، مؤثرترین گیت‌وی ارزان‌قیمت برای مدل زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — سیستمی است که هر گزارش پذیرفته شده را پیش از رسیدن به ضرب‌الاجل، به یک کاربر خاص و یک آیتم در صف متصل کند. این امر مستلزم انتقال «تخصیص هویت» به سطحی بالاتر از اعتبارنامه‌هاست تا کنترل پذیرش (Admission Control) پیش از ارسال درخواست شبکه رخ دهد. پذیرش یک کلید مشترک و بازسازی هویت کاربر در مراحل بعدی، برای کنترل دسترسی بسیار دیر است و تخصیص تلاش‌های مجدد (Retries) را در صورت توقف فرآیند دشوار می‌کند.

معماری پاسخگویی

برای جلوگیری از سناریوی «هشدار دیرهنگام» — جایی که مهندس آن‌کال تنها پس از گذشت ضرب‌الاجل متوجه مشکل می‌شود — سیستم باید سه مقدار مشخص را برای هر کاربر و هر منطقه ردیابی کند:

• سن قدیمی‌ترین شغل آماده: این معیار از هدف بررسی انسانی (مثلاً پنجره ۱۵ دقیقه‌ای) محافظت می‌کند.
• تفاضل کارهای پذیرفته شده و نهایی شده: این مقدار، نقاط گلوگاه و افت توان عملیاتی (Throughput) را آشکار می‌کند.
• هزینه تخمینی کارهای ناتمام: این مورد باعث می‌شود شعاع تخریب مالی در حالی که شغل‌ها هنوز در جریان هستند، قابل مشاهده باشد.

سناریویی را در نظر بگیرید که در ساعت ۰۲:۱۷ هشداری با متن moderation_review_deadline_risk{region="eu"} > 0 صادر می‌شود. مهندس مسئول می‌بیند که ۳۸ گزارش لجستیکی قدیمی‌تر از هدف ۱۵ دقیقه‌ای هستند که بین سه کاربر پخش شده‌اند. چون درخواست‌ها همچنان در حال تکمیل هستند، داشبورد در دسترس بودن سبز می‌ماند. اما سوالات کلیدی محدودتر می‌شوند: آیا یک کاربر ناگهان حجم درخواست‌هایش را زیاد کرده؟ آیا تلاش‌های مجدد باعث تکرار کارهای پذیرفته شده شده است؟ آیا یک Cache Miss باعث تغییر تأخیر (Latency) شده یا یک دسته (Batch) بیش از حد منتظر مانده است؟

پیاده‌سازی دفتر کل چرخه عمر

دید کلی نسبت به هزینه از لحظه پذیرش آغاز می‌شود. گیت‌وی باید شناسه کاربر، شناسه گزارش، کلید Idempotency (قابلیت تکرار بدون تغییر نتیجه)، منطقه سیاست‌گذاری و تخمینی از توکن‌های ورودی را ذخیره کند.

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

الزامات ابزارگذاری دقیق

برای حفظ این دفتر کل، سیستم باید نقاط داده مشخصی را در مراحل مختلف چرخه درخواست ثبت کند:

• در لحظه پذیرش: ذخیره شناسه کاربر، شناسه گزارش، کلید Idempotency، منطقه سیاست، تخمین توکن ورودی، حالت اجرای انتخاب شده و قابلیت کش شدن.
• در لحظه تکمیل: افزودن تعداد تلاش‌ها، وضعیت نهایی، مصرف گزارش شده، نتیجه کش و زمان سپری شده.
• استراتژی متریک‌ها: استفاده از برچسب‌هایی با تعداد محدود (مانند منطقه و وضعیت نهایی) برای متریک‌ها. شناسه‌های کاربر و گزارش باید در لاگ‌ها یا Traceها قرار گیرند تا سیستم مانیتورینگ به دلیل تعداد زیاد برچسب‌ها دچار اختلال نشود.

این منطق را بهتر است با جداسازی رکورد «شغل منطقی» از «تله‌متری تلاش‌ها» مدیریت کرد. در یک پیاده‌سازی مبتنی بر زبان Go، باید یک تخمین‌گر (Estimator) تزریق شود، زیرا قوانین توکن‌سازی (Tokenization) — که شبیه بریدن یک کیک طولانی به تکه‌های کوچک برای خوردن مدل است — و حسابداری مربوط به قرارداد زمان اجراست، نه یک میان‌بر ساده بر اساس طول رشته متنی.

package moderation
import (
 "context"
 "time"
)
type Job struct {
 TenantID string
 ReportID string
 IdempotencyKey string
 Region string
 Payload []byte
}
type Estimate struct {
 InputTokens int64
 OutputTokens int64
 CostMicros int64
}
type Usage struct {
 InputTokens int64
 OutputTokens int64
 CostMicros int64
 CacheHit bool
}
type Recorder interface {
 Admitted(context.Context, Job, Estimate, time.Time) error
 AttemptFinished(context.Context, Job, Usage, time.Duration, error) error
 Finalized(context.Context, Job, string, time.Time) error
}
type Estimator interface {
 Estimate(context.Context, Job) (Estimate, error)
}

حل تله تلاش مجدد و Idempotency

ارسال تکراری در سیستم‌های صف یک رفتار عادی است، اما بدون یک کلید Idempotency پایدار، مجموع توکن‌ها بالا می‌رود در حالی که صف به نظر بهره‌ور می‌رسد.

هر گزارش باید کلیدی داشته باشد که در برابر تلاش‌های مجدد و تغییر مسیرهای اجرا مقاوم باشد. قانون ساده است: Worker می‌تواند شغل را چندین بار امتحان کند، اما تنها یک نتیجه می‌تواند گزارش را به وضعیت نهایی برساند. تایم‌اوت درخواست یک وضعیت نهایی نیست، زیرا یک تلاش مجدد ممکن است همان شغل منطقی را تکمیل کند. وضعیت‌های نهایی معتبر عبارتند از: طبقه‌بندی شده، ارسال شده به بررسی انسانی، شکست دائمی یا منقضی شده.

مدیریت کشینگ و دسته‌بندی

کشینگ می‌تواند یک تله باشد اگر کلیدها فقط پرامپت را ردیابی کنند. کلیدهای کش باید شامل هر ورودی باشد که می‌تواند طبقه‌بندی را تغییر دهد، از جمله نسخه سیاست نظارتی و پیکربندی کاربر. در غیر این صورت، یک Hit موفقیت‌آمیز ممکن است تصمیمی را برگرداند که تحت یک سیاست اشتباه گرفته شده است. تیم‌ها باید «اجراهای اجتناب شده» و «رد درخواست به دلیل سیاست قدیمی» را به‌طور جداگانه ردیابی کنند.

به همین ترتیب، دسته‌بندی (Batching) — که شبیه جمع کردن چندین سفارش برای یک بار ارسال است تا هزینه کم شود — کارایی ارسال را با زمان انتظار معاوضه می‌کند. این روش برای گزارش‌هایی که بودجه زمانی بیشتری دارند مناسب است. هر دو مسیر تعاملی و دسته‌ای باید روی یک دفتر کل و قوانین نهایی‌سازی هم‌گرا شوند؛ استفاده از دو مدل حسابداری مختلف، دقیقاً در لحظاتی که اپراتورها به یک پاسخ واحد نیاز دارند، شکاف‌های تطبیقی ایجاد می‌کند.

استریمینگ و نتایج جزئی

استریمینگ نیاز به تست مجزا دارد. رویدادهای ارسالی سرور (SSE) یک جریان یک‌طرفه را روی HTTP منتقل می‌کنند. چون قطع اتصال کلاینت می‌تواند بعد از خروجی جزئی رخ دهد، Worker به قانونی نیاز دارد تا تشخیص دهد آیا آن تلاش قابل تکرار است و مصرف ناقص را چگونه ثبت کند. اگرچه انتقال داده می‌تواند زمان رسیدن به اولین نتیجه را بهبود بخشد، اما Idempotency یا یک نتیجه تجاری نهایی را فراهم نمی‌کند.

عملیاتی کردن سیستم هشدار

وقتی یک هشدار صادر می‌شود، دستورالعمل (Runbook) نباید از مهندس بخواهد که داشبوردها را مرور کند. در عوض، باید یک توالی عملیاتی محدود را دنبال کند:

۱. شناسایی کاربری که بیشترین سهم را در هزینه تخمینی ناتمام و سن قدیمی‌ترین شغل دارد.
۲. تفکیک داده‌ها بر اساس منطقه، حالت، نتیجه کش و تعداد تلاش‌ها.
۳. تشخیص تفاوت بین جهش درخواست‌های یک کاربر، تکثیر ناشی از تلاش‌های مجدد یا محدودیت‌های ظرفیت منطقه‌ای.

اولین اقدام حفاظتی، کنترل پذیرش در مرز کاربر است. این یعنی حفظ گزارش‌های نزدیک به ضرب‌الاجل، کند کردن کارهای جدید با اولویت پایین و معتبر نگه داشتن دفتر کل Idempotency. در حالی که یک محدودکننده (Throttle) جهانی ساده‌تر است، اما اجازه می‌دهد یک کاربر پرسرصدا، تجربه تمام مشتریان لجستیکی را تخریب کند. محدودیت‌های هر کاربر، شعاع تخریب را بسیار کوچک‌تر می‌کند.

تنظیم آستانه‌ها و هشدارها

تنظیم آستانه‌ها نیاز به تعادل دارد. آستانه خیلی پایین باعث مثبت‌های کاذب می‌شود و پاسخ‌دهندگان را عادت می‌دهد که منتظر بمانند. آستانه خیلی بالا نیز مشکلات را تنها زمانی تشخیص می‌دهد که پنجره بازیابی بسیار تنگ شده است.

• مثال آستانه: سن قدیمی‌ترین شغل بالای ۸ دقیقه برای دو پنجره ارزیابی، در حالی که هدف بررسی ۱۵ دقیقه است.
• مسیریابی فوریت: انحراف تخمین‌های کم‌اعتماد به تیکت ارسال شود؛ اما ریسک از دست دادن ضرب‌الاجل بررسی باید منجر به Page (هشدار فوری) شود.
• پایداری: برای یک هشدار، پایداری در دو یا چند پنجره ارزیابی لازم است، اما وقتی سن شغل به ضرب‌الاجل نزدیک می‌شود یا هزینه تخمینی از بودجه کاربر می‌گذرد، هشدار فوری مجاز است.

معیارهای انتخاب

تیم‌ها هنگام انتخاب گیت‌وی باید از رتبه‌بندی بر اساس قیمت‌های لحظه‌ای واحد اجتناب کنند. در عوض، باید مجموعه‌ای از گزارش‌های حذف‌شده را از طریق رابط عبور دهند تا کیفیت شواهد بازگشتی و معنای شکست‌هایی که Workerها باید جذب کنند، امتیازدهی شود.

چه از OpenAI، Claude یا Gemini استفاده کنید، این‌ها باید به عنوان ردیف‌هایی در یک ماتریس تست دیده شوند، نه یک رتبه‌بندی. هدف، مسیری از زمان اجراست که در آن دفتر کل شغل منطقی، اجازه کنترل هزینه را بدون قربانی کردن سیاست‌های منطقه‌ای یا صحت تلاش‌های مجدد بدهد.

این رویکرد زمانی ارزشمند است که سیاست‌های مرکزی و شواهد سازگار، وجود یک لایه شکست اضافی (گیت‌وی) را توجیه کنند. برای سرویس‌های کوچک که از یک مدل در یک منطقه استفاده می‌کنند، ادغام مستقیم API با یک دفتر کل کاربر ساده‌تر است. مسیر اجرا را صرفاً به دلیل ارزان‌تر به نظر رسیدن تغییر ندهید؛ تغییر تنها زمانی ایمن است که قرارداد خروجی، سیاست منطقه، رفتار Idempotency و فیلدهای مشاهده‌پذیری سازگار بمانند.

گام بعدی شما

• بررسی کنید آیا در حال حاضر از یک کلید API مشترک برای چندین مشتری استفاده می‌کنید یا هر کاربر شناسه مجزایی در لایه گیت‌وی دارد.
• پیاده‌سازی یک سیستم تخمین هزینه در لحظه پذیرش (Admission) را جایگزین ردیابی هزینه در پایان درخواست کنید تا بتوانید قبل از وقوع خسارت، دسترسی‌ها را محدود کنید.
• کلیدهای Idempotency را در تمام زنجیره درخواست‌ها (از صف تا مدل) یکپارچه کنید تا از پرداخت هزینه برای کارهای تکراری جلوگیری شود.

اما مدیریت این هزینه‌ها تنها نیمی از ماجراست؛ برای درک اینکه چگونه مدل‌های کوچک‌تر می‌توانند هزینه‌های استنتاج را تا ۹۰٪ کاهش دهند، به تحلیل ما درباره مدل‌های SLM مراجعه کنید.