پرش به محتوای اصلی
پرش به محتوای مقاله

درون سازوکار h3.c برای کاهش زمان پردازش ویدیو در مک

·۲۰ مرداد ۱۴۰۵۲۵ دقیقه مطالعه۳ بازدید
موتور استنتاج MiniMax H3 برای کامپیوترهای مک
موتور استنتاج MiniMax H3 برای کامپیوترهای مک
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

جایگزینی لایه‌های قابل حمل MLX/PyTorch با موتور بومی Metal 4 و استفاده از Zero-copy weights برای مدل‌های ۳۷ گیگابایتی؛ این یعنی حذف کامل کپی‌های اضافی حافظه و کاهش زمان استنتاج از ۲۶ ثانیه به ۳.۵ ثانیه.

تصور کنید می‌خواهید یک ویدیوی باکیفیت با هوش مصنوعی بسازید، اما مجبورید ساعت‌ها منتظر بمانید یا هزینه‌های گزاف APIهای ابری را بپردازید. موتور h3.c این معادله را تغییر داد و زمان تولید ویدیو روی سخت‌افزار محلی را به چند ثانیه محدود کرد.

این بهینه‌سازی‌ها در واقع تکامل یافته‌ی همان معماری است که باعث شد مدل MiniMax H3 به نخستین مدل وزن‌باز در صدر رتبه‌بندی ویدیوهای AI تبدیل شود.

طبق مستندات فنی منتشر شده در ۱۱ اوت ۲۰۲۶، روی تراشه M5 Max، فرآیند حذف نویز چهار مرحله‌ای برای یک کلیپ کوتاه تنها ۳.۵ ثانیه زمان می‌برد؛ در حالی که در حالت مرجع با کیفیت کامل، این زمان ۲۶.۴ ثانیه بود.

تولید محلی ویدیو به‌دلیل حجم عظیم داده‌هایی که باید در واحد پردازش گرافیکی (GPU) جابه‌جا شوند، همواره دشوارترین بخش هوش مصنوعی روی دستگاه بوده است. اکثر کاربران به دلیل فشار شدید روی حافظه در ترنسفورمرهای انتشار (Diffusion Transformers یا DiT) — که شبیه به یک نقاش است که برای هر پیکسل باید هزاران بار رنگ‌ها را بررسی کند — به سرویس‌های ابری روی می‌آورند. h3.c با استفاده از Metal 4 و TensorOps، حافظه یکپارچه مک را مستقیماً مدیریت می‌کند تا گلوگاه‌های چارچوب‌های عمومی را دور بزند.

همان‌طور که در تحلیل‌های پیشین ما درباره بهینه‌سازی مدل‌های محلی اشاره کردیم، حذف لایه‌های واسط نرم‌افزاری کلید دستیابی به حداکثر توان سخت‌افزار است. این رویکرد در واقع ادامه مسیر کاهش ۶۶ درصدی مصرف حافظه گرافیکی برای تولید ویدیوهای 2K است که پیش‌تر در این مدل مشاهده شد.

معماری سرعت

این موتور به‌صورت «برش‌های عمودی» طراحی شده است؛ یعنی توسعه آن از مدیریت متاداده‌های پایه شروع شده و به تولید پیچیده ویدیو و صدا از طریق پرامپت می‌رسد. توالی توسعه با متاداده‌های قطعی میزبان/مدل آغاز شد، سپس برابری بلوک‌های قابل حمل Metal، کدگذاری پرامپت و در نهایت شرط‌گذاری فریم اول/آخر و مراجع ترتیبی اضافه شدند. در حال حاضر، قابلیت‌های تبدیل متن به ویدیو/صدا، شرط‌گذاری فریم‌های اول و آخر و مراجع ترتیبی Ref2VA برای تصویر، ویدیو و صدا به‌طور کامل و سرتاسری (End-to-End) فعال شده‌اند.

