اگر برای مشتریان مختلف سرویس هوش مصنوعی ارائه می‌دهید، احتمالاً با مشکل «نشت بودجه» یا اختلاف بین هزینه واقعی و تخمینی توکن‌ها دست‌وپنجه نرم کرده‌اید. یک اپلیکیشن AI چندمستاجری (Multi-tenant) درست در لحظه‌ای که شمارنده توکن‌هایش از هزینه واقعی استنتاج فاصله می‌گیرد، شروع به ضرر مالی می‌کند. Telnyx در ۶ اکتبر ۲۰۲۶ با معرفی Telnyx AI Gateway، نقطه کنترل هزینه‌ها را از کدهای پیچیده اپلیکیشن مستقیماً به لایه استنتاج (Inference) — که شبیه لحظهٔ نهایی پخت غذا در آشپزخانه است، نه دوره آموزش آشپز — منتقل کرد.
بسیاری از توسعه‌دهندگان برای ردیابی مصرف، به تخمین‌های لایه اپلیکیشن تکیه می‌کنند. اما طبق گزارش‌های فنی، این تخمین‌ها معمولاً درخواست‌های هم‌زمان، رفتارهای استریمینگ یا شکست‌های سیستمی را نادیده می‌گیرند. این شکاف باعث ایجاد پدیده‌ای به نام «انحراف بودجه» (Budget Drift) می‌شود؛ وضعیتی که در آن یک مستاجر حتی پس از رسیدن به سقف بودجه تئوریک خود، همچنان به مصرف توکن‌های گران‌قیمت ادامه می‌دهد. این چالش‌ها نشان می‌دهد چرا بسیاری از رتبه‌بندی‌های درگاه‌های هوش مصنوعی بیشتر جنبه بازاریابی دارند تا ارائه راهکارهای عملی برای مدیریت دقیق هزینه‌ها.
برای حل این مشکل، معماری جدید درگاه AI را با «اکتورهای لبه» (Edge Actors) پایدار ترکیب می‌کند. در این مدل، اپلیکیشن دیگر نمی‌پرسد «آیا کاربر اعتبار دارد یا خیر»، بلکه خودِ درگاه این محدودیت را اعمال می‌کند. اگر بودجه کاربر تمام شود، درگاه بلافاصله خطای 403 (budget_exceeded) برمی‌گرداند و درخواست را پیش از آنکه اصلاً به مدل برسد، متوقف می‌کند.
همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های بازمتن اشاره کردیم، انتقال کنترل به لایه‌های زیرساختی، ریسک‌های عملیاتی را به‌شدت کاهش می‌دهد.
گردش‌کار تخصیص منابع
این سامانه از یک API مبتنی بر TypeScript برای مدیریت مشتریان استفاده می‌کند. نقطه اتصال /provision دفتر حساب مشتری، گروه توکن‌های درگاه و کلید توکن را می‌سازد. سایر نقاط اتصال شامل GET /spend برای بازگرداندن هزینه‌های جاری، میزان مصرف مدل و وضعیت بودجه، و همچنین POST /adjust برای تغییر بودجه‌ها با استفاده از قابلیت کنترل هم‌زمانی خوش‌بینانه (Optimistic Concurrency) است.
به نقل از مستندات Telnyx، هنگام ایجاد یک مشتری جدید از طریق API مربوط به /provision، زیرساخت‌های اختصاصی زیر به‌صورت خودکار مستقر می‌شوند:
- یک بودجه ۳۰ روزه برای درگاه AI و یک کلید توکن یک‌بار مصرف منحصربه‌فرد (که با
ltg_sk_...شروع می‌شود). - یک فهرست سفید (Allowlist) از مدل‌های خاصی که مشتری مجاز به دسترسی به آن‌هاست.
- حفاظ‌ها (Guardrails) — شبیه نرده‌های ایمنی در کنار پرتگاه — برای مسدود کردن اسرار (Secrets) یا داده‌های مالی در پرامپت‌ها و پاسخ‌ها.
- یک اکتور SpendLedger پایدار برای ردیابی تاریخچه عملیاتی.
- جداول SQL خصوصی برای ثبت هزینه‌های روزانه، هشدارها و رویدادهای مربوط به حفاظ‌ها.
- یک وظیفه تجمیع ساعتی (Hourly Rollup Task) برای نرمال‌سازی داده‌ها.
- اعلان‌های SMS در آستانه‌های بودجه که به‌صورت قابل پیکربندی هستند.
پیاده‌سازی فنی محدوده‌های درگاه
در این ساختار، ورکر (Worker) شناسه مشتری را به یک هویت اکتور پایدار متصل می‌کند. سپس اکتور با استفاده از متدهای client.createTokenGroup و client.createTokenKey یک گروه توکن با بودجه و سیاست حفاظتی مجزا می‌سازد.
اپلیکیشن مشتری سپس از یک نقطه اتصال استنتاج سازگار با OpenAI استفاده می‌کند. برای مثال، درخواستی به https://llm.telnyx.com/v1/chat/completions برای مدلی مثل "Kimi-K2.6"، از طریق توکن Bearer به‌طور خودکار به گروه توکن همان مشتری متصل می‌شود.
مدیریت وضعیت پایدار
در حالی که درگاه پاسخ «بله یا خیر» را به درخواست می‌دهد، اکتور SpendLedger دلیل این پاسخ را مدیریت می‌کند. هر مشتری به یک اکتور متصل است که هر ساعت یک وظیفه پایدار (armRollup) را برای تجمیع مصرف و انتقال آن به SQL اجرا می‌کند. این یعنی اگر محیط اجرا (Runtime) ری‌استارت شود، سیستم مجبور نیست دفتر حساب را از ابتدا بازسازی کند.
به‌روزرسانی SQL به‌صورت Idempotent (تکرارپذیر بدون تغییر نتیجه) بر اساس مشتری و روز انجام می‌شود. این سیستم از دستور INSERT INTO spend_days همراه با عبارت ON CONFLICT(tenant, day) DO UPDATE استفاده می‌کند تا معیارهای دقیقی را ردیابی کند، از جمله:
- مجموع هزینه‌ها
- تعداد توکن‌های ورودی و خروجی
- تعداد درخواست‌های مسدود شده
- تعداد درخواست‌های علامت‌گذاری شده
این اکتور همچنین هشدارها را مدیریت می‌کند. با ذخیره پرچم‌های alerted80 و alerted100 در وضعیت پایدار، سیستم تضمین می‌کند که مشتری دقیقاً یک پیامک در ۸۰٪ (آستانه هشدار) و ۱۰۰٪ (آستانه سخت) بودجه دریافت کند، فارغ از اینکه وظیفه تجمیع چند بار اجرا شده باشد. هنگامی که درگاه یک مقدار جدید برای resets_at گزارش می‌دهد، اکتور متوجه شروع یک دوره بودجه جدید شده و این گارد‌های هشدار را پاک می‌کند.
حفاظ‌ها و امنیت
امنیت از طریق یک سیاست خاص به نام GUARDRAILS_POLICY مدیریت می‌شود. سامانه می‌تواند داده‌های حساس، مانند پروفایل‌های مالی را در هر دو مسیر پرامپت و پاسخ مسدود یا علامت‌گذاری کند. پیکربندی این سیاست شامل موارد زیر است:
- Secrets: تنظیم شده روی حالت "block" (مسدود کردن) برای هر دو بخش پرامپت و پاسخ.
- DLP: پروفایل‌های مالی روی حالت "flag" (علامت‌گذاری) برای هر دو بخش تنظیم شده‌اند.
- Streaming: روی حالت "buffered" (بافری) قرار دارد.
نکته کلیدی این است که اکتور فقط متادیتای یافته‌ها — مانند مرحله، نتیجه، تشخیص‌دهنده (Detector)، کد یافته و تعداد — را ذخیره می‌کند و متن حساس واقعی که باعث فعال شدن قانون شده است را ذخیره نمی‌کند. این کار از تبدیل شدن دفتر حساب به مخزنی از داده‌های محرمانه پرامپت‌ها جلوگیری می‌کند.
جلوگیری از تداخلات (Race Conditions)
برای مدیریت ویرایش‌های هم‌زمان بودجه، سامانه از یک GatewayClient مرکزی برای قراردادهای ارتباطی درگاه AI استفاده می‌کند. هر درخواست POST, PATCH یا DELETE شامل یک Idempotency-Key منحصربه‌فرد است که توسط crypto.randomUUID() تولید می‌شود.
به‌روزرسانی بودجه از هدر If-Match استفاده می‌کند که حاوی نسخه فعلی گروه توکن است. فرآیند ابتدا نسخه فعلی را از طریق getTokenGroup می‌خواند و سپس آن نسخه را در هنگام فراخوانی patchTokenGroup بازمی‌گرداند. اگر فرآیند دیگری زودتر بودجه را تغییر داده باشد، API به‌جای بازنویسی داده‌ها، خطای 412 (precondition_failed) برمی‌گرداند.
استقرار و آزمایش
توسعه‌دهندگان می‌توانند پیش از استفاده از اعتبار واقعی، سیستم را با یک «تست دود» (Smoke Test) بررسی کنند. این فرآیند شامل کلون کردن مخزن telnyx-code-examples ،نصب وابستگی‌ها و اجرای دستورات npm run smoke و npm run typecheck است.
این تست موارد زیر را تایید می‌کند:
- ساختار درخواست‌های درگاه و پوشه‌های پاسخ داده‌ها.
- مدیریت هدرهای Idempotency و
If-Match. - محاسبات هزینه و گارد‌های هشدار.
- نرمال‌سازی یافته‌های امنیتی.
برای استقرار واقعی، کاربران باید TELNYX_API_KEY ،ADMIN_SMS_FROM و ADMIN_SMS_TO را پیکربندی کنند. فعال کردن DEMO_MODE=true باعث می‌شود هشدارها به‌جای ارسال، فقط در لاگ‌ها ثبت شوند.
کاربردهای این الگو
این معماری به‌طور خاص برای پلتفرم‌هایی طراحی شده که ویژگی‌های AI را برای مشتریان، تیم‌ها یا محیط‌های متعدد ارائه می‌دهند، از جمله:
- محصولات SaaS با دستیارهای AI داخلی.
- ارائه‌دهندگان خدمات مدیریت‌شده (MSP) که عامل‌های اختصاصی برای مشتریان اجرا می‌کنند.
- پلتفرم‌های داخلی شرکت‌ها با بودجه‌های تفکیک شده دپارتمانی.
- آژانس‌هایی که حجم استنتاج را برای مشتریان خود مدیریت می‌کنند.
- پلتفرم‌های توسعه برای جداسازی هزینه‌های محیط Staging و Production.
این رویکرد بار حاکمیت مالی را از منطق تجاری توسعه‌دهنده به لایه زیرساخت منتقل می‌کند. برای برنامه‌نویسان، این به معنای پایان بودجه‌های «نشت‌کننده» است. در واقع، استفاده از بودجه‌بندی تلمتری یکپارچه می‌تواند از وابستگی شدید به یک ارائه‌دهنده خاص جلوگیری کرده و انعطاف‌پذیری سیستم را افزایش دهد. با تبدیل درگاه به منبع حقیقت (Source of Truth) برای هزینه‌ها، شرکت‌ها می‌توانند قیمت‌گذاری‌های پلکانی سخت‌گیرانه را بدون ترس از سربار عملیاتی ناشی از انحراف توکن‌ها ارائه دهند.
گام بعدی شما
- اگر از مدل‌های مختلف (مثل Kimi یا GPT) در یک اپلیکیشن استفاده می‌کنید، ساختار درگاه (Gateway) را جایگزین شمارنده‌های داخلی کنید.
- برای جلوگیری از تداخل در به‌روزرسانی بودجه، پیاده‌سازی
If-Matchو کلیدهای Idempotency را در APIهای خود بررسی کنید. - سیاست‌های DLP را در لایه درگاه فعال کنید تا داده‌های حساس پیش از رسیدن به مدل مسدود شوند.
اما مدیریت هزینه تنها بخشی از چالش است؛ برای درک نحوه بهینه‌سازی سرعت پاسخ‌دهی در این لایه‌ها، به تحلیل ما درباره کاهش تأخیر در استنتاج مراجعه کنید.
گفتگو