AI 모델을 서빙하는 서버를 직접 운영하거나, 그 서버 사용료를 줄이고 싶은 분이라면 이 글이 도움이 됩니다. 결론부터 말하면, 프로그램은 그대로 두고 서버 설정 두 개만 바꿨는데 한 번에 처리할 수 있는 요청 수가 18배 넘게 늘었습니다. 모델을 새로 사거나 컴퓨터를 늘리지 않고, 지금 켜져 있는 서버의 설정만 다시 살펴봐도 되찾을 수 있는 크기의 성능입니다.

쉽게 말하면

이 이야기는 식당에 비유하면 이해가 쉽습니다. 손님이 주문하면 주방에서 요리를 하나씩 만들어 냅니다. 지금 이야기하는 AI 서버도 마찬가지입니다. 문장을 한 글자씩 만들어 낼 때마다, 주방에서 요리를 한 그릇씩 완성하는 셈입니다.

그런데 이 주방에는 아무도 손대지 않은 설정이 두 가지 있었습니다. 첫째는 화구, 그러니까 불 세기입니다. 요리사가 요리를 한 그릇 만들 때마다 불을 새로 붙였다가 다시 끄기를 반복하느라, 정작 요리보다 불 붙이는 시간이 더 걸렸습니다. 이 설정은 앞으로 ‘불 미리 붙여 두기’라고 부르겠습니다. 둘째는 문 앞에 걸린 팻말입니다. 팻말에는 ‘한 번에 32명까지만 입장’이라고 적혀 있었는데, 주방은 사실 256명분을 동시에 만들 수 있는 크기였습니다. 이 설정은 ‘동시 손님 수 상한’이라고 부르겠습니다.

두 설정 다 주방을 새로 짓거나 요리사를 바꾸지 않고도 종이 한 장 바꿔 붙이듯 고칠 수 있는 것들입니다. 그런데 아무도 다시 들여다보지 않아서 그대로 방치돼 있었습니다.

무엇을 해봤나

지금까지 서버 속도를 재는 연구는 대부분 이미 잘 맞춰 놓은 서버를 전제로 시작했습니다. 그 잘 맞춰 놓은 서버 자체가 처음부터 얼마나 손해를 보고 있는지는 아무도 재지 않았습니다.

그래서 이번 측정은 그래픽카드 한 장짜리 서버 한 대에서 진행했습니다. 서빙 프로그램(vLLM 0.24.0)과 압축한 모델(RadixArk/Qwen3.8-27B-NVFP4)은 그대로 두고, 서버 설정만 바꿨습니다. 손님에게 2,048자짜리 질문 하나를 주고 256자짜리 답을 만들어 내게 하는 같은 일을, 손님 수를 1명부터 128명까지(가장 잘 맞춘 경우는 256명까지) 단계별로 늘려 가며 시켰습니다. 매번 새 문장으로 세 번씩 반복해 가운데 값을 기록했습니다.

세 가지 경우를 비교했습니다. 첫째는 ‘아무것도 안 건드린 주방’으로, 불도 안 붙여 두고 손님 상한도 32명 그대로 둔 경우입니다. 둘째는 ‘불만 미리 붙여 둔 주방’으로, 손님 상한은 여전히 32명입니다. 셋째는 ‘불도 미리 붙이고 문도 활짝 연 주방’으로, 손님 상한을 256명까지 올렸습니다. 둘째 경우를 따로 만든 이유는 간단합니다. 첫째와 셋째만 비교하면 불과 상한이 동시에 바뀌어서 어느 쪽 덕분에 좋아졌는지 알 수 없기 때문입니다.

서버를 새로 켤 때 따라 할 수 있는 5단계 점검 절차를 보여주는 개념도 서버를 새로 켤 때 그대로 따라 할 수 있는 5단계 점검 절차입니다. 실제로 적용된 설정을 기록에서 확인하고, 손님 수 양 끝에서 기준값을 잰 뒤, 설정을 하나씩만 바꿔가며 두 설정의 효과를 따로 떼어냅니다. (개념도 예시)

나온 결과

혼자 온 손님도 오래 기다렸습니다

손님이 딱 한 명일 때를 재 봤습니다. 아무것도 안 건드린 주방은 1초에 7.4글자를 냈고, 불만 미리 붙여 둔 주방은 1초에 138.9글자를 냈습니다. 18.8배 차이입니다.

즉, 사람 말로는 불을 미리 붙여 두기만 해도 손님 한 명을 응대하는 속도가 열여덟 배 넘게 빨라진 것입니다. 불을 매번 새로 붙이고 끄는 데 드는 시간이 그만큼 손해였다는 뜻입니다.

