Tekoälyn laskentateho on jakautunut kahteen leiriin. Toisella puolella on Nvidia, joka myy GPU-siruja kaikille halukkaille markkinahintaan. Toisella puolella ovat pilvijätit, jotka rakentavat omia siruja vain omaan käyttöönsä, ohittaen Nvidian marginaalin kokonaan. Google aloitti tämän tien ensimmäisenä vuonna 2015 omalla TPU-arkkitehtuurillaan, ja lokakuussa 2026 sen seitsemäs sukupolvi, koodinimeltään Ironwood, pyörittää jo merkittävää osaa Googlen omista tekoälypalveluista, kuten Gemini-mallien inferenssiä. AWS seuraa perässä omalla kolmannella Trainium-sukupolvellaan, joka on nyt tarjolla Trn3 UltraServer -järjestelminä EC2:n kautta.
Molemmat yhtiöt väittävät piirinsä olevan kustannustehokkain tapa ajaa suuria kielimalleja, ja molemmilla on sama suurasiakas, joka käyttää kumpaakin alustaa rinnakkain: Anthropic. Se on jo itsessään merkki siitä, että kyse ei ole enää vain siitä, kuka kaataa Nvidian markkinaosuuden, vaan siitä, kumpi mukautettu piiri tarjoaa suomalaiselle tai pohjoismaiselle pilviostajalle parhaan euron vastineen jokaista käsiteltyä tokenia kohden.
Tämä artikkeli vertaa Google TPU v7 Ironwoodia ja AWS Trainium3:a kaikilla mittareilla, joilla ne voidaan oikeasti verrata: laskentateho, muistikapasiteetti, kaistanleveys, pilviveloitus, ohjelmistoekosysteemi, klusteriarkkitehtuuri ja todelliset käyttöönotot. Kaikki luvut on merkitty sen mukaan, ovatko ne valmistajan oma ilmoitus vai riippumattoman kolmannen osapuolen mittaus, tämä ero on olennainen, kun vertaillaan kahta yhtiötä, jotka molemmat myyvät omaa piiriään parhaalla mahdollisella valolla.
Lukijalle, joka ei seuraa piiriuutisia päivittäin, kannattaa muistaa yksi perusasia: TPU ja Trainium eivät ole ostettavissa laitteina, joita asentaisi omaan konesaliin, niin kuin esimerkiksi Nvidian RTX- tai näytönohjainsarjan tuotteita. Molemmat ovat saatavilla vain pilvipalveluna, Google Cloudin tai AWS:n kautta, mikä tekee tästä vertailusta ennen kaikkea pilvivalinnan, ei laitteistohankinnan vertailua perinteisessä mielessä.
Miksi pilvijätit rakentavat omia tekoälysiruja
Tausta on taloudellinen, ei vain tekninen. Nvidian GPU-sirujen hinnat ja saatavuus ovat olleet jatkuvan paineen alla vuosina 2025–2026, kun muistipula (erityisesti HBM- ja GDDR7-kapasiteetin rajallisuus) on nostanut hintoja läpi toimialan. Pilviyhtiö, joka vuokraa Nvidia-GPU:ita asiakkailleen, maksaa ensin Nvidian hinnan ja lisää sen päälle oman katteensa, mutta jos yhtiö suunnittelee oman sirunsa, se maksaa vain valmistuksen ja piirisuunnittelun, ei kolmannen osapuolen voittomarginaalia.
Google oli ensimmäinen, joka lähti tälle polulle: TPU v1 julkaistiin sisäiseen käyttöön vuonna 2015, ja yhtiö on sen jälkeen julkaisenut uuden sukupolven suunnilleen vuoden tai parin välein. Ironwood on tämän linjan seitsemäs julkinen sukupolvi, ja ensimmäinen, joka on suunniteltu alusta alkaen puhtaasti inferenssikäyttöön eikä mallien kouluttamiseen. AWS lähti vastaavalle polulle myöhemmin: ensimmäinen Trainium julkaistiin 2020, ja Trainium3 on kolmas sukupolvi tässä perheessä. Molemmat yhtiöt perustelevat investointinsa samalla logiikalla, oma piiri antaa täyden kontrollin koko pinoon piiristä ohjelmistoon asti, ja säästö siirtyy joko omaan käyttöön (Google Gemini, AWS:n sisäiset palvelut) tai ulkoisille asiakkaille alemman pilvihinnan muodossa.
TPU- ja Trainium-sukupolvien historia lyhyesti
Kumpikin sirulinja on tulos vuosien kehitystyöstä, ei yhden vuoden hankkeesta. Google on julkaisenut TPU-sukupolven suunnilleen vuoden tai parin välein vuodesta 2015 lähtien, ja jokainen sukupolvi on tuonut sekä raakatehon kasvua että arkkitehtonisia muutoksia, esimerkiksi siirtymän koulutusoptimoiduista piireistä (kuten TPU v5p) kohti inferenssioptimoitua Ironwoodia. AWS aloitti Trainium-linjansa myöhemmin, vuonna 2020, ja on sen jälkeen julkaisenut kolme sukupolvea tiiviimmällä aikataululla, osittain vastatakseen Googlen ja Nvidian etumatkaan.
| Sukupolvi | Google TPU | AWS Trainium |
|---|---|---|
| Ensimmäinen julkinen sukupolvi | TPU v1 (2015, sisäinen käyttö) | Trainium1 (2020) |
| Edellinen sukupolvi ennen nykyistä | TPU v6 “Trillium” | Trainium2 |
| Nykyinen sukupolvi (lokakuu 2026) | TPU v7 “Ironwood” | Trainium3 |
| Väitetty laskentatehon kasvu edeltäjään | ~4x Trillium-sukupolveen (Googlen oma ilmoitus) | 2x Trainium2:een (AWS:n oma ilmoitus) |
| Suunnittelupainotus | Siirtymä koulutuksesta inferenssiin | Koulutus ja inferenssi samassa piirissä |
Tämä historiallinen konteksti selittää, miksi suora sukupolvi-vs-sukupolvi-vertailu on hankalaa: Google ja AWS optimoivat piirejään hieman eri tavoitteisiin. Google on viimeisen parin sukupolven aikana erikoistunut yhä selkeämmin inferenssiin, kun taas AWS pitää Trainiumin yleiskäyttöisempänä, molempiin käyttötarkoituksiin sopivana piirinä. Kumpikaan lähestymistapa ei ole yksiselitteisesti oikea, ne heijastavat sitä, millaista työkuormaa kummankin yhtiön oma pilviliiketoiminta pääasiassa ajaa.
Mikä on Google TPU v7 Ironwood?
Google esitteli Ironwoodin huhtikuussa 2025, mutta kaupallinen saatavuus Google Cloudissa alkoi vasta 22. huhtikuuta 2026. Ironwood on Googlen ensimmäinen TPU-sukupolvi, joka on rakennettu puhtaasti inferenssiä silmällä pitäen eli valmiin mallin ajamista, ei sen kouluttamista. Piirissä on kaksi erillistä laskentakiekkoa (compute die) samassa paketissa, kumpikin ajaa omaa logiikkaansa, ja yhdessä ne muodostavat yhden loogisen TPU-sirun. Tämä kaksoiskiekkorakenne on yksi syy, miksi Google pystyi nostamaan laskentatehon niin paljon edellisestä sukupolvesta kasvattamatta yksittäisen kiekon kokoa mahdottomaksi valmistaa.
Google kertoo yhden Ironwood-sirun tarjoavan 4 614 TFLOPS huippu-FP8-laskentatehoa, mikä on yhtiön mukaan noin nelinkertainen määrä edeltäjään Trillium-sukupolveen (TPU v6) verrattuna. BF16-tarkkuudella luku on 2 307 TFLOPS. Jokaisessa sirussa on 192 gigatavua HBM3e-muistia ja noin 7,37 teratavua sekunnissa kaistanleveyttä. Sirujen välinen Inter-Chip Interconnect (ICI) -verkko tarjoaa noin 1,2 Tt/s kaksisuuntaista kaistaa, ja koko järjestelmä on rakennettu 3D-torus-topologiaan, joka minimoi hyppyjen määrän kaukaisimpien sirujen välillä.
Perusyksikkö on 64 sirun kuutio (4×4×4), ja optiset piirikytkimet yhdistävät näitä kuutioita toisiinsa, kunnes koko superpod kasvaa 9 216 siruun. Googlen omien lukujen mukaan tämä kokoonpano tuottaa 42,5 exaflopsia FP8-laskentatehoa, yhtiö vertasi tätä suoraan maailman tehokkaimpaan supertietokoneeseen El Capitaniin, joka tarjoaa noin 1,7 exaflopsia, eli Ironwood-pod on Googlen oman laskennan mukaan yli 24-kertainen. Native FP8 -tuki laitteistotasolla on myös uusi ominaisuus: aiemmat TPU-sukupolvet tukivat matalaa tarkkuutta ohjelmistotasolla, mutta Ironwood on ensimmäinen, jossa FP8-laskenta on rakennettu suoraan piiriin.
Mikä on AWS Trainium3?
AWS julkisti Trainium3:n tuotetiedot 13. toukokuuta 2026, ja syys-lokakuussa 2026 AWS päivitti Trn3-tuotesivujaan tarjonnan laajentuessa. Toisin kuin Google, joka myy TPU:ta pääasiassa suorana sirukapasiteettina, AWS markkinoi Trainium3:a ensisijaisesti Amazon EC2 Trn3 UltraServer -kokonaisuuksina, joissa useita siruja yhdistetään yhdeksi palvelinjärjestelmäksi ja myydään osana AWS:n laajempaa pilvi-infrastruktuuria.
AWS:n oman ilmoituksen mukaan Trainium3 tarjoaa 2,52 petaflopsia FP8-laskentatehoa per siru, 144 gigatavua HBM3e-muistia ja 4,9 teratavua sekunnissa kaistanleveyttä. AWS vertaa näitä lukuja suoraan edeltäjä Trainium2:een: kaksinkertainen laskentateho, 1,5-kertainen muistikapasiteetti ja 1,7-kertainen kaistanleveys. Trainium3 tukee useita laskentamuotoja, mukaan lukien MXFP8, FP8 ja FP16/BF16, mutta AWS ei ole julkaissut suoraan vertailukelpoista BF16-huippulukua samalla tarkkuudella kuin Google. Toissijaisten teknisten yhteenvetojen mukaan Trainium3 on valmistettu 3 nanometrin prosessilla, mutta AWS ei vahvista tätä suoraan omilla tuotesivuillaan, joten tieto kannattaa lukea raportoituna, ei virallisesti vahvistettuna.
Trainium-strategian ydin on hinta, ei huipputeho. AWS on vuosia markkinoinut Trainium-siruja vaihtoehtona Nvidia-GPU:iden pilvivuokrauksen hintapaineelle, ja Trainium3 jatkaa samaa linjaa: vähemmän raakaa laskentatehoa per siru kuin Ironwoodilla, mutta tiiviimpi integraatio AWS:n omaan pilvi-infrastruktuuriin, tallennusjärjestelmiin ja Neuron-ohjelmistopinoon. Tämä on sama logiikka, jolla AWS on aiemmin markkinoinut omia Graviton-prosessoreitaan Intel- ja AMD-vaihtoehtojen rinnalla: ei paras mahdollinen raakateho, vaan paras kokonaiskustannus sille asiakkaalle, joka on jo AWS:n ekosysteemissä.
Tekniset tiedot vertailussa
Seuraava taulukko kokoaa molempien sirujen julkaistut tekniset tiedot samaan paikkaan. Osa Ironwoodin luvuista on peräisin Googlen omasta blogista, osa riippumattomista teknisistä analyyseistä, kuten SemiAnalysisin InferenceX-tietokannasta. Taulukko sisältää myös rivejä, joissa toinen osapuoli ei ole julkaisenut vertailukelpoista lukua, tämä on tarkoituksella jätetty näkyviin, koska se on itsessään merkittävä ero yhtiöiden avoimuudessa. Lukijan kannattaa kiinnittää huomiota erityisesti siihen, kumpi yhtiö on valmis julkaisemaan tarkan luvun ja kumpi pysyy yleisemmällä tasolla, tämä ennustaa usein myös sitä, kuinka paljon neuvotteluvaraa myyjällä on, kun ostaja pyytää tarjousta suurelle kapasiteetille.
| Ominaisuus | Google TPU v7 Ironwood | AWS Trainium3 |
|---|---|---|
| Huippu-FP8-laskentateho / siru | 4 614 TFLOPS | 2 520 TFLOPS (2,52 PFLOPS) |
| Huippu-BF16-laskentateho / siru | 2 307 TFLOPS | Ei julkaistua suoraa lukua |
| HBM-muistikapasiteetti / siru | 192 Gt HBM3e | 144 Gt HBM3e |
| Muistin kaistanleveys / siru | ~7,37–7,4 Tt/s | 4,9 Tt/s |
| Sirujen välinen verkko | ICI, 3D-torus, ~1,2 Tt/s kaksisuuntainen | Ei julkista per-siru-lukua |
| Suurin vahvistettu klusterikoko | 9 216 sirua / superpod | Ei vastaavaa vahvistettua pod-lukua |
| Klusterin huippu-FP8-teho | 42,5 exaflopsia (9 216 sirua) | Ei julkaistua kokonaislukua |
| Valmistusprosessi | Ei julkaistu Googlen lähteissä | Raportoitu 3 nm (ei AWS:n vahvistama) |
| Myyntimalli | Suora sirukapasiteetti Google Cloudissa | EC2 Trn3 UltraServer -kokonaisuudet |
| Kaupallinen saatavuus | 22.4.2026 | Tuotesivu julkaistu 13.5.2026, laajennettu syys–lokakuussa 2026 |
| Ensisijainen ohjelmistokehys | JAX / PyTorch-XLA | PyTorch / Neuron SDK |
| Ensisijainen käyttötarkoitus | Inferenssi (myös koulutus) | Koulutus ja inferenssi |
| Tunnettu suurasiakas | Anthropic, Google itse (Gemini) | Anthropic (Project Rainier) |
Raakalukujen perusteella Ironwood voittaa jokaisen yksittäisen sirun mittauksen, jolla molemmat ovat julkaisseet luvun: 83 % enemmän FP8-laskentatehoa (4 614 vs 2 520 TFLOPS), 33 % enemmän muistia (192 Gt vs 144 Gt) ja 50 % enemmän kaistanleveyttä (7,37 Tt/s vs 4,9 Tt/s). Tämä ei kuitenkaan tarkoita, että Ironwood voittaisi automaattisesti jokaisen käytännön työkuorman, AWS:n Trn3 UltraServer-arkkitehtuuri on suunniteltu nimenomaan integroitumaan AWS:n muuhun pilveen, mikä voi kompensoida raakatehon eroa kokonaiskustannuksissa, kun mukaan lasketaan tallennus, verkko ja hallintatyökalut.
Suorituskyky ja benchmarkit: mitä riippumattomat testit kertovat
Suorin riippumaton vertailu tulee SemiAnalysisin InferenceX-benchmarkista, joka testasi Qwen3.5 397B -kielimallia FP8-tarkkuudella. Palvelunopeudella 100 tokenia sekunnissa käyttäjää kohden Ironwood tuotti 0,181 dollaria miljoonaa tokenia kohden, Nvidian B200 0,222 dollaria ja B300 0,276 dollaria. Hitaammalla, 20 tokenin sekuntinopeudella SemiAnalysis raportoi Ironwoodin tuottavan 50,4 % enemmän tokeneita per dollari kuin B200 ja 96,0 % enemmän kuin B300. Tämä on toistaiseksi laajin julkinen, metodologisesti avoin kolmannen osapuolen vertailu, jossa Ironwood on mukana.
On tärkeää huomata, että nämä ovat inferenssin kustannustehokkuuslukuja, ei universaaleja laitteistobenchmarkeja. Tulokset riippuvat mallista, kvantisoinnista, eräkoosta, käyttöasteesta ja ohjelmistopinosta. Riippumattomia, metodologisesti täysin avoimia vertailuja Ironwoodin ja Nvidian H100-, H200- tai GB200-sirujen välillä ei ole julkisesti saatavilla samalla tarkkuudella. Toinen riippumaton analyysi, Spheron Networkin julkaisema tekninen katsaus, päätyy samansuuntaiseen johtopäätökseen: Ironwoodin kustannusetu syntyy ensisijaisesti FP8-laskennan natiivista laitteistotuesta, ei vain raa’asta kellotaajuudesta.
Trainium3:n osalta tilanne on ohuempi: AWS:n oma vertailu rajoittuu väitteeseen kaksinkertaisesta laskentatehosta Trainium2:een nähden, ei suoraan Nvidia-vertailuun. Riippumatonta, yksityiskohtaista benchmarkia Trainium3:n ja Nvidian GPU:iden välillä ei ollut lokakuuhun 2026 mennessä julkaistu samalla läpinäkyvyydellä kuin SemiAnalysisin Ironwood-data. AWS:n oma builder.aws.com-vertailusivu listaa Trainium3:n teknisiä tietoja rinnakkain kilpailijoiden kanssa, mutta sivu keskittyy spesifikaatioihin, ei mitattuihin tuloksiin.
Kolmas lähde, Googlen oma huhtikuussa 2025 julkaisema tiedote, antaa pohjan koko vertailulle: yhtiö väitti Ironwoodin tarjoavan kymmenkertaisen huippusuorituskyvyn TPU v5p:hen verrattuna ja yli nelinkertaisen Trilliumiin (TPU v6) nähden per siru. Näitä lukuja ei ole riippumattomasti auditoitu, ja niitä kannattaa käsitellä valmistajan omana ilmoituksena, samalla tavalla kuin AWS:n omaa Trainium2-vertailua.
SemiAnalysisin menetelmä kannattaa ymmärtää hieman tarkemmin, koska se on koko vertailun ainoa aidosti riippumaton kolmannen osapuolen mittapiste. InferenceX-vertailu ajoi samaa Qwen3.5 397B -mallia FP8-tarkkuudella usealla eri laitteistoalustalla ja mittasi kokonaiskustannuksen (laitteisto, energiankulutus ja pilvivuokraus huomioiden) suhteessa tuotettuihin tokeneihin kahdella eri palvelunopeudella: 100 ja 20 tokenia sekunnissa käyttäjää kohden. Matalampi nopeus simuloi tilannetta, jossa järjestelmä palvelee useampaa käyttäjää samanaikaisesti pienemmällä yksittäisen vastauksen nopeudella, kun korkeampi nopeus simuloi tilannetta, jossa yksittäinen käyttäjä odottaa nopeaa vastausta. Se, että Ironwood voitti molemmissa asetelmissa, viittaa siihen, että etu ei rajoitu vain yhteen käyttötapaukseen.
Hinnoittelu: mitä TPU v7 ja Trainium3 maksavat pilvessä
Googlen Ironwood-hinnoittelu on julkisesti saatavilla useammassa muodossa. Suoraan käytettävissä oleva kapasiteetti maksaa noin 12 dollaria tunnissa osassa alueita ja kokoonpanoja. Joustava, Dynamic Workload Scheduler Flex-start -hinnoittelu laskee tämän noin 6 dollariin tunnissa. Sitoutumalla yhdeksi tai kolmeksi vuodeksi hinta putoaa Iowan alueella aina 8,40 dollariin ja 5,40 dollariin tunnissa. Kolmas, erikseen raportoitu luku koskee Anthropicin neuvoteltua kapasiteettia: noin 1,60 dollaria TPU-tuntia kohden, mutta tämä on neuvoteltu sopimushinta, ei julkinen listahinta, ja sitä ei pidä verrata suoraan vähittäishintoihin.
AWS ei ole julkaisemissaan materiaaleissa ilmoittanut yhtä selkeää per-siru-tuntihintaa Trainium3:lle, koska yhtiö hinnoittelee palvelun EC2 Trn3 -instanssityyppien ja UltraServer-kokoonpanojen kautta. Tämä tekee suorasta hintavertailusta hankalaa: todellista tehollista siruhintaa pitäisi laskea tietyn Trn3-instanssin SKU:n kokonaishinnasta, jaettuna sirujen määrällä, ja tämä luku vaihtelee alueen, sitoumustyypin ja instanssikoon mukaan.
| Hintamalli | Google TPU v7 Ironwood | AWS Trainium3 |
|---|---|---|
| Listahinta, kysynnän mukaan | ~12 $/h (alue- ja kokoonpanoriippuvainen) | Ei julkista per-siru-listahintaa, hinnoitellaan EC2 Trn3 -instanssin kautta |
| Joustava/Flex-hinnoittelu | ~6 $/h (Dynamic Workload Scheduler) | Ei vastaavaa julkista lukua löytynyt |
| 1 vuoden sitoumus (Iowa) | ~8,40 $/h | Ei vastaavaa julkista lukua löytynyt |
| 3 vuoden sitoumus (Iowa) | ~5,40 $/h | Ei vastaavaa julkista lukua löytynyt |
| Neuvoteltu suurasiakashinta | ~1,60 $/TPU-tunti (raportoitu Anthropic-arvio) | Ei julkista vastinetta |
| Kustannus / miljoona tokenia (SemiAnalysis, 100 t/s) | 0,181 $ | Ei vastaavaa riippumatonta mittausta löytynyt |
Käytännön johtopäätös suomalaiselle tai pohjoismaiselle ostajalle: Google julkaisee enemmän hintatietoa, joten TPU v7:n kustannusten ennustaminen etukäteen on helpompaa. Trainium3:n todellinen hinta selviää vasta, kun lasket yhteen tietyn Trn3-instanssin tuntihinnan ja jaat sen sirujen määrällä, ja tämä voi vaihdella AWS:n alueen ja sitoumustyypin mukaan huomattavasti. Molemmissa tapauksissa kannattaa pyytää tarjousta suoraan myyjältä ennen suurta sitoumusta, koska julkiset listahinnat ovat lähtökohta, ei lopullinen hinta suurelle kapasiteettitilaukselle.
Esimerkkilaskelma: mitä miljardi tokenia maksaa
Raakaluvut muuttuvat konkreettisiksi vasta, kun ne skaalataan tyypilliseen tuotantomäärään. SemiAnalysisin InferenceX-datan mukaan Ironwood käsittelee yhden miljoonan tokenin 0,181 dollarilla palvelunopeudella 100 tokenia sekunnissa käyttäjää kohden. Skaalattuna miljardiin tokeniin, mikä vastaa suuruusluokaltaan keskisuuren chatbot-palvelun kuukausittaista käsittelymäärää, tämä tarkoittaa noin 181 dollaria miljardilta tokenilta samalla mittarilla. Nvidian B200:lla vastaava luku olisi noin 222 dollaria ja B300:lla noin 276 dollaria samalla SemiAnalysisin menetelmällä.
Trainium3:lle vastaavaa, riippumattomasti mitattua lukua ei ole julkisesti saatavilla, koska AWS ei ole julkaissut Trainium3:lle samantyyppistä kolmannen osapuolen auditoitua kustannus-per-token-mittausta. Tämä ei tarkoita, että Trainium3 olisi kalliimpi, se tarkoittaa, että vertailukelpoista lukua ei yksinkertaisesti ole olemassa julkisessa muodossa lokakuuhun 2026 mennessä. Jokaisen AWS-asiakkaan on tällä hetkellä laskettava oma kustannus-per-token-lukunsa itse, ajamalla oma malli tietyllä Trn3-instanssilla ja mittaamalla todellinen läpimeno ja tuntihinta.
Käytännön ohje: ennen kuin vertailee mitään kahta alustaa hintalapuilla, pyydä tai laske aina kustannus samalla yksiköllä, dollaria per miljoona tokenia tietyllä palvelunopeudella, äläkä koskaan vertaa suoraan sirun tuntivuokraa toiseen, koska se jättää huomiotta sen, kuinka monta tokenia kumpikin siru oikeasti tuottaa samassa ajassa.
Mitä tämä tarkoittaa Nvidialle ja GPU-markkinalle
Ironwoodin ja Trainium3:n nousu ei tapahdu tyhjiössä. Molemmat sirut kilpailevat suoraan Nvidian B200- ja B300-kiihdyttimien kanssa samasta inferenssibudjetista, ja SemiAnalysisin oma data osoittaa Ironwoodin tuottavan edullisemman kustannuksen per token kuin kumpikaan Nvidia-vaihtoehto tietyssä testiasetelmassa. Tämä ei tarkoita, että Nvidia olisi menettämässä markkinaa kokonaan, yhtiön GPU:t ovat edelleen ainoa vaihtoehto suurimmalle osalle yrityksistä, jotka eivät ole Google, AWS, Microsoft tai Meta, koska vain suurimmilla pilvijäteillä on resursseja suunnitella ja valmistaa oma piiri alusta loppuun.
Mukautettujen sirujen todellinen vaikutus näkyy ennen kaikkea hintaneuvotteluissa. Kun Google ja AWS voivat ajaa merkittävän osan omasta inferenssikuormastaan omalla piirillä, niiden tarve ostaa Nvidia-GPU:ita markkinahintaan pienenee, mikä antaa niille vahvemman neuvotteluaseman jäljelle jäävästä GPU-tarpeesta. Tämä dynamiikka on yksi syy, miksi Nvidia on itse laajentanut tuotevalikoimaansa ja hinnoitteluaan vastaamaan sekä suuryritysten että pienempien ostajien tarpeisiin samanaikaisesti.
Klusteriarkkitehtuuri: pod vastaan UltraServer
Googlen Ironwood-arkkitehtuuri rakentuu selkeän hierarkian varaan. Perusyksikkö on 64 sirun kuutio, joka järjestetään 4×4×4-ristikkoon. Optiset piirikytkimet (optical circuit switches) yhdistävät näitä kuutioita toisiinsa, kunnes koko kokonaisuus kasvaa 9 216 siruun yhdessä superpodissa. Tämä on suurin julkisesti dokumentoitu yksittäinen kokoonpano, ja Google ilmoittaa sen tuottavan 42,5 exaflopsia FP8-laskentatehoa. Riippumaton teknologiamedia on raportoinut, että tämä skaala on merkittävä harppaus verrattuna Googlen aiempiin TPU-pod-kokoonpanoihin, vaikka tarkkaa tuotantokäytön laajuutta ei ole julkisesti vahvistettu.
AWS:n vastine on Amazon EC2 Trn3 UltraServer, joka yhdistää useita Trainium3-siruja yhdeksi tiiviisti kytketyksi palvelinjärjestelmäksi. AWS:n julkinen tuotesivu vahvistaa 144 Gt HBM3e-muistin ja 4,9 Tt/s kaistanleveyden per siru, mutta ei anna vastaavaa kokonais-pod-lukua kuin Google. Tämä ei tarkoita, että Trainium3-klusterit olisivat pienempiä, se tarkoittaa, että AWS ei ole julkaisemissaan materiaaleissa esittänyt vertailukelpoista superpod-mittakaavan lukua, joten suoraa pod-vs-pod-vertailua ei voida tehdä luotettavasti ilman lisätietoa.
Molempien yhtiöiden strategia on sama: siirtää pullonkaula pois yksittäisestä sirusta, jolloin sen tilalle tulee verkko, joka sitoo tuhansia siruja yhdeksi loogiseksi laskentayksiköksi. Erona on avoimuus, Google kertoo tarkan pod-koon ja sen suorituskyvyn julkisessa markkinointimateriaalissaan, kun AWS keskittyy instanssitason markkinointiin ja jättää kokonaismittakaavan asiakkaan itse laskettavaksi.
Ohjelmistoekosysteemi: JAX ja XLA vastaan Neuron SDK
Raakateho on vain puolet tarinaa. TPU-sirut on historiallisesti ohjelmoitu Googlen omalla XLA-kääntäjällä ja JAX- tai TensorFlow-kehyksillä, ja PyTorch-tuki on parantunut vuosien varrella XLA:n PyTorch/XLA-sillan kautta. Käytännössä moni tiimi, joka on rakentanut mallinsa suoraan CUDA-riippuvaiseksi, joutuu tekemään enemmän sovitustyötä siirtyessään TPU:lle kuin siirtyessään toiselle GPU-valmistajalle, jonka ekosysteemi on lähempänä CUDA:a.
AWS on rakentanut Trainium-siruilleen oman Neuron SDK:n, joka integroituu PyTorchiin ja JAX:iin NeuronX-kääntäjän kautta. AWS markkinoi Neuronia nimenomaan matalamman kynnyksen reittinä niille, jotka tuntevat PyTorchin mutta eivät halua opetella Googlen JAX-keskeistä työkalupinoa. Riippumaton toimialakatsaus kuvaa Neuron SDK:n kypsyneen merkittävästi Trainium1:n ja Trainium3:n välillä, mutta toteaa samalla, että operaattoreiden (eli yksittäisten laskentafunktioiden) tuki on edelleen suppeampi kuin CUDA:ssa, minkä takia osa monimutkaisimmista malliarkkitehtuureista ei vielä toimi suoraan Trainiumilla ilman muokkausta.
Molemmissa tapauksissa siirtymä pois Nvidian CUDA-ekosysteemistä vaatii koodin testaamista uudelleen, koska operaattoreiden tuki, muistinhallinta ja profiilityökalut eroavat CUDA:sta. Tämä ei ole TPU:n tai Trainiumin heikkous sinänsä, se on hinta, jonka jokainen mukautettu piiri vaatii, kun se ei ole suoraan yhteensopiva markkinan hallitsevan ekosysteemin kanssa.
Todelliset käyttöönotot: ketkä käyttävät kumpaa siruä
Käytännön esimerkit kertovat enemmän kuin spesifikaatiotaulukot, koska ne paljastavat, mitä suuret ostajat ovat oikeasti valmiita maksamaan ja millä ehdoilla. Tässä viisi vahvistettua tai laajasti raportoitua käyttötapausta:
- Anthropic ja Google TPU: Anthropic on tehnyt laajan sopimuksen Googlen TPU-kapasiteetista Claude-mallien ajamiseen, ja neuvoteltu hinta-arvio noin 1,60 dollaria TPU-tunnilta on raportoitu osana tätä järjestelyä. Tarkkaa Ironwood-sirujen määrää Anthropicin käytössä ei ole julkisesti vahvistettu.
- Anthropic ja AWS Trainium, Project Rainier: samaan aikaan Anthropic käyttää AWS:n Trainium-siruja osana Project Rainier -hanketta. AWS ja alan uutisointi yhdistävät Anthropicin suuriin Trainium-käyttöönottoihin, mutta tarkkaa Trainium3-sirujen määrää tai kokonaislaskentatehoa ei ole julkisesti vahvistettu, on myös mahdollista, että Project Rainier kattaa useita Trainium-sukupolvia yhtä aikaa.
- Google Gemini -inferenssi: Google käyttää omia TPU v7 -sirujaan ajaakseen osan Gemini-malliperheen inferenssikuormasta Google Cloudissa, mikä on yksi syy, miksi yhtiö rakensi Ironwoodin nimenomaan inferenssioptimoituna sirupiirinä koulutuksen sijaan.
- Apple ja Midjourney: molemmat mainitaan toistuvasti alan uutisoinnissa Google TPU -asiakkaina, mutta kummallakaan ei ole julkista, päivättyä ensilähteen vahvistusta nimenomaan Ironwood-sukupolven käytöstä, ne kannattaa siis lukea toimialan yleisinä mainintoina, ei vahvistettuina Ironwood-sopimuksina.
- AWS-asiakkaat EC2:n kautta: Trainium3 on tarjolla kaikille AWS:n asiakkaille EC2 Trn3 UltraServer -instansseina, mikä tekee siitä saatavuudeltaan laajemman kuin suoran TPU-kapasiteetin, Google Cloudin TPU-tarjonta on perinteisesti ollut keskittyneempi suuriin, neuvoteltuihin sopimuksiin kuin yksittäisten pienten kehitystiimien itsepalveluun.
Anthropicin kaksoisstrategia ansaitsee oman huomionsa. Yhtiö, joka kilpailee suoraan OpenAI:n ja Googlen omien mallien kanssa, on tietoisesti hajauttanut laskentakapasiteettinsa kahden eri pilvitoimittajan ja kahden eri sirualustan välille. Tämä ei ole sattumaa, se on riskienhallintaa tilanteessa, jossa yksikään yksittäinen toimittaja ei voi takuuvarmasti toimittaa riittävää kapasiteettia ajoissa, ja jossa hintaneuvotteluasema vahvistuu, kun ostajalla on uskottava vaihtoehto.
Tämä malli on todennäköisesti yleistyvä suunta koko toimialalla, ei poikkeus. Yritys, jonka koko liiketoiminta nojaa yhden tyyppisen tekoälylaskennan saatavuuteen, kantaa merkittävän toimittajariskin, jos se sitoutuu vain yhteen piiriin tai yhteen pilvitoimittajaan. Pienemmille yrityksille Anthropicin kaltainen monialustastrategia ei ole aina realistinen, kahden eri ohjelmistopinon (JAX/XLA ja Neuron SDK) ylläpito vaatii omaa osaamista ja ylläpitoresursseja, mutta periaate on silti siirrettävissä pienempään mittakaavaan: säilytä aina edes teoreettinen mahdollisuus vaihtaa alustaa, jotta neuvotteluasema ei katoa kokonaan.
Google Geminin tapauksessa sisäinen TPU-käyttö on erityisen havainnollistava esimerkki siitä, miksi Ironwood rakennettiin nimenomaan inferenssiä varten. Gemini-malliperhe palvelee satoja miljoonia kyselyitä päivässä Google-tuotteiden kautta, ja jokainen kysely on inferenssitapahtuma, ei koulutustapahtuma. Kun yhtiö optimoi omaa piiriään ensisijaisesti tähän käyttötapaukseen, se voi jättää pois koulutukseen tarvittavia ominaisuuksia ja käyttää vapautuvan piirialan inferenssin tehostamiseen, tämä on todennäköisesti yksi tekninen syy Ironwoodin korkealle FP8-laskentatehon ja muistikaistan suhteelle verrattuna aiempiin, yleiskäyttöisempiin TPU-sukupolviin.
AWS:n EC2-pohjainen myyntimalli tuo puolestaan erilaisen edun: koska Trainium3 myydään samojen työkalujen, laskutuksen ja hallintapaneelien kautta kuin kaikki muu AWS-infrastruktuuri, kehitystiimin ei tarvitse opetella uutta hankintaprosessia tai erillistä sopimusneuvottelua päästäkseen kokeilemaan siruja. Tämä alentaa kynnystä kokeilla Trainium3:a pienessä mittakaavassa huomattavasti matalammaksi kuin Googlen TPU-kapasiteetin hankkiminen, joka on historiallisesti vaatinut suoraa yhteyttä Google Cloudin myyntiorganisaatioon suuremman kapasiteetin osalta.
Energiatehokkuus ja konesalivaikutukset Pohjoismaissa
Molemmat yhtiöt markkinoivat uutta sirusukupolveaan energiatehokkaampana kuin edeltäjäänsä, mutta julkisesti vahvistettuja watti-per-TFLOPS-lukuja ei ollut lokakuuhun 2026 mennessä saatavilla samalla tarkkuudella kuin laskentateho- ja muistiluvut. Ironwoodin kaksoiskiekkorakenne ja 3D-torus-verkko on suunniteltu minimoimaan datan siirtomatkaa sirujen välillä, mikä pienentää verkkoliikenteen energiankulutusta suurissa klustereissa, tämä on arkkitehtoninen peruste, ei mitattu lopputulos, ja sitä ei pidä esittää vahvistettuna energiatehokkuuslukuna.
Pohjoismaille tämä on erityisen relevantti kysymys, koska alue on vuosia houkutellut konesaleja nimenomaan halvalla, vähäpäästöisellä vesi- ja tuulivoimalla. Googlella on oma, laajeneva konesali-infrastruktuuri Suomessa, ja AWS on investoinut omiin eurooppalaisiin alueisiinsa samalla logiikalla. Kumpi sirusukupolvi tuottaa enemmän inferenssiä per megawattitunti, ratkeaa todennäköisesti vasta, kun riippumattomat energiatehokkuustestit julkaistaan, toistaiseksi kannattaa suhtautua varauksella molempien valmistajien omiin tehokkuusväitteisiin, ja pyytää ostopäätöksen tueksi todellista mitattua kulutusdataa omasta työkuormasta, ei vain valmistajan ilmoittamaa teoreettista huippuarvoa.
Yrityksen kannalta energiakysymys ei ole vain ympäristöviestinnän asia, se näkyy suoraan laskussa. Pilvipalvelun hinta sisältää aina osan konesalin sähkölaskusta, ja jos yksi siru tuottaa enemmän käyttökelpoista laskentaa samalla sähkömäärällä, tämä näkyy ennen pitkää joko halvempana hintana tai valmistajan parempana kate-marginaalina. Tällä hetkellä kumpikaan yhtiö ei ole julkaissut riittävän yksityiskohtaista dataa, jotta ostaja voisi laskea tämän eron itse, se on yksi selkeä alue, jossa lisää avoimuutta odotetaan molemmilta valmistajilta seuraavien sukupolvien julkistusten yhteydessä.
Datan sijainti ja EU-näkökulma hankintapäätöksessä
Suomalaiselle tai pohjoismaiselle yritykselle sirun raakateho on vain yksi osa hankintapäätöstä. Molemmat yhtiöt tarjoavat EU-alueella sijaitsevia konesaleja, joissa data voidaan pitää unionin sisällä, mikä on olennaista GDPR-vaatimusten täyttämiseksi. Käytännössä tämä tarkoittaa, että valinta TPU v7:n ja Trainium3:n välillä ei useinkaan ratkea vain teknisten lukujen perusteella, vaan sen mukaan, missä pilvialueissa kumpi siru on jo tarjolla silloin, kun oma projekti käynnistyy.
Koska molempien sirujen laajentuminen uusille alueille tapahtuu vaiheittain uuden sukupolven julkistuksen jälkeen, kannattaa aina tarkistaa suoraan Google Cloudin ja AWS:n ajantasaisilta alue-sivuilta, onko juuri haluttu sirusukupolvi saatavilla halutussa EU-alueessa, ennen kuin sitoutuu kumpaankaan alustaan pitkäaikaisella sopimuksella. Uusimman sirusukupolven saapuminen uudelle alueelle voi viedä kuukausia julkistuksen jälkeen, ja tämä viive voi olla ratkaiseva tekijä, jos projektin aikataulu on tiukka.
Käyttötapaussuositukset: milloin kannattaa valita kumpi
Spesifikaatiot ja hinnat kääntyvät käytännön päätökseksi vain, jos ne suhteutetaan omaan työkuormaan. Kahden piirin raakatehon ero ei kerro mitään siitä, kumpi sopii paremmin juuri sinun tiimisi tilanteeseen, ratkaisevaa on, mikä ohjelmistopino on jo käytössä, kuinka suuri sitoumus on realistinen, ja kuinka kriittistä on päästä tuotantoon nopeasti ilman pitkää siirtymäprojektia. Tässä kuusi tyypillistä tilannetta ja kumpi siru sopii niihin paremmin julkisesti saatavilla olevien tietojen perusteella:
- Suurimittakaavainen LLM-inferenssi massamäärillä: SemiAnalysisin InferenceX-data antaa Ironwoodille mitattavissa olevan kustannusedun (0,181 $ vs 0,222–0,276 $ per miljoona tokenia Nvidia B200/B300:aan verrattuna), tämä puoltaa TPU v7:ää, jos työkuorma skaalautuu JAX/XLA-pinolle.
- PyTorch-pohjainen malliharjoittelu, jo AWS-infrassa: jos koko sovellusympäristö on rakennettu AWS:n päälle, Trainium3:n Neuron SDK -integraatio ja EC2 Trn3 UltraServer -saatavuus vähentävät siirtymäkustannuksia enemmän kuin raakatehon ero vaikuttaa.
- Yksittäisen suuren asiakkaan neuvoteltu kapasiteettisopimus: Anthropicin esimerkki näyttää, että molempia kannattaa käyttää rinnakkain, riskinhajautus eri pilvitoimittajien välillä vähentää riippuvuutta yhdestä sirutoimittajasta ja vahvistaa neuvotteluasemaa.
- Pieni tai keskisuuri yritys, joka testaa ensimmäistä mukautettua siruaan: AWS:n instanssipohjainen malli (Trn3 UltraServer EC2:n kautta) on matalamman kynnyksen reitti kuin Googlen suurempiin sopimuksiin keskittyvä TPU-kapasiteetti, koska EC2-instansseja voi tilata ilman suurta ennakkosopimusta.
- Muistikriittiset mallit, joissa yksittäisen sirun HBM-kapasiteetti ratkaisee: Ironwoodin 192 Gt voittaa Trainium3:n 144 Gt, mikä vähentää tarvetta pilkkoa malli useamman sirun kesken ja yksinkertaistaa rinnakkaistamista pitkäkontekstisissa sovelluksissa.
- Inferenssi, jossa latenssi per käyttäjä on tärkeämpi kuin kokonaisläpimeno: SemiAnalysisin 20 tokenia/s-mittaus antaa Ironwoodille 50,4–96,0 % paremman tokenit-per-dollari-suhteen matalammalla nopeudella Nvidiaan verrattuna, mikä viittaa vahvaan asemaan myös pienemmän kuormituksen inferenssissä.
Migraatio-opas: siirtyminen CUDA:sta TPU:lle tai Trainiumille
Siirtyminen Nvidia-keskeisestä CUDA-koodista mukautettuun siruun ei ole yksinkertainen vaihto, se on monivaiheinen projekti, joka kannattaa aikatauluttaa viikkojen, ei päivien, mittakaavassa. Yleisin virhe on aliarvioida testausvaihe: tiimit, jotka olettavat mallin toimivan suoraan uudella alustalla samalla tarkkuudella kuin alkuperäisellä GPU:lla, törmäävät usein pieniin numeerisiin eroihin, jotka johtuvat eri laitteiston pyöristyskäytännöistä matalan tarkkuuden (FP8/MXFP8) laskennassa. Seuraava järjestys toimii lähtökohtana molempiin suuntiin:
- Inventoi riippuvuudet. Listaa kaikki CUDA-spesifiset kirjastot (esim. custom CUDA-kernelit, TensorRT-optimoinnit), joita malliputki käyttää. Näiden korvaaminen vie yleensä enemmän aikaa kuin itse mallin siirto.
- Valitse kehys. TPU v7:lle luonnollisin reitti on JAX tai PyTorch/XLA. Trainium3:lle AWS suosittelee PyTorchia Neuron SDK:n kautta. Jos tiimi käyttää jo PyTorchia, Trainium-siirtymä on usein lyhyempi.
- Aja pienoiskoemalli pilvessä. Ennen tuotantomallin siirtoa, testaa pieni versio (esim. 1–7 miljardin parametrin malli) kohdealustalla ja vertaa tarkkuutta alkuperäiseen GPU-ajoon.
- Profiloi muistinkäyttö uudelleen. HBM-kapasiteetti ja kaistanleveys eroavat Nvidia-GPU:ista, joten eräkoko (batch size) ja mallin rinnakkaistamisstrategia on viritettävä uudelleen, mitä toimi H100:lla, ei toimi suoraan samalla asetuksella TPU:lla tai Trainiumilla.
- Vertaa kustannusta per token, ei vain tuntihintaa. Käytä samaa mittaria kuin SemiAnalysisin InferenceX: dollaria per miljoona tokenia tietyllä palvelunopeudella, ei raakaa tuntivuokraa, koska se huomioi myös laitteiston tehokkuuden.
- Aja rinnakkain siirtymävaiheessa. Pidä vanha Nvidia-pohjainen tuotantoympäristö käynnissä, kunnes uusi alusta on läpäissyt saman liikennemäärän vähintään viikon ajan ilman tarkkuus- tai latenssiregressioita.
- Neuvottele sitoumustaso vasta mittausten jälkeen. Googlen 1–3 vuoden sitoumushinnat (8,40 $ ja 5,40 $/h) ja AWS:n instanssikohtaiset hinnat kannattaa lukita vasta, kun todellinen kustannus per token on mitattu omalla työkuormalla, ei valmistajan ilmoittamalla teoreettisella huipulla.
- Dokumentoi poikkeamat tiimille. Kirjaa ylös jokainen operaattori tai kirjasto, joka ei toiminut suoraan uudella alustalla, ja jaa tämä lista muille tiimeille organisaatiossa, tämä säästää seuraavan projektin siirtymäaikaa huomattavasti.
Muut mukautetut sirut kilpailukentässä
Google ja AWS eivät ole ainoat pilviyhtiöt, jotka ovat valinneet oman piirin tien. Microsoft on kehittänyt omaa Maia-sirusarjaansa Azure-pilveään varten, ja Meta on rakentanut oman MTIA-piirinsä (Meta Training and Inference Accelerator) sisäisiä suosittelujärjestelmiään ja tekoälytyökuormiaan varten. Kumpikaan näistä ei ole suoraan vertailukelpoinen tässä artikkelissa käsiteltyihin Ironwoodiin ja Trainium3:een, koska niiden tekniset tiedot ja markkinarooli eroavat, Maia ja MTIA ovat historiallisesti olleet enemmän sisäiseen käyttöön suunnattuja kuin laajasti ulkoisille pilviasiakkaille myytyjä tuotteita.
Tämä laajempi kuva on tärkeä pitää mielessä: Ironwood-vs-Trainium3-vertailu on vain yksi osa suurempaa siirtymää, jossa kaikki merkittävät pilvijätit pyrkivät vähentämään riippuvuuttaan Nvidian GPU:ista omalla piirisuunnittelulla. Tämä trendi todennäköisesti jatkuu ja kiihtyy seuraavien vuosien aikana, kun jokainen sukupolvi kasvattaa mukautettujen sirujen osuutta kokonaislaskentatehosta suurimmissa pilvipalveluissa.
Edut ja haitat: Google TPU v7 Ironwood
Ironwoodin vahvuudet ja heikkoudet on syytä listata erikseen, koska moni etu riippuu siitä, onko sovellus valmis JAX/XLA-pinolle. Seuraava lista kokoaa yhteen tähän mennessä käydyt kohdat yhdeksi nopeasti silmäiltäväksi kokonaisuudeksi.
- Edut: korkein julkaistu per-siru-laskentateho (4 614 TFLOPS FP8), suurin muistikapasiteetti (192 Gt) ja kaistanleveys (7,37 Tt/s) tässä vertailussa, riippumattomasti mitattu kustannusetu SemiAnalysisin InferenceX-datassa, läpinäkyvä julkinen hinnoittelu usealla sitoumustasolla, suurin vahvistettu yksittäinen klusterikoko (9 216 sirua).
- Haitat: ekosysteemi nojaa vahvasti JAX/XLA:han, mikä kasvattaa siirtymäkustannusta puhtaasti PyTorch/CUDA-pohjaisille tiimeille. Saatavuus on historiallisesti keskittynyt suuriin neuvoteltuihin sopimuksiin eikä pienen mittakaavan kokeiluun, ja energiatehokkuudesta ei ole riippumatonta, julkista mittausta.
Edut ja haitat: AWS Trainium3
- Edut: saatavilla suoraan EC2:n kautta ilman suurta ennakkosopimusta, Neuron SDK tukee PyTorchia matalammalla siirtymäkynnyksellä, tiivis integraatio muuhun AWS-infraan (tallennus, verkko, IAM), kaksinkertainen laskentateho ja 1,7-kertainen kaistanleveys edeltäjä Trainium2:een verrattuna.
- Haitat: pienempi per-siru-laskentateho ja muistikapasiteetti kuin Ironwoodilla tässä vertailussa, ei julkista per-siru-tuntihintaa (vaatii laskemista EC2-instanssihinnasta), ei vastaavaa riippumatonta kolmannen osapuolen kustannus-per-token-benchmarkia kuin Ironwoodilla, ei julkaistua pod-mittakaavan kokonaislukua verrattavaksi Googlen 9 216 sirun superpodiin.
Yhteenvetona: Ironwoodin haittalista on pääosin ekosysteemiin ja saatavuuteen liittyvä, kun Trainium3:n haittalista on pääosin raakatehoon ja julkisen datan puutteeseen liittyvä. Kumpi painaa enemmän, riippuu siitä, kumpaa yritys arvostaa enemmän omassa päätöksenteossaan, nopeaa pääsyä tuotantoon vai parasta mitattua kustannustehokkuutta.
Lopullinen arvio: kumpi voittaa?
Puhtaasti spesifikaatioiden perusteella Google TPU v7 Ironwood voittaa AWS Trainium3:n jokaisella yksittäisellä mittarilla, jolla molemmat ovat julkaisseet vertailukelpoisen luvun: 83 % enemmän FP8-laskentatehoa, 33 % enemmän muistia, 50 % enemmän kaistanleveyttä ja ainoa riippumaton, julkinen kustannus-per-token-benchmark markkinoilla. Tämä tekee Ironwoodista vahvemman valinnan silloin, kun työkuorma on valmis JAX- tai PyTorch/XLA-pinolle ja mittakaava on riittävän suuri oikeuttamaan neuvotellun sopimuksen. On syytä korostaa, että tämä on spesifikaatiovoitto, ei automaattinen voitto jokaisessa reaalimaailman skenaariossa, ero muuttuu merkitykselliseksi vasta, kun se näkyy omassa laskussa tai omassa latenssimittauksessa.
Trainium3 ei kuitenkaan häviä käytännössä samalla marginaalilla kuin paperilla. AWS:n etu ei ole raakateho, se on saatavuus ja integraatio. Yritys, joka on jo rakentanut koko tuotantoympäristönsä AWS:n päälle, säästää enemmän siirtymäkustannuksissa ja operatiivisessa yksinkertaisuudessa valitsemalla Trainium3:n EC2 Trn3 UltraServer -muodossa kuin se menettäisi raakatehon erossa. Anthropicin päätös käyttää molempia alustoja samanaikaisesti, Google TPU:ta ja AWS Trainiumia, on paras todiste siitä, että kyse ei ole yhden voittajan pelistä, vaan riskienhajautuksesta ja työkuormakohtaisesta optimoinnista.
Pohjoismaiselle ostajalle käytännön neuvo on yksinkertainen: jos olet jo syvällä AWS-ekosysteemissä, testaa Trainium3 ensin EC2:n kautta pienellä kuormalla ennen suurempaa sitoumusta. Jos työkuormasi on inferenssipainotteinen ja sietää JAX/XLA-siirtymän, Ironwoodin mitattu kustannusetu, 0,181 dollaria miljoonaa tokenia kohden SemiAnalysisin datassa, on vaikea ohittaa pelkällä spesifikaatiovertailulla. Kummassakaan tapauksessa kannattaa pyytää oma pilottitesti omalla mallilla ja omalla datalla ennen vuosien mittaista sitoumusta, koska julkiset benchmarkit eivät koskaan vastaa täysin yrityksen omaa työkuormaa.
Usein kysytyt kysymykset
Onko Google TPU v7 Ironwood nopeampi kuin AWS Trainium3?
Julkaistujen huippulukujen perusteella kyllä: Ironwood tarjoaa 4 614 TFLOPS FP8-laskentatehoa yhdellä sirulla, Trainium3 2 520 TFLOPS. Tämä on 83 % enemmän Ironwoodin hyväksi, mutta ero käytännön työkuormassa riippuu ohjelmistopinosta ja rinnakkaistamisesta, eikä raakateho suoraan takaa nopeampaa sovellustason suoritusta kaikissa tilanteissa.
Kumpi on halvempi, TPU v7 vai Trainium3?
Google on julkaisemissaan materiaaleissa avoimempi hinnoittelussa: noin 12 $/h listahinnalla, 6 $/h joustavalla hinnoittelulla ja 5,40–8,40 $/h sitoumuksella. AWS ei julkaise suoraa per-siru-tuntihintaa Trainium3:lle, koska hinnoittelu tapahtuu EC2 Trn3 -instanssien kautta, joten suoraa vertailua on vaikea tehdä ilman omaa laskentaa tietyn instanssityypin pohjalta.
Käyttääkö Anthropic Google TPU:ta vai AWS Trainiumia?
Molempia. Anthropic on raportoitu käyttävän Googlen TPU-kapasiteettia Claude-mallien ajamiseen ja samalla AWS:n Trainium-siruja osana Project Rainier -hanketta. Tarkkoja sirumääriä kummassakaan tapauksessa ei ole julkisesti vahvistettu, ja yhtiö ei ole kommentoinut tarkkaa työkuormien jakoa alustojen välillä.
Voiko TPU:ta tai Trainiumia käyttää PyTorch-mallien ajamiseen?
Kyllä molempia. TPU v7 tukee PyTorchia PyTorch/XLA-sillan kautta, vaikka JAX on alustan luonnollisin kehys. Trainium3 tukee PyTorchia suoraan AWS:n Neuron SDK:n kautta, ja AWS markkinoi tätä matalamman kynnyksen reittinä PyTorch-tiimeille, jotka eivät halua opetella JAX:ia.
Kuinka paljon muistia TPU v7:ssä ja Trainium3:ssa on?
TPU v7 Ironwoodissa on 192 Gt HBM3e-muistia per siru, Trainium3:ssa 144 Gt HBM3e-muistia per siru. Ironwoodilla on siis 33 % enemmän muistia yhtä sirua kohden, mikä helpottaa suurten mallien ajamista yhdellä sirulla ilman pilkkomista.
Mikä on suurin julkisesti vahvistettu TPU- tai Trainium-klusteri?
Google on vahvistanut 9 216 sirun superpod-kokoonpanon, joka tuottaa 42,5 exaflopsia FP8-laskentatehoa. AWS ei ole julkaisemissaan materiaaleissa esittänyt vastaavaa yhden pod-kokoonpanon kokonaislukua Trainium3:lle, vaikka yhtiö todennäköisesti operoi suuria klustereita sisäisesti.
Häviääkö Trainium3 Ironwoodille jokaisessa työkuormassa?
Ei välttämättä. Raakateho ja riippumattomat benchmarkit suosivat Ironwoodia, mutta yritykset, jotka ovat jo syvällä AWS-ekosysteemissä, voivat säästää enemmän integraation ja operatiivisen yksinkertaisuuden ansiosta kuin ne menettävät raakatehon erossa. Päätös riippuu lopulta omasta infrastruktuurista, ei vain spesifikaatiotaulukosta.
Onko TPU v7 tai Trainium3 saatavilla Euroopassa tai Pohjoismaissa?
Google Cloud tarjoaa TPU-kapasiteettia useilla alueilla, ja hinnoitteluesimerkit (kuten Iowan sitoumushinnat) viittaavat alueriippuvaiseen hintaan. AWS tarjoaa Trn3 UltraServer -instanssit EC2:n kautta alueilla, joilla AWS on julkaissut tuen, tarkka alueellinen saatavuus molemmille kannattaa tarkistaa suoraan palveluntarjoajan ajantasaiselta alue-sivulta ennen hankintapäätöstä, koska uusien sirusukupolvien alueellinen laajennus tapahtuu usein vaiheittain.
Kannattaako pienen yrityksen edes harkita omaa sirukapasiteettia Nvidian sijaan?
Kannattaa harkita, mutta vasta kun työkuorma on vakiintunut ja riittävän suuri hyötymään sitoumushinnoista. Pienelle, kokeilevalle projektille Nvidia-GPU:iden joustava tuntivuokraus on usein yksinkertaisempi reitti, koska CUDA-ekosysteemi on laajin ja vaatii vähiten sovitustyötä ennen ensimmäistä tuotantoajoa.
Mitä eroa on Trainium3:n ja Trn3 UltraServerin välillä?
Trainium3 on yksittäisen sirun nimi, kun Trn3 UltraServer on AWS:n nimitys järjestelmälle, joka yhdistää useita Trainium3-siruja yhdeksi tiiviisti kytketyksi palvelinkokonaisuudeksi. Asiakkaat vuokraavat käytännössä aina UltraServer-kokoonpanon, eivät yksittäistä irrallista siruja, mikä on syy siihen, miksi AWS ei ilmoita erillistä per-siru-tuntihintaa samalla tavalla kuin Google.
Vaikuttaako muistipula GDDR7- ja HBM-siruista TPU v7:n tai Trainium3:n saatavuuteen?
Molemmat sirut käyttävät HBM3e-muistia, joka on eri tuotantolinja kuin kuluttaja-GPU:iden GDDR7-muisti, mutta HBM-kapasiteetin kokonaiskysyntä on kasvanut voimakkaasti kaikkien tekoälysirujen, mukaan lukien TPU:t, Trainium ja Nvidian omat kiihdyttimet, valmistuksessa. Tämä voi vaikuttaa toimitusaikoihin molemmilla alustoilla, vaikka kumpikaan yhtiö ei ole julkisesti vahvistanut tarkkaa toimitusaikaviivettä HBM-saatavuuden takia.