GN⁺: DeepSeek의 Fire-Flyer File System
(github.com/deepseek-ai)Fire-Flyer 파일 시스템
Fire-Flyer 파일 시스템(3FS)은 AI 학습 및 추론 작업의 문제를 해결하기 위해 설계된 고성능 분산 파일 시스템임. 최신 SSD와 RDMA 네트워크를 활용하여 분산 애플리케이션 개발을 단순화하는 공유 스토리지 계층을 제공함.
성능 및 사용성
- 분리된 아키텍처: 수천 개의 SSD와 수백 개의 스토리지 노드의 네트워크 대역폭을 결합하여 애플리케이션이 지역성에 구애받지 않고 스토리지 리소스에 접근할 수 있게 함.
- 강력한 일관성: Chain Replication with Apportioned Queries (CRAQ)를 구현하여 강력한 일관성을 제공하며, 애플리케이션 코드를 단순하고 이해하기 쉽게 만듦.
- 파일 인터페이스: 트랜잭션 키-값 저장소(예: FoundationDB)를 기반으로 하는 상태 비저장 메타데이터 서비스를 개발함. 파일 인터페이스는 널리 알려져 있으며 어디서나 사용됨. 새로운 스토리지 API를 배울 필요가 없음.
다양한 작업 부하
- 데이터 준비: 데이터 분석 파이프라인의 출력을 계층적 디렉토리 구조로 조직하고 대량의 중간 출력을 효율적으로 관리함.
- 데이터로더: 컴퓨트 노드 전반에 걸쳐 학습 샘플에 대한 무작위 접근을 가능하게 하여 데이터셋의 사전 로드나 셔플링이 필요하지 않음.
- 체크포인팅: 대규모 학습을 위한 고속 병렬 체크포인팅을 지원함.
- KVCache for Inference: DRAM 기반 캐싱에 대한 비용 효율적인 대안을 제공하며, 높은 처리량과 상당히 큰 용량을 제공함.
성능
1. 피크 처리량
- 3FS 클러스터의 대규모 읽기 스트레스 테스트에서 약 6.6 TiB/s의 최종 집계 읽기 처리량을 달성함.
2. GraySort
- 대규모 데이터셋의 정렬 성능을 측정하는 GraySort 벤치마크를 사용하여 평가함. 110.5 TiB의 데이터를 8,192개의 파티션으로 정렬하는 데 30분 14초가 소요되었으며, 평균 처리량은 3.66 TiB/분을 달성함.
3. KVCache
- LLM 추론 프로세스를 최적화하기 위해 KVCache 기술을 사용함. 디코더 레이어의 이전 토큰의 키와 값 벡터를 캐싱하여 중복 계산을 피함. 피크 처리량은 최대 40 GiB/s에 도달함.
문서
- 설계 노트
- 설정 가이드
- USRBIO API 참조
- P 사양
소스 코드 확인
- GitHub에서 3FS 저장소를 복제하여 소스 코드를 확인할 수 있음.
문제 보고
- 문제를 보고하려면 GitHub 이슈 페이지를 방문하면 됨.
Hacker News 의견
-
이 디자인은 원래 여기에서 발표되었음: 링크
- 이 파일 시스템은 몇 년 동안 개발되고 사용되었음
- 전통적인 파일 시스템과 비교하여 모델 훈련에 더 집중되어 있음
- 랜덤 읽기가 많은 경우 읽기 캐시와 사전 가져오기가 쓸모없음
- 성능 향상을 위해 이러한 기능 없이 파일 시스템을 설계했음
-
3FS는 AI 훈련 중 컴퓨팅 노드에서 샘플 데이터를 일괄 읽는 시나리오에서 사용됨
- 고속 컴퓨팅과 저장소 상호작용을 통해 모델 훈련을 가속화함
- 대규모 랜덤 읽기 작업이며, 읽은 데이터는 짧은 시간 내에 다시 사용되지 않음
- 따라서 "읽기 캐시"를 사용할 수 없고, 사전 읽기도 쓸모없음
- 3FS는 다른 파일 시스템과 구현이 상당히 다름
-
3FS는 Linux 기반 AIO와 io_uring 인터페이스를 사용하여 샘플 읽기를 완료함
- 파일 캐시는 전혀 효과가 없고, 시스템 메모리를 소모하여 후속 작업에 영향을 미침
- 파일 캐시를 끄고 Direct I/O 모드만 사용하여 데이터를 읽음
- 버퍼 포인터, 오프셋, 길이를 정렬해야 함
- 사용자가 정렬을 하면 추가 메모리 복사가 발생하므로 파일 시스템 내부에서 정렬을 수행함
- 성능을 최적화하고 사용자에게 편리함을 제공함
-
Deepseek와 OpenAI/Anthropic의 차이는 실무자와 학자의 차이 중 하나임
- OpenAI에는 세계적 수준의 인재가 있지만, 기술적 노출이 부족한 사람들도 있음
-
분산 파일 시스템은 가장 까다로운 소프트웨어 중 하나로 여겨짐
- FUSE 위에라도 파일 시스템을 처음부터 작성하지 말라는 조언을 받음
- 실리콘 밸리 회사가 100번째 회의를 할 때, 60명 미만의 팀이 고효율 병렬 파일 시스템을 개발함
-
관련 연구 논문: 링크
- "Fire-Flyer AI-HPC: 딥러닝을 위한 비용 효율적인 소프트웨어-하드웨어 공동 설계"
- 딥러닝과 대형 언어 모델의 급속한 발전으로 계산 능력과 대역폭 수요가 급증함
- Fire-Flyer AI-HPC 아키텍처를 소개하여 비용과 에너지 소비를 절감함
- HFReduce를 설계하여 allreduce 통신을 가속화함
- Computation-Storage Integrated Network의 혼잡을 방지하기 위한 여러 조치를 구현함
-
FUSE 기반 설계로 어떻게 그런 성능을 얻는지 궁금했음
- FUSE는 메타데이터를 관리하는 데 사용되며, 높은 성능을 얻기 위해 C++ 클라이언트 라이브러리를 연결해야 함
- 일반 용도가 아니며, 애플리케이션을 수정해야 함
- 여전히 영리한 방법이며, LD_PRELOAD 전략이 일반화될 수 있을지 궁금함
-
OpenAI 등도 시스템에 깊이 관여하고 있지만, 다른 곳에서는 이런 세심함을 보기 어려움
- 훌륭한 작업이며, Deepseek가 앞으로 더 멋진 일을 하길 바람
-
그들은 확실히 생산적임
- 내일은 무엇을 볼 수 있을까? DeepSeek OS 같은 것?
-
현재 인기 있는 시스템이 어디에서 어떻게 부족한지 명확하지 않음
- 데이터 접근 패턴이 전통적인 사용 사례와 어떻게 다른지 궁금함
-
K8s 같은 오케스트레이터로 포팅하는 것이 이점이 있는지 궁금함
- 훈련에는 과할 수 있지만, KVCache가 다중 복제본을 위한 추론에 유용할 수 있음
-
NIH 증후군이 아닌지 설득할 수 있는 사람이 있는지 궁금함
- 왜 SeaweedFS, Ceph, MinIO 대신 이것을 사용해야 하는지 궁금함