Revolut은 같은 GPU 56장에서 설정만 바꿔 자체 호스팅 코딩 모델의 10초 넘던 첫 응답을 1.6초로 줄였습니다 | DAKER 커뮤니티

유럽 디지털 은행 Revolut의 AI 운영 책임자 David Abitbol은 AI Engineer 채널에 올라온 발표 「How Revolut Cut AI Coding Costs 90% With Self-Hosted Open Models」에서 엔지니어 약 2,000명이 쓰는 코딩 모델을 오픈소스 GLM으로 직접 띄운 과정을 공개했습니다. 가장 눈에 띄는 대목은 비용보다 튜닝입니다. GPU 56장을 그대로 둔 채 서빙 설정만 바꿔 첫 토큰이 나오기까지 10초가 넘던 지연을 약 1.6초로 줄였다고 말합니다. 오픈 모델을 직접 서빙하는 해커톤 팀이나 사내 프로젝트라면, GPU를 더 구하기 전에 첫 토큰 지연과 캐시 적중률부터 재 보는 것이 이 발표에서 바로 가져갈 수 있는 행동입니다.

발표 한 줄 요약: 같은 GPU에서 설정만 바꿔 88% 빨라졌습니다

발표에 따르면 Revolut은 2026년 4월 무렵 오픈소스 모델 자체 호스팅을 시작했습니다. 처음 서비스를 열었을 때 초당 요청 수는 약 3건이었고, 첫 토큰 지연(time to first token)은 10초를 넘었습니다. 8월에는 초당 요청이 7건을 넘었는데도 첫 토큰 지연은 약 1.6초까지 내려왔습니다. 발표자는 이 기간 동안 GPU 수를 늘리지 않았고 여전히 56장이었다고 강조합니다. 영상 설명란도 같은 하드웨어에서 88% 빨라진 튜닝을 핵심 장으로 소개합니다.

GPU를 구하고 가중치를 올린 뒤 바로 추론을 돌리면 성능은 형편없을 것입니다. 워크로드는 여러분이 정하는 파라미터에 크게 좌우되기 때문입니다.

— David Abitbol, Revolut (발표 내용을 우리말로 옮김)

요청은 두 배 넘게 늘었는데 지연은 6분의 1 수준 이하로 줄었다는 뜻입니다. 모델을 바꾸지도, 장비를 더 사지도 않았다는 점에서 오픈 모델을 직접 다루는 팀에게 가장 실무적인 숫자입니다.

왜 자체 호스팅을 시작했나: 토큰 예산이 사람을 멈춰 세웠습니다

발표는 2,000명 엔지니어의 지난 1년 지표로 시작합니다. 리드 타임은 엔지니어가 기능을 맡은 순간부터 병합되어 배포 준비가 끝날 때까지의 기간(일 단위)이고, 코딩 시간은 실제 코드를 쓰는 시간(시간 단위)입니다. 사내 데이터로 처음 Gemini를 쓰기 시작했을 때 리드 타임은 약 10%, 코딩 시간은 약 20% 줄었다고 합니다. 문서나 검색을 뒤지는 시간이 줄어든 효과로 설명합니다.

그다음 도입한 Claude Code는 기대만큼 지표를 움직이지 못했다고 말합니다. 이유로 든 것은 비용입니다. 엔지니어 한 명이 한 달에 1,000달러, 많게는 10,000달러를 쓰는 사례가 보였고, 그래서 엄격한 예산 한도를 걸고 배포했습니다. 예산이 빠듯하면 사람들은 토큰을 아껴 두었다가 어려운 작업에만 씁니다. Revolut이 다음으로 찾은 답은 엔지니어가 비용 걱정 없이 쓸 수 있을 만큼의 토큰을 훨씬 싸게 공급하는 방법, 즉 오픈 모델 자체 호스팅이었습니다.

GLM 5.1을 자체 호스팅으로 붙인 뒤 코딩 시간은 약 60%, 리드 타임은 약 70% 개선됐다고 합니다. 발표자가 여기서 끌어낸 결론이 흥미롭습니다. 코딩 시간보다 리드 타임이 더 크게 줄었으니, 개발의 병목은 코드 작성 자체가 아니라 메일함을 뒤지고 이슈 관리 도구를 정리하는 일 같은 주변 작업이었다는 것입니다. 토큰이 넉넉하면 이런 잡무에도 모델을 부담 없이 쓸 수 있습니다.

지금 Revolut에서는 오픈소스 모델이 기본이고, 최신 상용 프런티어 모델은 예외적으로 씁니다. 발표자는 상용 모델이 여전히 훌륭하다고 인정하면서도, 청구액이 정액에 가까워 월말에 예상 밖 청구서가 날아오지 않는다는 점을 장점으로 꼽습니다.

