안녕하세요 :)

사전 세팅 필요 내용 우분투 22.04 이상에서 세팅하는것을 가정하고 작성된 문서입니다. 20.04에서 세팅시 libpmix-bin, libhdf5-103-1, libhdf5-hl-100 이 설치되지 않는 이슈를 발견했습니다. 각 인스턴스간 방화벽이 없을 경우를 상정하고 작성된 문서입니다. 만약 방화벽이 있을경우, 아래의 포트등을 열어주시면 됩니다. TCP: 22 TCP/UDP: 6817 TCP/UDP: 6818 TCP: 50001-52000 Slurm의 상태를 외부저장(Slurmdbd)하기 위해서 mysql 서버가 필요합니다. 데이터베이스의 위치는 큰 관계 없으나, 아래의 사항이 지켜져야 합니다. 데이터베이스명은 slurm_acct_db 로 사용합니다. [선택] 환경 세팅 innodb_buffer_pool_size=4096M innodb_log_file_size=64M innodb_lock_wait_timeout=900 max_allowed_packet=16M 설치 방법 모든 서버에 진행해야 할 경우 [ALL], 마스터 서버에만 진행해야 할 경우 [MASTER], 연산 서버에만 진행해야 할 경우 [COMPUTE] 마스터 서버는 마스터인 동시에 연산 서버가 될 수 있습니다....

패키지 설치 및 WOL 사용 sudo apt-get install net-tools ethtool wakeonlan sudo ethtool -s <인터페이스명> wol g 인터페이스 파일 수정 후 WOL 사용 sudo vi /etc/network/interfaces post-up /sbin/ethtool -s <인터페이스명> wol g post-down /sbin/ethtool -s <인터페이스명> wol g service 등록 sudo vi /etc/systemd/system/wol.service [Unit] Description=Configure Wake-up on LAN [Service] Type=oneshot ExecStart=/sbin/ethtool -s <인터페이스명> wol g [Install] WantedBy=basic.target 서비스 시작 sudo systemctl enable /etc/systemd/system/wol.service

작동 환경 차이 docker는 원래 Linux용으로 개발되었으므로 docker container는 기본적으로 Linux 아래에서 돌아갈때 빠르고 효율적입니다. windows는 기본적으로 Linux와는 아키텍쳐가 다르기 때문에 Linux를 실행하지 못합니다. 하지만 이를 가상 머신으로 실행시킬 수 있게 해주는 호환성 계층이 windows에는 WSL(Windows Subsystem for Linux)이라는 이름으로 존재합니다. 이는 컨테이너와 windows 운영체제 사이에 하나의 가상화 계층이 추가로 들어가는것이므로 성능에 영향을 미칠 수 있습니다. windows의 파일시스템은 NTFS로 docker와 직접적으로 호환하지 않아 오버헤드가 있습니다. windows는 가상 네트워크 인터페이스의 생성 및 격리를 용이하게 하기 위한 Network namespace를 지원하지 않습니다....

minio는 aws s3를 대체할 수 있는 고성능 s3 호환 object storage입니다. on-premise에서도 실행 가능한 오픈소스이며, 버킷 기반의 스토리지를 필요로 할때 사용할 수 있는 최적의 솔루션입니다. 위 문서에서는 온프레미스에 minio를 MNMD(multi node multi drive)방식으로 배포하는 법을 다루겠습니다. minio의 배포방식은 총 3가지가 있습니다. SNSD(single node single drive) - 하나의 인스턴스와 하나의 디스크를 사용합니다. 주로 개발 환경이나 테스팅용으로 사용하는 환경입니다. SNMD(single node multi drive) - 하나의 인스턴스에 여러 디스크를 사용합니다. 요구 성능이 낮을때 사용합니다....

nodejs에서 child process로 python 코드 실행 전변에서 사용됨 파이썬 코드를 건드리기 여의치 않은 상황에서 사용했던 방식. 파이썬을 아예 몰라도 개발할 수 있음 매우 비효율적임 flask에서 inference 실행 wim에서 건드리기 이전 매스튜터 ai에서 사용됨 가장 기본적인 모델 배포 방식 개발이 매우 빠름 모델을 실행함에 있어 최소한의 이해는 필요함 api 요청마다 모델을 올려서 사용하므로 매우 비효율적임 ray serve로 배포 후 inference 실행 wim에서 건드린 이후 매스튜터 ai에서 사용됨 어느정도 고도화된 배포 방식 fastapi를 사용하여 개발하며, ray serve가 익숙하다면 개발 속도가 빠른 편 ray라는 고유한 환경 위에서 개발하므로 클러스터링에 대한 걱정이 다소 적음 모델을 미리 올려놓고 api요청을 받기 때문에 꽤나 효율적임 도커나 쿠버네티스등의 대체제가 있는 상황에서 ray serve를 사용할 이유를 찾기 힘듦 도커라이징하지 않아도 클러스터링을 쉽게 사용할 수 있다는게 ray serve의 사용이유...

