JEDEC близка к завершению стандарта SPHBM4 — Standard Package High Bandwidth Memory. Этот формат нацелен на сохранение пропускной способности уровня HBM4 при более узком 512-битном интерфейсе. При этом он должен обеспечить более высокую ёмкость и более низкие затраты на интеграцию. Тем не менее, несмотря на амбициозные цели, SPHBM4 не предназначен для вытеснения GDDR-памяти.
Почему классическая HBM упирается в масштабируемость
Традиционная HBM использует интерфейсы шириной 1024 или 2048 бит. Благодаря этому она обеспечивает выдающуюся пропускную способность и энергоэффективность. Однако, с другой стороны, такие интерфейсы требуют значительных площадей кремния внутри процессора.
В результате количество HBM-стеков на одном чипе ограничено. Следовательно, это снижает максимальную ёмкость памяти, доступную ИИ-ускорителям. Более того, при росте вычислительных возможностей эта проблема становится всё заметнее.
Как SPHBM4 решает проблему ширины интерфейса
Именно здесь на сцену выходит SPHBM4. Вместо 2048 бит он использует 512-битный интерфейс. При этом для сохранения пропускной способности применяется сериализация 4:1. Иными словами, данные передаются быстрее по меньшему числу линий.
При этом JEDEC пока не раскрывает, достигается ли это за счёт повышения тактовых частот или за счёт нового метода кодирования. Тем не менее, ключевая цель очевидна — сохранить суммарную полосу HBM4 при меньших требованиях к площади интерфейса.
Внутренняя архитектура и ёмкость памяти
Важно отметить, что SPHBM4 использует стандартные HBM4 DRAM-кристаллы. Благодаря этому упрощается разработка контроллеров памяти. Кроме того, сохраняется сопоставимая ёмкость на стек — до 64 ГБ в случае HBM4E.
На бумаге это открывает возможность существенно увеличить суммарную ёмкость памяти на одном чипе. Однако на практике производители ИИ-ускорителей будут искать баланс. В частности, они будут распределять кремниевую площадь между памятью, вычислительными блоками и интерфейсами ввода-вывода.
Может ли SPHBM4 заменить GDDR7?
На первый взгляд может показаться, что SPHBM4 подходит и для игровых видеокарт. В конце концов, высокая пропускная способность всегда востребована. Однако на практике всё гораздо сложнее.
Несмотря на снижение стоимости по сравнению с HBM4 и HBM4E, SPHBM4 всё ещё остаётся дорогим решением. Он требует стеков DRAM, TSV, базового кристалла интерфейса и сложной внутрипакетной сборки. Следовательно, себестоимость плохо масштабируется при массовом производстве.
В отличие от этого, GDDR7 выигрывает за счёт огромных объёмов, простых корпусов и отлаженного PCB-монтажа. Поэтому замена нескольких чипов GDDR7 одним стеком SPHBM4, скорее всего, приведёт к росту стоимости, а не к её снижению.
Преимущества стандартизации и органических подложек
Тем не менее, у SPHBM4 есть важное стратегическое преимущество. JEDEC заявляет поддержку 2.5D-интеграции на обычных органических подложках. Таким образом, отпадает необходимость в дорогих кремниевых интерпозерах.
Кроме того, стандартизованный 512-битный интерфейс потенциально дешевле кастомных решений C-HBM4E с UCIe или проприетарными протоколами. Следовательно, SPHBM4 может стать более доступным вариантом для широкого круга ИИ-чипов.
Ограничения и инженерные сложности
С другой стороны, органические подложки допускают более длинные электрические соединения между SoC и памятью. Это может упростить компоновку крупных корпусов и позволить разместить больше памяти рядом с кристаллом.
Однако даже в этом случае трассировка тысяч линий данных, управления и питания остаётся серьёзным инженерным вызовом. Поэтому практическая реализация будет зависеть от конкретных дизайнов и компромиссов.
Итог: нишевое, но перспективное решение
В конечном счёте, SPHBM4 закрывает разрыв между классической HBM и внешней памятью. Он ориентирован на ИИ и HPC, где важны пропускная способность и ёмкость. При этом он не предназначен для массовых GPU и не является прямым конкурентом GDDR.
Таким образом, SPHBM4 — это эволюционное расширение экосистемы HBM, а не её замена.
Подписывайтесь на наш телеграмм канал и читайте новости в удобном формате — https://t.me/occlub_ru.
