هزینه‌های پنهان مهاجرت به مدل‌های برداری؛ ذخیره‌سازی گران‌تر از توکن‌ها

اگر امروز برای استنتاج مدل‌های خود هزینه پرداخت می‌کنید، احتمالاً هزینه‌ی توکن‌ها را می‌شناسید، اما از «تلهٔ ذخیره‌سازی» بی‌خبرید. تصور کنید می‌خواهید تمام کتابخانه‌ی دیجیتال خود را به زبانی جدید ترجمه کنید؛ شاید هزینهٔ مترجم کم باشد، اما خرید قفسه‌های جدید برای کتاب‌های حجیم‌تر، بودجه شما را می‌بلعد. یک مجموعه داده شامل ۴۰۰,۰۰۰ سند با قیمت‌های متوسط، کمتر از ۶۰۰ دلار هزینه باز-بردارسازی (Re-embedding) دارد، اما فضای ذخیره‌سازی این بردارها می‌تواند بی‌صدا صورت‌حساب ماهانه شما را دو برابر کند.

طبق گزارش فنی منتشر شده در dev.to در ۱۲ اوت ۲۰۲۶، ریسک مالی واقعی در مهاجرت به یک مدل جدید، هزینهٔ فراخوانی API نیست، بلکه سربار زیرساختی و «راه‌اندازی سرد» (Cold Start) — شبیه به گرم کردن موتور ماشین در زمستان که زمان و انرژی می‌برد — در حافظهٔ معنایی است. بسیاری از تیم‌ها مهاجرت را صرفاً یک محاسبهٔ ساده از تعداد توکن‌ها می‌بینند. آن‌ها هزینه عبور متن از یک مدل جدید را محاسبه می‌کنند و فرض می‌کنند این کل صورت‌حساب است. این رویکرد واقعیت پشته‌های بازیابی مدرن را نادیده می‌گیرد؛ جایی که بردارها برای استخراج مصنوعات دیگری مثل تخصیص خوشه‌ها، برچسب‌های موضوعی و لیست‌های توصیه استفاده می‌شوند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی سیستم‌های RAG اشاره کردیم، هر تغییری در مدل پایه، تمام مصنوعات وابسته به بردار را «مرده» می‌کند. این موضوع اهمیت ویژه‌ای دارد زیرا بسیاری از شکست‌های چت‌بات‌های RAG ریشه در خطاهای بازیابی دارند و هرگونه تغییر در مدل برداری بدون بازبینی دقیق، می‌تواند کیفیت بازیابی را بیش از پیش کاهش دهد. تست اینکه آیا یک مصنوع باطل شده است یا خیر، ساده است: آیا این مورد یک بردار است یا از بردارها محاسبه شده است؟ اگر پاسخ هر کدام مثبت باشد، آن مورد «مرده» است. شما نیازی به تولید مجدد متن یک خلاصه ندارید، اما باید آن را دوباره بردارسازی کنید. نادیده گرفتن این بردارهای ثانویه باعث می‌شود تخمین اولیه هزینه، پیش از شروع عملیات با شکست مواجه شود.

فهرست مصنوعات باطل شده

برای تخمین دقیق، باید هر آنچه نیاز به بازسازی دارد شناسایی شود. این فهرست شامل موارد زیر است:

• بردار معنایی تکه‌ها (Chunk embeddings): بدیهی‌ترین مورد و معمولاً ارزان‌ترین ردیف در صورت‌حساب است.
• بردارهای سطح سند و خلاصه: اگر خلاصه‌های تولید شده یا پرسش‌های فرضی را در کنار تکه‌ها بردار کرده‌اید، متن‌ها باقی می‌مانند اما بردارها باطل می‌شوند. باز-بردارسازی این موارد به جای تولید مجدد متن می‌تواند تخمین هزینه را به نصف کاهش دهد.
• محاسبات مبتنی بر شباهت: تخصیص خوشه‌ها (Cluster assignments)، برچسب‌های موضوعی مشتق شده از خوشه‌ها، تصمیمات حذف داده‌های تکراری (Deduplication) که در یک آستانه خاص گرفته شده‌اند، جداول پیش‌محاسبه شده اسناد مرتبط و لیست‌های توصیه. تمام این‌ها پاسخ‌هایی به پرسش‌هایی بودند که در فضای معنایی قدیمی پرسیده شده بودند. در محیط‌های عملیاتی، استفاده از جست‌وجوی برداری خالص اغلب در مواجهه با داده‌های صنعتی شکست می‌خورد و نیاز به رویکردهای ترکیبی برای حفظ دقت دارد.
• آداپتورهای تنظیم‌شده (Fine-tuned adapters) و رتبه‌بندها (Rerankers): یک آداپتور که روی یک مدل پایه قدیمی آموزش دیده است، در برابر مدل جدید بی‌ارزش است. بازآموزی این موارد اغلب هزینه واقعی مهاجرت است و باید به عنوان یک ردیف هزینه مجزا در نظر گرفته شود.
• خطوط پایه ارزیابی (Evaluation baselines): اعداد مربوط به Recall و Precision که روی شاخص قدیمی اندازه‌گیری شده‌اند، تا زمانی که دوباره اندازه‌گیری نشوند، نقطه مقایسه‌ای نیستند. این بدان معناست که مجموعه بازیابی باید پیش از مهاجرت وجود داشته باشد، نه پس از آن.

