اینفرنس به شیوه !Hogwild: موازی‌سازی مدل‌های زبانی با حافظه کش مشترک

زنجیره‌های استدلال در مدل‌های استدلالی مدرن مانند DeepSeek-R1 یا QwQ معمولاً به هزاران توکن می‌رسند. در این حجم از تولید متن، پردازش ترتیبی و کند مدل‌های زبانی بزرگ، ساخت نرم‌افزارهای بلادرنگ و کاربردی را به‌شدت چالش‌برانگیز می‌کند. حتی با راهکارهایی نظیر دیکودینگ حدسی (Speculative Decoding) هم به‌دلیل ماهیت خودبازگشتی مدل‌ها، سقف مشخصی برای شتاب‌بخشی وجود دارد.

رویکرد !Hogwild این بن‌بست را با یک معماری نامتعارف می‌شکند: اجرای موازی چند نسخه از مدل یکسان روی یک کش کلید-مقدار (KV cache) مشترک. در این ساختار، مدل‌های مجهز به قابلیت استدلال بدون هیچ‌گونه فاین‌تیونینگ اختصاصی، پیشرفت کارهای انجام‌شده را در حافظه مشترک می‌بینند و وظایف را به‌طور خودجوش میان خود تقسیم می‌کنند.

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

دیکودینگ حدسی (Speculative Decoding) (فاز 10 · 15) توکن‌ها را درون یک توالی موازی می‌کند. فریم‌ورک‌های چندایجنت (multi-agent) در سراسر توالی‌های کامل موازی‌سازی انجام می‌دهند، اما هماهنگی صریح (رأی‌گیری، شکستن وظیفه به زیرمسئله‌ها) را تحمیل می‌کنند. اینفرنس !Hogwild (رودیونوف و همکاران، arXiv:2504.06261) مسیر متفاوتی می‌رود: اجرای هم‌زمان N نمونه از یک مدل زبانی یکسان روی یک کش کلید-مقدار (KV cache) مشترک. هر پردازشگر (worker) توکن‌های تولیدشده‌ی سایر پردازشگرها را در همان لحظه می‌بیند. مدل‌های استدلالی مدرن — مانند QwQ و DeepSeek-R1 — می‌توانند از طریق این کش مشترک و بدون هیچ فاین‌تیونینگی خودشان هماهنگ شوند. این روش آزمایشی است، اما محور کاملاً تازه‌ای در موازی‌سازی اینفرنس باز می‌کند که کاملاً مستقل و عمود بر دیکودینگ حدسی می‌نشیند. این درس یک شبیه‌ساز دوپردازشگری !Hogwild را با کتابخانه‌ی استاندارد Python پیاده‌سازی می‌کند و نشان می‌دهد چرا همکاری مبتنی بر کش مشترک، به‌طور خودجوش از توانایی‌های استدلالی خود مدل سرچشمه می‌گیرد.

اهداف یادگیری

• تشریح سه توپولوژی رایج مدل‌های زبانی موازی (رأی‌گیری، زیرمسئله، !Hogwild) و نام بردن مسائلی که هرکدام هدف می‌گیرند.
• بیان ساختار اصلی !Hogwild: چند پردازشگر، یک کش کلید-مقدار مشترک، و هماهنگی خودجوش از طریق پرامپت‌نویسی درونی (self-prompting).
• محاسبه‌ی شتاب‌بخشی زمان واقعی (wall-time speedup) در !Hogwild برحسب تعداد پردازشگرها N، میزان موازی‌پذیری در سطح مسئله p، و سربار محاسباتی هماهنگی c.
• پیاده‌سازی یک شبیه‌ساز دوپردازشگری !Hogwild روی یک مسئله‌ی ساده و مشاهده‌ی تقسیم خودجوش وظایف بین آن‌ها.

صورت مسئله

مدل‌های زبانی مدرن مسائل سخت را با تولید زنجیره‌های استدلال طولانی حل می‌کنند — تولید 5000 توکن منطق گام‌به‌گام امری عادی است و در مسائل عمیق ریاضی به ده‌ها هزار توکن هم می‌رسد. با سرعت دیکود 35 توکن بر ثانیه روی یک مدل 70B، تولید 50 هزار توکن 24 دقیقه طول می‌کشد. چنین مدلی اصلاً به درد تعامل زنده نمی‌خورد.

