이전 편에서 확인한 기법들은 한 번의 forward pass를 얼마나 효율적으로 돌릴 것인가에 집중된 기법이었다.그런데 LLM 생성은 근본적으로 토큰을 한 개씩 순차적으로 만들어야 하는(autoregressive) 구조라서, 한 번의 pass를 아무리 최적화해도 "다음

LLM 서비스를 사용할 때 만족해야하는 조건들이 있다.1)사용자 경험. 실제 LLM을 사용해보면 응답 속도에 따라 만족도가 달라진다. 특히 첫 토큰이 나오기까지 걸리는 시간이 길면 답답함을 느끼는 경우가 많다. 즉, 사용자 경험에는 지연시간이 중요하다.이미 충분히 지연

4-1편에서는 하나의 GPU에서 하나의 모델을 서비스하는 문제를 다뤘다. 그런데 실제 서비스는 모델 하나만 필요로 하지 않는 경우가 많다.서로 다른 모델에 대해서 각각 GPU 한 장씩 붙여 서비스하는 것은 비용 면에서 낭비다. 그렇다고 모든 모델을 항상 GPU 메모리에

3-1편에서는 LLM Serving의 전체 구조를 살펴봤고, 3-2편에서는 Prefill, Decode, KV Cache를 통해 LLM이 실제로 어디에서 병목이 발생하는지 살펴봤다.여기까지 읽었다면 이제 이런 질문이 생긴다."그래서 실제 LLM Serving 서버는 어

3-1편에서는 LLM을 실제 서비스로 제공하기 위해 어떤 문제를 해결해야 하는지 전체 지도를 그렸다. Request를 받고, Tokenization을 거치고, 여러 요청을 관리하고, GPU에서 모델을 실행한 뒤 Streaming으로 결과를 전달한다. 그리고 Quanti

1편에서는 CPU와 GPU의 구조를, 2편에서는 그 GPU 위에서 Transformer가 어떻게 동작하는지 살펴봤다.Token은 Embedding과 Positional Encoding을 거쳐 Self-Attention과 FFN을 통과하고, 이 과정을 여러 Transfo

"GPU는 행렬곱을 가장 잘하는 프로세서다.그렇다면 GPU는 실제로 무엇을 계산하고 있을까?"1편에서는 CPU와 GPU의 구조를 살펴보며 왜 AI가 GPU 위에서 동작하는지 알아보았다.CPU는 복잡한 제어를 빠르게 수행하도록 설계되었고,GPU는 수천 개의 연산 유닛을

"같은 행렬곱인데 왜 CPU는 느리고 GPU는 빠를까?"ChatGPT에게 질문을 보내면 GPU 수천 개가 동시에 계산을 수행하며 답을 만들어낸다.그렇다면 이런 궁금증이 생긴다.CPU도 계산을 하는데, 왜 AI는 굳이 GPU를 사용할까?많은 사람들이"GPU는 병렬 처리를

Cilium은 여러 수준에서 보안을 제공하는데, 각 수준은 개별적으로 사용될 수도 있고, 함께 결합하여 사용할 수도 있다. 각 수준에 대해 알아본다. Layer 3 (Identity-Based) 엔드포인트간 연결 정책을 정의하는 방식이다. 전통적인 Kubernetes에서 사용하는 IP 기반 보안 모델은 파드가 생성·삭제될 때마다 모든 노드의 보안 규칙을 ...

GPU 환경에서의 네트워크 최적화: Cilium + SR-IOV + Multus GPU 워크로드는 대규모 연산과 빠른 데이터 전송을 동시에 요구한다. 특히 분산 학습이나 대규모 데이터셋을 다루는 환경에서는 네트워크 지연(latency)과 대역폭(bandwidth)이 성능의 핵심 요소가 된다. Kubernetes 환경에서 이러한 요구를 충족하기 위해서는 S...

