Still Running

Still Running

For developers
Achieve new heights

Field Notes

728x90
반응형
SMALL

Explore

전체 글

글 92개

DevOps, 클라우드(AWS·GCP·Azure), 빅데이터, AI를 다루는 기술 블로그. Kubernetes 운영, 클라우드 인프라 자동화, 데이터 엔지니어링 경험을 기록합니다.

  1. 행 기반 vs 열 기반 저장: 데이터를 세로로 모으면 무엇이 빨라질까?

    금액만 합산할 건데, 배송지까지 읽어야 할까?주문 하나의 배송지, 상태, 금액을 확인하려면 이 정보가 한곳에 있는 편이 편리하다.그래서 주문별로 값을 모아 저장했다고 하자. 이번에는 많은 주문의 금액만 합산하려 한다.질의에서 금액만 달라고 했으니 저장장치에서도 금액만 가져오면 될 것 같다.하지만 금액이 다른 정보와 같은 읽기 단위에 묶여 있다면, 필요 없는 값도 함께 읽을 수 있다.요청하는 값을 줄이는 것과 실제로 읽는 양을 줄이는 것은 같은 일이 아니다.그렇다면 금액끼리 모아 두면 해결될까?합산에는 유리해도 이번에는 주문 하나의 전체 정보를 여러 곳에서 모아야 한다.한쪽에서 편리한 배치가 다른 쪽에도 편리하지는 않다. 데이터를 무엇과 가까이 두어야, 원하는 일을 할 때 덜 읽을 수 있을까? 행 기반 저..

    댓글
  2. OLTP와 OLAP 차이: 주문 한 건 조회와 매출 집계는 왜 다를까?

    주문 내역은 바로 뜨는데, 매출 합계 하나는 왜 오래 걸릴까?주문 내역은 바로 열리는데 지난달 매출 합계는 기다려야 하는 상황을 생각해 보자.상세 화면에는 배송지부터 결제 내역까지 많은 정보가 나온다.반면 지난달 매출 합계는 숫자 하나면 충분하다.화면에 표시할 것이 적은 두 번째 요청이 DB에도 더 간단한 일일까?합계를 미리 계산해 두지 않았다면, 숫자 하나를 얻기 위해 많은 주문을 살펴야 한다.상세 화면은 필요한 주문 하나를 찾으면 되지만, 짧은 합계 뒤에는 넓은 범위의 계산이 숨어 있다.결과의 크기만으로는 처리할 일의 크기를 알 수 없는 셈이다.그렇다면 SQL이 짧은지, 결과가 몇 줄인지 대신 무엇을 봐야 할까?같은 데이터를 읽더라도, 어떤 일을 시키느냐에 따라 DB에 요구하는 것이 어떻게 달라질까?..

    댓글
  3. GPU 네트워크와 인터커넥트: LLM 요청은 어떤 길을 지날까?

    사용자가 LLM에 보낸 채팅과 학습 데이터는 여러 GPU와 서버 사이에서 어떤 길을 지나며,어디에서 느려질까?GPU 네트워크가 실제 서비스에서 하는 일을 보기 위해,사용자가 LLM에 “이 문서를 요약해 줘”라고 입력한 장면부터 시작해 보자.전송한 문장은 몇 KB에 불과할 수 있다.그런데 답변을 만들기 위해 모델이 여러 GPU에 나뉘어 있다면,GPU들은 모델의 층을 지날 때마다 중간 계산 결과를 주고받는다.답변을 한 토큰씩 생성할 때도 이 과정이 반복된다.겉으로는 짧은 채팅 한 번이지만,시스템 안에서는 사용자 메시지보다 훨씬 많은 데이터가 GPU 사이를 오갈 수 있다.대규모 학습에서는 그 규모가 더 커진다.순전파의 중간 결과와 역전파의 기울기를 수백·수천 개 GPU가 계속 교환해야 한다.따라서 GPU 네트..

    댓글
  4. 멀티 GPU 분산 학습 쉽게 이해하기: Data·Tensor· Pipeline·Expert 병렬화

    하나의 GPU에 들어가지 않는 모델을 여러 GPU에 어떻게 나눠 학습할까?멀티 GPU 분산 학습은 하나의 큰 학습 작업을 여러 GPU가 나눠 수행하는 방법이다.하지만 GPU를 여러 장 사용한다고 해서 모델이 저절로 나뉘는 것은 아니다.어떤 방식은 학습 데이터를 나누지만 모델은 GPU마다 똑같이 복제한다.어떤 방식은 모델의 층을 나누고, 어떤 방식은 하나의 거대한 행렬 계산을 여러 GPU가 함께 처리한다.결국 분산 학습에서 가장 먼저 물어야 할 질문은 “GPU가 몇 장인가?”가 아니라 “무엇을 나눌 것인가?”다.이번 글에서는 데이터(Data)·텐서(Tensor)·파이프라인(Pipeline)·전문가(Expert) 병렬화가 각각 무엇을 나누는지부터 살펴보고,ZeRO와 FSDP처럼 이름만 보면 어려운 기술도 실..

    댓글