h3.c به‌طور خاص برای Apple Silicon بهینه شده و از مسیر ذخیره‌سازی بومی BF16 و گراف‌های کش‌شده MPSGraph برای به حداقل رساندن تأخیر در ارسال دستورات (Dispatch Overhead) استفاده می‌کند. برای بهینه‌سازی بیشتر، هسته DiT به دو بافر دستور Metal تقسیم شده است. این یعنی GPU می‌تواند بخش اول را اجرا کند، در حالی که CPU هم‌زمان در حال کدگذاری بخش دوم است. روی سخت‌افزار M5، یک تقسیم‌بندی با عمق ۶۰٪ (مثلاً ۳۰/۵۰ بلوک، ۲۷/۴۵ یا ۲۴/۴۰) باعث افزایش بازدهی ۰.۵ تا ۱.۸ درصدی می‌شود. تراشه‌های M3 به‌طور خودکار تنها حالت ۳۰/۵۰ را تقسیم می‌کنند که ۱.۲٪ سریع‌تر اندازه‌گیری شد. کاربران می‌توانند با استفاده از H3_DIT_COMMAND_BLOCKS=0 برای یک بافر، یا مقادیر ۱ تا ۵۰ برای تنظیمات سفارشی، این تقسیم‌بندی را تغییر دهند.

یکی از بزرگ‌ترین دستاوردهای این موتور در مدیریت وزن‌ها (Weights) — همان دستورالعمل‌های عددی که مدل را تعریف می‌کنند — نهفته است. در GPUهای سری M5، وزن‌های ترنسفورمر به‌جای کپی شدن در بافرهای مشترک ناشناس، مستقیماً از تکه‌های (Shards) فایل‌های safetensor نگاشت می‌شوند. این روش باعث می‌شود مدل ۳۷ گیگابایتی به‌صورت File-backed باقی بماند و قابل بازپس‌گیری باشد، که از Swap کردن سیستم به دیسک در هنگام استنتاج سنگین جلوگیری می‌کند. تراشه‌های M3 به‌طور پیش‌فرض از مسیر سریع‌تر «بافر کپی‌شده» استفاده می‌کنند. این انتخاب در M5 را می‌توان برای عیب‌یابی از طریق H3_ZERO_COPY_WEIGHTS=0 غیرفعال کرد.

ادغام‌های DiT و مدیریت حافظه

برای استخراج حداکثری توان سخت‌افزار، h3.c چندین ادغام عمیق (Fusion) را اجرا می‌کند. هر بلوک فعال DiT، گیت باقی‌مانده توجه (Attention Residual Gate) خود را با لایه MLP AdaLN بعدی ادغام می‌کند. مقدار باقی‌مانده BF16 گرد شده در حافظه Threadgroup برای نرمال‌سازی نگه داشته می‌شود که این کار باعث حذف یک مرحله ارسال دستور و یک بار خواندن مجدد از حافظه جهانی می‌شود. همچنین گیت باقی‌مانده MLP، مقدار AdaLN توجه بلوک بعدی را تولید کرده و این وضعیت را در طول حلقه منتقل می‌کند. این قابلیت‌ها را می‌توان از طریق H3_DISABLE_FUSED_GATE_ADALN=1 و H3_DISABLE_FUSED_CROSS_BLOCK_ADALN=1 غیرفعال کرد.

همچنین، هسته‌های نهایی AdaLN برای صدا و ویدیو مستقیماً به آفست‌های جریان باقی‌مانده متصل می‌شوند. این کار از دو عملیات Slice Blit جلوگیری کرده و در رزولوشن ۵۱۲x۵۱۲ حدود ۱۸.۸ مگابایت و در رزولوشن‌های کلاس ۸۶۴ حدود ۲۹.۴ مگابایت از فضای حافظه موقت (Scratch) صرفه‌جویی می‌کند. سرهای نهایی BF16 در حالی که تایل‌های تصویرسازی ۱۶x۱۶ را بارگذاری می‌کنند، AdaLN را اعمال کرده و یک فعال‌ساز نرمال‌شده دیگر را حذف می‌کنند. در مجموع، این بهینه‌سازی‌ها ۳۷.۵ تا ۵۸.۹ مگابایت حافظه ذخیره می‌کنند. پرچم‌های H3_DISABLE_FUSED_FINAL_SLICE=1 و H3_DISABLE_FUSED_FINAL_HEAD=1 حالت‌های اصلی را بازمی‌گردانند.