دیکودینگ حدسی (فاز 10 · 15) با موازی‌سازی درون یک توالی واحد، شتابی بین 3 تا 5 برابری به دست می‌دهد. فراتر از آن، وابستگی ترتیبی دیکود خودبازگشتی (autoregressive) مانند سقفی صلب جلوی پیشرفت را می‌گیرد؛ چرا که هر توکن جدید به تمام توکن‌های پیشین وابسته است.

سؤال واضح این است: آیا می‌توانیم بین چند توالی مختلف موازی‌سازی کنیم؟ چند نسخه از یک مدل را روی یک مسئله بنشانیم تا با هم همکاری کنند و کار را بین خودشان تقسیم کنند؟

کارهای گذشته: گروه‌های رأی‌گیری یا انسمبل (اجرای N مدل و انتخاب پاسخ اکثریت)، درخت افکار یا Tree-of-Thought (شاخه‌زنی در مسیرهای استدلال و ترکیب دوباره‌ی آن‌ها)، و فریم‌ورک‌های چندایجنت (اختصاص یک زیرمسئله به هر ایجنت با کمک یک هماهنگ‌کننده). این روش‌ها همگی در حوزه‌های خاصی از مسائل کارایی دارند؛ اما همگی سازوکارهای هماهنگی صریحی هم به دوش سیستم می‌گذارند — قواعد رأی‌گیری، منطق شاخه‌زنی و هرس، و پروتکل‌های پیام‌رسانی بین ایجنت‌ها.

اینفرنس !Hogwild رویکرد متفاوتی در پیش می‌گیرد. در اینجا N پردازشگر در یک کش کلید-مقدار مشترک سهیم می‌شوند. هر پردازشگر توکن‌های تولیدشده‌ی سایر پردازشگرها را بلافاصله می‌بیند؛ درست مثل اینکه بخشی از زمینه‌ی خود او باشند. پردازشگرها — بدون ذره‌ای آموزش یا فاین‌تیونینگ — خودشان می‌فهمند چطور کار را تقسیم کنند. مدل‌های استدلالی مدرن (QwQ، DeepSeek-R1، حالت استدلالی خانواده‌ی Claude) می‌توانند کش مشترک را بخوانند و بگویند: «می‌بینم پردازشگر 2 قبلاً حالت پایه را حل کرده، پس من سراغ گام استقرا می‌روم.»

میزان این شتاب‌بخشی وابسته به بار کاری است و تا آوریل 2026 هنوز در مرحله‌ی آزمایشی قرار دارد. اما دانستن این ایده بسیار باارزش است، چون محور کاملاً جدیدی در موازی‌سازی اینفرنس باز می‌کند.

مفهوم اصلی

ساختار پیاده‌سازی

ابتدا N پروسه‌ی پردازشگر را راه‌اندازی کنید که همگی یک مدل زبانی یکسان را اجرا می‌کنند. به‌جای ساخت کش‌های کلید-مقدار جداگانه برای هر پردازشگر، فقط یک کش مشترک نگه دارید. وقتی پردازشگر i توکن t_j را تولید می‌کند، این توکن در موقعیت بعدی در کش مشترک نوشته می‌شود. هنگامی که پردازشگر k گام بعدی‌اش را برمی‌دارد، وضعیت فعلی کش را می‌خواند (که شامل همه‌ی توکن‌هایی است که تمام N پردازشگر تا همان لحظه تولید کرده‌اند).

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

چرا هماهنگی شکل می‌گیرد؟

پردازشگرها یک پرامپت مشترک دارند؛ متنی شبیه به این: «شما یکی از N نمونه‌ای هستید که در کنار هم روی این مسئله کار می‌کنید. هر نمونه حافظه‌ی مشترک را می‌خواند و می‌تواند نوشته‌های سایر نمونه‌ها را ببیند. از دوباره‌کاری بپرهیزید.» همین پرامپت در کنار کش مشترک کفایت می‌کند. مدل‌های استدلالی کش را می‌خوانند، متوجه می‌شوند کدام بخش‌های مسئله قبلاً بررسی شده، و (غالباً، گرچه نه همیشه) مسیرشان را به سمت بخش‌های دست‌نخورده کج می‌کنند.

