발전에서 점점 어려워지는 부분 객관성과 재현가능성 남이 확인한 결과를 나도 확인해볼 수 있는 것 필요로 하는 자원의 양 증가 자본 집약적 알고 있어야 하는 배경 지식과 대상의 증가 높은 복잡성 § Make AI Accessible 초기 분야에서 나타나는 다양한 비효율을 선제적으로 제거 및 최적화 유관 분야 지식과 기술 체계의 수직적 통합 머신러닝 분야의 워크로드 특징 이해 대규모 하드웨어 구축의 어려움 이해 소프트웨어 개발·유지보수 과정의 고유 특성 이해
논리적 자원의 분리 § 컨테이너 출발은 Linux cgroup을 통한 운영체제의 namespace 분리 및 자원 제약 구현 하드웨어 성능을 그대로 활용하면서, 일반 user process보다 높은 수준의 격리 가능 Docker가 overlay filesystem 개념을 도입하여 재현가능한 소프트웨어 배포 환경으로 부상 § 기술적 도전 Interactive workload Batch workload Mixed workload Homogeneous CPU·RAM·Local disk Heterogeneous GPU·NPU·RDMA·Network storage
고려하지 않고 모든 하드웨어 자원을 땡겨가려 시도하는 소프트웨어들 대부분의 최종 사용자들은 컨테이너를 VM처럼 생각 왜 sudo가 안 되나요? 이용 종료 후에도 가상 디스크 에 자신의 변경사항이 그대로 보존된다고 생각 컨테이너를 VM처럼 실행하는 것은 가능하지만 예: lxd , 연산자원 유연화를 달성하려면 가속기 자원의 동적 할당을 위해 언제든 휘발·재개 가능한 상태여야 함 VM보다는 프로세스에 가깝다!
컴퓨터들을 여러 개 모아서 병렬·분산 처리 § 이 분야에서 잘 하던 것 : 이종교배 하나의 연산 노드에 다양한 형태의 가속 프로세서 장착 고집적·고밀도 고려한 하드웨어 레이아웃 기반 스케줄링 최고의 성능을 위해서라면 x86 뿐만 아니라 다양한 CPU 아키텍처 활용 벡터 명령어 등 § 최근의 변화 개별 노드의 성능 극대화 발열과 전력 문제 수냉! 컨테이너 기반 스택 확산 § 기술적 도전 네트워크 병목을 어떻게 줄일 것인가? 불특정 다수 사용자 multi tenancy 지원
처음에는 각 픽셀에 추가 적용할 연산을 정의하는 계산 함수에서 출발 점차 범용 프로그램을 실행할 수 있는 형태로 발전 GPGPU 처음에는 영상·게임 분야에서 썼지만 과학연산, 머신러닝 등에도 활용 원리 상호의존도가 낮은 정보들을 대규모로 병렬 처리 GPU의 클럭 속도는 낮지만 높은 병렬성으로 고성능 달성 § 새로운 복잡성 운영체제의 CPU 스케줄링을 GPU 스케줄링에 그대로 적용할 수 없음 GPU가 컴퓨터의 중심이 되면서 점점 고도화된 스케줄링 요구 증대
I/O 네트워크 메모리 § 머신러닝의 등장으로 인한 변화 FP16, FP8, INT8, BF16 등 정밀도를 희생하고 계산속도를 올린 수치 형식 보급 추론에는 생각보다 높은 정밀도의 계산이 필요하지 않더라! § LLM의 특징 거대한 단일 벡터로 인해 메모리 대역폭의 중요성이 커짐 HBM 기술의 부상 § 점점 복잡해지는 하드웨어 가속 기술 RDMA / GPU Direct Storage 연산 작업 스케줄러가 이런 구성을 인식·반영해야 최적 성능 달성
문서, 위키, 이슈 트래커 작성된 코드와 그 변경 이력 개발도구와 사용한 의존성들 § 보통 간과하는 것 개발팀 구성원들의 머릿속에 들어있는 무형의 지식과 공유 경험 오랜 시간의 협업 과정을 통해 눈에 보이지 않게 성장·확장 내가 갑자기 큰 프로젝트에서 새로운 기여를 하기 어려운 이유 문서화가 도움은 되지만 문화 라는 배경 맥락을 더해야 함 도구, 코드, 의존성 등 눈에 보이는 실체는 다 바뀔 수 있으나 집합적 지식은 개발팀의 핵심 경쟁력이자 핵심 자산
작성한 코드를 지금도 유지보수해야 한다면? 그리고, 지금 작성하는 코드를 10년 후에도 유지보수해야 한다면? § 해결책 갈아끼울 수 있는 추상화 : SOLID 원칙 공통 요소의 인터페이스에 대한 regression test 집합적 지식 공동체의 유지보수와 확장 문서화 α 내부 세미나, 미팅, 코드리뷰, ... § 점점 어려워지는 것 가설 검증에 필요한 배경 지식과 셋업 과정의 복잡도 증가 의존성 관리 업그레이드 가능한 추상화 유지 새로운 엔지니어의 온보딩 credit: Software Engineering at Google https://abseil.io/resources/swe book/html/ch01.html#time and change Backend.AI
발을 딛고 있는 땅이 바뀔 수 있다는 것을 상수로 받아들여야 함 asyncpgsa aiopg.sa SQLAlchemy / aioredis redis py ? CUDA 8.0 ... CUDA 12.1 / TensorFlow PyTorch transformers isort Flake8 Ruff Polymer Lit React § 자체 라이브러리 개발 2017년 aiotools: asyncio 관련 유티릴티, multi process event loop 구조 지원, TaskGroup, VirtualClock 등 Callosum: serialization 계층을 교체할 수 있는 async native RPC 추상화 라이브러리 etcetra, etcd client py: 불안정한 Python용 gRPC 라이브러리 보완한 etcd 클라이언트 어댑터 raftify: Raft consensus 알고리즘 구현하여 Backend.AI Manager의 HA 구성 § 부분적 모노리포 도입 2022년 10여 개 이상의 별도 패키지들에 대한 엔터프라이즈용 버전 호환성 테이블 관리 🤯 Pantsbuild: 내부 의존성 관리 및 CI 병렬화 도구 변경된 모듈에 의존하는 모듈에 대해서만 lint test 수행
관리, 시스템 프로그래밍을 몰라도 된다! 계층화된 사용자·프로젝트를 바탕으로 한 정책 기반 자원·비용 관리 양쪽 장점을 모두 취하기 위해 자체 Sokovan 오케스트레이터 개발 § 업계 최고 수준의 성능 제공 갑자기 성능을 10배로 뻥튀기하지는 않지만, 가지고 있는 하드웨어를 최대 한계까지 활용 § 오픈소스 개발 모델 AI를 개발하고 서비스하는 모두가 우리껄 쓰게 만든다! 기여자를 위한 친절함 개선 은 아직 과제로 남아있음 의존성 문제 : 외부 오픈소스 기여 자체 라이브러리 개발 § 개밥먹기 우리도 비싼 서버 사서 이걸로 잘 돌려보자!
GPU/NPU Acceleration GPU GPU network Build tools / public image repository nvidia docker v1/v2 AI Framework Follow ups Data parallel Pipeline I/O Co existing in container Python adapter Container independent Job subsystem GraphQL based API Offline installer Large scale deployment system User GUI/ CLI/App High Availability CUDA driver layer abstraction Programmable syscall filter Control Panel Dashboard Metric API 통곡의 벽...
lablup
scottboms
ryanjones
paigeccino
axbom
portentint
addyosmani
andyhume
inesmontani
nmsamuel
maggiecrowley
eileencodes
marketingsoph
