تصور کنید یک توسعه‌دهنده مستقل هستید که بودجه‌ای برای اجاره سرورهای گران‌قیمت گرافیکی یا خرید شتاب‌دهنده‌های اختصاصی ندارد، اما می‌خواهد صدها کاراکتر متنوع و با جزئیات بالا برای بازی‌اش بسازد. گزارش ۲۷ سپتامبر ۲۰۲۶ از وب‌سایت dev.to ثابت می‌کند که این امر ممکن است و جزئیات آن نشان می‌دهد که یک سرور مجازی (VPS) با ۶ هسته vCPU و ۱۱ گیگابایت رم می‌تواند بدون نیاز به حتی یک هسته CUDA، کاراکترهای سه‌بعدی کامل و ریگ‌شده (Rigged) را تولید کند.
بیشتر خط‌لوله‌های هوش مصنوعی سه‌بعدی برای تولید مش (Mesh) و پوست‌اندازی (Skinning) به محاسبات سنگین واحد پردازش گرافیکی (GPU) وابسته‌اند. این موضوع یک سد مالی بلند برای سازندگان مستقل ایجاد کرده و یک گلوگاه فنی برای تولید محتوا در سمت سرور به شمار می‌رود. سیستم CHARFORGE با تغییر تمرکز معماری از «فرمت داده» به یک «رابط مشترک کاراکتر» (Actor Interface)، این گره فنی را باز می‌کند.
در این مدل، موتور بازی دیگر اهمیتی نمی‌دهد که کاراکتر چگونه ساخته شده است؛ بلکه فقط مجموعه‌ای از سوالات عملکردی را می‌پرسد: سرعت حرکت کاراکتر چقدر است؟ انیمیشن‌ها چگونه اجرا می‌شوند؟ و سلاح در کجای دست متصل شود؟ هر مدلی که این قرارداد (Contract) را رعایت کند، فارغ از منشأ تولید، یکسان پردازش می‌شود. همان‌طور که در تحلیل‌های قبلی ما درباره بهینه‌سازی مدل‌های لبه اشاره کردیم، حذف وابستگی به سخت‌افزارهای خاص، کلید مقیاس‌پذیری در تولید محتواست. این رویکرد شباهت زیادی به استاندارد MHS دارد که سعی می‌کند یک زبان مشترک برای اتصال مدل‌های هوش مصنوعی به سخت‌افزارهای مختلف ایجاد کند.
به نقل از مستندات این پروژه، چهار مسیر مجزا برای پر کردن کتابخانه کاراکترها روی سخت‌افزار CPU تعریف شده است:
- پیکرتراشی مبتنی بر مورف (Morph): حلقه اصلی تولید از یک مش پایه MakeHuman با ۱۹,۱۵۸ رأس و ۱۶۳ استخوان استفاده می‌کند. این سیستم ۱۶۳ وزن مورف را برای تعیین سن، جنسیت و تبار به کار می‌گیرد که تمام این محاسبات توسط جاوااسکریپت در CPU مرورگر کاربر انجام می‌شود.
- وارد کردن مدل‌های خارجی: سیستم از فایل‌های GLB، VRM، FBX و OBJ پشتیبانی می‌کند. برای مدیریت قراردادهای مختلف نام‌گذاری استخوان‌ها در Mixamo یا Unreal، از شناسایی استخوان‌های انسان‌نما بر اساس نام استفاده می‌کند و در صورتی که برچسب‌ها شناسایی نشوند، به روش پیمایش سلسله‌مراتبی ساختار (Structural Hierarchy Walking) روی می‌آورد.
- رشد رویه‌ای (Procedural): یک «آزمایشگاه موجودات» وجود دارد که ربات‌ها، گابلین‌ها و موجودات فضایی را با استفاده از رویکرد «بذر و لغزنده» (Seed-and-slider) تولید می‌کند. این بهینه‌ترین مسیر است زیرا هیچ نیازی به ورودی/خروجی فایل (File I/O) یا رفت‌وبرگشت درخواست به سرور ندارد.
- تولید AI مبتنی بر CPU: این مسیر از نسخه Blender 4.5.14 در حالت بدون رابط گرافیکی (Headless) به همراه افزونه MPFB2 برای تولید انسان‌های واقع‌گرایانه استفاده می‌کند. همچنین برای بازسازی سه‌بعدی از روی عکس، مدل TripoSR را ادغام کرده است که در آن یک تک تصویر با استفاده از PyTorch در حالت CPU به یک مش تبدیل می‌شود.
اجرای هم‌زمان سه مودالیته مختلف — زبان، انتشار (Diffusion) و بازسازی سه‌بعدی — روی ۱۱ گیگابایت رم نیازمند مدیریت سخت‌گیرانه حافظه است. طبق گزارش توسعه‌دهنده، سیستم برای تولید پیشینه و داستان‌های پس‌زمینه کاراکترها از Ollama (مدل llama3.2:3b) و برای تولید بافت لباس‌ها از PyTorch با مدل SD-Turbo استفاده می‌کند.
برای جلوگیری از کرش کردن سیستم به دلیل کمبود حافظه، این سرویس‌ها هرگز به صورت هم‌زمان اجرا نمی‌شوند. سیستم به‌طور صریح هر زمان که یک تسک سه‌بعدی یا تصویری نیاز به فضای خالی حافظه داشته باشد، سرویس Ollama را از رم خارج (Unload) می‌کند. این رویکرد «نوبتی» (Turn-taking)، نظم در زمان‌بندی را جایگزین قدرت خام سخت‌افزاری کرده است.
در بخش ذخیره‌سازی و پایداری داده‌ها، سیستم از localStorage مرورگر فاصله گرفته و تمام کاراکترها را در یک پایگاه‌داده MySQL ذخیره می‌کند. این تغییر اجازه می‌دهد یک سیستم نسخه‌بندی (Versioning) قدرتمند ایجاد شود که در آن هر کاراکتر تا ۱۵ نسخه از تاریخچه تغییرات خود را حفظ می‌کند. همچنین کاربران می‌توانند مدل‌های حذف‌شده را از طریق یک سطل زباله ۳۰ روزه بازیابی کنند.
با این حال، نویسنده اعتراف می‌کند که حذف GPU هزینه‌هایی (Taxes) داشته است. بازسازی عکس به مدل سه‌بعدی هنوز کیفیت پایینی دارد و چهره‌ها و دست‌های تولید شده تقریبی هستند و برای نماهای نزدیک (Close-up) مناسب نیستند. علاوه بر این، زمان تولید در CPU به جای چند ثانیه، چندین دقیقه طول می‌کشد.
برخی ریگ‌های (Rig) واردشده هنگام استفاده از شناسایی ساختاری، همچنان انیمیشن‌های ناقصی اجرا می‌کنند. همچنین ویرایشگر مرورگر همچنان محاسبات مورف و پوست‌اندازی را با جاوااسکریپت انجام می‌دهد، هرچند موتور بازی برای پخش نهایی از رندرینگ GPU-skinned استفاده می‌کند تا عملکرد بهینه شود.
این تغییر رویکرد نشان می‌دهد که گلوگاه تولید محتوای AI اغلب معماری است، نه سخت‌افزار. با تعریف یک رابط سخت‌گیرانه برای آنچه یک «کاراکتر» را تشکیل می‌دهد، توسعه‌دهندگان می‌توانند محتوا را از منابع کاملاً متفاوت جذب کنند بدون اینکه برای هر فرمت جدید، کد سفارشی بنویسند. این تلاش برای بهینه‌سازی فرآیندهای ادغام، یادآور پیشرفت‌های اخیر آنتروپیک است که توانسته زمان ادغام سخت‌افزارهای آزمایشگاهی را به شدت کاهش دهد.
برای برنامه‌نویسان، نقشه راه از «پشتیبانی از فرمت X» به «رعایت قرارداد کاراکتر» تغییر می‌کند. این یعنی یک گابلین تولیدشده رویه‌ای و یک انسان بازسازی‌شده از عکس، می‌توانند در یک صحنه باشند و به یک منطق بازی واحد واکنش دهند. باید منتظر تکامل بازسازی سه‌بعدی مبتنی بر CPU بود، چرا که مدل‌هایی مانند TripoSR برای سخت‌افزارهای غیرشتاب‌دهنده بیشتر بهینه می‌شوند.
گام بعدی شما
- بررسی مدل TripoSR برای درک نحوه بهینه‌سازی بازسازی سه‌بعدی روی CPU
- مطالعه معماری Interface-based در طراحی سیستم‌های تولید محتوا برای کاهش وابستگی به سخت‌افزار
- آزمایش اجرای مدل‌های کوچک زبانی (SLM) در محیط‌های محدود رم با متد نوبتی
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell و آینده استنتاج لبه مراجعه کنید.
گفتگو