هزینه پنهان حافظهٔ معنایی

یکی از بزرگ‌ترین نقاط کور، حافظهٔ موقت معنایی (Semantic Cache) است. اگر شما خروجی‌های LLM را بر اساس بردار درخواست کاربر کش (Cache) می‌کنید، در لحظه‌ای که به مدل جدید سوییچ می‌کنید، تک‌تک این ورودی‌ها غیرقابل دسترس می‌شوند.

این موضوع یک هزینه درجه دوم ایجاد می‌کند: با نرخ موفقیت h در برابر هزینه تولید روزانه G، یک کش سرد تقریباً h × G در روز هزینه دارد تا زمانی که دوباره پر شود. این هزینه تولید روزانه اغلب از کل صورت‌حساب یک‌باره‌ی بردارسازی بیشتر می‌شود.

محاسبهٔ صورت‌حساب توکن‌ها

برای رسیدن به عدد دقیق، نباید به اندازهٔ تکه‌ها تکیه کرد، بلکه باید توکن‌های واقعی را اندازه گرفت. عدم تطابق توکن‌ساز (Tokenizer) بین تنظیمات شما و توکن‌ساز واقعی مدل می‌تواند منجر به اختلاف فاحش در صورت‌حساب شود. راهنمای مذکور توصیه می‌کند ۱۰۰۰ تکه تصادفی را بردارسازی کرده و مقدار توکن را از فیلد usage در پاسخ API بخوانید؛ این تنها عددی است که با صورت‌حساب نهایی مطابقت دارد.

برای یک مجموعه داده معمولی، محاسبات بر اساس چهار فرض قابل اندازه‌گیری پیش می‌رود:

• اسناد (D): ۴۰۰,۰۰۰ مورد
• میانگین تکه‌ها در هر سند (C): ۸ مورد
• میانگین توکن‌ها در هر تکه (T): ۳۵۰ توکن
• قیمت هر میلیون توکن ورودی (P): متغیر

ابتدا تعداد کل تکه‌ها محاسبه می‌شود: D × C = 400,000 × 8 = 3,200,000 تکه.
سپس تعداد کل توکن‌ها: 3,200,000 × 350 = 1,120,000,000 (۱.۱۲ میلیارد توکن).

صورت‌حساب نهایی یک ضرب ساده است: هزینه = (تعداد توکن‌ها ÷ ۱,۰۰۰,۰۰۰) × P.

• اگر P = ۰.۰۲ دلار در هر میلیون: ۲۲.۴۰ دلار
• اگر P = ۰.۱۰ دلار در هر میلیون: ۱۱۲.۰۰ دلار
• اگر P = ۰.۵۰ دلار در هر میلیون: ۵۶۰.۰۰ دلار

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

تلهٔ ذخیره‌سازی

جایی که اعداد غافلگیرکننده می‌شوند، فضای ذخیره‌سازی است. یک بردار float32 با ابعاد d، به اندازه 4d بایت فضا می‌گیرد. برای ۳.۲ میلیون تکه، نیازهای ذخیره‌سازی بر اساس ابعاد تغییر می‌کند:

• d = 1,536: 3,200,000 × 1,536 × 4 = 19,660,800,000 ≈ ۱۹.۷ گیگابایت
• d = 3,072: 3,200,000 × 3,072 × 4 = 39,321,600,000 ≈ ۳۹.۳ گیگابایت

از آنجا که هزینه ذخیره‌سازی یک هزینه ماهانه تکرار شونده است، انتقال از یک مدل ۱۵۳۶-بعدی به یک مدل ۳۰۷۲-بعدی، صورت‌حساب ماهانه را دو برابر می‌کند. در طول یک سال، این اختلاف هزینه ذخیره‌سازی می‌تواند به راحتی از هزینه یک‌بارهٔ فراخوانی‌های API برای باز-بردارسازی پیشی بگیرد.

علاوه بر این، در طول مهاجرت، شما باید هر دو شاخص (Index) را به طور هم‌زمان نگه دارید. در مثال بالا، این مقدار ۱۹.۷ + ۳۹.۳ ≈ ۵۹.۰ گیگابایت است، به علاوه هزینه اضافی ساختار شاخص (که برای شاخص‌های گرافی کوچک نیست). این نیاز حداکثری به این معناست که ذخیره‌سازهای مدیریت‌شده با محدودیت حجم، نیاز به فضای خالی (Headroom) پیش‌بینی شده قبل از شروع پر کردن داده‌ها دارند.