숫자로 본 운영 기준: 첫 토큰 3초, 초당 200토큰

발표에서 공개한 운영 수치는 다음과 같습니다. 모두 발표자가 말한 값이며 DAKER가 따로 검증한 값은 아닙니다.

• 엔지니어 약 2,000명을 GPU 56장으로 서빙하며, 올린 모델은 GLM 5.3입니다. 발표자는 이 모델을 약 8천억 파라미터 규모의 큰 모델이라고 소개합니다.
• 목표 첫 토큰 지연은 3초 미만입니다. 5초를 넘기면 사내 메신저로 불만이 쏟아진다는 경험칙을 근거로 듭니다.
• 상호작용 속도는 초당 약 200토큰이면 충분하다고 봅니다. 엔지니어들이 생각 토큰이 흘러가는 화면을 지켜보지 않고, 여러 작업을 병렬로 맡겨 둔 뒤 끝나면 확인하는 방식으로 일하기 때문입니다. 사용량이 줄어드는 오후 5시 이후에는 초당 약 800토큰까지 나온다고 덧붙입니다.
• 토큰 혼합 단가는 100만 토큰당 약 0.3달러이고, 전체 청구액은 이전에 Anthropic과 OpenAI에 내던 금액의 약 10분의 1이라고 말합니다.

이 목록에서 눈여겨볼 점은 처리량보다 첫 토큰 지연을 사용자 만족의 기준으로 삼았다는 것입니다. 코딩 에이전트처럼 사람이 기다리는 작업에서는 초당 토큰 수가 조금 낮아도 첫 응답이 빨라야 체감이 좋다는 판단입니다.

튜닝에서 본 파라미터 다섯 가지

발표자는 정해진 비법은 없다고 전제한 뒤, 직접 손본 항목을 차례로 짚습니다.

1. 컨텍스트 길이: 발표자는 긴 컨텍스트를 과장된 기대라고까지 표현합니다. 100만 토큰을 서빙할 수 있더라도 실제로 필요한 것은 256K 정도라는 것입니다. 최대 길이를 줄이면 그만큼 KV 캐시 메모리를 다른 요청에 쓸 수 있습니다.
2. 양자화: 블랙웰 세대 GPU라면 FP4보다 높은 정밀도로 돌릴 이유가 없고, FP4가 가장 낫다고 말합니다. FP8과 비교한 정확한 속도 차이는 발표에서 분명하게 확인되지 않아 여기서는 옮기지 않습니다.
3. 텐서 병렬 크기: GLM은 TP4 구성에도 올라가지만, 그러면 KV 캐시 여유가 부족해 워크로드에 따라 TP8이 더 나을 수 있다고 합니다. 모델이 올라가는 최소 구성이 곧 최적 구성은 아니라는 뜻입니다.
4. 캐시 적중률: 코딩 작업은 프롬프트 캐시 적중률이 90%를 넘어야 한다고 말합니다. 같은 저장소 맥락과 시스템 지침이 반복해서 들어가는 코딩 에이전트의 특성상, 이 수치가 낮으면 같은 앞부분을 매번 다시 계산하고 있다는 신호입니다.
5. 그 밖의 기법: 추측 디코딩(speculative decoding) 최적화, 프리필 처리 방식 조정, 프리필과 디코드를 분리하는 구성 등을 검토 대상으로 꼽습니다.

이 다섯 가지는 대부분 서빙 엔진 설정 파일에서 바로 바꿀 수 있는 값입니다. 발표자가 강조한 순서대로 보면, 먼저 필요 이상으로 긴 최대 컨텍스트를 줄이고, 정밀도와 병렬 구성을 GPU 세대에 맞춘 뒤, 캐시 적중률을 지표로 확인하는 흐름입니다.

운영 구성: 텍스트 모델과 라우터, 호환 API

GLM은 텍스트 전용 모델이라 이미지를 이해하지 못한다는 한계가 있습니다. 발표자는 매번 더 똑똑한 텍스트 모델을 고르고, 이미지 인식은 다른 방법으로 해결하는 쪽을 택한다고 말합니다. 로컬 라우터를 두고 이미지가 들어간 요청만 Gemini 같은 다른 모델로 보내고 본 작업은 GLM이 맡게 하는 방식입니다. 시각 기능이 꼭 필요하면 GLM 계열의 경량 비전 모델도 쓸 만하다고 덧붙입니다.