مقاله‌ی !Hogwild (رودیونوف و همکاران، 2025) چنین مشاهداتی را گزارش می‌کند:

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

هیچ‌کدام از این‌ها نیازی به فاین‌تیونینگ ندارد. این رفتار خودجوش مستقیماً از قابلیت‌های استدلالیِ نهفته در خود مدل سرچشمه می‌گیرد.

ریشه‌ی نام‌گذاری

نام این مقاله از !Hogwild! SGD (رشت و همکاران، 2011) وام گرفته شده است؛ روشی برای بهینه‌سازی با به‌روزرسانی ناهم‌گام. شباهت اینجاست: در SGD، پردازشگرهای ناهم‌گام همگی روی یک بردار پارامتر مشترک می‌نویسند؛ در اینفرنس !Hogwild هم پردازشگرها همگی روی یک کش کلید-مقدار مشترک می‌نویسند. هر دو روش به‌جای ارائه‌ی تضمین‌های سفت‌وسخت برای همگام‌سازی، به همگرایی تجربی تکیه دارند.

نقش RoPE در عملی شدن ایده

امبدینگ‌های موقعیت چرخشی (RoPE، سو و همکاران 2021) اطلاعات موقعیت را از طریق چرخش در بردارهای پرسش (Q) و کلید (K) کدگذاری می‌کنند. از آنجا که امتیاز اتنشن بین یک کوئری چرخیده و یک کلید چرخیده صرفاً به فاصله‌ی نسبی آن‌ها بستگی دارد، یک بلوک کامل از داده‌های کش‌شده می‌تواند بدون محاسبه‌ی مجدد به یک آفست جدید جابه‌جا شود: کافی است کوئری را بچرخانید، نه اینکه تک‌تک کلیدهای کش‌شده را از نو بچرخانید. اینفرنس !Hogwild این کار را یک بار به ازای هر بلوک کش انجام می‌دهد: برای کوئری در موقعیت i_q و بلوکی که از دید آن پردازشگر در i_k شروع می‌شود، کوئری به اندازه‌ی فاصله‌ی نسبی i_q - i_k چرخانده می‌شود. پردازشگرها به همین شیوه بلوک‌های کش مشترک را با ترتیب اختصاصی خودشان می‌بینند. این ترفند برای جابه‌جایی یکنواختِ یک بلوک پیوسته در حافظه جواب می‌دهد. اگر بخواهید توکن‌های تکی را به موقعیت‌های متفاوتی جابه‌جا کنید، چرخش آن‌ها عوض می‌شود و همچنان به محاسبه‌ی مجدد نیاز خواهد بود.

در مدلی با موقعیت‌های یادگرفتنی یا موقعیت مطلق، !Hogwild در هر بار نوشتن هم‌زمان ناچار به ابطال کش (cache invalidation) می‌شد. اما RoPE کاری می‌کند که کش پایدار بماند.

فرمول‌های زمان واقعی

فرض کنید T_serial زمان لازم برای حل مسئله توسط یک پردازشگر به تنهایی باشد. p را کسر موازی‌پذیر در سطح مسئله و c را سربار محاسباتی هماهنگی در هر گام (خواندن کشِ طولانی‌تر و تصمیم‌گیری درباره‌ی اینکه چه چیزی نوشته شود) در نظر بگیرید.

زمان برای یک پردازشگر: T_serial. زمان !Hogwild با N پردازشگر، در صورتی که هماهنگی هزینه‌ای نداشته باشد: T_serial * ((1 - p) + p / N). همان قانون کلاسیک آمدال. با احتساب سربار هماهنگی: T_serial * ((1 - p) + p / N) + c * steps_per_worker.

برای اینکه کارایی پردازشگر حفظ شود، مقدار c باید در مقایسه با زمان دیکود در هر گام ناچیز باشد. در مدل‌های استدلالی که بیش از 5 هزار توکن تولید می‌کنند، پردازشگرها می‌توانند صدها توکن سربار هماهنگی را تاب بیاورند و باز هم در مجموع جلو بیفتند. اما در مکالمات کوتاه چت، هزینه‌ی هماهنگی دست بالا را می‌گیرد و عملکرد !Hogwild از اجرای ترتیبی بدتر می‌شود.

یک مثال ملموس