728x90
반응형
LIST

행 기반 vs 열 기반 저장: 데이터를 세로로 모으면 무엇이 빨라질까?

금액만 합산할 건데, 배송지까지 읽어야 할까?주문 하나의 배송지, 상태, 금액을 확인하려면 이 정보가 한곳에 있는 편이 편리하다.그래서 주문별로 값을 모아 저장했다고 하자. 이번에는 많은 주문의 금액만 합산하려 한다.질의에서 금액만 달라고 했으니 저장장치에서도 금액만 가져오면 될 것 같다.하지만 금액이 다른 정보와 같은 읽기 단위에 묶여 있다면, 필요 없는 값도 함께 읽을 수 있다.요청하는 값을 줄이는 것과 실제로 읽는 양을 줄이는 것은 같은 일이 아니다.그렇다면 금액끼리 모아 두면 해결될까?합산에는 유리해도 이번에는 주문 하나의 전체 정보를 여러 곳에서 모아야 한다.한쪽에서 편리한 배치가 다른 쪽에도 편리하지는 않다. 데이터를 무엇과 가까이 두어야, 원하는 일을 할 때 덜 읽을 수 있을까? 행 기반 저..

OLTP와 OLAP 차이: 주문 한 건 조회와 매출 집계는 왜 다를까?

주문 내역은 바로 뜨는데, 매출 합계 하나는 왜 오래 걸릴까?주문 내역은 바로 열리는데 지난달 매출 합계는 기다려야 하는 상황을 생각해 보자.상세 화면에는 배송지부터 결제 내역까지 많은 정보가 나온다.반면 지난달 매출 합계는 숫자 하나면 충분하다.화면에 표시할 것이 적은 두 번째 요청이 DB에도 더 간단한 일일까?합계를 미리 계산해 두지 않았다면, 숫자 하나를 얻기 위해 많은 주문을 살펴야 한다.상세 화면은 필요한 주문 하나를 찾으면 되지만, 짧은 합계 뒤에는 넓은 범위의 계산이 숨어 있다.결과의 크기만으로는 처리할 일의 크기를 알 수 없는 셈이다.그렇다면 SQL이 짧은지, 결과가 몇 줄인지 대신 무엇을 봐야 할까?같은 데이터를 읽더라도, 어떤 일을 시키느냐에 따라 DB에 요구하는 것이 어떻게 달라질까?..

GPU 네트워크와 인터커넥트: LLM 요청은 어떤 길을 지날까?

사용자가 LLM에 보낸 채팅과 학습 데이터는 여러 GPU와 서버 사이에서 어떤 길을 지나며,어디에서 느려질까?GPU 네트워크가 실제 서비스에서 하는 일을 보기 위해,사용자가 LLM에 “이 문서를 요약해 줘”라고 입력한 장면부터 시작해 보자.전송한 문장은 몇 KB에 불과할 수 있다.그런데 답변을 만들기 위해 모델이 여러 GPU에 나뉘어 있다면,GPU들은 모델의 층을 지날 때마다 중간 계산 결과를 주고받는다.답변을 한 토큰씩 생성할 때도 이 과정이 반복된다.겉으로는 짧은 채팅 한 번이지만,시스템 안에서는 사용자 메시지보다 훨씬 많은 데이터가 GPU 사이를 오갈 수 있다.대규모 학습에서는 그 규모가 더 커진다.순전파의 중간 결과와 역전파의 기울기를 수백·수천 개 GPU가 계속 교환해야 한다.따라서 GPU 네트..

멀티 GPU 분산 학습 쉽게 이해하기: Data·Tensor· Pipeline·Expert 병렬화

하나의 GPU에 들어가지 않는 모델을 여러 GPU에 어떻게 나눠 학습할까?멀티 GPU 분산 학습은 하나의 큰 학습 작업을 여러 GPU가 나눠 수행하는 방법이다.하지만 GPU를 여러 장 사용한다고 해서 모델이 저절로 나뉘는 것은 아니다.어떤 방식은 학습 데이터를 나누지만 모델은 GPU마다 똑같이 복제한다.어떤 방식은 모델의 층을 나누고, 어떤 방식은 하나의 거대한 행렬 계산을 여러 GPU가 함께 처리한다.결국 분산 학습에서 가장 먼저 물어야 할 질문은 “GPU가 몇 장인가?”가 아니라 “무엇을 나눌 것인가?”다.이번 글에서는 데이터(Data)·텐서(Tensor)·파이프라인(Pipeline)·전문가(Expert) 병렬화가 각각 무엇을 나누는지부터 살펴보고,ZeRO와 FSDP처럼 이름만 보면 어려운 기술도 실..