Мы, видимо, тихо подошли к моменту, когда у нас стало галлюцинировать железо.

Наткнулся на пост в ныттере от ресерчера в гугле, где говорится о том, что мы выжали кремний до уровня где silent data corruptions уже больше не теоретическая проблема. Google назвал такие ядра "mercurial cores"- они проходят все заводские тесты, исправно служат месяцами, а потом в непредсказуемый момент, при определённой комбинации инструкций, выдают мусор вместо результата.

Проблему подсветили три крупнейших оператора дата-центров:

Meta - одно из первых исследований крупномасштабного воздействия тихих ошибок на реальной инфраструктуре Silent Data Corruptions at Scale

Google - ключевая работа, давшая название таким ядрам Cores that don't count

Alibaba - Understanding Silent Data Corruptions in a Large Production CPU Population

Собственно, а почему это проблема? В статье The Register Питер Хокшильд рассказывает, что подобное ядро повредило процесс шифрования данных, причем таким образом, что расшифровать файлы могло только это же самое дефектное ядро. Плюс сравнительно недавно вышла статья Understanding Silent Data Corruption in LLM Training, где исследователи из университета Торонто провели эксперименты на больных нодах, выведенных из продакшена: при файнтюнинге LLM на дефектных машинах возникали скачки loss-функции, и в одном случае точность модели упала для нуля.

Как от этого защищаться - пока хз. ECC-память не спасает, потому что данные портятся при вычислении, а не при хранении. Контрольные суммы вроде CRC сами используют векторные инструкции, которые одни из самых уязвимых. Нашел только костыли вроде SiliFuzz (ловит дефекты, которые проявляются на конкретных инструкциях), BootRIST (проверяет ядра при загрузке, то есть дефект, который проявляется после нескольких часов прогрева он не поймает) и Farron (зависит от качества тесткейсов и правильности определения температурной границы)

iCTS: Iterative and Hierarchical Clock Tree Synthesis With Skew-Latency-Load Tree [ссылка]

Прикольная статья, в которой китайцы предлагают интересный метод оптимизации тактового дерева.

Если кратко, то синхронная цифровая схема держится на одном допущении: каждый триггер видит фронт тактового сигнала одновременно (иначе данные защёлкнутся раньше, чем вычисление закончилось, и триггер захватит некорректный результат).

Но "одновременно" физически невозможно. Сигнал идёт от одного источника до тысяч триггеров по металлическим проводам с сопротивлением и емкостью, разные триггеры находятся на разном расстоянии, и сигнал приходит в разное время (эта разница называется skew).

Решение - буферы. Они восстанавливают деградировавший фронт и добавляют контролируемую задержку, и если вставить буферы в нужных точках сети, суммарная задержка по всем путям выравнивается и каждый триггер получает фронт в +/- одно и то же время. Собственно, автоматическое построение такого дерева буферов и называется Clock Tree Synthesis.

Звучит как инженерная задача с однозначным решением, но внутри три цели, которые конфликтуют между собой: минимальный skew, минимальная длина проводов и минимальная latency. Получить всё три одновременно - NP-hard.

Стандартный CTS flow разбит на два независимых шага без обратной связи: сначала DME (алгоритм балансировки топологии тактового дерева) фиксирует структуру дерева: где провода соединяются и как ветвятся. Потом отдельный алгоритм (как правило, ван Гинекен) вставляет буферы уже в готовую структуру: обходит дерево снизу вверх, в каждом узле оценивает варианты буферов с учётом ёмкостной нагрузки downstream и выбирает лучший. Топологию изменить уже нельзя, поэтому алгоритм подстраивается под то, что есть.

Чтобы выровнять задержки на коротких ветках, DME добавляет wire elongations - буквально удлиняет провода змейкой, из-за чего растёт ёмкость и мощность. Буферы потом сайзятся под худший случай нагрузки, часто избыточно.

И это бьёт не только по мощности. Буферы занимают площадь кристалла, тактовые провода съедают ресурсы роутинга, рядом с кластерами буферов нужны decap-ячейки. Место, которое могло быть вычислениями, занято инфраструктурой доставки сигнала.

Тактовое дерево переключается каждый такт, независимо от того что делает логика. На высокопроизводительных процессорах это может отъедать до 50% от TDP, то есть если чип греется на 100 Вт, то до 50 Вт уходит только на доставку тактового сигнала, а не на вычисления (пара статей про это - [тык], [тык], [тык])

Исследователи из CUHK и Pengcheng Lab предложили строить топологию и буферизацию одновременно с явным trade-off между skew, latency и wirelength. В классическом DME точка слияния двух поддеревьев единственная, где задержки выравниваются, и никакого выбора нет. iCTS расширяет это до отрезка допустимых точек слияния, где любая точка даёт skew в пределах заданной границы, и на этом отрезке алгоритм выбирает точку, минимизирующую сумму с явными весами для latency и wirelength.

Поверх этого иерархическая кластеризация группирует синки не по геометрической близости, а по ёмкостной нагрузке, потому что физически близкие синки могут нагружать дерево по-разному и ломать балансировку. Результат кластеризации дополнительно оптимизируется отжигом. Буферы оцениваются до вставки, что позволяет отсекать плохие варианты раньше. После буферизации ISCA итеративно перезапускает BST-DME на зафиксированной топологии, каждый раз уточняя оценки задержек, пока skew не достигает целевого значения.

На бенчмарках ISCAS'89, OpenLane, OpenCores и ysyx (от 1248 до 22810 flip-flop) при 28nm результат такой: коммерческий P&R инструмент проигрывает iCTS на 39.5% по skew, 13.0% по latency и 18.5% по capacitance, OpenROAD - на 101.6%, 50.7% и 25.5% соответственно. По clock power коммерческий инструмент потребляет в среднем на 32% больше, OpenROAD - на 81% больше.

Хоть в максимальном бенчмарке всего ~23к триггеров, иерархическая архитектура iCTS должна масштабироваться. Не знаю, применит ли это кто-нибудь в продакшене, но звучит многообещающе