«سرعت Native در جاوا»؛ دستاورد جدید libargus برای مدل‌های چندوجهی

تصور کنید یک محیط اجرای جاوا وجود داشته باشد که در آن خط لوله‌های پیچیده هوش مصنوعی با اثر صفر (Absolute Zero) روی Garbage Collection اجرا شوند. در ۱۴ ژوئیه ۲۰۲۶، کتابخانه libargus به عنوان یک محیط اجرای Native یکپارچه منتشر شد تا «مالیات عملکردی» که معمولاً ماشین مجازی جاوا (JVM) هنگام مدیریت تانسورهای حجیم می‌گیرد را به طور کامل حذف کند.

برای سال‌ها، بزرگ‌ترین مانع پیش روی هوش مصنوعی در زبان جاوا، پدیده‌ای به نام «دیوار حافظه» بود. جابه‌جایی آرایه‌های بزرگ از اعداد اعشاری (Floats) یا صحیح‌ها (Integers) بین Heap جاوا و کتابخانه‌های Native نوشته شده با C++ اغلب باعث توقف‌های عظیم برای پاک‌سازی حافظه (GC Pauses) و کپی‌برداری ناکارآمد حافظه می‌شد. libargus دقیقاً همین مشکل را با دور زدن کامل Heap برای استنتاج در مسیرهای حساس (Hot-path inference) حل می‌کند.

بسیاری از برنامه‌نویسان با تضاد میان امنیت زبان جاوا و سرعت زبان C++ آشنا هستند. برای پل زدن میان این دو، libargus از API حافظه و توابع خارجی پروژه پاناما (Project Panama Foreign Function & Memory API) که در JDK 22 معرفی شد، استفاده می‌کند. این قابلیت به محیط اجرا اجازه می‌دهد تا با حافظه Native مانند یک شهروند درجه‌یک برخورد کند؛ به این ترتیب با استفاده از MemorySegment توکن‌ها، موج‌های صوتی و فریم‌های ویدئویی را مدیریت می‌کند بدون اینکه حتی یک شیء جاوا در حلقه‌های حیاتی (Critical Loop) تخصیص یابد.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی لایه‌ی سخت‌افزاری مدل‌ها اشاره کردیم، حذف لایه‌های واسطه تنها راه رسیدن به تأخیر نزدیک به صفر است.

هسته معماری

به نقل از مستندات رسمی گیت‌هاب، libargus یک پوشش استنتاج فوق‌سبک، با عملکرد بالا و مستقل از مدل (Model-agnostic) است که بر روی موتورهای محاسباتی ماژولار GGML و llama.cpp (libmtmd) بنا شده است. این سیستم چهار حوزه اصلی هوش مصنوعی را در یک محیط اجرای Native سراسری در سطح پروسس تجمیع می‌کند:

• مدل‌های زبانی بزرگ (LLM): تولید متن با پشتیبانی از رمزگشایی گمانه‌زنانه (Speculative Drafting) و حلقه‌های تأیید پیش‌بینی چند-توکنی (MTP) مستقیماً در لایه‌ی اجرای C++.
• بازشناسی گفتار (ASR): ادغام مستقیم خط لوله‌های تبدیل گفتار به متن مبتنی بر Whisper از طریق کانتکست‌های اختصاصی مدل Whisper.
• تبدیل متن به گفتار (TTS): تولید صوتی با راندمان بالا که به‌طور یکپارچه در خط لوله مدیریت متن ادغام شده است.
• ارزیابی چندوجهی: پذیرش Native بیت‌مپ‌های خام، آرایه‌های PCM صوتی و جریان‌های ویدئویی با استفاده از موتور C++ مدل libmtmd.

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

برای جلوگیری از پراکندگی منابع (Resource Fragmentation)، این سیستم از یک «تکینگی بک‌اند سراسری در سطح پروسس» استفاده می‌کند. این بدان معناست که سیستم یک مسیر مقداردهی اولیه مشترک و واحد یعنی ggml_backend_load_all() را برای تمام زیرسیستم‌های متنی، صوتی و چندوجهی سازمان‌دهی می‌کند. این طراحی مانع از تکه‌تکه شدن VRAM می‌شود و از بروز شرایط رقابتی درایورها (Driver Race Conditions) در محیط‌های پیچیده هوش مصنوعی که دارای چندین کانتکست هستند، جلوگیری می‌کند.

جزئیات فنی و مکانیسم‌های حافظه

