واحد‌های محاسباتی دانه‌ریز؛ راهکار جدید برای پایان هزینه‌های پیش‌بینی‌ناپذیر GPU

یک حلقهٔ بازگشتی ساده در یک بوم هوش مصنوعی گره‌محور می‌تواند در عرض چند ثانیه هزاران اعتبار محاسباتی را ببلعد و ابزاری خلاقانه را به یک بدهی مالی تبدیل کند. در ۲۸ اوت ۲۰۲۶، یک تحلیل فنی عمیق در وب‌سایت dev.to نقشه‌ای برای سیستم‌های صورت‌حساب «ضدگلوله» ارائه کرد که به‌طور خاص برای جریان‌های کاری سنگین واحد پردازش گرافیکی (GPU) طراحی شده‌اند. توجیه تجاری موتورهای جریان کاری بصری و غیرمتمرکز با توان عملیاتی بالا، به یک مدل اقتصادی سخت‌گیرانه وابسته است: تبدیل چرخه‌های سخت‌افزاری نوسانی و سنگین به واحدهای مالی قطعی، قابل تأیید و پیش‌بینی‌پذیر.

در مدل‌های سنتی وب، صورت‌حساب بر اساس فراخوانی‌های مجزای API است؛ یعنی کاربر یک نقطه انتهایی (Endpoint) را فراخوانی می‌کند و یک شمارنده ساده زیاد می‌شود. اما این مدل در رایانش فضایی (Spatial Computing) شکست می‌خورد، جایی که کاربران گراف‌های جهت‌دار بدون دور (DAGs) یا گراف‌های چرخه‌ای از گره‌های اجرایی می‌سازند. در این محیط‌ها، حجم‌های کاری غیرخطی هستند و به‌طور موازی اجرا می‌شوند. این بدان معناست که یک حلقهٔ دو ثانیه‌ای در Stable Diffusion بسیار بیشتر از یک فیلتر اصلاح رنگ ده ثانیه‌ای، منابع سخت‌افزاری مصرف می‌کند. هر عملیات پایه — از یک جمع برداری ساده در برنامه‌های شیدر تا یک استنتاج (Inference) چندوجهی عظیم از طریق Transformers.js — هزینه‌ای واقعی در وات، استهلاک سیلیکون و اجاره زیرساخت ابری دارد. این چالش‌ها نشان می‌دهد که چرا بسیاری از هزینه‌های سرسام‌آور GPU را نباید صرفاً به مدل‌ها نسبت داد، بلکه ناکارآمدی پلتفرم‌ها در مدیریت این منابع ریشه اصلی مشکل است.

پل زدن میان میکروسرویس‌ها و اجرای گره‌محور

برای مدیریت این پیچیدگی، این چارچوب صورت‌حساب محاسباتی را از دریچه معماری میکروسرویس‌ها و تله‌متری سیستم‌های توزیع‌شده می‌بیند. همان‌طور که یک معماری میکروسرویس یک برنامه یکپارچه (Monolithic) را به خدمات کوچک و مستقل تقسیم می‌کند، یک موتور جریان کاری بصری نیز تولید رسانه‌های پیچیده را به گره‌های ماژولار خرد می‌کند.

در یک معماری میکروسرویس، هر فراخوانی بین-سرویسی نیازمند ردیابی توزیع‌شده (Distributed Tracing)، تله‌متری و محدودسازی نرخ (Rate Limiting) صریح است تا از شکست‌های زنجیره‌ای جلوگیری شود. به همین ترتیب، در یک موتور جریان کاری سنگین GPU، هر یال داده که دو گره بوم را به هم وصل می‌کند، نشان‌دهنده یک مرز داخلی شبیه به RPC است که در آن باید اعتبارسنجی محاسبات و کسر اعتبار صورت گیرد.

اگر هر گره پردازشی WebGPU یا یک نمونه Transformers.js میزبانی‌شده در مرورگر را به عنوان یک میکروسرویس ایزوله در نظر بگیریم، کل بوم به یک موتور ارکستراسیون سیستم توزیع‌شده تبدیل می‌شود. در این حالت، دفتر کل اعتبار به عنوان یک لاگ تراکنش مرکزی عمل می‌کند تا تضمین شود هر تغییر وضعیت به‌طور اتمیک به یک برداشت قابل تأیید از موجودی حساب کاربر متصل است.