بافرهای فعال‌ساز (Activation buffers) نیز بر اساس طول عمر واقعی خود در هر بلوک مدیریت می‌شوند. فضای حافظه Arena تصویرسازی QKV ابتدا برای سرهای توجه و سپس برای ورودی نرمال‌شده MLP استفاده می‌شود. در همین حال، Arena خروجی توجه فعلی، پس از مصرف شاخه‌اش، به خروجی MLP تبدیل می‌شود. این تداخل هوشمندانه (Aliasing)، ۶۱.۲۵ مگابایت حافظه را در هندسه ۵۱۲ و ۹۹.۶۳ مگابایت را در هندسه ۸۶۴ آزاد می‌کند. این قابلیت از طریق H3_DISABLE_DIT_ACTIVATION_ALIAS=1 قابل غیرفعال‌سازی است.

اهرم‌های بهینه‌سازی تهاجمی

برای ایجاد تعادل بین کیفیت و سرعت، h3.c چندین ابزار کنترلی مستقل ارائه می‌دهد:

  • مراحل حذف نویز: کاربران می‌توانند از ۵۰ مرحله مرجع به حالت «تهاجمی» ۴ مرحله‌ای تغییر وضعیت دهند. در حالی که ۵۰ مرحله کیفیت «اوراکل» (کامل‌ترین) را ارائه می‌دهد، ۴ تا ۷ مرحله برای تکرارهای سریع کافی است. در یک تست ۲۲ فریم با اندازه ۵۱۲، نتیجه چهار مرحله‌ای به SSIM 0.556 نسبت به مرجع ۲۹ مرحله‌ای دست یافت (در یک تست مستقل روی موج‌سوار، این مقدار 0.547 بود).
  • نازک کردن لایه‌ها: موتور می‌تواند به‌جای ۵۰ بلوک ترنسفورمر، تنها مجموعه‌ای از بلوک‌ها (مثلاً ۴۰ یا ۴۵ بلوک) را اجرا کند تا زمان محاسبات و حافظه اشغال‌شده کاهش یابد. این کار با رتبه‌بندی گیت‌های AdaLN و در عین حال محافظت از بلوک‌های حیاتی اول و آخر انجام می‌شود.
  • استفاده مجدد از حذف‌کننده: با پرچم --reuse، مدل می‌تواند گذارهای حذف‌شده را برون‌یابی کند. برای مثال، در ۲۰ گام، مقدار --reuse 2 باعث می‌شود تنها ۱۱ ارزیابی واقعی DiT انجام شود (به جای ۲۰ مورد). در ۲۰ گام، مقدار --reuse 3 تنها ۸ ارزیابی واقعی انجام می‌دهد. برای بودجه‌های بسیار کم (۴ تا ۷ گام)، مقدار --reuse 1 توصیه می‌شود تا هر پاس مدل را به‌طور کامل اجرا کند.
  • استفاده مجدد از باقی‌مانده هسته (Core Residual Reuse): این قابلیت هر گام کار روی Patch و Head را به‌روز می‌کند اما هسته گران‌قیمت را با دفعات کمتر اجرا می‌کند. این روش با استفاده مجدد از کل سرعت (Whole-velocity reuse) ناسازگار است. مقادیر بالای ۶ نمایش داده نمی‌شوند زیرا دقت سوژه را کاهش می‌دهند.
  • کاهش توکن‌ها: یک حالت تهاجمی که توکن‌های هدف ویدیویی افقی مجاور را در بلوک‌های میانی (بعد از بلوک ۳) جفت می‌کند. در M5 Max، این کار زمان اجرای یک پروفایل ۴۵ لایه با reuse-2 را از ۱۶.۶۹ به ۱۲.۶۰ ثانیه (۲۴.۵٪ بهبود) رساند. این سیستم از یک Bypass استفاده می‌کند تا رزولوشن کامل را قبل از بلوک ۴۰ (در ۱۰ ارزیابی اول) یا بلوک ۳۰ (در ارزیابی‌های بعدی) بازیابی کند. این حالت از طریق H3_DISABLE_TOKEN_REDUCTION=1 غیرفعال می‌شود.

مسیر قدرتمند int8