Gateway API Gateway API는 Kubernetes에서 서비스 트래픽의 진입 및 라우팅을 관리하기 위한 표준 API다. 기존 Ingress 리소스의 한계를 보완하고, 복잡한 L7 트래픽 관리, 멀티-테넌시, 확장성을 제공한다. Gateway API는 CRD(Custom Resource Definition) 형태로 제공되어 Kubernetes 네...

Cilium Service Mesh Cilium Service Mesh는 기존의 사이드카 프록시(Envoy 등)를 강제적으로 사용하지 않고, eBPF를 활용해 커널 레벨에서 네트워크 및 애플리케이션 계층 트래픽을 제어하는 서비스 메시 구조를 제공한다. 이를 통해 애플리케이션 성능 손실을 최소화하면서도 L3~L7 보안 정책, 트래픽 관리, 모니터링 기능을 통...

BGP ControlPlane 앞선 글에서 살펴본 것 처럼, 서로 다른 네트워크 대역 간 통신을 위해 라우터를 거쳐야 하는 환경에서는 노드가 많아질수록 수동 라우트 설정이 비효율적이라는 문제가 발생한다. 이러한 한계를 해결하기 위한 대표적인 방법에는 Overlay 네트워크와 BGP를 통한 동적 라우팅이 있는데, 이번 글에서는 BGP(Border Gatewa...

Native Routing 환경에서 잘못된 라우팅 설정으로 인해 통신이 되지 않는 상황을 만들고, 이를 라우팅 설정 변경을 통해 해결하는 실습을 진행한다. 실습 환경 Kubernetes 클러스터 노드 k8s-ctr(IP: 192.168.10.100, podCIDR: 172.20.0.98) k8s-w1(IP: 192.168.10.101, podCIDR: ...

IPAM (IP Address Management) IPAM이란 IP Address Management의 약자로, 네트워크의 IP 주소 할당을 자동화하고, 사용 상태를 추적하며, 충돌이나 낭비 없이 효과적으로 IP를 관리하는 시스템이다. Cilium은 기본적으로 eBPF를 기반으로 한 고성능 네트워킹을 제공하는데, 이때 여러 IPAM 모드를 통해 다양한 ...

Hubble Hubble이란 Cilium의 eBPF 흐름을 기반으로, 네트워크 보안 정책, 서비스 흐름, L3~L7 수준의 트래픽을 관찰·분석할 수 있도록 도와주는 관찰/모니터링 플랫폼이다. Hubble 구성 요소 Cilium에서 제공하는 공식문서에는 Hubble을 이용한 Observability에 관해 상세하게 작성되어 있다. | 구성 요소 ...

Migration to Cilium 현재 많은 Kubernetes 클러스터에서 Flannel 또는 Calico와 같은 전통적인 CNI(Container Network Interface) 플러그인이 사용되고 있다. 하지만 최근 eBPF 기반의 고성능 네트워킹 기능이 각광받으면서, CNI 플러그인을 Cilium으로 전환하는 방향이 검토되고 있다. 다음은 Fl...

AWS VPC CNI AWS VPC CNI는 Amazon EKS에서 Pod가 VPC의 IP 주소를 직접 사용할 수 있게 해주는 네트워크 플러그인이다. 이를 통해 Pod와 외부 네트워크간의 통신이 VPC 내에서 직접적으로 이루어지며, 추가적인 네트워크 변환 없이 통신이 가능하도록 한다. VPC CNI의 중요한 특징 중 하나는 Pod가 노드의 네트워크 대역(...

BPF/eBPF iptables는 오랜 기간 리눅스 네트워크 필터링 및 방화벽의 핵심 역할을 해왔지만, 몇 가지 명확한 한계가 있었다. 성능 저하: 방대한 규칙이 쌓일수록 검사해야하는 패킷 수가 늘어나면서 성능이 저하된다. 복잡한 유지보수: 규칙이 많아질수록 관리가