پشته LLM در محیط عملیاتی: آنچه واقعاً در اواسط ۲۰۲۶ کار میکند
استک LLM در محیط تولید: آنچه در اواسط ۲۰۲۶ واقعاً کار میکند
سیستمهای LLM در محیط تولید از آستانهای عبور کردهاند که اکثر نوشتههای حوزه هوش مصنوعی هنوز به آن نرسیدهاند: خود مدلها دیگر بخش دشوار ماجرا نیستند. گرفتن یک تکمیل خوب از Claude 3.5 Sonnet یا Gemini 2.0 Flash حالا پیشپاافتادهترین کار است. چالش واقعی مهندسی همهچیز اطراف مدل است؛ بهطور مشخص، کارایی استنتاج، کیفیت بازیابی، پایداری عاملها، و کنترل هزینه در حجم درخواستهایی که بارهای کاری واقعی عاملی تولید میکنند.
هجده ماه است که ویژگیهای مبتنی بر LLM را در محیط تولید اجرا میکنم و استک بهطور قابلتوجهی تغییر کرده است. آنچه تا ژوئن ۲۰۲۶ میدانم درست است را اینجا میآورم.
لایه استنتاج: vLLM برنده شد، فعلاً
اگر مدلها را خودتان میزبانی میکنید، انتخاب فریمورک استنتاج بیشتر از آنچه معمولاً گفته میشود اهمیت دارد. سه گزینه جدی عبارتند از vLLM، SGLang و TensorRT-LLM که هر کدام کاربرد متفاوتی دارند. vLLM نقطه شروع درست برای تقریباً هر تیمی است. گستردهترین طیف مدلها را پوشش میدهد، نیازی به مرحله کامپایل ندارد، و از طریق PagedAttention و batching پیوسته، توان عملیاتی رقابتی ثابتی ارائه میدهد. SGLang در بارهای کاری با پیشوند مشترک که زمان رسیدن به اولین توکن اهمیت دارد، مثل پایپلاینهای RAG که همان سیستم پرامپت بلند را به هر درخواست اضافه میکنند، از آن جلو میزند. TensorRT-LLM تنها زمانی ارزش درد آوردنش را دارد که مدلی را برای ماهها قفل کرده باشید و نیاز داشته باشید در مقیاس، آخرین توکن در ثانیه را هم بکشید.
TGI هوش مصنوعی HuggingFace رسماً در حالت نگهداری است. خود HuggingFace حالا vLLM یا SGLang را توصیه میکند. این را یک سیگنال واضح میدانم.
معماری پشته تولید برای استقرارهای جدی سه لایه است: موتور استنتاج روی سختافزار شتابدهنده، یک لایه سرویسدهی که مسیریابی و قراردادهای API را مدیریت میکند (LiteLLM یا Envoy AI Gateway)، و یک لایه هماهنگسازی مبتنی بر Kubernetes با KEDA برای مقیاسبندی خودکار. اهداف کارایی که مهندسان اکنون ملزم به رعایت آنها هستند عبارتند از TTFT زیر ۳۰۰ میلیثانیه برای بارهای کاری استاندارد و تاخیر بین توکن در حد چند ده میلیثانیه.
هزینه: ریاضیات تغییر کرد، مشکل نه
قیمتگذاری API بین سالهای ۲۰۲۵ و ۲۰۲۶ حدود ۸۰ درصد کاهش یافت. کارایی در سطح GPT-4 اکنون حدود ۰.۴۰ دلار به ازای هر میلیون توکن است، در مقایسه با ۳۰ دلار در اوایل ۲۰۲۳. این در نگاه اول مسئلهای حلشده به نظر میرسد، تا زمانی که در نظر بگیرید سیستمهای عاملمحور واقعاً چه میکنند: یک وظیفه واحد کاربر میتواند ۵۰ تا ۲۰۰ فراخوانی LLM را فعال کند. قیمت ارزان به ازای هر توکن خیلی سریع به هزینه گران به ازای هر وظیفه تبدیل میشود.
تکنیکهایی که واقعاً تفاوت ایجاد میکنند عبارتند از کشکردن پرامپت (که هزینههای ورودی را در زمینههای تکراری تا ۹۰ درصد کاهش میدهد)، کوانتیزاسیون FP8 در ترکیب با Flash Attention 3 و رمزگشایی تخمینی، و مسیریابی هوشمند درخواست که وظایف فرعی سادهتر را به مدلهای کوچکتر و ارزانتر ارسال میکند. رمزگشایی تخمینی ارزش پروفایلگیری دقیق را دارد: از یک مدل پیشنویس کوچک برای تولید توکنهای کاندیدا استفاده میکند که مدل اصلی آنها را به صورت موازی تأیید میکند، اما اگر نرخ پذیرش به زیر حدود ۰.۵ توکن در هر مرحله کاهش یابد، سربار اضافه میکنید، نه کاهش.
نظر من: تیمهایی که داشبورد هزینه به ازای هر ویژگی نمیسازند، کور خرج میکنند. صرفهجوییها واقعی هستند، اما نیاز به انضباط اندازهگیری دارند.
بازیابی تقویتشده با داده: مشکل همچنان در بازیابی است
لگو کردن PDFها در یک پایگاه داده برداری و نامیدنش «پایگاه دانش» اکنون بهطور گستردهای ناکافی شناخته میشود. تا سال ۲۰۲۶، مرحله بازیابی جایی است که بیشتر شکستهای RAG از آن ناشی میشوند، نه مدل تولید. حالت شکست ظریف است: سیستم پاسخهایی با لحن اطمینانبخش اما مبتنی بر قطعههای اشتباه برمیگرداند، و کاربران متوجه آن نمیشوند.
بازیابی ترکیبی که جستجوی برداری متراکم را با BM25 ترکیب میکند و با یک reranker مبتنی بر cross-encoder دنبال میشود، خط پایه فعلی برای سیستمهای تولیدی است. جستجوی برداری خالص به تنهایی در پرسوجوهای حساس به دقت عملکرد پایینتری دارد. بازیابی مبتنی بر گراف برای حوزههایی با روابط ساختارمند بین موجودیتها در حال رشد است. و سوال حاکمیت منبع دانش، بهطور مشخص اینکه چه کسی مسئول تازگی chunkها، حذف موارد تکراری، و بررسی کیفیت است، یک تصمیم محصولی است که تیمهای مهندسی دائماً سعی میکنند آن را به تعویق بیندازند تا زمانی که دردسرساز شود.
عوامل و MCP: استانداردی که ماندگار شد
پروتکل زمینه مدل Anthropic، که در اواخر ۲۰۲۴ معرفی شد، به استاندارد غالب برای اتصال ابزارها به عوامل LLM تبدیل شده است. OpenAI آن را در مارس ۲۰۲۵ پذیرفت و متعاقباً deprecation API دستیاران را با برنامه توقف در اواسط ۲۰۲۶ اعلام کرد. این ترکیب اکوسیستم را مجبور به همگرایی کرد. Cursor، Cline، و اکثر محیطهای توسعه عاملی جدی اکنون انتظار سرورهای ابزار سازگار با MCP را دارند.
این از نظر عملیاتی اهمیت دارد. یک رابط ابزار استانداردشده به این معناست که میتوانید مدل زیرین را بدون بازنویسی اتصالدهندههای ابزارتان عوض کنید. همچنین به این معناست که سطح حمله برای تزریق prompt و سوءاستفاده از ابزار اکنون قابل پیشبینی و قابل ممیزی است. هیچکدام از این موارد هجده ماه پیش صادق نبود.
قابلیت مشاهده: دیگر اختیاری نیست
Langfuse در ژانویه ۲۰۲۶ توسط ClickHouse خریداری شد، و این خود نشانهای است از مسیری که بازار در پیش دارد: پایپلاینهای ردیابی به پایگاههای دادهای نیاز دارند که بتوانند حجم نوشتاری را که عوامل در محیط تولید تولید میکنند تحمل کنند. پلتفرمهای پیشرو در این حوزه عبارتند از LangSmith (گزینه طبیعی برای استکهای سنگین LangChain)، Langfuse (بهترین گزینه برای میزبانی شخصی)، و Arize Phoenix (قویترین گزینه برای جریانهای کاری بازیابی سنگین RAG).
آنچه APM سنتی قادر به پاسخگویی نیست: کدام مرحله بازیابی زمینه نامرتبط برگرداند، چرا یک عامل وارد یک حلقه بازگشتی شد، آیا کیفیت خروجی در طول نسخههای مختلف مدل از خط پایه منحرف میشود. این پرسشها به ردیابی بومی LLM نیاز دارند که درخواستها را از میان فراخوانیهای LLM، مراحل بازیابی، فراخوانیهای ابزار، و شاخههای تصمیمگیری عامل به صورت یکپارچه دنبال میکند، نه به صورت جداگانه.
توهمزایی: یک معیار، نه یک دوگانه
توهمزایی همچنان مهمترین مانع برای استقرار در محیطهای تولیدی پرخطر است. تحول مهم در سال ۲۰۲۶ این است که تیمها عمدتاً از رویکرد قبول/رد دوگانه دست برداشتهاند و شروع به اندازهگیری آن به صورت نرخ کردهاند. تشخیص به روش LLM-as-judge بسته به طراحی پرامپت، ۶۰ تا ۷۵ درصد از خروجیهای توهمی را شناسایی میکند. در وظایف مبتنی بر بازیابی، نرخها در سیستمهای خوبمهندسیشده به زیر ۲ درصد میرسند. گاردریلهای زمان اجرا که پیش از تحویل خروجیها را بررسی کرده و پاسخهای مشکوک را برای بررسی هدایت میکنند، به استاندارد تبدیل شدهاند، هرچند تأخیر تشخیص ۲۰۰ تا ۵۰۰ میلیثانیهای سربار واقعیای به بودجه تأخیر اضافه میکند.
توصیه عملی: از همان روز اول یک حلقه نمونهبرداری توهمزایی در پایپلاین ارزیابی خود بسازید. هر روز یک نمونه تصادفی از ردهای تولید زنده را امتیازدهی کنید. این کار به شما امکان میدهد انحراف مدل، شاخصهای بازیابی قدیمی، و رگرسیونهای پرامپت را پیش از آنکه کاربران گزارش دهند شناسایی کنید.
جایگاه این استک
مدل یک کالاست. موتور استنتاج، کیفیت بازیابی، پروتکل ابزار، لایه مشاهدهپذیری و انضباط هزینه در حجم فراخوانیهای عاملی، جایی هستند که اهرم مهندسی واقعی در سال ۲۰۲۶ زندگی میکند. تیمهایی که این موارد را فرعی میپندارند، به آتشنشانی مشغول خواهند ماند. تیمهایی که آنها را دغدغههای درجه اول میدانند، محصولات قابلاعتماد ارائه میدهند.
منابع
- بهترین موتورهای استنتاج LLM در ۲۰۲۶: vLLM، SGLang و TensorRT-LLM | Yotta Labs
- پشته تولید vLLM: استقرار خوشهای بومی K8S | GitHub
- بهینهسازی استنتاج LLM: راهنمای هزینه و تأخیر ۲۰۲۶ | Morph
- استنتاج LLM: پیشپردازش، رمزگشایی، حافظه پنهان KV و راهنمای هزینه ۲۰۲۶ | Morph
- بهترین شیوههای RAG: بازاندیشی مدیریت دانش برای هوش مصنوعی | Redwerk
- الگوهای معماری برای RAG مبتنی بر گراف | VentureBeat
- راهنمای جامع MCP در ۲۰۲۶: معماری و نقشه راه سازمانی | DEV Community
- بهترین ابزارهای مشاهدهپذیری LLM برای عاملهای هوش مصنوعی: Latitude در برابر Langfuse، LangSmith، Arize 2026 | Latitude
- مشاهدهپذیری عامل: LangSmith، Langfuse، Arize 2026 | Digital Applied
- بهترین ابزارهای تشخیص توهم برای برنامههای LLM در ۲۰۲۶ | Braintrust