برای کسانی که سرعت را بر دقت عددی ترجیح می‌دهند، مسیر M5 به‌طور پیش‌فرض از موتور int8 MLP بومی استفاده می‌کند. این سیستم فعال‌سازها را به‌صورت پویا کوانتیده (Quantization) می‌کند و از مقیاس‌های وزن به‌ازای هر کانال خروجی استفاده می‌کند، به‌طوری که ورودی FC2 برای هر ۱۰۲۴ کانال یک مقیاس دارد. هسته FC2 محصولات جزئی مقیاس‌شده را در قطعات همکاری خصوصی (Private Cooperative Fragments) نگه می‌دارد تا از Spill شدن تایل ۳۲ کیلوبایتی Threadgroup جلوگیری کند.

در یک رندر ثابت ۵۰ لایه، مسیر int8 زمان حذف نویز را از ۳۶.۳۰ ثانیه (در BF16) به ۲۵.۸۰ ثانیه کاهش داد. با بهینه‌سازی‌های بیشتر، از جمله تصویرسازی‌های کوانتیده QKV، این زمان به ۱۹.۳۲ ثانیه رسید. تهاجمی‌ترین مسیر، کوانتش را در هسته gated AdaLN ادغام می‌کند که ۹۹ ارسال دستور مستقل در هر پاس پیشرو را حذف می‌کند. این مسیر ادغام‌شده ردیف‌های H3 را به‌صورت بردارهای BF16x4 بارگذاری کرده و به‌صورت int8x4 می‌نویسد که حدود ۰.۱ تا ۰.۵٪ در اندازه‌گیری‌های متقاطع صرفه‌جویی می‌کند.

سایر هسته‌های تخصصی این مسیر را بهبود می‌بخشند:

  • پایان‌بندی‌های ادغام‌شده: نرمال‌سازی RMS و RoPE برای Q/K داخل تایل تصویرسازی int8 QKV انجام می‌شود که سرعت پاس‌های کامل را در رزولوشن ۵۱۲ بین ۲.۱ تا ۳.۲٪ افزایش می‌دهد. حلقه RMS از بارگذاری‌های BF16x4 و سپس چهار FMA مرتب صریح استفاده می‌کند. این حالت را می‌توان با --use-slower-unfused-qkv-rope به هسته مجزا بازگرداند.
  • تخصص TensorOps: تصویرسازی خروجی توجه با شکل ۷۱۶۸ در ۵۳۷۶ برای توالی‌های تا ۲۰۴۸ ردیف در هسته TensorOps کامپایل می‌شود که ۰.۲ تا ۰.۸٪ در اندازه‌گیری‌های ۵۱۲-forward صرفه‌جویی می‌کند. FC1 نیز از یک حلقه TensorOps تخصصی با عرض ۵۳۷۶ در زمان کامپایل استفاده می‌کند که ۰.۱ تا ۰.۴٪ صرفه‌جویی می‌کند.
  • صرفه‌جویی در حافظه: بارگذاری معمولی int8 بافرهای BF16 مربوط به FC1/FC2 را پس از کوانتش آزاد می‌کند و پیک ذخیره‌سازی تنسور را از ۳۶.۴ گیگابایت به ۲۵.۹ گیگابایت کاهش می‌دهد.
  • بهبودهای کوانتش: برای کوانتش فعال‌ساز FC2، توالی‌های تا ۲۰۴۸ ردیف از یک کاهش ۱۲۸-رشته‌ای دقیق استفاده می‌کنند تا از دومین خواندن حافظه دستگاه جلوگیری شود، که سرعت ۵۱۲-forward را ۰.۲ تا ۰.۸٪ بهبود می‌بخشد.

شرط‌گذاری پیشرفته و رسانه