برای حل تضاد قیمت‌گذاری، این چارچوب واحدهای محاسباتی دانه‌ریز (GCU) را معرفی می‌کند. GCU یک واحد ثابت از زمان یا داده نیست، بلکه یک تابع ریاضی نرمال‌شده از میزان بهره‌برداری از منابع است. طبق گزارش dev.to، سیستم GCUها را با وزن‌دهی به چهار معیار سخت‌افزاری اصلی محاسبه می‌کند: عملیات اعشاری در ثانیه (FLOPs)، تخصیص حافظه ویدیویی (VRAM)، پهنای‌باند داده و تعداد توکن (Token) — که مثل برش‌های کوچک یک کیک متن است که مدل می‌خورد. این رویکرد دقیق، در راستای تلاش‌هایی است که برای پایان دادن به غافلگیری‌های مالی در صورت‌حساب‌های مدل‌های تولیدی صورت می‌گیرد.

بردار محاسباتی چندبعدی

مصرف GPU در اینجا به جای یک خط زمانی خطی، به عنوان یک بردار چندبعدی دیده می‌شود. برخلاف عملیات CPU که برای منطق شاخه‌ای و تعویض زمینه (Context Switching) بهینه شده‌اند، GPUها موتورهای موازی عظیمی هستند که برای ضرب ماتریسی، تبدیلات تنسور و شیدینگ موازی پیکسل‌ها طراحی شده‌اند.

وقتی یک خط لوله محاسباتی WebGPU فراخوانی می‌شود، زمان اجرا (Runtime) بافرهای حافظه را تخصیص می‌دهد، کد WGSL (زبان شیدینگ WebGPU) را کامپایل می‌کند، گروه‌های کاری (Workgroups) را اعزام می‌کند و منتظر همگام‌سازی حصار GPU (Fence Synchronization) می‌ماند. بنابراین، مصرف منابع یک بردار چندبعدی شامل موارد زیر است:

• حجم تخصیص VRAM: ردپای فضایی بافت‌ها، بافرهای راس (Vertex Buffers) و وزن‌های مدل که در حافظه دستگاه قرار دارند.
• شدت محاسبات (FLOPs/Cycles): تقاضای پردازشی خام که توسط پیچیدگی شیدر، ابعاد گروه‌های کاری و حلقه‌های پالایش تکراری (مانند مراحل حذف نویز در مدل‌های انتشار) ایجاد می‌شود.
• پهنای‌باند داده: حجم داده‌های منتقل‌شده بین حافظه میزبان CPU و حافظه دستگاه GPU از طریق گذرگاه PCI، یا داده‌هایی که در خط لوله‌های استریم رسانه‌ای در لحظه از طریق سوکت‌های شبکه منتقل می‌شوند.
• هم‌روندی عامل‌ها: تعداد عامل‌های کارگر موازی یا نمونه‌های Transformers.js که به‌طور هم‌زمان در مرورگر کلاینت یا گره لبه (Edge Node) اجرا می‌شوند.

مدل‌های محاسباتی مختص هر گره

این سیستم گره‌ها را به سه مدل محاسباتی متمایز تقسیم می‌کند تا دقت قیمت‌گذاری تضمین شود:

• گره‌های رستریکاسیون و فیلترینگ: این گره‌ها پردازش‌های استاندارد ۲ بعدی و ۳ بعدی تصویر را از طریق شیدرهای فرگمنت WebGL یا WebGPU اجرا می‌کنند. مصرف آن‌ها متناسب با رزولوشن پیکسل‌ها (W x H) و تعداد دفعات رندر است، مانند محاسبات تاری گاوسی چندمرحله‌ای یا محاسبات عمق میدان (Depth-of-Field).
• گره‌های استنتاج عصبی: هزینه‌ها توسط تعداد پارامترها، عمق لایه‌های ترنسفورمر، ابعاد سر attention و طول توکن‌های تولیدشده تعیین می‌شود. این گره‌ها از طریق APIهای سمت سرور یا در سمت کلاینت از طریق Transformers.js با بهره‌گیری از ONNX Runtime Web و ارائه‌دهندگان اجرای WebGPU اجرا می‌شوند. این ساختار لایه‌بندی شده یادآور سیستم‌های استنتاج چندلایه در اپلیکیشن‌های مالی است که برای بهینه‌سازی سرعت و دقت طراحی شده‌اند.
• گره‌های فیزیک و شبیه‌سازی: این گره‌ها شبیه‌سازی ذرات، دینامیک پارچه یا جریان سیالات را از طریق شیدرهای محاسباتی WebGPU اجرا می‌کنند. مصرف آن‌ها با تعداد ذرات، فرکانس تشخیص برخورد و تکرارهای زیر-گام (Sub-stepping) در هر فریم مقیاس می‌یابد.

فرمول نرمال‌سازی GCU

از آنجا که این حجم‌های کاری از پروفایل‌های سخت‌افزاری متفاوتی استفاده می‌کنند — برخی توسط پهنای‌باند VRAM و برخی دیگر توسط توان عملیاتی ALU محدود می‌شوند — سیستم از یک تابع ترکیبی وزنی برای تعریف GCU استفاده می‌کند:

GCU = integral_{t0}^{t1} ( w1 * FLOPs(t) + w2 * VRAM(t) + w3 * Bandwidth(t) + w4 * TokenCount(t) ) dt

در این فرمول:

• FLOPs(t): عملیات اعشاری اجرا شده در ثانیه در گروه‌های کاری فعال GPU.
• VRAM(t): مگابایت‌های حافظه دستگاه که به‌طور فعال توسط رجیسترهای بافت و بافر تخصیص یافته و پین شده‌اند.
• Bandwidth(t): گیگابایت بر ثانیه منتقل شده از طریق گذرگاه CPU-GPU یا سوکت‌های شبکه.
• TokenCount(t): توکن‌های ورودی/خروجی مجزا که توسط Transformers.js یا میکرو-عامل‌های مدل‌های زبانی/انتشاری دوردست پردازش می‌شوند.
• w1-w4: وزن‌های کالیبراسیونی که بر اساس هزینه زیرساختی لایه سخت‌افزاری زیرین تعیین می‌شوند.

اجرا در سمت کلاینت و حاکمیت

یکی از پیچیده‌ترین چالش‌ها، اندازه‌گیری کارهایی است که کاملاً در مرورگر کاربر از طریق WebGPU اجرا می‌شوند. با کتابخانه‌هایی مانند Transformers.js، ارائه‌دهنده ابری هزینه ساعت‌های نمونه GPU را نمی‌پردازد. با این حال، ارائه‌دهنده پلتفرم همچنان در حال پرداخت لایسنس وزن‌های مدل، نگهداری نرم‌افزار ارکستراسیون و ارائه سرورهای سیگنالینگ برای همکاری در لحظه است.

این گزارش استدلال می‌کند که اندازه‌گیری همچنان به سه دلیل ضروری است:

۱. تجاری‌سازی لایسنس و مالکیت معنوی (IP): مدل‌های پریمیوم توزیع شده از طریق پلتفرم نیازمند ردیابی حق امتیاز هستند، زیرا وزن‌های مدل حتی در صورت اجرای محلی، نشان‌دهنده مالکیت معنوی اختصاصی هستند.
۲. مدیریت سهمیه همکاری: در محیط‌های چند-مستاجری (Multi-tenant)، کاربران یک استخر محدود از اعتبارات سازمانی را به اشتراک می‌گذارند. جریان‌های کاری محلی Transformers.js باید از این موجودی کسر شوند تا برابری با اعضای تیمی که از مدل‌های سمت سرور استفاده می‌کنند حفظ شود.
۳. اجماع و تأیید: در بوم‌های همکاری چندعاملی، عامل‌های سمت کلاینت، بردارهای ویژگی میانی یا بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است — را به همتایان خود یا یک گره ناظر مرکزی ارسال می‌کنند. این هماهنگی باعث ایجاد هزینه‌های سیگنالینگ سمت سرور و هزینه‌های ذخیره‌سازی پایگاه داده می‌شود.

مکانیزم‌های اجماع در جریان‌های کاری عاملی