یک مسئله‌ی استدلالی را در نظر بگیرید: 10 هزار توکن زنجیره‌ی افکار (chain-of-thought). فرض کنید مسئله شامل p = 0.7 محتوای موازی‌پذیر باشد (راهبردهای مختلف اثبات، تحلیل حالت‌های گوناگون) و c = 200 توکن سربار هماهنگی به ازای هر پردازشگر داشته باشیم. با N = 4 پردازشگر:

• زمان ترتیبی: 10000 گام دیکود.
• زمان !Hogwild برابر است با: 10000 * (0.3 + 0.7 / 4) + 200 * 4 = 10000 * 0.475 + 800 = 5550 گام دیکود.
• شتاب حاصل: 10000 / 5550 = 1.8x.

این بهبودی چشمگیر نیست؛ اما در مسائل استدلالی طولانی‌تر (50 هزار توکن)، سربار هماهنگی سرشکن می‌شود و شتاب به مرز 2.5 تا 3 برابر می‌رسد. !Hogwild در دنیای اینفرنس معادلِ موازی‌سازی در سطح نخ‌ها (thread-level parallelism) در زبانی است که امکان نوشتن کدهای چندنخی را به‌شکلی کاملاً طبیعی به شما می‌دهد.

چه زمانی باید به سراغ !Hogwild رفت؟

• مسائل استدلالی طولانی (چند هزار توکن) که وظیفه قابلیت شکستن به زیرهدف‌های مستقل را دارد.
• مدل‌های استدلالی که برای تفکر گام‌به‌گام تعلیم دیده‌اند. مدل‌های غیر استدلالی هماهنگی خودجوش خوبی از خود نشان نمی‌دهند.
• استقرار روی یک سرور واحد (single-node) با حافظه‌ی گرافیکی کافی برای نگهداری کش مشترک به‌علاوه‌ی N پروسه‌ی پردازشگر. هرچند کش به اشتراک گذاشته می‌شود، اما هر پردازشگر حافظه‌ی اکتیویشن اختصاصی خودش را مصرف می‌کند.

چه زمانی نباید رفت؟

• مکالمات چت تعاملی کوتاه؛ چرا که سربار هماهنگی غلبه پیدا می‌کند.
• کارهایی که موازی‌پذیر نیستند (یک اثبات خطی واحد، کامپایل یکپارچه). در اینجا سقف کارایی همان N=1 است.
• مدل‌های غیر استدلالی؛ چون هیچ هماهنگی خودجوشی در آن‌ها شکل نمی‌گیرد.
• سیستم‌های توزیع‌شده روی چند نود. کش مشترک به همگام‌سازی بسیار سریع بین پردازشگرها نیاز دارد. ارتباط درون یک سرور عالی است؛ اما برقراری آن بین چند سرور مجزا فاجعه‌ای از نظر تاخیر به بار می‌آورد.

وضعیت فعلی و آزمایشی

تا آوریل 2026، روش !Hogwild یک رویکرد پژوهشی به حساب می‌آید که پیاده‌سازی متن‌بازی در PyTorch دارد، اما هنوز به استفاده در پروداکشن نرسیده است. سه مانع اصلی پیش رو داریم:

1. مدیریت کش کلید-مقدار مشترک بین پروسه‌های هم‌روند از نظر مهندسی بسیار دشوار است.
2. هماهنگی خودجوش کاملاً وابسته به وظیفه است؛ بنچ‌مارک‌های آن نیز همچنان در دست ساخت هستند.
3. شتاب حاصل در مقایسه با دستاوردهای فعلی دیکودینگ حدسی چندان زیاد نیست؛ هرچند ترکیب این دو ممکن است، اما لایه‌ی مهندسی مضاعفی می‌طلبد.

ارزش یادگیری دارد. ارزش آزمایش هم دارد. اما هنوز برای آنکه آینده‌ی یک محصول را به آن گره بزنید زود است.

پیاده‌سازی

فایل code/main.py یک شبیه‌ساز ساده از !Hogwild را پیاده‌سازی می‌کند:

