가속 서빙은 정말 아름다운 기술일까? 직접 API를 호출해 보고 알게 된 것들
같은 모델을 훨씬 빠르게 실행할 수 있다면
AI 모델을 개발하거나 서비스를 운영하다 보면 결국 성능 문제에 부딪힌다. 모델이 아무리 뛰어나도 응답을 받기까지 수십 초씩 기다려야 한다면 사용자 경험은 나빠질 수밖에 없다. 특히 실시간 대화, 음성 인식, 의료 현장처럼 응답 지연이 서비스의 실용성을 좌우하는 분야에서는 속도가 단순한 성능 지표를 넘어 제품의 경쟁력 자체가 된다.
그래서 추론 가속(inference acceleration)이라는 분야에 관심을 갖게 됐다.
내가 흥미를 느낀 지점은 단순히 더 빠른 하드웨어를 사용하거나 모델을 작게 만드는 방법이 아니었다. 기존 모델의 능력을 최대한 유지하면서, 같은 추론 작업을 훨씬 빠르게 처리할 수 있다면 어떨까?
모델의 크기를 줄이거나 파라미터 수가 적은 모델로 교체하면 속도를 높일 수 있다. 하지만 그것은 엄밀히 말해 동일한 모델을 가속한 것과는 다르다. 모델 자체가 바뀌면 성능 특성도 달라질 수 있기 때문이다.
내가 기대하는 것은 조금 다른 방향이다. 모델의 지능을 포기하지 않고도 실행 효율을 획기적으로 높이는 기술이다.
이것이 가능하다면 AI 서비스를 설계하는 방식 자체가 달라질 수 있다. 지금까지는 높은 품질을 원하면 느린 응답을 감수하거나, 빠른 응답을 원하면 더 작은 모델을 선택해야 하는 경우가 많았다. 그런데 품질을 유지하면서 속도를 높일 수 있다면 이 두 가지 선택지 사이의 타협을 줄일 수 있다.
나는 이 가능성이 상당히 매력적이라고 생각했다.
물론 기술적으로 가능하다는 것과 실제 서비스에서 일관되게 구현된다는 것은 별개의 문제다. 그래서 직접 API를 호출해 보기로 했다.
문서보다 먼저 확인하고 싶었던 것
온라인에서 기술 소개나 벤치마크를 찾아보면 인상적인 숫자를 쉽게 만날 수 있다. 기존 대비 몇 배 빠르다거나, 처리량이 크게 증가했다는 식의 설명이다. 하지만 실제 서비스를 만드는 입장에서는 그런 숫자만으로 판단하기 어렵다.
벤치마크 환경에서 높은 처리량을 달성하는 것과 내가 호출하는 API가 매번 빠르게 응답하는 것은 다른 문제이기 때문이다.
가령 초당 수천 개의 토큰을 처리할 수 있는 인프라가 있다고 해도, 내 요청이 처리되기 위해 대기해야 한다면 실제 체감 속도는 느릴 수 있다. 반대로 전체 처리량은 평범해도 요청 하나에 대한 첫 응답이 빠르고 일정하다면 실시간 서비스에는 더 적합할 수 있다.
결국 내가 알고 싶은 것은 명확했다.
- 실제 API를 호출했을 때 첫 응답은 얼마나 빨리 도착하는가?
- 같은 조건으로 반복 호출하면 응답 시간이 얼마나 일정한가?
- 짧은 요청과 긴 요청에서 성능은 어떻게 달라지는가?
- 추론 관련 설정이 실제 응답에 반영되는가?
- 그리고 무엇보다, 속도가 빨라졌을 때 모델의 품질은 유지되는가?
마지막 질문이 가장 중요하다. 다만 이번 실험에서는 마지막 항목까지 검증하지 않았다. 우선 API의 응답 시간과 설정 동작부터 확인했다.
이번 테스트는 특정 회사의 기술 전체를 평가하기 위한 종합 벤치마크가 아니다. 실제 서비스에서 API를 사용할 때 마주칠 수 있는 현상을 직접 확인한 제한적인 실험이다.
OpenGateway(OGW)를 직접 호출하다
이번에 테스트한 대상은 한국 기업 Sionic AI가 제공하는 OpenGateway(OGW) API다. 호출한 모델은 deepseek/deepseek-v4.1-flash-ultrafast였고, 트래픽 클래스는 PAID_STANDARD로 설정된 요청을 사용했다.
API 키가 본문이나 로그에 노출되지 않도록 주의하면서 응답 시간을 측정했다. 여기서 중점적으로 기록한 값은 TTFB(Time to First Byte), 전체 응답 시간, 그리고 응답 헤더에 포함된 x-envoy-upstream-service-time이다.
TTFB는 요청을 보낸 뒤 첫 바이트를 받기까지 걸린 시간이다. 스트리밍 응답에서는 첫 토큰이 사용자에게 도착하기까지의 시간을 가늠하는 데 도움이 된다. 전체 응답 시간은 요청을 보낸 시점부터 응답이 완전히 끝날 때까지 걸린 시간이다.
두 값은 비슷해 보이지만 의미가 다르다.
예를 들어 첫 토큰이 0.4초 만에 도착해도 나머지 응답을 생성하는 데 20초가 걸린다면, 사용자는 일찍 결과를 보기 시작하지만 작업이 끝날 때까지는 오래 기다려야 한다. 반대로 첫 응답이 늦게 도착하더라도 이후 토큰이 빠르게 생성되면 전체 응답 시간은 상대적으로 짧을 수 있다.
따라서 단일한 ’속도’라는 숫자만으로 API를 평가하기는 어렵다.
짧은 요청에서 나타난 큰 편차
먼저 추론을 끈 상태에서 Hello라는 짧은 요청을 스트리밍 방식으로 다섯 번 호출했다.
| 실행 | TTFB | 전체 응답 시간 |
|---|---|---|
| 1 | 2.585초 | 3.541초 |
| 2 | 5.924초 | 6.935초 |
| 3 | 7.181초 | 7.200초 |
| 4 | 0.421초 | 0.475초 |
| 5 | 0.300초 | 0.354초 |
가장 빨랐던 실행에서는 첫 응답이 약 0.3초 만에 도착했다. 반면 다른 실행에서는 첫 응답까지 7초 이상이 걸렸다.
전체 응답 시간 기준으로도 가장 빠른 실행은 0.354초, 가장 느린 실행은 7.2초였다. 약 20배의 차이다.
짧은 요청이기 때문에 출력 토큰을 생성하는 데 걸리는 시간은 상대적으로 작다. 그럼에도 전체 시간이 이렇게 크게 달라졌다면, 적어도 이번 측정에서는 모델이 토큰을 생성하는 속도만으로 응답 시간을 설명하기 어렵다.
요청 대기, 라우팅, 서버 측 처리, 동시 부하, 추론 서버의 상태 등 여러 요소가 영향을 미쳤을 가능성이 있다. 다만 이번 실험만으로 어느 요소가 주원인이었는지 특정할 수는 없다.
이 지점에서 구분해야 할 것이 있다. 빠른 응답이 한 번 나왔다는 사실은 그 API가 빠른 응답을 낼 수 있다는 증거이지만, 항상 빠르다는 증거는 아니다.
실제 서비스에서는 최고 속도만큼이나 응답 시간의 분포가 중요하다. 평균이 낮더라도 일부 요청이 지나치게 늦어지면 사용자는 그 지연을 경험하게 된다. 특히 음성 대화나 실시간 인터페이스에서는 최악의 몇몇 요청이 서비스 전체의 인상을 좌우할 수 있다.
서버 측 처리 시간도 일정하지 않았다
응답 헤더의 x-envoy-upstream-service-time 값도 별도로 확인했다.
| 실행 | Upstream service time |
|---|---|
| 1 | 6110ms |
| 2 | 4616ms |
| 3 | 932ms |
| 4 | 509ms |
| 5 | 341ms |
이 값은 약 341ms에서 6110ms까지 달라졌다. 적어도 이 헤더가 보여 주는 서버 측 처리 구간 역시 실행마다 큰 편차가 있었다.
물론 이 헤더 하나만으로 서버 내부에서 정확히 어떤 일이 벌어졌는지 알 수는 없다. 요청이 대기한 시간과 실제 모델 추론 시간이 어떻게 나뉘는지, 서로 다른 실행이 같은 서버나 같은 하드웨어에서 처리됐는지도 이 데이터만으로는 확인할 수 없다.
그럼에도 관찰 자체는 의미가 있다. 클라이언트와 네트워크만의 문제라고 단정할 수 없으며, 응답 헤더에 기록된 upstream 구간에서도 큰 차이가 나타났기 때문이다.
’ultrafast’라는 모델 이름만 보고 일관된 초고속 응답을 기대하기는 어려웠다.
긴 요청에서는 더 극단적인 차이가 나타났다
짧은 요청만으로는 생성 속도를 제대로 평가하기 어렵다. 그래서 약 150단어 분량의 에세이를 요청하는 긴 프롬프트도 테스트했다. 이때도 스트리밍을 사용하고 추론을 끈 상태였다.
| 실행 | TTFB | 전체 응답 시간 | 출력 길이 |
|---|---|---|---|
| 1 | 1.092초 | 4.327초 | 746자 |
| 2 | 0.370초 | 7.660초 | 874자 |
| 3 | 5.664초 | 79.954초 | 833자 |
첫 번째 실행은 약 4.3초 만에 끝났다. 두 번째는 첫 응답이 0.37초 만에 도착했지만 전체 응답에는 7.66초가 걸렸다. 세 번째 실행에서는 첫 응답까지 약 5.7초가 걸렸고, 전체 완료 시간은 약 80초에 달했다.
출력 길이가 746~874자로 비슷하다는 점을 생각하면 상당히 큰 편차다.
이 데이터만으로 원인을 단정할 수는 없다. 서버 부하, 큐 대기, 생성 중 지연, 일시적인 인프라 문제 등 여러 설명이 가능하다. 세 번의 실행만으로 일반적인 성능을 대표한다고 주장할 수도 없다.
하지만 실제 API 사용자의 관점에서 중요한 사실은 남는다. 같은 엔드포인트에 유사한 길이의 요청을 보냈을 때 응답 완료 시간이 크게 달라질 수 있었다는 점이다.
참고로 문자 수를 약 4로 나누어 토큰 수를 거칠게 추정하면 이번 긴 응답의 생성 속도는 대략 초당 2.6~43토큰 수준으로 계산된다. 다만 이는 실제 토크나이저로 토큰 수를 측정한 결과가 아니다. 언어와 문장 구성에 따라 문자 수와 토큰 수의 관계가 달라지고, 전체 응답 시간에는 생성 외의 시간도 포함될 수 있으므로 정확한 TPS 측정값으로 받아들여서는 안 된다.
정확한 생성 속도를 비교하려면 실제 출력 토큰 수를 기록하고, 첫 토큰까지 걸린 시간과 생성 구간의 시간을 분리해야 한다. 서버가 제공하는 처리량 지표가 있다면 그것도 별도로 확인할 필요가 있다.
이번 결과가 보여 주는 것은 엄밀한 의미의 모델 생성 속도라기보다, 해당 API를 사용했을 때 관찰된 전체 응답 경험이다.
추론을 끄면 실제로 달라질까?
응답 시간이 크게 달라지는 것만큼 흥미로웠던 부분은 추론 관련 설정이었다.
일부 모델은 최종 답변을 만들기 전에 별도의 추론 과정을 수행한다. 이런 과정은 복잡한 문제를 해결하는 데 도움이 될 수 있지만, 작업과 설정에 따라 추가적인 토큰과 시간이 필요할 수 있다.
따라서 단순한 인사말이나 짧은 응답처럼 깊은 추론이 필요하지 않은 작업이라면 추론을 비활성화하는 것이 합리적인 선택일 수 있다.
이번 테스트에서는 다음 설정을 비교했다.
reasoning_effort: "none"thinking: { "type": "disabled" }enable_thinking: false
관찰 결과, reasoning_effort: "none"을 지정한 요청에서는 reasoning_content가 0자였고, thinking: { "type": "disabled" }를 사용한 요청에서도 추론 내용이 나타나지 않았다. 반면 enable_thinking: false를 지정했을 때는 추론 내용이 계속 생성됐다.
적어도 이번 엔드포인트와 모델 조합에서는 설정 이름이 비슷하다고 해서 모두 동일하게 작동하지는 않았다.
여기서 주의할 점은 추론 내용이 응답에 나타나지 않는 것과 내부적으로 모든 추론 계산이 사라졌다는 것이 반드시 같은 의미는 아니라는 사실이다. 이번 테스트에서 확인한 것은 응답에 포함된 추론 내용과 설정의 동작이다. 내부 계산량이나 GPU 사용량까지 직접 측정한 것은 아니다.
또한 API 제공자마다 파라미터 지원 방식이 다를 수 있다. 모델이 지원하는 설정과 게이트웨이가 실제로 전달하는 설정, 그리고 최종 응답에 반영되는 동작이 모두 일치한다고 가정해서는 안 된다.
이런 차이는 실제 서비스에서는 생각보다 중요하다. 문서에 없는 설정을 무작정 시도하거나, 의미가 비슷해 보이는 파라미터를 사용하면 원하는 동작이 적용되지 않을 수 있다.
결국 설정의 이름보다 실제 응답을 확인해야 한다. 추론을 끄는 것이 목표라면 추론 관련 필드가 사라지는지, 응답 시간이 달라지는지, 그리고 필요한 작업에서 결과 품질이 어떻게 변하는지까지 확인하는 편이 낫다.
다만 이번 실험은 추론을 켠 상태와 끈 상태의 품질을 비교하지 않았다. 따라서 추론을 끄는 것이 항상 더 좋다거나, 품질에 영향을 주지 않는다고 결론 내릴 수는 없다.
스트리밍은 모델을 더 빠르게 만들까?
이번 실험에서 스트리밍의 의미도 다시 생각하게 됐다.
스트리밍은 모델의 계산 자체를 반드시 빠르게 만드는 기술은 아니다. 핵심은 생성된 결과를 한꺼번에 전달하지 않고, 준비되는 대로 나눠서 전달한다는 데 있다.
비스트리밍 방식에서는 일반적으로 응답이 완성될 때까지 클라이언트가 결과를 받지 못한다. 반면 스트리밍 방식에서는 첫 토큰이 준비되면 나머지 생성이 진행되는 동안에도 결과를 보여 줄 수 있다.
이 차이는 사용자 경험에 직접적인 영향을 준다.
예를 들어 전체 생성 시간이 8초인 작업이라도 첫 토큰이 0.4초 만에 도착한다면 사용자는 빠르게 반응이 시작됐다고 느낄 수 있다. 반대로 첫 응답까지 8초를 기다린 뒤 결과가 한꺼번에 나타난다면 같은 총 소요 시간이라도 훨씬 답답하게 느껴질 수 있다.
하지만 스트리밍을 사용했다고 해서 총 생성 시간이 줄었다고 단정해서는 안 된다. 이번 실험에서도 첫 응답이 빨리 도착한 요청이 반드시 가장 빨리 완료된 것은 아니었다.
따라서 API 성능을 평가할 때는 최소한 다음 세 가지를 분리해 봐야 한다.
- TTFB: 사용자가 처음 결과를 보기까지 걸리는 시간
- 생성 속도: 첫 토큰 이후 출력이 얼마나 빠르게 이어지는지
- 전체 완료 시간: 요청을 시작한 뒤 결과가 완성될 때까지 걸리는 시간
이 세 지표는 서로 연관되어 있지만 같은 것은 아니다. 스트리밍은 첫 응답을 빨리 보여 주는 데 유리하지만, 생성이 멈추거나 서버가 긴 지연을 보이는 문제까지 해결해 주지는 않는다.
실제 서비스에서는 스트리밍을 기본으로 적용하되, 장시간 응답이 이어질 때의 처리 방식도 설계해야 한다. 타임아웃, 취소 처리, 재시도, 대체 엔드포인트로의 전환 같은 전략이 필요할 수 있다.
특히 재시도는 무조건 적용할 기능이 아니다. 응답 생성 중 연결이 끊겼을 때 전체 요청을 다시 보내면 비용이 중복되거나, 이미 일부 결과를 받은 사용자에게 중복 응답이 발생할 수 있다. 요청의 성격과 API의 재시도 정책에 맞춰 구현해야 한다.
그렇다면 가속 서빙 기술 자체가 기대에 못 미친 것일까?
여기서 한 가지 구분이 필요하다.
이번 테스트에서 관찰한 것은 특정 API 엔드포인트의 응답 시간과 설정 동작이다. 이 결과만으로 추론 가속 기술 자체가 효과가 없다고 결론 내릴 수는 없다.
API의 실제 성능은 여러 계층의 영향을 받는다. 모델 아키텍처와 추론 엔진뿐 아니라 하드웨어, 배치 처리 방식, 요청 큐, 라우팅, 네트워크, 동시 접속자 수, 제공자의 운영 정책까지 영향을 줄 수 있다.
어떤 제공자가 훌륭한 가속 기술을 사용하더라도 서빙 계층의 대기 시간이 길면 사용자가 체감하는 속도는 낮아질 수 있다. 반대로 가속 기술의 차이가 크지 않더라도 효율적인 인프라 운영으로 좋은 응답 경험을 제공할 수도 있다.
그러므로 이번 결과를 특정 알고리즘의 성능 문제로 해석하는 것은 적절하지 않다. 이번 테스트에서 확인한 것은 해당 엔드포인트를 통해 얻은 실제 응답이 기대만큼 일관되지 않았다는 사실이다.
이 글은 OpenGateway를 비판하기 위해 쓴 것이 아니다. 한국 기업 Sionic AI가 이런 AI 추론 서빙 서비스를 만들고 있다는 점이 기쁘고 자랑스럽다. 이번 측정 결과를 기록한 이유는 서비스가 더 빠르고 안정적으로 발전하길 바라는 기대 때문이다.
그렇다고 이 차이를 무시할 수도 없다. 사용자는 추론 엔진의 내부 구조를 직접 경험하는 것이 아니라 API를 통해 서비스를 사용한다. 실제 제품을 만드는 입장에서는 알고리즘의 잠재력과 별개로, 서비스의 응답 시간이 얼마나 안정적인지가 중요하다.
나는 기술의 가능성과 서비스의 완성도를 별도로 평가해야 한다고 생각한다.
’같은 품질, 더 빠른 속도’를 어떻게 검증할까?
추론 가속을 평가할 때 가장 어려운 질문은 속도가 얼마나 빨라졌느냐가 아니라, 그 속도를 얻기 위해 무엇을 바꿨느냐일 수 있다.
예를 들어 양자화는 모델의 가중치 표현을 더 낮은 정밀도로 바꿔 메모리 사용량과 계산 비용을 줄일 수 있다. 하지만 양자화 방식과 모델, 작업에 따라 결과에 차이가 생길 가능성이 있다.
반면 적절하게 구현된 speculative decoding은 작은 초안 모델 등이 제안한 토큰을 대상 모델이 검증하는 방식으로 생성 과정을 가속할 수 있다. 특정 조건을 충족하는 알고리즘은 대상 모델의 출력 확률 분포를 보존하면서 생성 속도를 높일 수 있다. 다만 이것이 모든 가속 방식에 자동으로 적용되는 성질은 아니다.
여기서 ’동일한 품질’이라는 표현도 구체적으로 정의할 필요가 있다.
두 번의 모델 호출에서 문장 하나하나가 완전히 같아야 한다는 뜻인지, 동일한 출력 분포를 유지한다는 뜻인지, 아니면 실질적인 과제 수행 능력이 통계적으로 동등하다는 뜻인지에 따라 검증 방법이 달라진다.
같은 모델이라도 샘플링 설정과 난수 상태가 다르면 출력 문장이 달라질 수 있다. 따라서 출력이 다르다는 사실만으로 품질 저하를 주장할 수는 없다. 반대로 문장이 비슷하다는 이유만으로 품질이 보존됐다고 단정할 수도 없다.
실제로 품질을 비교하려면 동일한 프롬프트 집합을 사용하고, 비교 대상의 모델 버전과 설정을 최대한 맞춰야 한다. 정답이 있는 작업이라면 정확도나 과제별 성공률을 측정하고, 개방형 생성 작업이라면 평가 기준과 블라인드 평가 방법을 사전에 정해야 한다.
속도 역시 평균만으로 비교하기보다는 충분한 횟수의 반복 측정을 통해 중앙값과 상위 지연 시간, 즉 P95나 P99를 살펴보는 편이 유용하다. 짧은 요청과 긴 요청, 부하가 낮은 상황과 높은 상황을 나눠 테스트하면 어느 조건에서 성능 차이가 생기는지도 더 잘 알 수 있다.
물론 모든 평가를 한 번에 할 필요는 없다. 먼저 실제 서비스에 중요한 요청 유형을 선정하고, 그 조건에서 기준 모델과 가속 모델을 비교하는 것부터 시작할 수 있다.
내가 궁극적으로 확인하고 싶은 것도 바로 이것이다. 속도가 빨라졌다는 사실이 아니라, 품질을 유지한 채 얼마나 빠르고 안정적으로 실행할 수 있는가.
다음에는 다른 제공자도 테스트해 볼 생각이다
이번 실험만 놓고 보면 결과는 기대에 미치지 못했다.
가장 빠른 실행에서는 짧은 응답이 0.35초 정도 만에 끝났지만, 비슷한 요청에서 전체 응답 시간이 7초를 넘기도 했다. 긴 요청에서는 약 80초가 걸린 사례도 있었다. 추론 관련 설정 역시 파라미터마다 동작이 달랐다.
물론 실행 횟수가 많지 않고, 서버 부하나 내부 처리 상태를 통제하지 못했기 때문에 이 결과를 일반화할 수는 없다. 특정 시간대의 일시적인 현상이었을 수도 있고, 내가 테스트한 구성에 한정된 문제일 수도 있다.
그래서 이 실험은 결론이라기보다 출발점에 가깝다.
다른 제공자의 API도 비슷한 조건으로 테스트해 볼 생각이다. 가능하다면 같은 모델 또는 비교 가능한 기준 모델을 사용하고, 짧은 요청과 긴 요청을 반복해서 보내며 TTFB, 전체 응답 시간, 출력 토큰 수, 지연 시간의 분포를 기록할 것이다. 이후에는 품질 비교까지 포함해 가속의 실질적인 이득을 검증하고 싶다.
그 과정을 거쳐야만 특정 엔드포인트의 운영상 문제와 가속 기술 자체의 한계를 구분할 수 있을 것이다.
그래도 내가 이 기술에 기대를 거는 이유
이번 결과가 아쉬웠다고 해서 추론 가속이라는 방향 자체에 대한 기대가 사라진 것은 아니다.
오히려 기술의 잠재력과 실제 서비스 사이에 어떤 간극이 있는지 확인하는 것이 더 중요하다는 생각이 들었다. 논문이나 데모에서 가능성을 보여 주는 기술이 실제 API에서도 일관된 성능을 제공하는지는 별도로 검증해야 한다. 그 간극을 줄이는 일이 결국 기술을 제품으로 만드는 과정일 것이다.
모델의 능력을 낮추지 않으면서 계산을 더 효율적으로 수행하고, 불필요한 연산과 대기 시간을 줄여, 더 많은 사람이 더 빠르게 AI를 사용할 수 있게 한다면 그것은 상당히 아름다운 기술이라고 생각한다.
모델의 크기만 키우는 경쟁도 중요하겠지만, 이미 만들어진 모델을 얼마나 효율적으로 활용할 수 있는지도 그에 못지않게 중요하다. 같은 하드웨어와 모델로 더 빠른 응답을 제공할 수 있다면 비용, 전력, 사용자 경험, 서비스 확장성에 모두 영향을 줄 수 있기 때문이다.
다만 아직 내게는 검증해야 할 질문이 남아 있다.
정말 같은 모델의 품질을 유지하면서 속도를 획기적으로 높일 수 있는가? 그리고 그 성능은 실제 API에서도 안정적으로 재현되는가?
이번에 테스트한 OpenGateway(OGW)에서는 기대했던 만큼 일관된 속도를 확인하지 못했다. 하지만 이것만으로 기술 자체를 평가하기에는 이르다. 다른 제공자도 테스트하고, 품질까지 비교해 본 뒤에야 더 확실한 판단을 내릴 수 있을 것이다.
나는 여전히 이 기술이 흥미롭다. 그리고 기대가 큰 만큼, 홍보 문구나 최고 기록보다 직접 측정한 데이터로 확인하고 싶다.
결국 내가 찾는 것은 단순히 빠른 API가 아니다. 모델의 능력을 희생하지 않으면서, 실제 서비스에서 믿고 사용할 수 있을 만큼 빠르고 안정적인 추론 기술이다.
그런 기술을 찾을 수 있을지, 다음 테스트가 기대된다.