[태그:] GPU

GPU 연산 여력은 아직 남아 있다. 그런데 동시 요청이 조금 늘자 응답이 밀리기 시작한다. LLM을 직접 띄워 운영하는 팀이라면 충분히 마주칠 수 있는 장면이다.

이때 먼저 떠오르는 해법은 두 가지다. 모델을 바꾸거나, GPU를 더 사거나. 원인이 모델 바깥에 있다면 둘 다 돈만 더 쓰는 선택이 될 수 있다.

EXL이 MIT Technology Review에 실은 기고문은 이 ‘모델 바깥’에 서빙 하네스(serving harness)라는 이름을 붙였다. 매체 편집국이 아니라 EXL이 제작한 콘텐츠다. 주장은 한 줄로 줄어든다. 엔터프라이즈 AI의 다음 경쟁력은 어떤 모델을 고르느냐보다 그 주변에 무엇을 짓느냐에 달렸다는 것.

솔루션 기업이 쓴 글이니 걸러 들을 대목은 있다. 다만 뼈대가 되는 설명, 즉 가중치는 고정이고 KV 캐시는 요청에 따라 불어난다는 대목은 추론 시스템의 일반적인 동작 원리와 맞아떨어진다. 개념을 정리하는 용도로는 충분히 쓸 만하다. 아래에서 서빙 하네스의 구성, 병목이 생기는 지점, 그 병목을 푸는 순서를 차례로 본다.

서빙 하네스, 가중치 파일 바깥의 네 가지 결정

AI 이야기의 중심엔 늘 모델 성능이 있었다. 더 큰 모델, 더 나은 추론 능력, 더 긴 컨텍스트 윈도, 더 높은 벤치마크 점수.

실험 단계를 지나 프로덕션에 들어서면 질문 자체가 바뀐다.

• 실험 단계: ‘이 모델이 뭘 할 수 있지?’
• 프로덕션: ‘이 지능을 안정적으로, 경제적으로, 대규모로 전달할 수 있나?’

서빙 하네스는 두 번째 질문에 답하는 시스템이다. 모델 가중치 파일 자체를 말하는 게 아니다. 모델을 둘러싸고 요청을 받아 처리하고 응답을 돌려주는 엔지니어링 전체를 가리킨다. 쪼개 보면 네 덩어리.

• 아키텍처: 요청이 어떤 경로로 들어와 어느 서버와 GPU에서 처리되는지, 모델을 몇 벌 띄워 어떻게 배치하는지
• 메모리 관리: 한정된 GPU 메모리를 모델 가중치와 요청별 상태(뒤에서 볼 KV 캐시)에 어떻게 나눠 쓰는지
• 스케줄링: 동시에 들어온 요청을 어떤 순서와 묶음으로 처리할지
• 최적화 결정: 양자화, 추측 디코딩, 어텐션 최적화 같은 기법 중 무엇을 언제 적용할지

하네스(harness)는 원래 말에 씌우는 마구, 혹은 전선을 묶은 배선 뭉치를 뜻한다. 힘을 내는 건 말이지만, 그 힘으로 마차를 끌게 만드는 건 마구다. 이름부터가 꽤 정확한 비유다.

기고문의 논리는 이렇게 이어진다. 기업들이 점점 같은 모델을 쓸 수 있게 되면서 모델만으로는 차별화가 어려워진다. 차이는 그 모델을 얼마나 효율적으로 실제 기능으로 바꾸느냐에서 난다.

대화형이냐 배치형이냐가 서빙 구조를 가른다

전제부터 짚자. 누구에게나 ‘최고’인 모델이나 AI 아키텍처는 없다. 풀려는 업무 문제에 맞는 해법이 있을 뿐이다. 워크로드가 제약을 정하고, 제약이 서빙 구조를 정한다.

빠른 응답이 생명인 고객 응대 어시스턴트와 밤새 돌아가도 괜찮은 문서 처리 파이프라인. 둘을 나란히 놓으면 요구사항이 근본부터 다르다.

• 대화형 서비스: 사용자가 첫 글자를 기다리는 시간이 체감 품질을 좌우한다. 지연을 짧게 유지하는 게 1순위.
• 배치형 파이프라인: 개별 응답 속도보다 전체 처리량과 건당 비용이 중요하다.

사내 지식 검색 앱과 대량 트래픽을 받는 고객 서비스 플랫폼도 마찬가지다. 같은 기반 모델을 써도 서빙 구조는 완전히 달라질 수 있다.

문제는 PoC 단계에선 이 차이가 잘 안 보인다는 점. 사용자가 몇 명뿐이면 모델 정확도가 논의를 독차지한다. 지연, 동시성, 메모리 압박, GPU 활용률, 인프라 비용, 예측하기 어려운 트래픽 같은 제약은 뒤로 밀리기 쉽다. 그리고 프로덕션에 올라가는 순간 한꺼번에 드러난다.

구분	PoC 단계	프로덕션 단계
핵심 질문	모델이 무엇을 할 수 있나	그 지능을 안정적·경제적·대규모로 전달할 수 있나
주로 보는 지표	모델 정확도	지연, 동시성, GPU 활용률, 인프라 비용
사용자와 트래픽	소수 사용자	많은 사용자, 예측하기 어려운 트래픽
메모리 압박	사용자가 적어 무시하기 쉬움	동시 요청이 늘면서 병목으로 드러남
모델 선택 기준	가장 좋은 답을 내는 모델	워크로드에 맞는 성능을 맞는 비용으로 내는 모델

기고문에 나오는 비유 하나가 이 표의 마지막 줄을 잘 요약한다. 모든 워크로드에 페라리가 필요한 건 아니라는 것.

답변이 조금 더 나은 모델이라도 추론 비용을 두 배로 늘리거나 애플리케이션의 지연 요구를 맞추지 못한다면, 프로덕션에서는 더 나은 선택이 아닐 수 있다. 업무에 필요한 만큼의 성능을 내면서 쓰지도 않을 능력에는 돈을 내지 않는 모델. 이쪽이 더 영리한 결정일 때가 많다.

이렇게 보면 서빙 구조는 엔지니어링 문제이면서 동시에 투자 결정이다. 정해야 할 것은 세 가지다.

• 어디에 연산 자원을 쓸지
• 어디를 최적화할지
• 어느 지점부터는 모델 성능을 더 올려도 비용만큼의 가치가 없는지

연산은 남는데 메모리가 먼저 바닥나는 이유, KV 캐시

서빙 하네스에서 가장 먼저 이해해야 할 자원은 GPU 메모리다.

언어 모델은 토큰을 하나씩 생성한다. 새 토큰을 만들 때마다 앞선 모든 토큰을 참고하는 어텐션 연산을 거친다. 이때 앞 토큰들의 키(key)와 값(value)을 매번 다시 계산하면 낭비가 크다. 그래서 한 번 계산한 결과를 메모리에 저장해 두고 재사용하는데, 이 저장 공간이 KV 캐시다.

GPU 메모리를 차지하는 건 크게 두 덩어리다. 둘의 성격이 정반대라는 점이 이 글 전체의 열쇠.

구분	모델 가중치	KV 캐시
크기	추론 중에는 변하지 않고 고정	컨텍스트가 길수록 커짐
누가 쓰나	한 번 올려 두면 모든 요청이 함께 씀	요청마다 따로 생김
무엇이 쌓이나	추론 중에는 늘지 않음	입력 토큰과 이미 생성한 토큰이 모두 쌓임
동시 요청이 늘면	그대로	전체 크기도 그만큼 늘어남

동시 요청이 늘면 KV 캐시 전체가 불어난다. 그러다 어느 순간 연산 장치엔 여유가 있는데 쓸 수 있는 GPU 메모리가 먼저 바닥난다. 이때 서버가 할 수 있는 건 두 가지뿐이다. 새 요청을 대기열에 세우거나, 처리 중이던 요청을 밀어내거나. 사용자 쪽에선 그저 ‘느려졌다’로 보인다.

이 병목을 모른 채 GPU만 늘리면 비효율적인 시스템을 더 비싸게 만들 뿐일 수 있다. 서두에서 GPU 추가 구매가 답이 아닐 수 있다고 한 근거가 바로 이 대목이다.

운영 지표도 GPU 사용률 하나로는 부족하다. 함께 봐야 할 숫자는 이렇다.

• GPU 메모리 중 KV 캐시가 차지하는 비중
• 동시에 처리 중인 요청 수
• 대기열 길이
• 요청별 컨텍스트 길이 분포

긴 컨텍스트 윈도도 같은 맥락에서 봐야 한다. 스펙표에선 매력적이지만, 긴 컨텍스트를 쓰는 요청이 많아질수록 같은 메모리로 동시에 받을 수 있는 요청 수는 줄어든다. 최대 컨텍스트를 지원한다는 것과 그걸 다 써도 괜찮다는 것은 별개의 이야기다. 이 지점을 겨냥한 선택지는 다음과 같다.

• 워크로드별로 최대 컨텍스트 길이 제한하기
• 프롬프트에 매번 붙는 불필요한 내용 줄이기
• KV 캐시를 최대 길이만큼 미리 잡아 두지 않고 필요한 만큼 나눠 할당하는 서빙 엔진 고르기

양자화·추측 디코딩은 병목을 확인한 다음 차례

프로덕션에선 따로 떨어져 보이던 결정들이 서로 맞물려 돌아간다. 연결 고리를 따라가면 이렇다.

서빙 구조 → 메모리 활용 → 동시성 → 배칭·스케줄링 → GPU 활용률과 지연

서빙 구조가 메모리 쓰는 방식을 정한다. 남은 메모리가 동시에 받을 수 있는 요청 수를 정하고, 그 수가 배칭과 스케줄링 방식을 제한한다. 최종 결과는 GPU 활용률과 응답 지연으로 나타난다. 양자화, 추측 디코딩, 어텐션 최적화 같은 기법은 이 사슬이 정리된 뒤에야 제값을 한다. 기법마다 겨냥하는 지점도, 치르는 대가도 다르다.

기법	방식과 겨냥하는 지점	조건·주의점
양자화	가중치를 더 낮은 정밀도로 표현해 메모리 사용량과 메모리 대역폭 부담을 줄인다. 아낀 메모리는 KV 캐시에 돌릴 수 있다.	답변 품질이 떨어지지 않는지 평가가 따라와야 한다.
추측 디코딩	작은 초안 모델이 여러 토큰을 먼저 제안하고 큰 모델이 한 번에 검증한다. 초점은 토큰 생성 지연 단축.	초안 모델도 메모리를 차지하고, 부하 상황에 따라 효과가 달라진다.
어텐션 최적화	어텐션 연산의 메모리 접근 방식을 개선해 속도와 메모리 효율을 끌어올린다.	긴 컨텍스트에서 특히 효과가 크다.

함정은 표의 가운데 줄에 있다. 시스템을 막고 있는 원인이 KV 캐시 메모리 부족인데 추측 디코딩부터 붙이면, 초안 모델이 메모리를 더 차지해 동시 처리량이 오히려 줄 수 있다. 지연을 줄이려고 넣은 기법이 메모리 병목을 더 조이는 꼴이다.

기고문은 이를 두고 최적화 기법을 포켓몬 카드처럼 다 모으려 하지 말라고 썼다. 가벼운 비유지만, 위 사례를 보면 과장은 아니다. 목표는 기법 수집이 아니다. 애플리케이션의 업무 요구사항을 지키면서 가장 영향이 큰 제약을 걷어내는 것이다.

순서는 단순하다.

• 측정: 최적화하기 전에 먼저 잰다.
• 병목 찾기: 가장 큰 제약을 골라낸다.
• 해결: 그 제약을 푼다.
• 재측정: 결과를 다시 재고, 새 병목이 생겼는지 확인한다.
• 반복: 위 과정을 다시 돌린다.

의사결정 질문도 바뀌어야 한다. ‘우리 조직이 어떤 AI 기능을 배포할 수 있나’가 아니다. ‘검증된 기능이 지속 가능한 비즈니스 가치가 되지 못하게 막는 제약이 무엇인가’를 물어야 투자 방향이 잡힌다.

API만 쓰는 팀은 호출 구조, 자체 서빙 팀은 KV 캐시가 숙제

한국에서 LLM 서비스를 만드는 팀 입장으로 옮겨 보자. 기고문 밖에서 추론한 부분이 섞여 있어서, 추정인 대목은 따로 표시했다.

상용 API만 호출하는 팀. GPU 메모리나 배칭 같은 서빙 하네스의 핵심부는 API 제공사가 맡는다. 그렇다고 하네스와 무관한 건 아니다. 아래 항목은 여전히 우리 몫이고, 요청당 비용과 지연에 직접 영향을 준다.

• 프롬프트 길이 관리
• 워크로드별 모델 라우팅(간단한 요청은 가벼운 모델로 보내기)
• 응답 캐싱
• 모델을 갈아 끼울 수 있는 호출 구조

사내 GPU에 공개 모델을 직접 띄우는 팀. 앞에서 본 KV 캐시, 동시성, 스케줄링 이야기가 그대로 적용된다. 금융·공공처럼 망분리 같은 보안 요건이 있는 환경은 외부 API보다 자체 서빙을 검토할 이유가 생기기 쉽다. 이런 조직일수록 모델 선정만큼 서빙 구조 검토에도 시간을 써야 할 것으로 보인다(추정).

한국어 서비스라면 토큰 효율도 따져 볼 만하다(추정). 토크나이저에 따라 같은 뜻의 문장이 영어보다 더 많은 토큰으로 쪼개지는 경우가 있다. 토큰이 늘면 KV 캐시 크기도, API 과금도 함께 늘어난다. 모델마다 한국어를 처리하는 방식이 다르니, 후보 모델들에 실제 서비스 문장을 넣고 토큰 수를 직접 세어 보는 게 가장 확실하다.

국내 팀도 대개 해외 팀과 같은 모델 후보군에서 고른다. 모델 선택만으로 경쟁사와 차이를 만들기는 점점 어려워질 가능성이 크다(추정). 기고문의 주장을 국내 상황에 옮기면 이런 해석이 나온다. 같은 모델로 더 싸고, 더 빠르고, 더 안정적으로 서비스하는 팀이 앞선다.

확인된 것과 아직 불확실한 것

확인된 것

• 출발점이 된 기고문은 EXL이 제작한 콘텐츠로, 게재 매체의 편집국이 쓴 기사가 아니다.
• 추론 중에 모델 가중치는 고정되어 있고, KV 캐시는 활성 요청 수와 컨텍스트 길이에 따라 커진다.
• 동시성이 높아지면 연산 여력이 남아 있어도 쓸 수 있는 GPU 메모리가 먼저 부족해질 수 있다.
• 서빙 구조, 메모리, 동시성, 배칭·스케줄링, GPU 활용률, 지연은 서로 연쇄적으로 영향을 준다.
• EXL은 ‘Engineering the Harness’ 시리즈에서 서빙 구조, 메모리 관리, 스케줄링, 추론 최적화를 더 깊이 다룬다고 밝혔다.

아직 불확실한 것

• 하네스 설계를 바꾸면 비용이나 지연이 얼마나 줄어드는지에 대해 기고문은 구체적인 수치를 내놓지 않았다.
• 어떤 최적화 기법이 어떤 워크로드에서 가장 효과적인지는 일반화된 답이 없고, 실측으로만 확인할 수 있다.
• 모델 교체를 평가와 설정 변경 수준으로 만드는 게 실제로 어디까지 가능할지는 팀마다 다를 것으로 보인다. 모델마다 프롬프트 형식, 토크나이저, 컨텍스트 길이가 다르기 때문이다.
• 하네스가 모델 선택보다 중요해진다는 주장에는 솔루션 기업의 시각이 담겨 있고, 독립적으로 검증된 결론은 아니다.

모델 교체를 설정 변경으로 끝내는 다섯 가지 장치

서빙 하네스에 투자할 가장 큰 이유는 선두 모델이 계속 바뀐다는 데 있다. 모델은 좋아지고, 하드웨어는 발전하고, 새 최적화 기법도 꾸준히 나온다. 기술이 바뀔 때마다 AI 플랫폼을 다시 지어야 한다면 그 비용은 매번 되풀이된다. 주변 구조가 이런 변화를 쉽게 흡수할 수 있어야 하는 이유다.

기고문이 내놓는 기준은 세 가지다.

• 워크로드 요구사항
• 명확한 서비스 수준 목표(SLO)
• 측정 가능한 프로덕션 경제성

이 셋을 기준으로 시스템을 짜 두면 새 모델이나 인프라가 나왔을 때 업무에 실제로 필요한 것과 대조해 평가할 수 있다. 실무 체크리스트로 바꾸면 다섯 항목이 나온다.

• 워크로드 정의서: 대화형인지 배치형인지, 허용 지연, 예상 동시 요청 수, 컨텍스트 길이 분포를 문서로 남긴다.
• SLO 명문화: 첫 토큰까지 걸리는 시간, 전체 응답 시간, 꼬리 지연(가장 느린 일부 요청의 지연), 가용성, 요청당 비용 상한을 숫자로 정한다.
• 모델 호출 추상화: 애플리케이션 코드가 특정 모델의 API 형식에 직접 묶이지 않도록 인터페이스를 한 겹 두고, 모델 이름과 생성 파라미터는 설정 파일로 뺀다.
• 자체 평가 세트: 공개 벤치마크 대신 우리 업무 데이터로 만든 평가 세트를 유지하고, 새 모델을 품질·지연·비용 세 축으로 기존 모델과 비교한다.
• 관측 지표: GPU 메모리 중 KV 캐시 비중, 동시 요청 수, 대기열 길이, 처리량, 요청당 비용을 대시보드에서 상시 확인한다.

다섯 가지가 갖춰져 있으면 모델 교체는 아키텍처를 갈아엎는 일이 아니라 평가하고 설정을 바꾸는 일이 된다. 다만 프롬프트 형식과 토크나이저가 모델마다 다르니, 어디까지 설정 변경만으로 끝날지는 팀마다 차이가 날 것이다. 체크리스트에 자체 평가 세트가 들어간 것도 그 차이를 숫자로 확인하기 위해서다.

기고문의 결론은 이렇다. 모델은 지능을 제공하고, 그 지능을 안정적이고 경제적인 대규모 결과물로 바꿀 수 있는지는 하네스가 결정한다. 실천으로 옮기면 한 가지로 모인다. 새 모델 소식이 나올 때마다 흔들리지 않으려면, 모델을 고르기 전에 우리 워크로드와 병목부터 숫자로 적어 둘 것.

출처: MIT Tech Review AI