Okei, tein tutkimusta, ja kaiken lukemani jälkeen tässä on minun poimintoni: 4O Native Image Gen sylkee ensin ulos jättimäisen piilevien patch-merkkien ruudukon ja antaa sen sitten diffuusiodekooderille, joka tekee ~25ish kohinanpoistovaihetta kaistaa kohden ennen tuloksena olevien pikselien näyttämistä. Sen jälkeen se suorittaa korjaustiedostojen yhdistämisen, upottaa c2pa-alkuperän metatiedot ja suorittaa raskaita multimodaalisia turvasuodattimia, joista jokainen lisää muutaman 100 ms:n. Myös bc 4o native image gen on kirjaimellisesti sama 4o-instanssi (ei erillinen työkalukutsu), se pitää koko chat-kontekstin VRAM-muistissa ja jongleeraa 10 s/1000 kuvamerkkiä, joten GPU tekee PALJON moniajoa. sillä välin Grok: Aurora on MoE, joka on suunnattu raakaan token/sec-siirtoon (~1.2k t/s väitetty) ja ohittaa diffuusion kokonaan. Se lähettää automaattisesti diskreettejä kuvamerkkejä yhdellä kertaa, syöttää ne kevyen VQ-dekooderin kautta 1024x768 jpeg-kokoon, lisää vesileiman, tekee nopean käytännön pyyhkäisyn ja lähettää kuvan. Ei skaalausta, monikaistaista diffuusiota, ei chat-kontekstia ja yksi kehys pyyntöä kohden, joten se tuntuu lähes välittömältä kompromissi on, että 4O polttaa ylimääräisiä FLOPeja käsittelemään pientä tekstiä, asettelun tarkkuutta ja usean kierroksen muokkauksen johdonmukaisuutta (väitetään), kun taas Grok on viritetty nopeuteen, jotta saat jpegin nopeammin.

Kyllä, käytin LLM:iä tutkimukseen, mutta EI, en käyttänyt sellaista tämän kirjoittamiseen.

Vau, lukiessani tätä uudelleen, kirjoitusvirheitä on niin paljon, että minun pitäisi hävetä

lisäys: Minua on korjattu [muokattu], että 4o:lle se on lähes varmasti 1d-sekvenssi, EI perinteinen ruudukko