h3.c از ورودی‌های چندوجهی (Multimodal) پشتیبانی می‌کند و یک چک‌پوینت مجزای Ref2VA برای مراجع ترتیبی پیاده‌سازی کرده است که به کاربران اجازه می‌دهد تصاویر، ویدیوهای بی‌صدا یا کلیپ‌های کامل صوتی-تصویری را به عنوان راهنما ارائه دهند.

  • لنگرهای فریم اول و آخر: کاربران می‌توانند شروع و پایان ویدیو را با --first-frame و --last-frame تثبیت کنند. تصویر اول به بوم هدف کشیده می‌شود، در حالی که تصویر آخر با مقیاس Aspect-cover تغییر اندازه یافته و از مرکز برش (Center-crop) می‌خورد. این لنگرها را نمی‌توان با مراجع Ref2VA ترکیب کرد.
  • مراجع ترتیبی: تصاویر به‌صورت <Picture 1>، <Picture 2> و غیره به مدل معرفی می‌شوند. نام فایل‌ها برای مدل معنایی ندارند و تنها ترتیب پرچم‌های --ref-image اهمیت دارد. کاربران در جلسات تعاملی می‌توانند این‌ها را با دستورات !refs ،!ref-remove N و !refs clear مدیریت کنند.
  • ادغام صدا: سیستم از مراجع صوتی مستقل (۲ تا ۱۵ ثانیه) پشتیبانی می‌کند که توسط یک AudioVAE بومی کدگذاری شده و به‌صورت ۰.۹۹۹ لیتنت پاک + ۰.۰۰۱ نویز دانه‌بندی‌شده در خط زمانی نهان ترکیب می‌شوند. حداکثر سه ورودی صوتی پذیرفته می‌شود و سقف کل مدت‌زمان رمزگشایی شده ۱۵ ثانیه است. کدگذار صوتی بومی با اوراکل اصلاح‌شده MLX در L2 نسبی 3.59e-6 مطابقت دارد.
  • مراجع ویدیویی: کاربران می‌توانند از --ref-silent-video برای نادیده گرفتن موسیقی متن یا --ref-video برای حفظ صدای داخلی استفاده کنند. پرچم خاص --ref-video-audio اجازه می‌دهد صدای یک ویدیو با یک فایل .wav مجزا جایگزین شود.

محدودیت‌های حافظه و رزولوشن

حداکثر اندازه بوم پشتیبانی‌شده ۷۶۸ در ۱۳۴۴ پیکسل است و عرض و ارتفاع باید مضربی از ۳۲ باشند. برای توسعه، اندازه ۵۱۲x۵۱۲ مربع به عنوان اندازه «ایمن» تایید شده است. مدل H3-Base به‌طور بومی یک مدل 768p است و از محدودیت‌های افقی/عمودی ۱۳۴۴x۷۶۸ و ۷۶۸x۱۳۴۴ و همچنین بوم‌های ۴:۳ و ۳:۴ (۱۰۲۴x۷۶۸ و ۷۶۸x۱۰۲۴) پشتیبانی می‌کند.

برای تسریع پیش‌نمایش‌ها، پرچم‌های --render-width و --render-height اجازه می‌دهند مدل روی بوم داخلی کوچک‌تری اجرا شود و سپس از طریق vImage بزرگ‌نمایی شود:

  • کیفیت سریع (Fast-Quality): ۳۸۴x۳۸۴ داخلی به ۵۱۲x۵۱۲ خروجی. این کار زمان DiT در M5 را ۳۳٪ و زمان VAE را ۱۸٪ کاهش می‌دهد.
  • تهاجمی (Aggressive): ۳۲۰x۳۲۰ داخلی به ۵۱۲x۵۱۲ خروجی. این حالت یک روباه در حال راه رفتن را در ۸.۰۲ ثانیه زمان DiT تولید کرد، در حالی که در حالت بومی ۱۵.۸۲ ثانیه زمان می‌برد.
  • پیش‌نمایش بومی: بوم ۲۵۶x۲۵۶. در این اندازه، H3 به‌طور خودکار مختصات RoPE فضایی را نصف می‌کند تا آرتیفکت‌های توری تکرار شونده حذف شوند. اندازه ۱۲۸ مربع همچنان پشتیبانی نمی‌شود زیرا شبکه توکن ۴x۴ نتوانست سوژه‌های قابل شناسایی را بازیابی کند.

اشکال زمانی و پرامپت‌نویسی