طبق اعلام توسعه‌دهندگان، libargus چندین مکانیسم سطح پایین را برای تضمین عملکرد قطعی (Deterministic Performance) و جریان داده بدون کپی (Zero-copy) پیاده کرده است:

• تفکیک وزن‌ها و اجرا: محیط اجرا، بارگذاری وزن‌های مدل (argus_model_t) را از حالت‌های حافظه بستر ارزیابی (argus_context_t) جدا می‌کند. این تفکیک اجازه می‌دهد یک مدل واحد در چندین نشست هم‌زمان بدون تکرار حافظه‌ی وزن‌ها در RAM استفاده شود.
• ترازنام‌یابی FFM با اشاره‌گر: برای حفظ مرزهای سخت حافظه، libargus مرزهای پلی‌مورفیسم متغیر C++ و ارسال با مقدار (Pass-by-value) را با توابع تخت C که صرفاً اشاره‌گر (Pointer) می‌پذیرند، جایگزین کرده است. پدینگ ساختارها به‌صورت دستی بسته‌بندی (Packed) شده تا از ایجاد شکاف‌های ترازنایی توسط کامپایلر که باعث شکست در نگاشت‌های جاوا-به-Native می‌شود، جلوگیری شود.
• کوانتش KV Cache: سیستم از enumهای type_k و type_v برای پشتیبانی از پیکربندی‌های Native استفاده می‌کند. این امر به کاربران اجازه می‌دهد اثر حافظه را به فرمت‌های Q8_0، Q4_0 یا سایر فرمت‌های بهینه منتقل کنند که به‌طور قابل توجهی VRAM مورد نیاز برای پنجره‌های زمینه (Context Window) طولانی را کاهش می‌دهد.
• قفل‌های هم‌زمانی انتخابی: امنیت حافظه از طریق هم‌گام‌سازی Mutex در سطح کانتکست مدیریت می‌شود. این امر رمزگشایی ایمن در محیط چندرشته‌ای را ممکن می‌کند در حالی که دسترسی به توکنایزر در مدل‌های Read-only کاملاً بدون قفل (Lock-free) و هم‌زمان است.
• بازرسی بدون تخصیص: API دسترسی‌های امن و غیرمدیریتی برای یافتن توکن‌های خاص واژگان مانند BOS (شروع جریان)، EOS (پایان جریان)، EOT (پایان نوبت) و PAD فراهم می‌کند. همچنین به توسعه‌دهندگان اجازه می‌دهد شرایط پایان تولید (EOG) را بررسی کرده و ورودی‌های دیکشنری GGUF را به‌صورت پویا شماره‌گذاری کنند.

توپولوژی کد و منطق ساخت

پروژه در یک سلسله‌مراتب سخت سازماندهی شده تا ایزولاسیون وابستگی‌ها تضمین شود. ریشه پروژه شامل ماتریس بهینه‌سازی CMakeLists.txt است. دایرکتوری include/ شامل فایل libargus.h است که چیدمان پایدار ABI سی را تعریف می‌کند. دایرکتوری src/ منطق را به فایل‌های تخصصی تقسیم کرده است: argus_internal.h (ساختارهای خصوصی مشترک)، argus_common.cc (ثبت‌های سخت‌افزاری و چرخه‌های حیات بک‌اند سراسری)، argus_text.cc (مدیریت Llama، TTS و حلقه‌های گمانه‌زنی)، argus_audio.cc (Whisper ASR) و argus_multimodal.cc (لودرهای رسانه‌ای و لوله‌های ویدئو).

برای ساخت محیط اجرا، libargus از FetchContent در سطح CMake استفاده می‌کند تا پیاده‌سازی‌های حجیم سرورهای بالادستی و اهداف قدیمی CLI را حذف کند. برای شتاب‌دهی سخت‌افزاری، این سیستم بر اساس ماتریس ساخت CMake برای شتاب‌دهنده CUDA طراحی شده است. توسعه‌دهندگان می‌توانند با دستور cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON گراف محاسباتی بهینه را تولید کرده و با دستور cmake --build build --config Release -j $(nproc) فایل باینری یکپارچه نهایی را کامپایل کنند.

خط لوله‌های ویدئو و چندوجهی

این محیط اجرا از موتور C++ مدل libmtmd برای مدیریت داده‌های غیرمتنی استفاده می‌کند. پرامپت‌ها و رسانه‌ها را به یک توالی تکه‌بندی شده (Chunk) واحد تبدیل کرده و شبکه‌های موقعیت M-RoPE و ماتریس‌های توجه غیرعلّی (Non-causal attention) را به‌طور خودکار روی GPU پیکرب 경기 می‌کند.