محدودیت‌های نرخ و زمان

زمان‌بندی مهاجرت شما به ندرت توسط هم‌روندی (Concurrency) کد شما محدود می‌شود، بلکه توسط محدودیت‌های نرخ (Rate Limits) ارائه‌دهنده تعیین می‌گردد. مدت زمان توسط هر محدودیتی که زودتر فعال شود تعیین می‌شود. برای همان مجموعه ۱.۱۲ میلیارد توکنی:

• محدودیت توکن در دقیقه (TPM): با فرض L = ۱,۰۰۰,۰۰۰ TPM، زمان برابر است با ۱,۱۲۰,۰۰۰,۰۰۰ ÷ ۱,۰۰۰,۰۰۰ = ۱,۱۲۰ دقیقه ≈ ۱۸.۷ ساعت.
• محدودیت درخواست در دقیقه (RPM): با فرض R = ۳,۰۰۰ RPM و اندازه دسته (B) ۱۰۰ تکه در هر درخواست، زمان برابر است با ۳۲,۰۰۰ درخواست ÷ ۳,۰۰۰ ≈ ۱۰.۷ دقیقه.

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

بازسازی‌های واقعی به دلیل تلاش‌های مجدد (Retries) پس از خطاهای ۴۲۹ و باقی‌مانده‌های پارتیشن، بیشتر از کف ۱۸.۷ ساعتی زمان می‌برند. برای زمان‌بندی، ضریبی از این کف تئوریک را در نظر بگیرید.

عوامل حساسیت هزینه

دو متغیر هزینه را بیش از آنچه اکثر مهندسان تصور می‌کنند تغییر می‌دهند:

۱. هم‌پوشانی (Overlap): اگر تکه‌های T توکنی با مقدار o هم‌پوشانی داشته باشند، مجموعه داده تقریباً T / (T − o) بار بردارسازی می‌شود. در تکه‌های ۳۵۰ توکنی با ۵۰ توکن هم‌پوشانی، این ضریب ۱.۱۷ است. در تکه‌های ۲۰۰ توکنی با ۵۰ توکن هم‌پوشانی، ضریب ۱.۳۳ است. نصف کردن اندازه تکه در حالی که هم‌پوشانی ثابت می‌ماند، هزینه را بیشتر از آنچه تعداد تکه‌ها نشان می‌دهد افزایش می‌دهد.
۲. تعدد (Multiplicity): اگر پشته شما تکه، یک خلاصه و سه پرسش فرضی را بردارسازی می‌کند، شما در واقع مجموعه داده را ۵ بار بردارسازی می‌کنید. باید ردیف توکن‌ها را در تعداد بردارهای هر تکه ضرب کنید.

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

مهندسی انتقال

برای به حداقل رساندن هزینه‌ها، این راهنما استفاده از لایه‌های دسته‌ای غیرهم‌زمان (Asynchronous Batch) را پیشنهاد می‌کند. بسیاری از ارائه‌دهندگان برای کارهایی که می‌توانند به جای ثانیه، ساعت‌ها منتظر بمانند (که دقیقاً توصیف یک عملیات Backfill است)، تخفیفات قابل توجهی ارائه می‌دهند. این تخفیف در واقع درصدی از قیمت هر توکن است.

علاوه بر این، توصیه می‌شود رفتار تلاش مجدد (Retry) به جای ابداع منطق‌های سفارشی، به «پس‌روی نمایی» (Exponential Backoff) در خطاهای ۴۲۹ (Too Many Requests) متصل شود. این کار تضمین می‌کند که مهاجرت با حداکثر سرعت ممکن مجاز از سوی ارائه‌دهنده اجرا شود.

این تغییر دیدگاه، گفتگو درباره مهاجرت را از «آیا توان مالی توکن‌ها را داریم؟» به «آیا فضای ذخیره‌سازی کافی و بودجه‌ای برای کش سرد داریم؟» تغییر می‌دهد.

برای کسانی که این هزینه‌ها را مدیریت می‌کنند، استفاده از یک درگاه (Gateway) یکپارچه برای ردیابی هزینه‌ها، بسیار کارآمدتر از تطبیق دستی چندین صورت‌حساب در طول دو هفته‌ای است که دو ارائه‌دهنده به طور هم‌زمان اجرا می‌شوند. این دقیقاً همان مشکلی است که ردیابی هزینه یکپارچه Multigrid برای حل آن طراحی شده است.

اگر در حال برنامه‌ریزی برای مهاجرت هستید، با اندازه‌گیری تعداد توکن‌های واقعی از یک نمونه ۱۰۰۰ تکه تصادفی شروع کنید. فرض‌های خود را در کنار پاسخ ثبت کنید تا اختلافات آینده بر سر ورودی‌ها باشد، نه بر سر نتایج.