اگر برای هر پرسش از یک مدل زبانی، هزینه‌ی پردازش کل یک سند ۱۰۰ صفحه‌ای را می‌پردازید، احتمالاً بخش بزرگی از بودجه‌ی پردازشی شما هدر می‌رود. در حال حاضر، ناوگان‌های GPU مقادیر عظیمی از توان محاسباتی را صرف تکرار کارهای مشابه می‌کنند، هر بار که کاربران سؤالی را درباره‌ی یک سند طولانی یکسان می‌پرسند. پلتفرم Tensormesh که در ۱۴ اکتبر ۲۰۲۶ عرضه شد، دقیقاً برای پایان دادن به این ناکارآمدی و مدیریت حافظه کلید-مقدار (KV Caching) در مقیاس سازمانی طراحی شده است.
بسیاری از دستیارهای هوش مصنوعی هر بار که یک سند طولانی در پرامپت ظاهر می‌شود، آن را از ابتدا پردازش می‌کنند. این تکرار، ظرفیت گران‌بهای واحد پردازش گرافیکی (GPU) را بدون ایجاد ارزش جدید مصرف می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی ابزارهای مشاهده‌پذیری مانند Langfuse و Helicone دیدیم که نحوه رصد عملکرد AI را بررسی می‌کردند، تمرکز بر رصد عملکرد مهم است، اما Tensormesh مستقیماً روی زیرساخت هزینه‌ای این عملکرد دست می‌گذارد.
تصور کنید یک بات پشتیبانی مشتری دارد که برای هر پرس‌وجوی تک‌تک کاربران، باید به یک دفترچه راهنمای ۱۰۰ صفحه‌ای رجوع کند. بدون سیستم حافظه KV، GPU باید برای هر کاربر دوباره این دفترچه را «بخواند». Tensormesh اجازه می‌دهد حالت پردازش‌شده‌ی آن دفترچه ذخیره شود و برای صدها پرسش مختلف بازیافت شود. به همین ترتیب، یک عامل هوش مصنوعی (AI Agent) ممکن است به‌طور مکرر مجموعه‌ای از ابزارها یا دستورالعمل‌های یکسان را در کنار وظایفی که مدام تغییر می‌کنند قرار دهد؛ حافظه کردن این موارد ثابت، از پردازش‌های زائد جلوگیری می‌کند. این بهینه‌سازی در لایه‌ی حافظه، مکمل راهکارهای سخت‌افزاری است، مشابه آنچه در سرور Superfluid برای کاهش زمان پاسخ‌دهی عامل‌های محلی مشاهده کردیم.
سازوکار حافظه KV
استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند — در دو مرحله رخ می‌دهد: پیش‌پُرکردن (Prefill) که مربوط به پردازش ورودی است و رمزگشایی (Decode) که مربوط به تولید پاسخ است. حافظه KV Cache حالت‌های میانی مربوط به مکانیزم توجه (Attention) در مرحله‌ی پیش‌پُرکردن را ذخیره می‌کند. با بازیافت این حالت، سیستم می‌تواند از پردازش سنگین متون تکراری بپرد.
برخلاف ذخیره کردن یک پاسخ نهایی، این روش محاسبات مربوط به «زمینه» (Context) را بازیافت می‌کند، در حالی که همچنان یک پاسخ منحصربه‌فرد برای یک سؤال جدید تولید می‌کند. به نقل از مستندات vLLM درباره‌ی حافظه پیشوندی خودکار (Automatic Prefix Caching)، این روش به‌ویژه برای گفتگوهای چندمرحله‌ای و پرس‌وجوهای مکرر از یک سند مؤثر است.
اما یک محدودیت کلیدی وجود دارد: حافظه پیشوندی تنها مرحله‌ی پردازش پرامپت را سرعت می‌بخشد، نه مرحله‌ی تولید توکن‌های خروجی جدید را. در نتیجه، بارهای کاری که توسط پاسخ‌های بسیار طولانی یا ورودی‌های عمدتاً منحصربه‌فرد هدایت می‌شوند، ممکن است بهره‌ی کمتری از این معماری ببرند.
مدیریت در سطح سازمانی
این پلتفرم فراتر از یک حافظه ساده عمل کرده و با حافظه به عنوان یک زیرساخت مدیریت‌شده برخورد می‌کند. Tensormesh پنج اولویت عملیاتی را برای سازمان‌ها تعریف کرده است:
- امنیت: محافظت از داده‌های ذخیره‌شده در حافظه در برابر دسترسی‌های غیرمجاز.
- مشاهده‌پذیری: رصد عملکرد و نرخ برخورد (Cache-hit rate).
- تاب‌آوری: بازیابی حالت‌ها پس از شکست‌های سیستمی.
- مدیریت سیاست‌ها: کنترل اینکه داده‌ها چه مدت نگهداری شوند یا چه زمانی حذف (Evict) گردند.
- چندمستاجری: جداسازی داده‌های تیم‌های مختلف یا مشتریان مختلف در یک زیرساخت مشترک.
برای پشتیبانی از این اولویت‌ها، شرکت APIهای کنترل‌کننده‌ای ارائه داده است. این ابزارها به اپراتورها اجازه می‌دهند ورودی‌های حافظه را به‌طور صریح تثبیت (Pin)، مکان‌یابی، جابه‌جا، فشرده یا پاک کنند. این امر مدیریت چرخه حیات حافظه را از یک فرآیند رها شده به دست موتورهای استنتاج، به یک دغدغه‌ی عملیاتی صریح تبدیل می‌کند.
حل مسئله‌ی «پیشوند»
حافظه‌های پیشوندی استاندارد تنها زمانی کار می‌کنند که دو پرامپت دقیقاً با توکن‌های یکسانی شروع شوند. این موضوع در تولید بازیابی‌افزا (RAG) یک چالش جدی است؛ زیرا در RAG، اپلیکیشن اسناد مرتبط را بازیابی می‌کند، اما این اسناد ممکن است با ترتیب متفاوتی ظاهر شوند یا متون متفاوتی قبل از آن‌ها بیاید.
دو درخواست را در نظر بگیرید که از اسناد یکسانی استفاده می‌کنند: یکی سند A و سپس B را دارد، و دیگری سند B و سپس A را. هر دو حاوی مطالب قابل بازیافت هستند، اما شروع مشترک آن‌ها کوتاه است و باعث می‌شود تطبیق پیشوندی سنتی ناکارآمد شود.
برای حل این مشکل، Tensormesh از مکانیزمی به نام CacheBlend استفاده می‌کند. بر اساس پژوهشی که در EuroSys ۲۰۲۵ ارائه شد، CacheBlend تنها بخش کوچکی از توکن‌ها را مجدداً محاسبه کرده و تکه‌های حافظه را از هر جای پرامپت بازیافت می‌کند. این محاسبه مجدد گزینشی ضروری است زیرا زمینه‌ی اطراف یک تکه (Chunk) می‌تواند بر حالت داخلی مدل تأثیر بگذارد.
در بارهای کاری ارزیابی شده، CacheBlend سرعت رسیدن به نخستین توکن (Time-to-first-token) را ۲.۲ تا ۳.۳ برابر و توان عملیاتی (Throughput) را ۲.۸ تا ۵ برابر در مقایسه با محاسبه کامل افزایش داده است. این نتایج در سه مدل متن‌باز و چهار مجموعه داده‌ی بنچمارک آزمایش شده‌اند.
زیرساخت و سازگاری
این پلتفرم بر پایه پروژه متن‌باز LMCache بنا شده است که مدیریت حافظه را از موتور سرویس‌دهی (Serving Engine) جدا می‌کند. این سیستم از تخلیه (Offloading) و بازیابی در چندین لایه ذخیره‌سازی پشتیبانی می‌کند و اجازه می‌دهد از طریق بک‌اندهای ذخیره‌سازی و انتقال قابل تعویض، حافظه در درخواست‌ها، نشست‌ها و نمونه‌های مختلف موتور بازیافت شود. این رویکرد بهینه‌سازی حافظه در کنار تکنیک‌های فشرده‌سازی مدل، مانند آنچه در پروژه PrismML برای کاهش اثر حافظه مدل‌های Qwen دیدیم، به کاهش هزینه‌های عملیاتی زیرساخت کمک می‌کند.
جزئیات استقرار
- ارکستراسیون: یک اپراتور Kubernetes اجزای موتور حافظه را مدیریت می‌کند.
- تنظیمات گره: سرورهای حافظه روی گره‌های GPU مستقر می‌شوند، در حالی که یک هماهنگ‌کننده (Coordinator) هماهنگی در سطح کل ناوگان را بر عهده دارد.
- مسیر استقرار: از Helm برای استقرار استفاده می‌شود که توسط یک رابط وب و ابزارهای خط فرمان پشتیبانی می‌گردد.
- سخت‌افزار: سیستم از GPUهای NVIDIA یا GPUهای AMD Instinct از طریق ROCm پشتیبانی می‌کند.
- ذخیره‌سازی: پلتفرم از ذخیره‌سازی مبتنی بر سیستم فایل (Filesystem-backed) استفاده می‌کند.
برای صرفه‌جویی در حافظه محدود GPU، سیستم حالت‌های کم‌کاربرد را به حافظه CPU یا فضای ذخیره‌سازی منتقل می‌کند. این کار مانع از رقابت حافظه با فرآیند استنتاج واقعی برای VRAM گران‌بها می‌شود، هرچند بازیابی داده‌ها هزینه‌های پهنای باند و تأخیر (Latency) خاص خود را به همراه دارد.
در مورد سازگاری، ماتریس ۱۷ سپتامبر شرکت، موتورهای vLLM و NVIDIA Dynamo را به عنوان موتورهای تأیید شده لیست کرده است. پشتیبانی از SGLang و TensorRT-LLM در حال حاضر در نقشه راه قرار دارد. این سیستم برای مدل‌های میزبانی شخصی (Self-hosted) طراحی شده و نمی‌تواند به APIهای مدل‌های ابری خارجی متصل شود. همچنین حافظه غیرپیشوندی برای مدل‌های متراکم (Dense) و پشتیبانی از SGLang به عنوان قابلیت‌های آتی ذکر شده‌اند.
هماهنگی پیشرفته در خوشه
اعلامیه عرضه این محصول به انتقال‌های peer-to-peer در سطح KV اشاره دارد که اجازه می‌دهد یک گره، حالت حافظه را از گره دیگر دریافت کند. علاوه بر این، پلتفرم از جداسازی پیش‌پُرکردن و رمزگشایی (Prefill/Decode Disaggregation) پشتیبانی می‌کند. این قابلیت پردازش پرامپت را از تولید خروجی جدا می‌کند تا این دو مرحله بتوانند روی کارگران (Workers) متفاوتی اجرا شوند.
این‌ها استراتژی‌های مکمل هستند. اشتراک‌گذاری حالت از محاسبه مجدد آن روی گره‌ای دیگر جلوگیری می‌کند، در حالی که جداسازی به تیم‌های زیرساخت اجازه می‌دهد منابع را بر اساس تقاضاهای پردازشی خاص به‌طور متفاوتی تخصیص دهند. با این حال، کاربران باید توجه کنند که طبق ماتریس ۱۷ سپتامبر، انتقال peer-to-peer و جداسازی در وضعیت پیش‌نمایش یا نقشه راه هستند.
موازنه اقتصادی
برای یک کسب‌وکار، ارزش این پلتفرم به «نرخ برخورد» (Hit rate) پرامپت‌های آن‌ها بستگی دارد. اگر هر ورودی کاربر منحصربه‌فرد باشد، سربار مدیریت حافظه ممکن است بیشتر از مزایای آن باشد.
اما برای پایگاه‌های دانش داخلی، سرویس‌های تحلیل سند یا گردش‌های کاری عامل‌محور (Agentic) با دستورالعمل‌های ثابت، صرفه‌جویی‌ها ملموس است. اپراتورها باید رفتار حافظه سرد (Cold-cache) را در مقابل حافظه گرم (Warm-cache) با استفاده از ترافیک واقعی بسنجند و موارد زیر را اندازه‌گیری کنند:
- زمان تا نخستین توکن و توان عملیاتی کلی.
- زمان بازیابی حافظه و میزان بهره‌وری GPU.
- هزینه‌های حافظه، ذخیره‌سازی و شبکه برای نگهداری حالت‌ها.
نرخ برخورد به تنهایی کافی نیست؛ یک نرخ برخورد بالا تنها زمانی مفید است که کار بازیابی شده، پس از کسر سربار انتقال، یک سود خالص ایجاد کند. علاوه بر این، کیفیت پاسخ‌ها باید تأیید شود، به‌ویژه زمانی که تکه‌های حافظه در زمینه‌های جدید ترکیب می‌شوند.
این تغییر رویکرد، حالت استنتاج را به جای یک محصول جانبی یک‌بار مصرف، به عنوان یک منبع قابل بازیافت در نظر می‌گیرد. این امر صنعت را به مدلی نزدیک‌تر می‌کند که در آن «حافظه» هوش مصنوعی در کل ناوگان باقی می‌ماند، نه فقط در یک نشست واحد.
گام بعدی شما
- اگر از مدل‌های میزبانی شخصی استفاده می‌کنید، نرخ تکرار اسناد در پرامپت‌های خود را تحلیل کنید تا متوجه شوید آیا کاندیدای استفاده از KV-Caching هستید یا خیر.
- مستندات LMCache را برای درک لایه‌های ذخیره‌سازی حافظه بررسی کنید.
- در صورت استفاده از RAG، تأثیر ترتیب اسناد بر هزینه استنتاج را بسنجید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو