일반적인 컨테이너 생성 흐름

쿠버네티스에서 컨테이너를 생성하는 과정은 아래와 같다. kubelet은 gRPC 소켓통신으로 containerd에게 파드 생성에 필요한 명세를 전달한다.  파드 명세를 containerd는 OCI spec으로 바꾸는데 이 과정에서 이미지 레이어를 받아 파일 시스템을 준비하고 CDI 이름을 보고 /etc/cdi에서 실제 디바이스, 마운트, hook을 채워 넣고, cgroup 경로 및 네임스페이스 설정을 확정한다. 

그 후 shim을 띄우고 이는 파드(sandbox) 마다 하나씩 뜨는 별도 프로세스이다. 별도 프로세스인 이유는 containerd가 죽거나 업그레이드 되어도 컨테이너는 살아 남아야하기때문이다. 즉, 수명이 분리되어있다.  컨테이너의 stdout/stderr 중계, 종료 코드 수집, 좀비 프로세스 수확도 shim 몫이다. 

LLM 서비스 최적화가 중요한 이유

앞선 장들이 모델을 동작하게 만드는 이야기였다면 이번 챕터는 LLM을 빠르고 효율적으로 돌아가게 하기 위한 내용이다.

고객 경험

응답 지연은 만족도와 직결된다. 질문을 던지고 첫 토큰까지 20초를 기다린다면 대부분 이탈한다. 같은 하드웨어에서 그 20초를 1초로 줄이면 제품의 성공 확률을 높힐수 있다. 다만 빠를수록 무조건 좋은 것은 아니다.

0.1초를 0.01초로 줄여봐야 사람은 그 차이를 느끼지 못한다. 곡선이 평평해지는 구간에서는 지연을 조금 내주고 처리량을 얻는 편이 낫다. 0.01초를 0.1초로 되돌리는 대신 동시 처리량을 올리면 비용 효율이 좋아진다.