엔드포인트는 모두 OpenAI 호환 API로 열고 Responses API도 지원하게 해서, OpenCode나 Codex 앱 같은 기존 코딩 도구에 그대로 연결해 쓴다고 합니다. 모델을 바꿔도 엔지니어가 쓰는 도구는 바꾸지 않게 한 셈입니다.

규제 산업에서의 안전장치: 사람 승인, 샌드박스, 관측

발표 마지막은 최고정보책임자를 향한 이야기입니다. 중국에서 만든 오픈소스 모델을 쓰는 데 대한 거부감이 있지만, 중국으로 가는 추론 엔드포인트를 쓰는 것이 아니라 가중치만 받아 데이터 보호 기준이 동등하다고 인정된 지역의 서버에 올리는 것이므로 데이터 공유 측면에서는 문제가 없다는 설명입니다. 발표자는 미국, EU, 영국, 이스라엘을 예로 들고, GPU·추론 제공사는 기본적으로 데이터를 보관하지 않는 설정을 제공한다고 말합니다.

EU 규제를 받는 은행으로서 가장 중요하게 보는 것은 사람이 항상 개입한다는 점을 보장하는 일입니다. Revolut은 코딩 작업을 자율 에이전트가 아니라 사람이 승인하는 작업으로 운영하고, 이를 샌드박스로 보장한다고 합니다. 허용할 명령과 막을 명령을 규칙으로 정해 두는 방식입니다. 샌드박스는 내부의 악의적 사용을 막는 데에도 쓰이고, 프롬프트 인젝션에도 대비합니다. 마지막으로 사고가 났을 때 로그를 깊이 파고들 수 있도록 OpenTelemetry 기반의 관측 체계를 갖추라고 권합니다.

DAKER 참가자가 오늘 해 볼 일

Revolut의 규모는 대회 팀과 다르지만, 측정 순서는 그대로 가져올 수 있습니다. 해커톤이나 대회에서 오픈 모델을 직접 띄워 에이전트나 서비스를 만드는 팀이라면 다음 순서를 권합니다.

1. 지금 서빙 중인 모델에 같은 프롬프트를 여러 번 보내 첫 토큰 지연과 초당 토큰 수를 따로 기록합니다. 두 값을 하나의 응답 시간으로 뭉뚱그리지 않는 것이 출발점입니다.
2. 설정 파일의 최대 컨텍스트 길이가 실제 입력 길이보다 훨씬 크다면 줄여 보고, 같은 측정을 반복합니다.
3. 서빙 엔진이 보여 주는 프롬프트 캐시 적중률을 확인합니다. 시스템 프롬프트나 저장소 요약처럼 매번 같은 앞부분을 프롬프트 맨 앞에 고정해 두면 적중률을 높이는 데 도움이 됩니다.
4. 이미지 입력이 필요한 과제라면 하나의 멀티모달 모델로 모든 것을 처리하기보다, 이미지 요청만 다른 모델로 보내는 간단한 라우터를 두는 구성을 비교해 봅니다.

로컬 서버 튜닝을 에이전트에게 맡겨 본 실험이 궁금하다면 DAKER 잡담에 올라온 Qwen에게 자기 llama.cpp 서버를 튜닝하게 한 실험 정리도 함께 보시면 좋습니다. 규모는 작지만 같은 GPU에서 설정만으로 속도를 끌어올린다는 문제의식이 닮아 있습니다. 진행 중인 대회와 해커톤은 DAKER와 DACON 대회 목록에서 확인하실 수 있습니다.

발표가 말하지 않은 것

발표는 약 12분 분량이라 세부 설정값을 모두 공개하지는 않았습니다. 어떤 서빙 엔진을 썼는지, 88% 개선에 각 파라미터가 얼마씩 기여했는지, 개선 전후의 모델 품질을 어떻게 비교했는지는 나오지 않습니다. 생산성 수치도 Revolut 내부 지표이고, 같은 기간에 모델 버전과 도구가 함께 바뀌었으므로 자체 호스팅만의 효과로 떼어 보기는 어렵습니다. 비용이 10분의 1이 됐다는 비교 역시 GPU 구매·임대 방식이나 운영 인력 비용이 어떻게 반영됐는지 설명되지 않았습니다. 그래서 이 발표는 따라 할 정답이라기보다, 무엇을 먼저 재야 하는지 알려 주는 측정 목록으로 읽는 편이 정확합니다.

출처: AI Engineer 채널 「How Revolut Cut AI Coding Costs 90% With Self-Hosted Open Models - David Abitbol, Revolut」(2026년 10월 29일 공개). 본문의 인용은 발표 음성을 우리말로 옮긴 것이며, 수치는 모두 발표자가 말한 값입니다.