손님이 몰릴 때는 어땠을까요. 불도 붙이고 문도 활짝 연 주방은 손님 256명이 한꺼번에 왔을 때 1초에 4,150.7글자를 냈습니다. 아무것도 안 건드린 주방은 231.6글자에서 더 늘지 않고 멈춰 있었습니다. 격차는 17.9배입니다. 다만 이 숫자는 최솟값으로 봐야 합니다. 문을 활짝 연 주방이 마지막 순간까지도 직전보다 7.9퍼센트씩 더 오르고 있어서, 진짜 한계에는 아직 도달하지 않았기 때문입니다.

즉, 사람 말로는 손님이 많이 몰리는 바쁜 시간대일수록 두 설정을 고치지 않은 대가가 더 커진다는 것입니다.

두 설정은 다르게 작동합니다

두 설정을 하나씩 따로 재 보니 흥미로운 사실이 나왔습니다. 두 설정은 같은 방식으로 일하지 않았습니다.

불 미리 붙여 두기의 효과는 손님이 한 명이든 여덟 명이든 서른두 명이든 백스물여덟 명이든 거의 똑같이 크게 나타났습니다. 각각 18.8배, 16.5배, 10.2배, 10.0배였습니다. 이유는 단순합니다. 불을 매번 새로 붙이는 주방은 손님이 늘어도 요리 한 그릇당 걸리는 불 붙이는 시간이 줄지 않습니다. 실제로 아무것도 안 건드린 주방은 손님이 1명, 8명, 32명일 때 요리사 한 명당 만들어 내는 양이 7.4, 6.96, 7.12로 거의 그대로였습니다. 반면 불을 미리 붙여 둔 주방은 138.9, 115.2, 72.7로 손님이 늘수록 오히려 한 사람당 처리량이 줄었습니다. 이것은 여러 명을 한꺼번에 요리해서 효율이 나는 정상적인 모습입니다.

동시 손님 수 상한은 반대로 움직였습니다. 손님이 32명 이하일 때는 이 설정을 아무리 올려도 효과가 정확히 1.00배, 즉 아무 차이가 없었습니다. 손님이 32명을 넘어설 때부터만 효과가 나서, 128명일 때 1.66배, 가장 많이 몰렸을 때는 최소 1.79배를 벌었습니다.

트래픽 상황별로 두 설정의 효과 크기를 비교한 막대그래프 손님이 적을 때와 많을 때 각각, 두 설정을 하나씩만 바꿔서 잰 효과 크기입니다. 불 미리 붙여 두기 쪽이 두 경우 모두 더 큰 효과를 냅니다. 동시 손님 수 상한 쪽은 상한 이하일 때는 정확히 1.00배로 아무 효과가 없다가 상한을 넘을 때만 작동합니다. (실측: 논문 표 1의 분리된 값)

즉, 사람 말로는 문 앞 팻말을 넓히는 것은 손님이 실제로 그 문턱을 넘어설 때만 의미가 있는 설정이라는 것입니다. 불 미리 붙여 두기는 언제나 먼저 해야 할 일이고, 문을 넓히는 것은 손님이 몰릴 때만 챙기면 되는 두 번째 일입니다.

세 가지 설정에서 손님 수를 늘려가며 잰 처리 속도 그래프 세 가지 경우의 손님 수별 처리 속도입니다. 아무것도 안 건드린 곡선과 불만 미리 붙인 곡선 사이 간격이 불 설정의 효과이고, 그 위 튜닝 곡선과의 간격이 손님 상한의 효과입니다. 손님 수가 32명을 넘기 전까지 두 곡선은 겹쳐 있습니다. 튜닝 곡선은 마지막 지점에서도 여전히 오르는 중이라, 4,150.7은 한계치가 아니라 측정이 끝난 지점으로 읽어야 합니다. (실측값)

논문은 여기에 원칙을 하나 더 얹습니다. 운영자가 요청한 값이 아니라, 서버가 켜질 때 기록에 실제로 남긴 값만 ‘적용됐다’고 인정하자는 것입니다. 중간에 있는 다른 정책이 값을 몰래 바꾸거나 무시할 수 있어서, 운영자가 믿고 있는 설정과 서버가 실제로 쓰는 설정이 다를 수 있기 때문입니다. 이 원칙 위에서 다섯 단계 점검 절차를 제시합니다. 먼저 실제 설정을 기록에서 읽고, 전체 손해를 잰 다음, 불 설정만 켜서 그 효과를 따로 떼어내고, 손님 상한만 올려서 그 효과를 또 따로 떼어낸 뒤, 두 효과와 문턱값, 서버 켜는 데 드는 시간을 함께 보고합니다. 이 절차는 새 그래픽카드 없이 지금 켜져 있는 서버에서 그대로 해볼 수 있습니다.

