Гаразд, я провів невелике дослідження, і після всього, що я прочитав, ось мій висновок: 4o Native Image Gen спочатку випльовує гігантську сітку латентних патч-токенів, а потім передає їх дифузійному декодеру, який робить ~25 кроків знешумлення на смугу, перш ніж показати отримані пікселі. Після цього він запускає злиття патчів, вбудовує метадані походження c2pa та запускає важкий мультимодальний фільтр безпеки, кожен з яких додає кілька 100 мс. Крім того, bc 4o native image gen - це буквально той самий екземпляр 4o (а не окремий виклик інструменту), він зберігає весь контекст чату у відеопам'яті, жонглюючи 10 з 1000 токенами зображення, тому графічний процесор виконує БАГАТО багатозадачності. Тим часом Grok: Aurora — це MoE, націлена на пропускну здатність необроблених токенів/сек (заявлено ~1,2 тис т/с) і повністю пропускає дифузію. Він авторегресивно випромінює дискретні токени зображень за один прохід, подає їх через легкий VQ-декодер до jpeg 1024x768, додає водяний знак, виконує швидку розгортку політики та надсилає зображення. Тут немає апскейлера, багатосмугової дифузії, немає контексту чату та один кадр на запит, тому це відчувається майже миттєво компроміс полягає в тому, що thst 4o спалює додаткові пробіжки для обробки дрібного тексту, точності макета та послідовності редагування за кілька ходів (імовірно), тоді як Grok налаштований на швидкість, щоб отримати jpeg швидше.

Так, я використовував LLM для дослідження, але НІ, я не використовував жодний, щоб написати це.

вау, перечитуючи це, стільки друкарських помилок, що мені має бути соромно

додаток: Мене виправило [видалено], що для 4o це майже напевно 1d послідовність, а не традиційна сітка vae