مدل H3 ویدیوها را با نرخ ۲۴ فریم بر ثانیه تولید می‌کند و درخواست‌های فریم را به سمت فرمول 5 + 17*n گرد می‌کند. این یعنی درخواست برای ۲۳ فریم به ۳۹ فریم گرد می‌شود. اشکال زمانی رایج عبارتند از:

  • ۲۲ فریم (۰.۹۱۷ ثانیه)
  • ۳۹ فریم (۱.۶۲۵ ثانیه)
  • ۵۶ فریم (۲.۳۳۳ ثانیه)
  • ۱۰۷ فریم (۴.۴۵۸ ثانیه)
  • ۲۴۳ فریم (۱۰.۱۲۵ ثانیه)
  • ۳۶۲ فریم (۱۵.۰۸۳ ثانیه)

گردش کار منتشر شده برای کلیپ‌های بین ۴ تا ۱۵ ثانیه در نظر گرفته شده است.

برای نتایج بهینه، سیستم انتظار توصیفاتی شبیه به Context-IR دارد. پرامپت‌ها باید صراحتاً سوژه، اکشن، محیط، دوربین (مثلاً «نمای تعقیبی جانبی با ارتفاع متوسط، لنز ۵۰ میلی‌متری»)، نورپردازی/استایل («نور محیطی آبی سرد، نور لبه طلوع خورشید گرم») و صدای مورد نظر («صدای نرم قدم‌ها در برف») را بیان کنند.

روی یک M5 Max با ۱۲۸ گیگابایت رم، یک رندر کامل تصویر و صدا در ۷۴.۵۸ ثانیه با حداکثر اشغال حافظه فیزیکی ۴۰.۱ گیگابایت تکمیل شد. این نشان می‌دهد که با وجود حجیم بودن مدل، پیاده‌سازی بومی Metal مانع از کند شدن کل سیستم می‌شود.

این چرخش به سمت موتورهای استنتاج سخت‌افزاری نشان می‌دهد که آینده هوش مصنوعی محلی تنها در مدل‌های کوچک‌تر نیست، بلکه در ادغام عمیق با دستورالعمل‌های خاص GPU است. با دور زدن لایه‌های «قابل حمل» مانند MLX یا PyTorch، h3.c ثابت کرد که هنوز پتانسیل‌های زیادی برای افزایش سرعت در لایه‌های سخت‌افزاری وجود دارد. با این حال، باید به یاد داشت که نادیده گرفتن نوسانات سخت‌افزاری می‌تواند نتایج بنچمارک‌ها را در دنیای واقعی گمراه‌کننده کند.

گام بعدی شما

  • اگر از مک‌های High-end استفاده می‌کنید، توازن بین --reuse و --core-reuse را تست کنید تا نقطه شکست حرارتی سخت‌افزار خود را بیابید.
  • برای پیش‌نمایش‌های سریع، از رزولوشن داخلی ۳۲۰x۳۲۰ استفاده کنید تا زمان رندر را تقریباً نصف کنید.
  • پرامپت‌های خود را با جزئیات فنی دوربین و نورپردازی بازنویسی کنید تا از حداکثر توان مدل H3 بهره ببرید.

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

چرا این موضوع مهم است؟

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

تأثیر برای ایران

به‌دلیل تحریم‌ها و محدودیت‌های دسترسی به APIهای ابری مدل‌های ویدیویی، ابزارهای استنتاج محلی مانند h3.c برای تولیدکنندگان محتوای ایرانی که سخت‌افزار مک دارند، تنها راه دسترسی به کیفیت سطح جهانی است.

·نگاه ما
تحریریه دات‌هوش

تمرکز h3.c بر حذف لایه‌های انتزاعی (Abstraction Layers) و تعامل مستقیم با Metal، نشان می‌دهد که دوران تکیه بر فریم‌ورک‌های چندمنظوره برای مدل‌های سنگین به پایان رسیده است. این رویکرد ثابت می‌کند که بهینه‌سازی در سطح دستورالعمل‌های GPU می‌تواند حتی بدون تغییر در معماری مدل، جهشی ۷ برابری در سرعت ایجاد کند. در واقع، ما شاهد بازگشت به دوران «برنامه‌نویسی نزدیک به سخت‌افزار» برای دستیابی به کارایی در مقیاس واقعی هستیم.

منابع

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.