그래서 무엇을 바꾸면 되나

첫째, 지금 켜져 있는 서버의 진짜 설정값을 로그에서 직접 확인하는 것이 먼저입니다. 요청한 값과 실제로 적용된 값이 다를 수 있기 때문입니다.

둘째, 불 미리 붙여 두기는 항상 먼저 켜는 것이 맞습니다. 손님이 몰리든 아니든 손해가 크기 때문입니다.

셋째, 동시 손님 수 상한은 실제로 손님이 몰리는 서비스에서만 올리면 됩니다. 값을 올리는 대가는 서버가 켜지는 시간이 약 79초 늘어나는 것뿐이라, 이 정도로 처리량을 몇 배씩 되찾을 수 있다면 남는 장사입니다.

저희 회사 ThakiCloud도 이 실측 결과를 그대로 반영했습니다. 이 측정 자체가 저희 실제 서버에서 나온 값이기도 합니다. AI 추론 서비스 Metis의 서버리스 엔드포인트는 앞으로 두 설정(엔진 설정으로는 TORCH_COMPILE_DISABLE=0max_num_seqs=256)을 처음부터 켜 두는 쪽으로 정책을 바꾸기로 했습니다. 에이전트가 자동으로 일을 처리하는 서비스일수록 결국 이 서버 위에서 돈을 쓰는 구조이므로, 방치된 설정이 조용히 태우는 처리량은 곧 자동화 비용으로 이어집니다.

이 문제는 저희만의 것이 아닙니다. 회사가 AI 서버 비용으로 얼마를 쓰는지는 어떤 모델을 골랐는지보다, 아무도 재 보지 않은 기본 설정 하나에 달려 있는 경우가 많습니다. 이 다섯 단계 점검은 새 그래픽카드를 사지 않고도, 셀프호스팅으로 AI를 서빙하는 누구나 자기 서버에 지금 바로 적용해 볼 수 있습니다. 지금까지의 서빙 성능 연구는 대부분 이미 잘 맞춰 놓은 서버를 기준으로 삼았는데, 이 논문은 반대로 방치된 기본 설정 자체가 얼마나 손해를 내는지를 직접 재서 분리해 낸 첫 사례이기도 합니다.

못 믿을 부분

이 실측에는 분명한 한계가 있습니다. 그래픽카드 한 세대(B200)와 서빙 프로그램 한 버전, 모델 하나로만 잰 값입니다. 여러 종류의 그래픽카드와 여러 모델에 걸쳐 확인한 결과가 아니라는 뜻입니다. 두 설정이 곱셈으로 합쳐지고 그중 하나가 문턱값처럼 작동하는 구조 자체는 다른 환경에서도 비슷할 것으로 보이지만, 아직 확인되지 않았습니다.

측정 자체의 한계도 있습니다. 문을 활짝 연 주방은 측정이 끝나는 순간까지도 여전히 오르는 중이었습니다. 그래서 17.9배와 1.79배라는 숫자는 최솟값이고, 실제로는 더 클 수 있습니다. 측정에 쓴 서버도 완전히 혼자 쓰는 환경은 아니었습니다. 같은 서버의 다른 그래픽카드에서 같은 모델이 실제 손님을 받고 있어서, 컴퓨터 자원과 전력을 일부 나눠 썼습니다. 이 때문에 불 미리 붙여 두기의 효과가 실제보다 조금 크게 나왔거나, 전체 속도가 실제보다 낮게 보였을 수 있습니다. 마지막으로, 불을 안 붙였을 때 요리 한 그릇마다 불 붙이는 시간이 병목이라는 설명은 이번에 잰 그 모델과 프로그램 조합에서 관찰된 것입니다. 다른 조합에서는 두 설정 중 어느 쪽이 더 중요한지 자체가 바뀔 수 있습니다.


논문 상세 페이지는 여기에서 볼 수 있습니다: The Default Configuration Tax

본문의 수치는 단일 B200 그래픽카드 한 대에서 실측한 값이며, 읽기 쉽게 반올림했습니다. 원 수치는 각 그림 캡션에 그대로 두었습니다.

태그: b200-gpu, 추론 비용, LLM 추론, max-num-seqs, serving-optimization, throughput, token-factory, torch-compile, vllm

카테고리:

업데이트: