Репост из: Марков цепи пропил
Мы, видимо, тихо подошли к моменту, когда у нас стало галлюцинировать железо.
Наткнулся на пост в ныттере от ресерчера в гугле, где говорится о том, что мы выжали кремний до уровня где 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 (зависит от качества тесткейсов и правильности определения температурной границы)
Наткнулся на пост в ныттере от ресерчера в гугле, где говорится о том, что мы выжали кремний до уровня где 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 (зависит от качества тесткейсов и правильности определения температурной границы)