تصور کنید بتوانید سخت‌افزار گرافیکی مرورگر خود را دقیقاً همان‌طور که یک مهندس متخصص انویدیا برنامه‌نویسی می‌کند، بهینه کنید. در ۳۰ ژوئیه ۲۰۲۶، توسعه‌دهنده‌ای به نام phulin ثابت کرد که کد تولیدشده توسط هوش مصنوعی می‌تواند در وظایف محاسباتی خاص، از کتابخانه‌های استاندارد و عمومی پیشی بگیرد. او برای ساخت یک حل‌کننده پوکر مبتنی بر مرورگر، تمام کتابخانه‌های سنتی را کنار گذاشت و به‌جای آن‌ها از کرنل‌های اختصاصی WebGPU (WebGPU Kernels) استفاده کرد که توسط عامل‌های هوشمند (AI Agents) طراحی شده بودند.
برای سال‌ها، صنعت نرم‌افزار به کتابخانه‌هایی مثل PyTorch یا TensorFlow تکیه می‌کرد تا هزینه بالای نوشتن کدهای سریع، دقیق و با معماری درست را برای هزاران کاربر تقسیم کند. این رویکرد باعث ایجاد یک «جریمه عمومی» (Generality Penalty) می‌شد؛ یعنی لایه‌های اضافی انتزاع که سرعت اجرا را کاهش می‌دهند. در محیط مرورگر، این مشکل شدیدتر است؛ زیرا در حالی که WebGL و WebGPU قدرت سخت‌افزاری خام را فراهم می‌کنند، معادل دقیقی برای یک کتابخانه تنسورِ عمومی مثل PyTorch که به‌طور مؤثر برای وب فعال باشد، وجود ندارد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی سخت‌افزاری در لبه (Edge) اشاره کردیم، حذف لایه‌های واسط همواره کلید دستیابی به حداکثر توان عملیاتی است.
phulin اشاره کرد که اگرچه TensorFlowJS (TFJS) وجود دارد، اما عملاً رها شده است. طبق گزارش او، در مراحل تست، TFJS بسیار کند بود و بسیاری از عملیات‌های ابتدایی (Primitive Operations) مورد نیاز برای مدل پوکر را پشتیبانی نمی‌کرد. این یعنی او مدل‌های خود را ماه‌ها در PyTorch ساخته و تست کرده بود، اما راهی برای اجرای بهینه آن خروجی نهایی در مرورگر بدون یک راهکار اختصاصی نداشت.
او برای حل این معضل از Codex استفاده کرد تا PyTorch را به‌عنوان یک «اوراکل صحت» (Correctness Oracle) به کار بگیرد. از آنجایی که PyTorch یک پیاده‌سازی مرجع و قابل اعتماد فراهم می‌کرد، هدف صرفاً این بود که کدی تولید شود که همان خروجی را با سرعتی بسیار بیشتر در WebGPU ارائه دهد. این فرآیند شامل دستور دادن به هوش مصنوعی بود تا کرنل‌های WebGPU را به‌گونه‌ای بسازد که دقیقاً با خروجی PyTorch مطابقت داشته باشند.
بر اساس مستندات phulin.me، نتایج به‌دست‌آمده فوری و چشمگیر بود:
- تطابق کامل: کرنل‌ها تنها با یک پرامپت (Prompt)، تست‌های تطبیق با مرجع PyTorch را پاس کردند.
- جهش سرعت: با اجرای هوش مصنوعی در یک حلقه بهینه‌سازی شبانه‌روزی، عامل هوشمند توانست به سرعت ۱۰ برابری نسبت به اولین پیاده‌سازی ساده و ابتدایی خود برسد.
- بهینه‌سازی خودکار: هوش مصنوعی به‌طور خودکار تشخیص داد که برای حداکثر کردن عملکرد سخت‌افزاری، تابع فعال‌ساز (Activation Function) مدل باید تغییر کند.
این پروژه بر حل پوکر از طریق «کاهش پشیمانی متقابل» (CFR) تمرکز دارد؛ الگوریتمی که برای یافتن یک استراتژی تقریبی «تعادل نش» (Nash Equilibrium) استفاده می‌شود. چون این استراتژی‌ها به‌طور اثباتی (تا حد اپسیلون) غیرقابل استثمار هستند، بازیکنی که از استراتژی تعادلی استفاده می‌کند، حتی اگر حریف استراتژی او را بداند، در بلندمدت و از نظر آماری شکست نمی‌خورد.
حل‌کننده‌های مدرن برای مدیریت نیازهای محاسباتی عظیم از یک رویکرد ترکیبی استفاده می‌کنند:
- رویکرد جدولی: ابزارهایی مثل Piosolver از جداول غول‌پیکر استراتژی‌ها و مقادیر مورد انتظار استفاده می‌کنند و با استفاده از «انتزاع» (Abstraction)، موقعیت‌های مشابه بازی را در یک دسته یا «سطل» واحد ادغام می‌کنند.
- رویکرد عصبی: ابزارهایی مثل GTOWizard هر موقعیت را تا عمق جستجوی محدودی «باز-حل» (Re-solve) می‌کنند و سپس از یک شبکه عصبی (Neural Network) — شبیه نقشه مترویی که سیگنال‌ها را از ورودی به جواب می‌رساند — به‌عنوان تابع تقریب در نقطه قطع عمق استفاده می‌کنند.
پیاده‌سازی phulin ترکیبی از متون آکادمیک، به‌ویژه ارجاعات به DeepStack و ReBeL است. نسخه فعلی برای بازی‌های دو نفره (Heads-up) طراحی شده است. البته این مدل هنوز فاقد قابلیت «قفل گره» (Node Locking) است؛ یک ویژگی تجاری که برای تعیین چگونگی استثمار استراتژی‌های غیرتعادلی حریف استفاده می‌شود. علاوه بر این، احتمالاً ۱۰۰ برابر محاسبات آموزشی کمتری نسبت به مدل‌های آکادمیک دارد، به این معنی که هنوز قوی‌ترین حل‌کننده موجود نیست.
نوشتن این حل‌کننده به‌صورت دستی در اواخر سال ۲۰۲۵ یک مبارزه دشوار بود. در آن زمان، مدل‌های زبانی (LLMs) مکرراً الگوهای ممنوعه تولید می‌کردند (مثلاً استفاده از حلقه‌های for برای پیمایش تنسورها) و در پیاده‌سازی کرنل‌های پیچیده و غیر استاندارد شکست می‌خوردند. اما تا اواسط ۲۰۲۶، توانایی‌ها تغییر کرد. اکنون مدل می‌تواند مقالات آکادمیک را از صفر پیاده کند، انواع CFR را بررسی نماید و برای بهینه‌سازی ابرپارامترها (Hyperparameters) و استخراج قوانین پایه مقیاس‌بندی (Scaling Laws)، آزمایش‌های کوتاه‌مدت را به‌طور خودکار اجرا کند. این روند بهبود کارایی عامل‌های کدنویس با تحولاتی در معماری مدل‌ها همراه شده است؛ برای نمونه، معماری TokenFold توانست هزینه‌های عملیاتی عامل‌های کدنویسی را تا ۳۰٪ کاهش دهد تا فرآیندهای تکراری بهینه‌سازی سریع‌تر صورت بگیرد.
این تحول، اقتصاد بنیادین معماری نرم‌افزار را تغییر می‌دهد. وقتی تولید کد ارزان شود و از طریق یک مجموعه تست قابل اعتبارسنجی باشد، نیاز به کتابخانه‌های عمومی کاهش می‌یابد. یک کرنل اختصاصی که دقیقاً یک محاسبه خاص را انجام می‌دهد، سریع‌تر از کتابخانه‌ای است که سعی می‌کند همه کار را انجام دهد. تا زمانی که محاسبات به‌خوبی تعریف شده و پیاده‌سازی مرجع قابل اعتماد باشد، یک مجموعه تست اغلب بهتر از یک مشخصات فنی دستی است.
البته این به معنای جایگزینی برنامه‌نویس نیست. عامل هوشمند هنوز فاقد برنامه‌ریزی سطح بالا و قضاوت است؛ او نمی‌تواند تصمیم بگیرد «چه چیزی» ساخته شود. توسعه‌دهنده همچنان لایه سازمان‌دهنده است که آزمایش‌ها را نظارت و مسیر پروژه را در طول چندین ماه مدیریت می‌کند. این پروژه بخشی از دوران حضور phulin در Recurse Center، خلوتگاه برنامه‌نویسان در نیویورک، بود.
برای برنامه‌نویسان، این یعنی بازنویسی کدها دیگر «میوه ممنوعه» نیست. هزینه انتقال یک پیاده‌سازی مرجع سطح بالا (مثل PyTorch) به یک هدف سطح پایین با کارایی بالا (مثل WebGPU) به‌شدت کاهش یافته است. شما می‌توانید بدون نوشتن دستی کدهای تکراری (Boilerplate)، از یک نمونه اولیه پژوهشی در PyTorch به یک پیاده‌سازی آماده تولید در WebGPU بروید.
گام بعدی شما
- اگر پروژه‌ای با محاسبات سنگین در وب دارید، به‌جای استفاده از کتابخانه‌های سنگین، خروجی‌های مدل خود را در PyTorch استخراج کرده و از LLM برای تولید کرنل‌های WebGPU بخواهید.
- پیاده‌سازی زنده این حل‌کننده عصبی را در holdem.computer بررسی کنید.
- کد منبع را در گیت‌هاب (
https://github.com/phulin/poker) تحلیل کنید تا نحوه عملکرد کرنل‌های تولیدشده را ببینید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو