АНАЛИТИКА

Google может сменить CoWoS на Intel EMIB для TPU нового поколения

Google, по данным Tom's Hardware, может перевести TPU девятого поколения на упаковку Intel EMIB. Это сигнал о сдвиге на рынке AI-чипов.

✍️ Редакция iTech News | 16.07.2026 | ⏱ 5 мин | Источник: Tom's Hardware
📊

Google, по данным Tom's Hardware, якобы выбрала упаковку Intel EMIB для TPU девятого поколения под кодовым именем Humufish. Если решение подтвердится, это не просто техническая перестановка в цепочке поставок: крупнейший заказчик AI-ускорителей показывает, что зависимость от TSMC и ее CoWoS уже перестает быть безальтернативной. Для российской IT-аудитории это важный маркер: борьба в ИИ идет не только на уровне моделей и дата-центров, но и на уровне упаковки чипов, где сейчас решаются сроки поставок, энергопотребление и масштабируемость.

Сама новость выглядит точечной, но последствия у нее системные. Google много лет использовала упаковку TSMC CoWoS для своих TPU, начиная с третьего поколения и вплоть до восьмого. Сначала это была CoWoS-S, позже компания перешла на CoWoS-L. Теперь, если верить публикации, для Humufish рассматривается не очередная версия TSMC, а упаковка Intel EMIB-T. Для рынка это нетривиальный шаг: смена advanced packaging для такого класса процессоров требует перепроектирования части межсоединений, питания и механики корпуса. То есть речь не о банальном переносе заказа к другому подрядчику, а о пересборке важного слоя аппаратной архитектуры.

Почему вокруг этого столько шума? Потому что CoWoS у TSMC за последние годы стала фактическим стандартом для AI- и HPC-чипов. На этой технологии держатся упаковка крупных ускорителей, HBM-память рядом с вычислительными кристаллами и вся та плотная коммутация, без которой современные ускорители быстро превращаются в дорогой кремний с посредственной пропускной способностью. CoWoS-S опирается на кремниевый интерпозер размером до 3,3 reticle, а CoWoS-L использует перераспределительный слой, или RDL-interposer, плюс локальные кремниевые мосты LSI. За счет этого TSMC уже сегодня масштабирует упаковку до 5,5 reticle, а к концу десятилетия обещает уйти дальше 14 reticle. Иными словами, TSMC давно знала, что размер пакета станет бутылочным горлышком, и готовилась к этому заранее.

На этом фоне упаковка Intel EMIB долго воспринималась как запасной маршрут, когда у TSMC тесно с мощностями или сроки начинают неприятно плыть. Но у EMIB есть собственная логика, а не только роль «плана Б». В отличие от CoWoS, где важную роль играет интерпозер на весь пакет, EMIB строится на небольших встроенных кремниевых мостах внутри подложки. Они ставятся только там, где нужны плотные межкристальные соединения. Версия EMIB-T добавляет к этой схеме TSV, то есть вертикальные сквозные контакты, а еще интегрирует MIM-конденсаторы и выделенную земляную плоскость прямо в мост. Для AI-ускорителей это уже не косметика: подача питания становится едва ли не такой же сложной задачей, как передача сигналов между вычислительными плитками и HBM.

Именно в подаче питания и может скрываться главный мотив Google, если переход действительно состоится. Современные ускорители требуют все больше энергии, причем не просто «больше ватт», а более чистого и стабильного питания с быстрым откликом на пиковые нагрузки. EMIB-T как раз продается идеей более прямой вертикальной подачи питания и лучшей power integrity. Для TPU, которые проектируются под гигантские AI-кластеры, это аргумент не хуже лишних процентов по пропускной способности. Проблема в том, что извне почти невозможно точно сравнить, как упаковка Intel EMIB и CoWoS-L ведут себя именно в дизайне Google: публичных электрических и механических характеристик для Humufish никто не публиковал. Поэтому версия «Google выбрала Intel, потому что так технологически лучше во всем» звучит слишком прямолинейно.

У CoWoS-L, в свою очередь, есть сильная сторона, которую рынок ценит не меньше. Ее глобальный RDL-interposer обеспечивает более плотную и гибкую разводку по всему пакету, чем обычная органическая подложка. Это особенно важно, когда нужно не только связать соседние кристаллы, но и тянуть сигналы на более длинные расстояния внутри большого модуля. EMIB отлично работает в точках локальной высокой плотности, но все, что выходит за пределы мостов, все равно уходит в менее тонкую по топологии подложку. У CoWoS-L таких ограничений меньше именно за счет пакетного слоя переразводки. Поэтому выбор между решениями Intel и TSMC определяется не одним параметром, а балансом из производительности межсоединений, питания, механики, цены, доступности мощностей и желания заказчика не держать всю критическую упаковку у одного поставщика.

Есть и еще один контекст, который рынок теперь игнорировать не может: механическая надежность больших пакетов. После проблем Nvidia с Blackwell, где, по данным отраслевых публикаций, обсуждался риск, связанный с несовпадением коэффициентов теплового расширения между частями упаковки, вопрос жесткости и деформации перестал быть темой только для инженеров по сборке. Чем крупнее пакет, тем выше цена любой ошибки в материалах, тепловом профиле и геометрии. Nvidia, как сообщалось, нашла решение для своих конфигураций, и другие разработчики тоже не сидят сложа руки. Но сам прецедент показал: advanced packaging больше нельзя считать скучным производственным этапом после tape-out. Это уже часть конкурентной стратегии продукта, а иногда и его ахиллесова пята.

Для разработчиков и руководителей продуктов из этого следует довольно приземленный вывод. Рынок AI-железа уходит от эпохи, когда выигрывал тот, у кого просто был доступ к передовому техпроцессу. Теперь важна вся связка: вычислительные кристаллы, HBM, корпусировка, питание, тепловой режим и возможность выпустить все это в нужном объеме. Если Google действительно ставит на упаковку Intel EMIB для Humufish, значит Intel получила шанс перестать быть в этой части индустрии лишь альтернативой на случай дефицита у TSMC. А главный вопрос теперь не в том, уйдет ли кто-то еще от CoWoS прямо завтра, а в том, сколько крупных заказчиков захотят иметь второй реальный маршрут для самых дорогих и сложных AI-чипов.

Поделиться: Telegram X LinkedIn