Ito ay maaaring ang panahon na hinintay ng AMD.
Kahit na ang Wafer AI ay in-deploy sa AMD MI355X Kimi K3. Ang resulta ay, ang modelo na kailangan ng 16 na NVIDIA B200 na nakakabit sa dalawang server, ay maaari na ngayong i-deploy sa isang AMD server na may 8 na MI355X.
Mas mahalaga pa, hindi lang ito isinama ang modelo.
Sa pagsubok na may 1,024 token na input at 400 token na output, ang MI355X ay nakamit ng kabuuang throughput na 952 token/s, na may isang user na generation speed na 118 token/s.
Batay sa isang node, ang throughput nito ay halos 3.8 beses ang dami ng 16 B200 configuration, at mas mataas pa ang value for money kaysa sa B200 at B300.
At ang pinakamasidhi ay ang ROCm ay hindi nagdulot ng anumang malaking pagbabago sa pagkakataong ito.
Ang model ay masyadong malaki, ang VRAM ay nagsisimula na naingatan kaysa sa computing power
Kimi Ang K3 ay may 2.8 trilyon na parameter, kailangan ng higit sa 1.5 TB na VRAM para sa mga timbang ng modelo lamang, hindi kasama ang KV Cache na kailangan para sa milyon-milyon na token na konteksto.
Isang server na may 8 na B200 GPU, bawat isa ay may 192 GB na VRAM, na may kabuuang kapasidad na humigit-kumulang 1.5 TB. Ibig sabihin, mahirap i-save ang lahat ng model weights, at mas mahirap pa mag-iwan ng espasyo para sa KV Cache. Kaya, kailangan ng B200 na gumamit ng dalawang server at 16 na GPU.
May 288 GB ng VRAM bawat B300, kaya maaaring i-fit ang model sa isang node. Nakakatuwid, mayroon din ang AMD MI355X ng 288 GB ng VRAM, at ang 8 na MI355X ay magkakaroon ng halos 2.3 TB, sapat na sa isang server.
Hindi ito tungkol sa paggamit ng isang maliit na machine. Pagkatapos mag-run ang model sa iba’t ibang node, bawat pagbuo ng Token ay maaaring kailanganin ang pag-sync ng data sa pamamagitan ng network. Kahit na gumagamit ng RoCE v2 network na may bilis na halos 195 Gb/s, ang komunikasyon sa pagitan ng nodes ay maaaring magdulot ng pagbagsak sa decoding.
Ang MI355X ay nag-iisa sa isang node gamit ang mas malaking VRAM para sa buong modelo.
Batay sa huling resulta, ang kabuuang peak throughput ng 8 MI355X ay umabot sa 952 Token/s, na may isang path generation speed na 118 Token/s.
Para sa paghahambing, ang kabuuang throughput ng dual-node deployment ng 16 B200 ay 498 Token/s, na katumbas ng halos 249 Token/s bawat node.
Ibig sabihin, ang single-node throughput ng MI355X ay halos 3.8 beses ang laki ng average single-node throughput ng B200 dual-node deployment. Sa aspeto ng single-user generation speed, ang 118 Token/s ng MI355X ay mas mataas kaysa sa 90 Token/s ng B200.
Ang B300 ay patuloy na ang pinakamataas na performance. Ang kabuuang throughput ng node na may 8 B300 ay umabot sa 1568 Token/s, na may isang path generation speed na 172 Token/s, na halos 1.65 beses ang kabuuang throughput kumpara sa MI355X.
Ngunit nagbago ang presyo ang konklusyon. Ikinukwenta ng Wafer ang ₱2.50 bawat kard bawat oras para sa MI355X, ₱4.25 para sa B200, at ₱6 para sa B300.
Sa ilalim ng ipinagpalagay na presyong ito, ang MI355X ay maaaring magbigay ng halos 48 Token/s na peak throughput bawat dolyar; ang B200 ay halos 7 Token/s; ang B300 ay halos 33 Token/s.
Mas mabilis ang B300, ngunit mas mataas ang efficiency ng unit cost ng MI355X. Para sa mga data center na nangangailangan ng malaking pagsasagawa ng open models, maaaring mas mahalaga ito kaysa sa pagpapalaban para sa pinakamataas na performance.
Mas nakakagulat pa, maaari na lamang gamitin ang ROCm nang direkta
Sa matagal nang panahon, ang pinakamalaking problema ng AMD data center GPU ay madalas hindi ang hardware, kundi ang software.
Ang parehong modelo ay maaaring tumakas nang direkta sa CUDA, ngunit sa ROCm, maaaring kailanganin ang pagbabago ng framework, pagdaragdag ng operator, o kaya ay pagsusulit muli ng mga core sa ilalim.
pero Kimi Iba ang sitwasyon ng K3.
Binigyan ng AMD ang malapit na suporta sa synchronous launch. Sinabi ng Wafer na ang mga modelo ay direktang maaaring i-run sa MI355X, at ang mga susunod na gawain ay nakatuon sa kaunting mga problema sa compatibility at performance optimization.
Isang problema ay lumabas sa bahagi ng paghula ng decoding. Kimi Hindi nagbibigay ang K3 ng mga parameter ng draft model na kailangan ng MTP o EAGLE, kaya gamit ng Wafer isang panlabas na draft model na block diffusion.
Direktang nagpapatakbo ang solusyong ito sa CUDA, ngunit sa ROCm environment, ang unang tunay na hiling ay nagdudulot ng error sa scheduler. Ang dahilan ay kulang ang isang function na tinatawag na top_k_renorm_prob sa ROCm branch.
Hindi komplikado ang ginagawa ng function na ito: pumili ng mga pinakamataas na k na halaga mula sa probability distribution, i-zero ang iba pang mga probabilidad, at i-re-normalize ang mga pinanatili na probabilidad.
Ginamit ni Wafer ang isang karaniwang PyTorch function upang mabuo ang logika na ito, nang walang kailangang isulat ang GPU kernel sa kamay o muling disenyo ang system ng speculative decoding.
Pagkatapos ng pagpapabuti, inaasahang tumataas ang single-threaded performance ng humigit-kumulang 2.2 beses, ang single-stream performance sa medium concurrency ng humigit-kumulang 1.7 beses, at ang peak total throughput ay tumataas ng humigit-kumulang 18%.
Mas mahalaga, ang sistema ay makakamit ng peak throughput sa mas mataas na concurrency.
Masyadong mabagal ang unang titik, kaya lang nagdagdag ng apat na zero.
Hindi lamang ang throughput ang lahat ng isang inference service. Para sa mga tunay na user, isa pang direktang indikador ng karanasan ay ang TTFT, o ang oras na inaasam mula sa pagpapadala ng kahilingan hanggang sa pagkakita ng unang Token.
Sa item na ito, hindi nagtagumpay nang maayos ang MI355X mula sa simula. Sa harap ng isang cold start pre-fill task na may halos 172,000 Token, kailangan ng MI355X ng halos 51 segundo, samantalang ang B300 ay kailangan lang ng halos 23 segundo.
Sa isang modelo na sumusuporta sa milyon-milyong token na konteksto, ang pre-filling task ay maaaring napakalaki. Kung ang mga user ay kailangang maghintay ng ilang sampung segundo o higit pa bawat beses habang inaaproso ang mahabang konteksto, kahit gaano pa kalakas ang decoding speed, hindi ito makakatulong sa pagpapabuti ng user experience.
Natuklasan ng Wafer na ang pagkakaiba sa performance ay halos buo sa isang attention kernel. Kimi Sa 8-way tensor parallel configuration, ang bawat GPU ay makakatanggap ng 12 attention heads. Ang mas mabilis na MLA prefill kernel sa AMD AITER ay sumusuporta lamang sa mga hugis na multiple ng 4, 8, o 16.
Hindi makapag-match ang 12 na heads, kaya bumalik ang sistema sa mas mabagal na pangkalahatang Triton implementation.
Ang solusyon ay simpleng: punan ang 12 mga attention head ng zero hanggang 16, gamitin ang umiiral na high-speed kernel, at pagkatapos ng computation, kunin ang tunay na kailangang 12 mga head. Walang pagbabago sa istruktura ng modelo, walang pagsusulat ng bagong assembly kernel, tanging idinagdag ang apat na zero.
Pagkatapos ng pag-optimize, ang stabilong prefill speed ng AITER MLA kernel ay umabot sa halos 13,000 Token/s, habang ang dating Triton fallback path ay nasa paligid ng 4,000–7,000 Token/s lamang, kaya nabawasan ang cold prefill time ng halos dalawa hanggang tatlong beses.
Hindi magbabago ang optimal na throughput ng pag-decode, ngunit makakabawas nang malaki sa oras na inaantay ng user para makita ang unang titik.
Ito ay nagpapakita rin na ang malaking pagkakaiba sa software sa pagitan ng AMD at NVIDIA ay minsan ay hindi dahil sa kakulangan sa pundamental na kakayahan, kundi dahil ang mga kasalukuyang mabilis na kernel ay hindi pa nakakapag-coverage sa isang bagong anyo ng modelo.
Ang mga parapet ng CUDA ay nananatili, ngunit may mga puwang na lumabas na
Hindi makakatotohanan ang isang pagsubok na patunay na kinabigyan na ng buo ni AMD ang NVIDIA.
Ang B200 ay forced na mag-run sa ibang node dahil sa kakulangan ng VRAM; ang absolute performance ng B300 ay patuloy na nangunguna; ang ROCm toolchain, framework support, at developer ecosystem ay patuloy na mas mababa kaysa sa CUDA.
Ngunit ang mga bukas na modelo ay mabilis na pumasok sa era ng trilyon na parameter. Kapag malaki ang modelo hanggang sa hindi ito makakapaskil sa isang server, ang kapasidad ng VRAM ay hindi na lamang isang numero sa isang talaan ng parameter, kundi direktang nakakaapekto sa gastos sa komunikasyon, kumplikadong pag-deploy, at huling throughput.
Ang estratehiya ng AMD na bigyan ng higit pang HBM ang single-GPU setup ay nagsisimulang maging isang tunay na sistema advantage.
Kung maaari ng AMD na patuloy na pabuting ang katatagan ng ROCm, palawakin ang suporta sa mga hugis ng high-speed cores, at magbigay ng mas mabilis na first-day compatibility para sa mga bagong model, kailangang isipin ng mga data center ang mga GPU na ito. Mas mura ang presyo, mas malaki ang VRAM, sapat ang performance, at hindi na kailangang magpapahinga ng ilang buwan ang software.
Ano ang iyong opinyon dito?
Link ng referensya:
https://x.com/wafer_ai/status/2083628389903315406
https://x.com/ChiragAsarpota/status/2083864019870634151
Ang artikulong ito ay mula sa WeChat public account na “Machine Heart” (ID: almosthuman2014), may-akda: Mga nagmamalasakit sa LLM