اگر امروز مدیر فنی هستید و هزینه استنتاج مدل‌های مختلف را روی هر کاربر محاسبه می‌کنید، احتمالا با یک بمب ساعکی در دیتابیس خود دست و پنجه نرم می‌کنید. ذخیره پرامپت‌های خام برای محاسبه هزینه، یعنی پذیرفتن ریسک‌های حقوقی شدید در بازرسی‌های حریم خصوصی اروپا (European privacy reviews) یا ممیزی‌های سازمانی.
لاگ‌های خام (Raw request logs) در محیط تولید، در واقع یک ریسک یا liability هستند. اگرچه این لاگ‌ها برای عیب‌یابی یک خطای ۵۰۰ مفیدند، اما ذخیره کامل پرامپت‌ها برای اهداف صورت‌حساب، معمولاً در ممیزی‌های GDPR یا بازرسی‌های سازمانی زنگ خطر را به صدا در می‌آورد. لاگ‌های خام تمایل دارند حول هر چیزی که هفته پیش خراب شده باشد رشد کنند. آن‌ها بدنه درخواست‌ها، Stack Traceها، کدهای وضعیت HTTP و گاهی اوقات پرامپت‌های کامل را شکار می‌کنند. این رویکرد در زمان توسعه راحت است، اما در مقیاس تولید، تبدیل به یک وضعیت دشوار و مخاطره‌آمیز می‌شود.
بسیاری از تیم‌ها زمانی به شکست لاگینگ سنتی پی می‌برند که راه سخت را طی کرده باشند. آن‌ها متوجه می‌شوند که بدنه درخواست‌ها و Stack Traceها برای استخراج «حقیقت مالی» بیش از حد حجیم و برای «حفظ داده‌ها» بیش از حد خطرناک هستند. در فضای فعلی اپلیکیشن‌های چند-مدلی، سوال عملیاتی از «آیا درخواست موفق بود؟» به این تغییر کرده است: «چرا این مدل انتخاب شد و هزینه واقعی آن چقدر بود؟». به طور مشخص، تیم‌ها باید بدانند: کدام مدل انتخاب شده و چرا؟ چه تعداد توکن ورودی بدون کش (uncached)، توکن‌های ورودی کش‌شده و توکن‌های خروجی صورت‌حساب شده‌اند؟ آیا یک تلاش مجدد (Retry) یا جایگزینی مدل (Fallback)، قیمت نهایی را تغییر داده است؟ و هنگام تخمین هزینه، از کدام جدول قیمت (Price sheet) استفاده شده است؟ برای مدیریت بهینه این جایگزینی‌ها، قوانین جایگزینی ساختاریافته می‌توانند از شکست ناگهانی اپلیکیشن در هنگام تغییر مدل جلوگیری کنند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت لایه دسترسی به داده‌ها حیاتی است. این رویکرد جدید برای افزایش پایداری عملیاتی، فراتر از اتصال ساده است و اصطکاک مسیریابی بین ارائه‌دهندگان متنوع نظیر DeepSeek، Kimi، Qwen، GLM، MiniMax و ERNIE را هدف قرار می‌دهد. از آنجایی که هر ارائه‌دهنده APIهای خود را به شکل متفاوتی مستند کرده است — از Alibaba Cloud و مستندات Qwen برای مدل Qwen، تا BigModel برای Zhipu (GLM) و مستندات مجزا برای Moonshot (Kimi) — استفاده از یک درگاه (Gateway) یکپارچه برای کاهش پراکندگی و تغییرات مکرر SDKها ضروری است. این لایه انتزاعی مشابه معماری بای‌فراست (Bifrost) است که در مؤسسات مالی برای کنترل دقیق نشت داده‌ها به کار می‌رود.
به نقل از راهنمای منتشر شده در dev.to در تاریخ ۶ آگوست ۲۰۲۶، راهکار جایگزین، ایجاد یک «دفتر کل استفاده» (Usage Ledger) است. این دفتر کل، یک رکورد کوچک و فقط-الحاقی (Append-only) از تصمیمات قابل پرداخت AI است که خسته‌کننده (boring)، قابل پرس‌وجو و به طور خاص برای ممیزی‌ها طراحی شده است. در این مدل، AIWave به عنوان یک درگاه مثال زده شده که مدل‌های چینی را از طریق API سازگار با OpenAI در آدرس https://aiwave.live/v1 ارائه می‌دهد، هرچند این الگوی دفتر کل برای فراخوانی مستقیم ارائه‌دهندگان نیز به همان ترتیب کار می‌کند.
سازوکار دفتر کل
تفاوت اصلی دفتر کل با لاگ در این است که به جای «محتوا»، «متا-داده» را ذخیره می‌کند. به جای متن پرامپت، یک هش از شناسه کاربر (Tenant ID)، نام مدل و تعداد دقیق توکن‌ها ثبت می‌شود. این کار به تیم‌های فنی و مالی اجازه می‌دهد تا بدون افشای داده‌های شخصی، روی یک شیء خنثی برای تحلیل توافق کنند. با این روش می‌توان پرس‌وجوهای دقیقی زد، مانند: «کدام کاربران از بودجه روزانه مدل خود فراتر رفتند؟»، «جایگزینی یک مدل با مدل دیگر، هزینه‌ها را چقدر تغییر داد؟» یا «کدام دسته‌بندی‌های تسک (Task classes) بیشترین توکن‌های خروجی را تولید می‌کنند؟».
برای رسیدن به این دقت، دفتر کل باید سه دسته توکن را به طور مجزا ردیابی کند تا محرک‌های واقعی هزینه پنهان نمانند:
- توکن‌های ورودی بدون کش (Uncached input tokens): هزینه‌های استاندارد پرامپت.
- توکن‌های ورودی کش‌شده (Cached input tokens): نرخ‌های کاهش‌یافته برای Prefix Caching.
- توکن‌های خروجی (Output tokens): که معمولاً اصلی‌ترین عامل هزینه هستند.
یک درخواست با پیشوند کش‌شده طولانی و پاسخ کوتاه، پروفایل هزینه کاملاً متفاوتی نسبت به درخواستی دارد که هزاران توکن خروجی تولید می‌کند. بنابراین، یک ستون ساده تحت عنوان tokens_total ناکافی است و شما به ستون‌های مجزا نیاز دارید تا بتوانید صورت‌حساب را به درستی کنترل کنید.
طرح‌واره (Schema) عملیاتی برای ممیزی
برای اینکه یک دفتر کل در برابر تغییر ارائه‌دهندگان مقاوم باشد و بقا یابد، به یک ساختار پایدار نیاز دارد. فیلدهای زیر برای این منظور توصیه شده‌اند:
request_id: برای پیوند دادن ردپای اپلیکیشن (App traces)، فراخوانی‌های درگاه و تیکت‌های پشتیبانی مشتری.tenant_hash: ردیابی هزینه در سطح حساب بدون ذخیره شناسه‌های مستقیم.task_class: تفکیک کارهای کدنویسی، استخراج (Extraction)، چت، جست‌وجو و کارهای دسته‌ای (Batch jobs).model: شفاف‌سازی رفتار مسیریابی و جایگزینی مدل.region: مفید برای بررسی تأخیر (Latency) و یادداشت‌های مربوط به محل استقرار داده‌ها (Data residency).cached_input_tokens: مورد نیاز برای قیمت‌گذاری آگاه از کش.uncached_input_tokens: مورد نیاز برای قیمت‌گذاری ورودی عادی.output_tokens: ردیابی محرک اصلی هزینه.retry_count: نظارت بر اینکه تکرارهای پنهان چگونه صورت‌حساب را افزایش می‌دهند.fallback_from: نمایش اینکه آیا یک مدل ارزان‌تر در مرحله اعتبارسنجی شکست خورده است.validation_result: اتصال گیت‌های کیفیت به هزینه‌ها.estimated_usd: هزینه محاسبه شده در لحظه درخواست.price_source_url: مستندسازی اینکه نرخ قیمت از کجا آمده است.price_checked_at: ثبت زمانی که نرخ قیمت تأیید شده است.retention_class: تعیین مدت نگهداری؛ برای مثالaggregate_only(فقط تجمیعی)،debug_7d(۷ روز برای دیباگ) یاaudit_90d(۹۰ روز برای ممیزی).
شفافیت عملیاتی مستلزم ردیابی retry_count و مدل fallback_from است. این فیلدها افشا می‌کنند که آیا یک مدل ارزان‌تر شکست خورده و بی‌سروصدا هزینه را با مجبور کردن سیستم به سوئیچ به یک جایگزین گران‌تر بالا برده است. همچنین، دقت مالی به فیلدهای price_source_url و price_checked_at وابسته است. به دلیل تغییرات مکرر قیمت مدل‌های AI، این برچسب‌های زمانی توضیح می‌دهند که چرا یک درخواست در ماه گذشته با نرخ متفاوتی نسبت به امروز تخمین زده شده است.
پیاده‌سازی و بودجه‌بندی
این فرآیند شامل تخمین توکن‌ها — با استفاده از tiktoken (به‌ویژه رمزگذاری cl100k_base) یا روش‌های جایگزین مبتنی بر کلمه (تقریباً ۱.۳۵ توکن به ازای هر کلمه) — و محاسبه هزینه قبل یا بعد از فراخوانی API است. با محاسبه «هزینه پیش‌پرواز» (Preflight Cost)، توسعه‌دهندگان می‌توانند بودجه کاربران را در لحظه کنترل کرده و درخواست‌هایی که از حد مجاز روزانه می‌زنند را قبل از رسیدن به API مسدود کنند.
با استفاده از AIWave به عنوان یک درگاه، سیستم می‌تواند به ۶۲ ورودی مدل (تأیید شده از طریق نقطه انتهایی قیمت‌گذاری در تاریخ ۲۰۲۶-۰۸-۰۵) از طریق یک نقطه انتهایی واحد سازگار با OpenAI دسترسی داشته باشد. یک تصویر لحظه‌ای (Snapshot) از قیمت‌ها در ۵ آگوست ۲۰۲۶، تفاوت‌های فاحش در هزینه‌ها (USD برای هر ۱ میلیون توکن) را نشان می‌دهد. برای مثال، مدل DeepSeek V4 Flash با هزینه‌های بسیار پایین، استانداردهای جدیدی برای مدل‌های اقتصادی کدنویسی ایجاد کرده است:
- deepseek-v4-flash: ورودی ۰.۱۰ | خروجی ۰.۲۱ | کش ۰.۰۲
- deepseek-v4-pro: ورودی ۰.۵۴ | خروجی ۱.۰۹ | کش ۰.۲۷
- kimi-k2.6: ورودی ۰.۵۵ | خروجی ۲.۳۰ | کش ۰.۰۹
- glm-5-turbo: ورودی ۰.۹۰ | خروجی ۲.۷۰ | کش ۰.۲۴
- qwen3.5-122b-a10b: ورودی ۰.۲۵ | خروجی ۱.۸۶ | کش n/a
- minimax-m2.5: ورودی ۰.۲۵ | خروجی ۱.۰۰ | کش n/a
استراتژی حذف داده‌های حساس
هسته اصلی رویکرد GDPR-aware، حذف سخت‌گیرانه (Redaction) است. دفتر کل هرگز نباید شامل موارد زیر باشد:
- متن پرامپت یا پاسخ (Completion)
- آدرس ایمیل‌ها
- نام مستقیم مشتریان
- شناسه‌های پرداخت
- کلیدهای API (که باید در متغیرهای محیطی یا Secret Managerها بمانند).
این المان‌ها فقط باید در ذخیره‌سازهای کوتاه‌مدت اشکال‌زدایی با تاریخ انقضای صریح قرار بگیرند. یک سطر در دفتر کل که می‌گوید «یک کاربر آلمانی، استخراج فاکتور، مدل Kimi، شکست اعتبارسنجی، جایگزینی با DeepSeek، ۱ تکرار، هزینه تخمینی ۰.۰۰۰۴۲ دلار» اطلاعات کافی برای عیب‌یابی مسیریابی را می‌دهد بدون اینکه نیاز باشد خودِ سند فاکتور ذخیره شود.
تحلیل عملیاتی
این چرخش، متدولوژی مشاهده‌پذیری (Observability) در AI را از «همه چیز را لاگ کن» به «تصمیم را ثبت کن» تغییر می‌دهد. وقتی انتخاب مدل را به عنوان یک تصمیم مهندسی ببینیم، نه فقط یک انتخاب برند، تیم‌ها می‌توانند برای تسک‌های خاص بهینه شوند. مدل‌های چینی جایگزین یکدیگر نیستند: برخی برای نوشتن متون با کانتکست طولانی، برخی برای کدنویسی، برخی برای استخراج داده‌ها و برخی برای کارهای پس‌زمینه ارزان‌قیمت مناسب‌ترند.
برای توسعه‌دهنده، این یعنی درگاه (Gateway) اصطکاک ادغام را حل می‌کند، اما دفتر کل (Ledger) شکاف پاسخگویی را می‌پوشاند. این روش، «گفتگوی دشوار» با افسران حریم خصوصی را به یک زنجیره مستند از شواهد تبدیل می‌کند. این امر نه تنها برای GDPR، بلکه به عنوان یک عامل فشار برای ارائه شواهد SOC 2، پشتیبانی مشتری و بررسی‌های کیفیت مدل مفید است.
پرسش‌های متداول (FAQ)
آیا باید پرامپت‌ها را در دفتر کل استفاده ذخیره کنم؟
معمولاً خیر. ابتدا متا-داده‌های عملیاتی را ذخیره کنید. اگر برای اشکال‌زدایی به ضبط پرامپت‌ها نیاز دارید، آن‌ها را پشت یک دوره نگهداشت کوتاه، کنترل‌های دسترسی و حذف صریح (Redaction) قرار دهید.
آیا می‌توانم به تخمین‌های تعداد توکن اعتماد کنم؟
از تخمین‌ها فقط برای بررسی‌های پیش‌پرواز (Preflight) استفاده کنید. برای صورت‌حساب نهایی و گزارش‌دهی، تعداد توکن‌های بازگردانده شده توسط پاسخ API یا لاگ‌های درگاه را ترجیح دهید.
چرا تاریخ منبع قیمت را ذکر کنیم؟
قیمت مدل‌های AI مکرراً تغییر می‌کند. یک منبع تاریخ‌دار به تیم‌های مالی و مهندسی اجازه می‌دهد بفهمند چرا یک درخواست قدیمی با نرخ متفاوتی نسبت به صفحه قیمت‌های امروز تخمین زده شده است.
گام بعدی شما
- استراتژی لاگینگ فعلی خود را بررسی کنید تا ببینید آیا در حال انباشت «بدهی حریم خصوصی» (Privacy Debt) هستید یا خیر.
- یک سیستم بودجه‌بندی مبتنی بر هشِ کاربر (Hashed-tenant) را برای جلوگیری از هزینه‌های خارج از کنترل API پیاده کنید.
- ستون‌های تفکیکی برای توکن‌های کش‌شده و نشده را در دیتابیس هزینه‌های خود تعریف کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو