Dev Tweet: post #414 — TG.ME

سریع‌تر از GPU؛ اما چطور؟! — بخش دوم

این روند فقط به Cerebras محدود نیست. چند شرکت دیگر به همان مسئله‌ی جابه‌جایی داده، latency و هزینه‌ی inference حمله کرده‌اند، اما هرکدام از زاویه‌ای متفاوت.

در رویکرد Groq، مسئله این است که GPU برای انعطاف‌پذیری بالا طراحی شده و اجرای کارها را در لحظه زمان‌بندی می‌کند. Groq معماری را deterministicتر کرده؛ یعنی مسیر اجرای عملیات تا حد زیادی از قبل توسط compiler مشخص می‌شود و مقدار زیادی SRAM سریع هم نزدیک واحدهای پردازشی قرار دارد. حاصل، latency قابل‌پیش‌بینی‌تر و سرعت بالای تک‌کاربر است، بدون اینکه برای throughput خوب الزاماً مجبور باشید تعداد زیادی درخواست را batch کنید. از نظر هزینه هم مهم است: batching معمولاً cost per token را پایین می‌آورد ولی latency را بالا می‌برد؛ اگر سخت‌افزار با batch کوچک هم utilization خوبی داشته باشد، این trade-off ضعیف‌تر می‌شود. البته برای مدل‌های بسیار بزرگ باید تعداد زیادی LPU به هم متصل شوند و مزیت هزینه‌ای در هر مقیاسی تضمین‌شده نیست. Nvidia هم فناوری Groq را license کرده و تعدادی از مدیران اصلی آن را جذب کرده است.

در معماری d-Matrix ایده رادیکال‌تر است. در سیستم عادی، داده از memory به واحد محاسباتی می‌رود، ضرب ماتریسی انجام می‌شود و نتیجه دوباره برمی‌گردد. d-Matrix با Digital In-Memory Compute بخشی از محاسبه را به محل نگهداری داده نزدیک می‌کند. انتقال داده یکی از بخش‌های پرمصرف inference است، بنابراین کم‌کردن این رفت‌وآمد می‌تواند هم joule per token و هم cost per token را پایین بیاورد. خود شرکت برای Corsair در برخی مقایسه‌ها چند برابر بهبود cost-performance و efficiency نسبت به H100 گزارش کرده، هرچند این‌ها عمدتاً benchmarkهای خود شرکت‌اند.

در رویکرد SambaNova فرض دیگری شکسته می‌شود: اینکه تمام مراحل inference باید روی یک نوع پردازنده اجرا شوند. مرحله‌ی prefill که prompt را می‌خواند محاسباتی و بسیار parallel است و GPU در آن خوب عمل می‌کند؛ اما decode که tokenها را یکی‌یکی می‌سازد بیشتر به پهنای باند حافظه و latency حساس است. SambaNova در یک سیستم disaggregated، B200 را برای prefill و RDU خودش را برای decode استفاده کرده و Artificial Analysis سرعتی حدود دو برابر پیکربندی B200-only گزارش کرده است. از نظر اقتصادی هم هر مرحله می‌تواند روی سخت‌افزاری اجرا شود که performance-per-dollar و performance-per-watt بهتری برای همان کار دارد.

در مسیر Etched، هزینه‌ی general-purpose بودن هدف قرار گرفته است. GPU باید برای طیف بزرگی از برنامه‌ها مناسب باشد، اما Sohu مشخصاً برای Transformer طراحی شده است. وقتی سخت‌افزار فقط یک خانواده‌ی محدود از عملیات را لازم دارد، بخش بیشتری از سطح چیپ و توان مصرفی می‌تواند صرف همان محاسبات شود. نتیجه‌ی بالقوه throughput بیشتر و هزینه و انرژی کمتر به‌ازای token است، اما flexibility کاهش می‌یابد؛ اگر معماری غالب مدل‌ها عوض شود، ASIC تخصصی خیلی سخت‌تر از GPU با آن سازگار می‌شود.

در نهایت Taalas این تخصصی‌سازی را تا مرز محوکردن فاصله‌ی software و hardware می‌برد. بخشی از اطلاعات مدل مستقیماً وارد طراحی silicon می‌شود. نمونه‌ی HC1 آن‌ها Llama 3.1 8B را با حدود ۱۷ هزار token/s اجرا کرده است. شرکت ادعا می‌کند سیستمش حدود ۱۰ برابر انرژی کمتر و نزدیک ۲۰ برابر هزینه‌ی ساخت پایین‌تر از راه‌حل‌های متعارف دارد؛ اعدادی که هنوز ادعای خود شرکت‌اند. trade-off هم روشن است: اگر مدل عوض شود، سخت‌افزار به اندازه‌ی GPU قابل استفاده‌ی مجدد نیست. این روش وقتی اقتصادی‌تر می‌شود که یک مدل ثابت در مقیاس بسیار بزرگ و برای مدت طولانی اجرا شود. AMD هم اخیراً Taalas را خریده تا فناوری آن را در کنار Instinct GPUها توسعه دهد.

بنابراین تفاوت این شرکت‌ها فقط در تعداد token در ثانیه نیست. هرکدام بخشی از هزینه‌ی معماری فعلی را هدف گرفته‌اند: Cerebras ارتباط بین تعداد زیادی چیپ را، Groq scheduling و latency را، d-Matrix رفت‌وآمد memory را، SambaNova استفاده از یک سخت‌افزار واحد برای دو مرحله‌ی متفاوت را، و Etched و Taalas general-purpose بودن را.
به همین دلیل احتمالاً آینده‌ی inference به جای «جایگزینی GPU با یک چیپ دیگر»، به سمت دیتاسنترهای heterogeneous می‌رود: GPU برای training و prefill، acceleratorهای memory-centric برای decode و شاید siliconهای بسیار تخصصی برای مدل‌های پرتکرار. در چنین مدلی معیار مهم دیگر فقط FLOPS یا حتی token/s نیست؛ معیار واقعی این است که برای یک مقدار مشخص کار مفید، چند دلار هزینه می‌کنیم، چند ژول انرژی مصرف می‌شود و کاربر چقدر منتظر می‌ماند.
👍5
August 20, 2026 261 2 8