وقتی جریان‌های کاری به سیستم‌های خودمختار چندعاملی تبدیل می‌شوند، صورت‌حساب باید «اجرای گمانه‌زنانه» (Speculative Execution) را هم در نظر بگیرد. برای مثال، اگر کاربر به یک بوم دستور دهد تا یک صحنه سه بعدی تولید کند، سیستم ممکن است عامل A را برای توپولوژی مش سه بعدی، عامل B را برای نقشه‌های بافت PBR از طریق Transformers.js و عامل C را برای کد شیدر WebGPU سفارشی جهت اتصال آن‌ها فعال کند.

از آنجا که عامل‌های زاینده احتمالی (Stochastic) هستند، معماری از الگوی «مکانیزم اجماع» استفاده می‌کند که در آن چندین عامل کارگر به‌طور موازی روی یک زیر-وظیفه یکسان کار می‌کنند. سپس یک گره ناظر یا بازبین، خروجی‌های آن‌ها را در یک محیط WebGPU ایزوله (Sandbox) کامپایل، اجرا و مقایسه می‌کند تا بهینه‌ترین نتیجه را سنتز کند.

این افزونگی (Redundancy) مصرف محاسبات را به‌طور چشمگیری افزایش می‌دهد. اگر سه عامل فعال شوند اما فقط یکی از آن‌ها در نتیجه نهایی نقش داشته باشد، کاربر سه برابر چرخه محاسباتی مصرف کرده است. موتور صورت‌حساب این موارد را به عنوان «زنجیره‌های اجرای گمانه‌زنانه» علامت‌گذاری کرده و یک سیاست حاکمیتی را اعمال می‌کند تا یا کل هزینه محاسبات اکتشافی را دریافت کند یا درصدی از اعتبار را مسترد نماید.

دفتر کل رمزنگاری‌شده اعتبار

برای جلوگیری از شرایط رقابتی (Race Conditions) و دستکاری، این معماری ردیف‌های متغیر پایگاه‌داده (مانند UPDATE balance = balance - X) را کنار گذاشته است. در سیستم‌های با توان عملیاتی بالا، این الگو معیوب است زیرا تکمیل هم‌زمان گره‌های WebGPU می‌تواند باعث تداخل شود، مگر اینکه قفل‌های سنگینی (Heavy Locking) اعمال گردد.

در عوض، یک دفتر کل رمزنگاری‌شده «فقط-افزودنی» (Append-only) پیاده می‌کند. موجودی کاربر هرگز به صورت یک عدد ثابت ذخیره نمی‌شود، بلکه به‌طور پویا از طریق جمع زدن (Folding) یک توالی کامل از رویدادهای تراکنشی تغییرناپذیر از ابتدای زمان استخراج می‌شود. هر بلوک در این دفتر کل شامل موارد زیر است:

• شناسه تراکنش: یک UUIDv4 منحصر‌به‌فرد.
• برچسب زمانی: برچسب زمانی یکنواخت (Monotonic) با دقت بالا.
• شناسه بازیگر: شناسه‌ی کاربر یا حساب سرویس.
• نوع عملیات: دسته‌بندی (مثلاً WEBGPU_COMPUTE_PASS، TRANSFORMERS_INFERENCE، CREDIT_TOPUP، REFUND_SPECULATIVE).
• دلتا: مقدار علامت‌دار اعتبارات اضافه یا کسر شده.
• هش متاداده: یک هش رمزنگاری SHA-256 از پارامترهای اجرا، هش دارایی‌های ورودی و تله‌متری سخت‌افزار.
• هش قبلی: هش بلوک پیشین که یک زنجیره ضد-دستکاری تشکیل می‌دهد.

پیاده‌سازی دفتر کل در تایپ‌اسکریپت

برای تضمین مطلق ضد-دستکاری، دفتر کل از Web Crypto API استفاده می‌کند. اگر هر تراکنش محاسباتی تاریخی تغییر کند، metadataHash آن تغییر کرده و پیوند previousHash برای هر بلوک بعدی می‌شکند و فوراً تأیید یکپارچگی زنجیره را باطل می‌کند.