یکی از متمایزترین ویژگی‌ها، لوله تکرار ویدئو بدون مدیریت (Unmanaged Video Iteration Pipe) است. libargus فایل‌های ویدئویی را فریم‌به‌فریم با استفاده از لوله‌های داخلی FFmpeg رمزگشایی می‌کند. این فرآیند فریم‌های RGB خام یا تکه‌های متنی برچسب‌دار زمانی (مانند [12m34s]) را با نرخ فریم مشخص تولید می‌کند. این فریم‌ها مستقیماً به حافظه Native جریان می‌یابند و به برنامه‌های جاوا اجازه می‌دهند ویدئو را در زمان واقعی «ببینند» بدون اینکه باعث توقف JVM به دلیل Garbage Collection شوند.

تجربه توسعه‌دهنده در جاوا

اگرچه هسته با C++ نوشته شده، اما ماژول Binding جاوا، محاسبات پیچیده اشاره‌گرها و زمان‌بندی ماسک‌های توجه را نامرئی می‌کند. توسعه‌دهندگان از مدیران AutoCloseable برای وزن‌ها و کانتکست‌ها استفاده می‌کنند تا اطمینان حاصل شود حافظه Native فوراً و بدون تأخیر آزاد می‌شود.

برای مثال، یک مدل GGUF با قابلیت بینایی مانند Qwen2-VL-7B را می‌توان با ArgusMultimodalContext بارگذاری کرد. لایه جاوا مسیر آداپتور .mmproj را ارسال می‌کند و کتابخانه عملیات تصویر کردن (Projection) بیت‌مپ‌های تصویر روی GPU را مدیریت می‌کند. این جریان شامل بارگذاری یک ArgusBitmap، توکن‌بندی رشته پرامپت با یک نشانگر رسانه (مانند <__media__>) و اجرای evalMultimodalChunks برای تعیین موقعیت جدید (newNPast) است.

سلسله‌مراتب API جاوا به این صورت است:

• ArgusBackend: مدیریت تله‌متری دستگاه و مقداردهی اولیه از طریق متدهای ArgusBackend.init() و ArgusBackend.free().
• ArgusModel: یک مدیر AutoCloseable برای وزن‌های GGUF بدون مدیریت (unmanaged) که متدهایی مثل vocabBos()، vocabEos() و vocabNTokens() را فراهم می‌کند.
• ArgusContext: نشست اصلی برای ارزیابی متن که از ArgusContextConfig برای تنظیم پارامترهایی مثل cpuThreads و انواع KV cache استفاده می‌کند.
• ArgusVideo & ArgusVideoItem: یک تکرارکننده فریم و ظرف قابل استفاده مجدد برای پردازش متوالی ویدئو جهت اجتناب از تخصیص Heap در هر فریم.
• ArgusBitmap: فراهم‌کننده بافرهای خام پیکسل RGB پارس شده یا نمونه‌های PCM صوتی.
• ArgusInputChunks: ظرفی برای تکه‌های پرامپت چندوجهی توکن‌بندی شده.
• ArgusLayouts: تعریف دقیق نگاشت‌های ساختاری (Struct Layout) از C به جاوا در پاناما.

متد مهندسی «کامپایل‌شده با هوش مصنوعی»

libargus با یک متدولوژی ترکیبی انسان-هوش مصنوعی در یک اسپرینت مداوم به نسخه پایدار رسید. برای دستیابی به این سرعت بدون به خطر انداختن امنیت حافظه، تفکیک دقیقی در اجرا اعمال شد:

هسته انسانی تمام معماری و طراحی سیستم‌ها را هدایت کرد. هر سمانتیک حیاتی حافظه، محدودیت‌های سطح پایین و مرزهای بهینه‌سازی سخت‌افزاری — شامل چرخه‌های زیست Arena.ofConfined خارج از Heap، بسته‌بندی دستی تراز ساختارها و ماتریس هدایت لوگیت‌های درهم‌تنیده با پیچیدگی $O(1)$ (argus_logit_bias_t) — صراحتاً توسط مهندسان انسانی طراحی شد. این امر کنترل کامل معماری بر بازیافت دارایی‌های تغییرپذیر خارج از Heap، مانند موارد استفاده شده در ArgusVideoItem را تضمین می‌کند.

