Один из самых удобных способов записать данные это использование готовых форматов, такие как JSON или YAML.
Из плюсов такого подхода стоит отметить вот что:
🔸 готовый, повсеместно используемый и поддерживаемый формат
🔸 простой и понятный файл, удобочитаемый для человека
🔸 можно легко редактировать в любом текстовом редакторе без специальных программ и библиотек
Но есть и минусы
🔹 затраты времени при записи файла (кодирование данных в нужный формат строки)
🔹 затраты времени при чтении файла (декодирование данных в Python объекты)
🔹 размер файла увеличивается из-за разметки данных (скобки, запятые, переносы, отступы...)
🔹 перед записью все данные должны быть помещены в память в полном объёме (не всегда)
🔹 при чтении необходимо считать весь файл в память и только потом декодировать данные
Если нужно писать немного данных в несколько файлов, то затраты по времени не ощутимы. Обычно это файлы конфига или какие-либо метаданные. Это отличный вариант под такие задачи.
Есть и другой поход к записи файлов - это бинарные файлы. Используется, когда данных достаточно много и никто их не собирается читать глазками😳.
🔸 очень быстрая запись
🔸 чтение значительно быстрей чем JSON, YAML итд
🔸 размер файла значительно меньше, так как нет разметки
🔸 можно записывать данные по мере поступления не загружая всё в память
🔸 можно извлечь любую часть данных независимо
Из минусов
🔹 нужно определить свой формат записи данных (если не используете готовую спецификацию определённого формата)
🔹 не получится открыть файл и визуально понять что там записано, а для чтения файла потребуется знать его спецификацию.
🔹 не так-то просто создать такой файл без специальной библиотеки
В таком виде удобно записывать большой массив любых однородных данных. Например, мониторинг валютной биржи или кэшированная анимация 3D геометрии.
(Это не означает что нельзя записать данные разного типа, просто это будет не так удобно)
Представьте себе JPG-картинку. По сути это немного мета-информации и большой массив пикселей. Тоже самое со звуком или видео файлом. Поэтому, если вы попробуете открыть картинку в текстовом редакторе вы увидите что-то вроде такого
f15d cd29 a564 4578 ...
09e2 9bc4 a696 1253 ...
84e9 4de1 3b23 c24a ...
2534 5161 28e0 709d ...
...
Это и есть записанные байтики. И для их чтения требуется определённый софт который знает что с ними делать. Под каждый тип файла.
К чему это я? Читайте в следующем посте...
#tricks#basic
Q. 우주 데이터센터, 방사능 문제 괜찮나?
⇒우주 데이터센터에서 HBM이 방사능에 취약하지만, 추론은 문제 없다 (Google 썬캐쳐 논문)
구글은 V6e Trillium 클라우드 TPU와 AMD 호스트 서버를 67 MeV 양성자 빔에 노출시켜 태양 동기 저궤도(LEO)의 운영 환경 (저궤도 환경은 주로 양성자와 은하 우주선(GCR)으로 구성) 을 모사를 해보았음.
결론 ) 방사능 관련해서는 두 가지 한계점이 있음.
1. 총 이온화 선량(TID)
절연층에 전하가 누적되어 장치 성능이 서서히 저하되는 현상
1년에 150 rad(Si)를 견뎌야 함.
5년 임무를 수행하려면 약 750 rad(Si)를 견뎌야 함.
⇒ HBM에서 가장 민감함.
HBM은 연산 로직보다 방사능에 약 3.4배 더 민감하게 반응
⇒ 2000 rad(Si)부터 불규칙한 동작 발생
⇒ 위성의 수명은 5년이기에 2000rad(Si)까지 누적되지 않음. 따라서 HBM이 750rad(Si)까지는 버텨줌.
결론 ) HBM이 이건 버틴다
2. 단일 사건 효과(SEE)
고에너지 입자 하나가 충돌하여 즉각적인 오류 (비트 플립 등)를 일으키는 현상.
(비트 플립이란 방사선의 영향으로 메모리의 0이 1로, 1이 0으로 바뀌는 오류)
특히 감지되지 않는 비트 플립은 무소음 데이터 부패(SDC)를 유발하여 AI 모델 학습을 망칠 수 있음.
⇒ 역시나 HBM에서 가장 민감함.
⇒ 주로 수정 불가능한 ECC 오류로 발생
결론 ) HBM이 이걸 못 버팀. 비트 플립으로 비트가 0이었던게 1로 바뀌는 효과 발생해버려서 치명적
따라서 학습과 추론 시 영향이 차이가 나는데,
학습 ) 학습은 아직 추가 연구 필요
학습 중에는 감지되지 않는 비트 플립이 무소음 데이터 부패(SDC)를 일으켜 모델 전체를 망칠 위험이 있음. 따라서 학습 과정에 대한 영향과 이를 막기 위한 시스템 수준의 완화 기술은 추가 연구가 필요하다고 명시되어져 있음.
추론 ) 추론은 실질적으로 오류 발생 확률 낮아 사용 가능 수준
오류 발생 확률은 낮음. 실질적으로 사용 가능한 수준에 머뭄.
1년에 약 150 rad의 방사선이 내리쬐는 저궤도 환경을 가정하면, AI 추론 시 1,000만 건당 1번 정도의 오류가 발생하는 셈
#우주#SpaceX#구글#데이터센터#TPU#HBM