این پیاده‌سازی از یک متد deriveBalance استفاده می‌کند که زنجیره را بر اساس actorId فیلتر کرده و از یک کاهش تابعی (Functional Reduction) برای محاسبه موجودی فعلی استفاده می‌کند. این امر تضمین می‌کند که وضعیت مالی نتیجه مستقیم یک لاگ رویداد تغییرناپذیر است، نه یک متغیر قابل تغییر.

مدارشکن‌های توقف خودکار

برای محافظت در برابر حلقه‌های اجرای «فرار» — مانند زمانی که کاربر خروجی متن-به-تصویر را دوباره به ورودی همان گره وصل می‌کند یا یک حلقه انیمیشن با فرکانس بالا را پیکربندی می‌کند که شیدرها را با سرعت ۱۲۰ فریم در ثانیه اعزام می‌کند — سیستم از یک مکانیزم دفاعی دو لایه الهام گرفته از مهندسی برق استفاده می‌کند.

یک مدارشکن توقف خودکار (Auto-Pause Circuit Breaker) «سرعت سوختن» (GCU در ثانیه) را در لحظه رصد می‌کند تا از اتمام VRAM، اشباع پهنای‌باند شبکه و ورشکستگی حساب جلوگیری کند. این مدارشکن در سه حالت عمل می‌کند:

۱. بسته (Closed): عملیات عادی که در آن محاسبات آزادانه جریان می‌یابند و تله‌متری در دسته‌های کوچک (Micro-batches) به دفتر کل ارسال می‌شود.
۲. باز (Open): مدار زمانی می‌پرد که نرخ سوختن از یک آستانه ایمنی فراتر رود یا موجودی اعتبار به کف برسد. این حالت فوراً جریان اجرا را قطع می‌کند، حقوق ارسال بافر دستور WebGPU را لغو می‌کند، رشته‌های کارگر Transformers.js را متوقف کرده و بوم را در حالت فقط-خواندنی یا متوقف قفل می‌کند.
۳. نیمه‌باز (Half-Open): یک حالت آزمایشی که اجازه می‌دهد یک گره تست واحد اجرا شود تا پایداری منابع پس از شارژ مجدد حساب یا رفع حلقه بازگشتی توسط کاربر تأیید شود.

مهندسی مدارشکن

در یک پیاده‌سازی سطح تولید با تایپ‌اسکریپت، کلاس AutoPauseCircuitBreaker رویدادهای مصرف (consumptionEvents) را در یک پنجره ارزیابی خاص (evaluationWindowMs) رصد می‌کند. این کلاس رویدادهای خارج از این پنجره را حذف می‌کند تا نرخ سوختن فعلی را محاسبه کند.

اگر burnRatePerSecond از مقدار maxBurnRatePerSecond تعریف شده در پیکربندی فراتر رود، متد trip() فراخوانی می‌شود. این متد باعث فعال شدن onTripListeners می‌شود که می‌توانند فوراً حلقه رندر WebGPU و هندلرهای پیام کارگر را متوقف کنند و از سرمایه کاربر و پایداری زیرساخت محافظت نمایند.

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

این چارچوب، فرض صنعت را از صورت‌حساب «زمان روی دستگاه» به صورت‌حساب «شدت منابع» تغییر می‌دهد. برای توسعه‌دهندگان، این به معنای توانایی ارائه ابزارهای پیچیده و عاملی بدون ریسک هزینه‌های فاجعه‌بار زیرساختی یا ورشکستگی کاربر است. برای پیاده‌سازی این الگوها، مهندسان باید ادغام Web Crypto API برای یکپارچگی دفتر کل و همگام‌سازی حصار WebGPU برای جمع‌آوری دقیق تله‌متری را بررسی کنند.

گام بعدی شما

• اگر توسعه‌دهنده ابزارهای AI هستید، به جای صورت‌حساب ساعتی، مدل قیمت‌گذاری مبتنی بر «شدت منابع» را بررسی کنید.
• برای تضمین امنیت تراکنش‌های مالی در سیستم‌های توزیع‌شده، از Web Crypto API برای ساخت دفاتر کل تغییرناپذیر استفاده کنید.
• مکانیزم‌های مدارشکن (Circuit Breaker) را برای جلوگیری از مصرف تصادفی و فاجعه‌بار منابع در جریان‌های کاری بازگشتی پیاده کنید.

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