• دو پروسه‌ی پردازشگر، که هر کدام یک «مدل زبانی» قطعی هستند و دسته‌های مشخصی از توکن‌ها (توکنِ کار، توکنِ مشاهده، توکنِ هماهنگی) را با احتمالات معین تولید می‌کنند.
• یک کش مشترک (صرفاً لیستی از توکن‌ها) که هر دو پردازشگر از آن می‌خوانند و در آن می‌نویسند.
• یک منطق هماهنگی ساده: وقتی پردازشگری می‌بیند که دیگری به اندازه‌ی کافی توکنِ کار در یک دسته تولید کرده، به سراغ دسته‌ی دیگری می‌رود.

این شبیه‌ساز با سقف گام‌های ثابت اجرا می‌شود و این نتایج را گزارش می‌دهد:

• مجموع توکن‌های کار تولیدشده.
• کل زمان واقعی (تعداد گام‌های پردازشگر).
• شتاب مؤثر در مقایسه با یک پردازشگر تنها.
• ردگیری دقیق اینکه کدام پردازشگر کدام توکن را نوشته است.

گام 1: کش مشترک

لیستی که هر دو پردازشگر داده‌ها را به انتهای آن اضافه می‌کنند. در پیاده‌سازی واقعی از قفل‌گذاری ساده (threading.Lock در Python) استفاده می‌شود؛ ما اینجا با یک شمارنده آن را شبیه‌سازی می‌کنیم.

گام 2: حلقه‌ی پردازشگر

هر پردازشگر در هر گام این مراحل را طی می‌کند:

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

گام 3: هیوریستیک هماهنگی

اگر دسته‌ی X در حال حاضر K توکن در کش داشته باشد و پردازشگر هم قصد نوشتن دسته‌ی X را داشته باشد، دسته‌اش را به Y تغییر می‌دهد. این یک ماکت ساده برای رفتار مدل استدلالی است که «می‌بیند این بخش قبلاً پوشش داده شده، پس سراغ کار دیگری می‌رود.»

گام 4: سنجش شتاب

شبیه‌ساز را یک بار با N=1 پردازشگر و بار دیگر با N=2 پردازشگر، با سقف گام‌های کاملاً یکسان اجرا کنید. تعداد توکن‌های کار تولیدشده را بشمارید. به دلیل تقسیم کاری که از هماهنگی ناشی شده، حالت N=2 باید تقریباً بین 1.5 تا 1.8 برابر توکن کار بیشتری بسازد.

گام 5: سنجش هماهنگی زیر فشار

حساسیت هیوریستیک هماهنگی را کاهش دهید. شبیه‌ساز را دوباره اجرا کنید. خواهید دید که بدون هماهنگی مناسب، دو پردازشگر دست به تولید توکن‌های تکراری می‌زنند و شتاب به زیر 1 سقوط می‌کند. این موضوع با یافته‌های مقاله کاملاً هم‌خوانی دارد: این ترفند فقط زمانی جواب می‌دهد که پردازشگرها ظرفیت استدلالی لازم برای هماهنگ کردن خودشان را داشته باشند.

کاربرد عملی

استفاده از !Hogwild در محیط‌های عملیاتی تا آوریل 2026 در فاز پژوهشی است. پیاده‌سازی مرجع تهیه‌شده توسط Yandex/HSE/IST با PyTorch نوشته شده و سناریوهای چندپروسه‌ای روی یک سرور واحد را برای مدل‌های DeepSeek-R1 و QwQ هدف گرفته است.

مسیر واقع‌بینانه‌ی پیاده‌سازی:

1. بار کاری وظایف استدلالی خود را پروفایل کنید. نسبت توکن‌های اکتشافی (راهبردهای چندگانه، تحلیل حالت‌ها، جست‌وجو) را به بخش‌های خطی بسنجید.
2. اگر ماهیت کار بیشتر اکتشافی است، آزمایشی دوپردازشگری با !Hogwild اجرا کنید و بهبود زمان واقعی را اندازه بگیرید.
3. اگر بهبود کمتر از 1.3 برابر بود، هزینه‌ی هماهنگی دارد به کل کار غلبه می‌کند؛ کار را به همان حالت تک‌پردازشگری برگردانید.
4. اگر بهبود بیش از 1.5 برابر شد، به سراغ N=4 بروید و مجدداً اندازه بگیرید. بازده نزولی معمولاً حوالی N=4 تا 8 رخ نشان می‌دهد.