기획 전 클라이언트와 미팅 후 나온 내용들을 전달받음. - 부정확하나 필요한 사항 이때 아예 불가능한 내용들을 말할 경우에는 refuse. 사용하기 어려운 기술이나 어느정도 기획이 수정되어야 할점이 보일 경우 관련 부분 노티해주고 기술의 경우는 리서칭 [개발, 디자이너] - 금액 및 기간산정 - 개발자들이 산정을 잘못했을 경우 위험함. 고로 비용을 많이 잡거나 기본 금액에 개발 전 파트에서 산정하는게 나을 것 같음 금액 및 기간산정이 완료되고 클라이언트 및 프로젝트 참여자들이 납득 할 경우에 기획 중 단계로 넘어감 기획 중 -현재 기획자는 포지션이 따로 있지 않음(일반적으로 Seena, Jax가 함)...

발단 Lightning AI가 stable diffusion 모델을 수정하여 실시간 요청량에 따른 동적 배치로 같은 성능에서 최대 동접자수를 10배 늘렸다더라. 기존 방식 1. 배치 수를 1개로 고정 무조건 모델의 배치 수를 1개로 고정한다. 장점 빠른 배포 쉬운 유지보수 단점 비효율적인 gpu mem 사용량 2. 배치 수를 n개로 고정 예상되는 유저량을 예상 후, 최대한 효율적이라고 생각되는 배치수로 고정하여 배포한다. 장점 높은 처리량 단점 유저수의 증감에 따라 오히려 비효율적일 수 있음 초기에 최적의 배치수를 찾는 과정에 시간이 걸림 Lightning AI의 dynamic batching Lighting AI는 stable diffusion모델의 batch 수를 1개로 고정하여 최대 동접자 30명을 처리할 수 있었고, batch 수를 12로 늘려 프로세스당 60명의 동접자를 처리할 수 있었다....

Ray is a unified framework for scaling AI and Python applications. Ray consists of a core distributed runtime and a toolkit of libraries (Ray AIR) for simplifying ML compute Ray는 인공지능 개발, 배포 및 스케일링을 손쉽게 할 수 있도록 도와주는 프레임워크 모음입니다. Ray에는 여러 툴킷등이 있으나 이 문서에서는 Ray Serve의 기초적인 사용법과 Ray Serve를 배포하면서 만난 이슈들에 대해 다룹니다. Ray Serve 작동 원리 Ray Serve는 언어에 구애받지 않고 AI를 손쉽게 배포, 확장하기 위해 만들어진 라이브러리입니다....

Grafana Labs의 오픈소스 로깅 시스템인 Loki와 log tailing agent인 Promtail에 대해 다룹니다. 선택 이유 ELK stack, new Relic등 다른 좋은 서비스들도 있었으나, ELK stack은 기본 리소스 사용량이 많고, new Relic은 on premise가 없고, 일정 기준 이후에는 비용이 든다는 문제가 있어 가볍고 Grafana, Prometheus조합으로 사용해봤던 기억이 있는 Grafana, Loki 환경을 선택하게 되었습니다. Loki, PromTail Loki는 Grafana Labs에서 출시한 로깅 시스템이다. Prometheus와는 다르게, metric 수집보다는 로그 수집에 더욱 특화되어 있어, 가볍고 로깅 관련 쿼리도 빠르다는 장점이 있습니다....

인덱싱은 무언가를 빨리 찾고자 할때 사용함. 개념적인 원리는 책의 목차와 같음 우리는 책의 목차에 내용의 위치와 키워드 등 내용을 특정할 수 있는 짧은 문자열을 새겨둠 인덱싱만 보고 책의 내용을 알수는 없음 인덱싱에 쓰일 키워드를 잘못 정하면 책의 크기가 너무 커짐 하지만 이를 제대로 해둔다면 책의 크기는 큰 차이가 없으면서 필요한 내용을 찾는 속도를 획기적으로 줄일 수 있음 innodb는 b+tree를 사용함 b+tree를 이해하려면 먼저 b tree를 이해해야 한다. 그전에, 왜 트리구조인지 먼저 이해해야 함 정보의 저장은 디스크에서 일어남 100개의 정보를 저장할때에 이의 n%가 인덱스가 되어서 저장됨 하지만 원본정보가 아니라 10000개라고 하면 n도 점점 커짐 n을 인덱싱할 필요가 생김 b → c → d 가 계속 반복되면 자연스럽게 트리구조가 됨 b tree란?...