هسته هوش مصنوعی به عنوان یک کامپایلر سینتکسی سریع عمل کرد. مدل‌های زبانی صرفاً برای تولید کدهای تکراری (Boilerplate) استفاده شدند؛ مواردی مانند Bindingهای Downcall غیرمدیریتی در ArgusBindings.java، الگوهای Parameter Builder و رشته‌های طولانی نگاشت ساختاری جاوا در ArgusLayouts.java. این رویکرد با هوش مصنوعی به عنوان یک کامپایلر متن پیشرفته برخورد می‌کند تا تحویل کدهای سیستم که با سخت‌افزار سازگار (Mechanically Sympathetic) هستند را بدون تولیدات هدایت‌نشده تسریع کند.

بردارهای معنایی و تنظیمات

libargus همچنین از استخراج بردار معنایی (Semantic Embedding) از مدل‌های تخصصی نظیر jina-embeddings-v3 پشتیبانی می‌کند. با فعال کردن پرچم .embeddings(true) در ArgusContextConfig، کاربران می‌توانند decodeBatch را اجرا کرده و سپس با فراخوانی getEmbeddings بردارهای اعشاری با ابعاد بالا (مثلاً ۱۰۲۴ بُعد) را مستقیماً در یک MemorySegment با استفاده از ValueLayout.JAVA_FLOAT دریافت کنند.

توسعه‌دهندگان همچنین می‌توانند ابعاد معماری عمیق مدل شامل nEmbd (اندازه بردار)، nCtxTrain (سقف زمینه آموزش)، nLayer (لایه‌های ترنسفورمر)، nHead (تعداد سرهای توجه) و nParams (تعداد کل پارامترها) را بازرسی کنند. متادیتاها از طریق getMetadataValue برای کلیدهایی مانند general.architecture (مثلاً qwen2vl) یا general.name (مثلاً Qwen2 VL 2B Instruct) در دسترس هستند.

در نهایت، این کتابخانه مکانیزمی برای نمونه‌برداری Logit Bias بدون تخصیص حافظه فراهم می‌کند. با تخصیص یک قطعه Bias با استفاده از ArgusLayouts.LOGIT_BIAS در ابتدای نشست، توسعه‌دهندگان می‌توانند تولید را هدایت کنند؛ مثلاً با ممنوع کردن توکن‌های خاص (مانند تگ‌های <__think__> در مدل‌های استدلالی با استفاده از -Float.MAX_VALUE) یا تقویت برخی توکن‌های دیگر. این فراخوانی sampleTokenWithBias در مسیر حساس اجرا (Hot-path) رخ می‌دهد بدون اینکه هیچ شیء جدیدی در جاوا ایجاد شود.

نقشه راه و زیرساخت

libargus صرفاً به عنوان «لایه صفر» (پایه اجرای هسته) برای پلتفرم‌های JVM با تأخیر پایین مهندسی شده است. این موتور زیرساخت با توان عملیاتی بالا را برای سازمان‌دهی تانسورهای Native بدون تخصیص حافظه فراهم می‌کند. این موتور به عنوان زیرساختی برای یک پلتفرم شناختی گسترده‌تر عمل می‌کند که در نهایت با هسته شناختی وضعیت‌مند آینده به نام L-TABB و یک داشبورد سیستمی یکپارچه (مطابق با جزئیات ProjectArgus.cc) متصل خواهد شد. برای سازمان‌های بزرگی که نیاز به مدیریت متمرکز این مدل‌ها دارند، گذار به سیستم‌های مدیریت‌شده‌ای مانند Bifrost برای جایگزینی LiteLLM می‌تواند مکمل مناسبی برای لایه‌ی اجرای Native باشد.

این نرم‌افزار تحت مجوز MIT منتشر شده و از توابع تانسوری مشتق شده از llama.cpp (شامل libmtmd) و whisper.cpp بهره می‌برد. کاربران می‌توانند انطباق سیستم را با اجرای تست‌های واحد C از طریق ./build/test_libargus یا تست‌های یکپارچه‌سازی FFM پاناما در Gradle از طریق دستور gradle test در دایرکتوری bindings/java بررسی کنند.

گام بعدی شما

• اگر از JDK 22 یا نسخه‌های جدیدتر استفاده می‌کنید، API پاناما را برای مدیریت حافظه خارج از Heap فعال کنید.
• برای مدل‌های چندوجهی، ساختار ArgusVideoItem را جایگزین لودرهای سنتی کنید تا فشار روی GC را کاهش دهید.
• در مدل‌های استدلالی، از sampleTokenWithBias برای کنترل دقیق‌تر خروجی و حذف توکن‌های ناخواسته استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.