ترکیب با دیکودینگ حدسی: هر پردازشگر !Hogwild می‌تواند مستقلاً از دیکودینگ حدسی هم استفاده کند. این دو شتاب تقریباً در هم ضرب می‌شوند؛ یعنی ترکیب یک دیکودینگ حدسی با ضریب 3 و یک !Hogwild با ضریب 1.8، شتاب مؤثر را نسبت به دیکود ساده‌ی تک‌پردازشگری به حدود 5.4 برابر می‌رساند.

تحویل نهایی

خروجی این درس فایل outputs/skill-parallel-inference-router.md است. این مسیریاب (Router) بر اساس پروفایل بار کاری استدلال (سقف توکن، پروفایل موازی‌پذیری مسئله، خانواده‌ی مدل، بستر استقرار هدف)، مسیر بهینه را بین استراتژی‌های رأی‌گیری، درخت افکار، چندایجنت، !Hogwild، و دیکودینگ حدسی انتخاب می‌کند.

تمرین‌ها

1. فایل code/main.py را با مقادیر پیش‌فرض اجرا کنید. بررسی کنید که آیا پیکربندی !Hogwild با N=2، در همان زمان واقعی، توکن‌های کار بیشتری در مقایسه با خط مبنای N=1 تولید می‌کند یا خیر.

2. قدرت هیوریستیک هماهنگی را کم کنید (مقدار coordination_weight=0.1 را قرار دهید). برنامه را دوباره اجرا کنید. نشان دهید که شتاب چگونه از دست می‌رود و دلیل آن را تحلیل کنید: پردازشگرها وقتی نتوانند با هم هماهنگ شوند، دست به دوباره‌کاری می‌زنند.

3. شتاب مورد انتظار !Hogwild را برای یک مسئله‌ی استدلالی 50 هزار توکنی با مقادیر p=0.8, c=500 و N=4 پردازشگر به دست آورید. همین محاسبه را برای یک گفت‌وگوی چت 1000 توکنی با p=0.3, c=200 و N=4 تکرار کنید. چرا اولی بازدهی دارد و دومی ضرر می‌زند؟

4. بخش 4 مقاله‌ی !Hogwild (ارزیابی اولیه) را مطالعه کنید. دو حالت شکست (failure modes) گزارش‌شده توسط نویسندگان را استخراج کنید. شرح دهید که یک پرامپت هماهنگی دقیق‌تر چگونه می‌تواند هرکدام از این دو حالت را کاهش دهد.

5. روش !Hogwild را با دیکودینگ حدسی در این شبیه‌ساز ساده ترکیب کنید: هر پردازشگر درون خودش یک دیکودینگ حدسی 2 توکنی پیاده کند. شتاب ضرب‌شده را گزارش کنید. اگر هر دو پردازشگر هم‌زمان بخواهند یک پیشوند کش مشترک یکسان را توسعه دهند، چه چالشی در ثبت و ردیابی وضعیت به وجود می‌آید؟

واژگان کلیدی

مطالعه‌ی بیشتر

• Rodionov et al. — Hogwild! Inference: Parallel LLM Generation via Concurrent Attention (arXiv:2504.06261) — مقاله‌ی اصلی !Hogwild، ارزیابی اولیه روی مدل‌های QwQ و DeepSeek-R1
• Recht, Re, Wright, Niu — Hogwild!: A Lock-Free Approach to Parallelizing Stochastic Gradient Descent (arXiv:1106.5730, NeurIPS 2011) — مقاله‌ی اصلی !Hogwild در SGD که منبع نام‌گذاری این روش است
• Su et al. — RoFormer: Enhanced Transformer with Rotary Position Embedding (arXiv:2104.09864) — مقاله‌ی RoPE و خاصیتی که اینفرنس بر بستر کش مشترک را عملیاتی می‌کند
• Yao et al. — Tree of Thoughts: Deliberate Problem Solving with Large Language Models (arXiv:2305.10601) — راهبرد استدلالی درخت افکار که رویکرد !Hogwild عمود بر آن قرار می‌گیرد
• Leviathan et al. — Fast Inference from Transformers via Speculative Decoding (arXiv:2211.17192) — دیکودینگ حدسی، راهکار موازی‌سازی درون‌توالی که با !Hogwild تجمیع می‌شود
• پیاده‌سازی مرجع PyTorch برای !Hogwild — مرجع اصلی پیاده‌سازی آزمایش‌های مقاله