프로덕션에서 오픈 모델을 빠르게 만드는 방법 — Nebius의 Sujee Maniyam

URL: https://www.youtube.com/watch?v=TRe1u7dHYiA 날짜: 2026-10-04 채널: aiDotEngineer

📌 핵심 질문 / 오픈 모델을 프로덕션에서 빠르고 싸고 안정적으로 운영하려면 무엇이 필요한가

==오픈 모델의 지능만 고르는 것으로는 충분하지 않으며, 실리콘부터 모델 엔진·라우팅·캐시·튜닝·배포까지 통제하는 수직 통합형 추론 플랫폼이 성능·비용·행동을 함께 최적화한다.==

• 폐쇄형 API는 시작하기 쉽지만 모델과 인프라를 조정할 수 없고 비용이 사용량과 함께 직선적으로 증가한다.
• 셀프 호스팅은 통제력을 주지만 전담 엔지니어링 팀이 필요하고 제품 개발 전에 인프라 구축으로 수개월이 소요될 수 있다.
• 캐시 인식 라우팅, speculative decoding, KV cache, prefill/decode 분리, 적정 quantization을 조합하면 같은 오픈 모델도 제공자별로 전혀 다른 지연시간·처리량·비용을 낼 수 있다.

Nebius Token Factory는 모델 추론, 프로덕션 로그 분석, post-training, 배포를 하나의 지속적 개선 루프로 연결한다. 고객은 모델이 어느 칩과 어떤 quantization으로 실행되는지 통제하면서도 데이터센터·GPU·서빙 엔진을 직접 운영하지 않고, 제품에 집중할 수 있다.

1. Nebius와 Token Factory가 겨냥하는 문제

오픈 모델의 프로덕션 가치는 모델 자체뿐 아니라 모델을 실제 서비스로 만드는 전체 스택을 얼마나 세밀하게 조정하느냐에서 결정된다.

1.1. Nebius의 사업과 수직 통합

1. Nebius의 위치

   1. AI 풀스택 클라우드: Nebius는 모델 API만 노출하지 않고 실제 물리적 AI 계층과 인프라를 운영한다. 자체 데이터센터, NVIDIA 시스템, bare-metal 용량, 관리형 클라우드, 추론·서빙 최적화를 함께 다룬다.
   2. Token Factory의 역할: Token Factory는 관리형 추론(managed inference) 회사로서 고객 모델을 배포하고 고객의 사용 사례에 맞게 최적화한다.

2. 규모와 신뢰의 기반

   1. 기업 정보: Nebius는 암스테르담에 본사를 둔 NASDAQ 상장사다.
   2. NVIDIA와의 관계: NVIDIA가 몇 달 전 Nebius에 20억 달러를 투자했으며, Nebius는 2030년 말까지 NVIDIA 시스템 5GW를 확보하는 것을 목표로 한다.
   3. 대형 고객 신호: Microsoft·Meta와 강한 계약 및 협력 관계를 맺고 있으며, 대형 AI 빌더들이 이미 Nebius에서 이런 종류의 용량을 구축하고 있음을 보여준다.

3. 스택을 직접 통제하는 방식

   1. 자체 데이터센터: EU와 미국 전역의 데이터센터를 직접 운영한다.
   2. bare metal: 여러 고객이 공유하는 추상화된 클라우드가 아니라 bare-metal 기반으로 운용한다.
   3. 최신 하드웨어 선점: NVIDIA Rubin을 매우 이른 시기에 도입했고 BlueField storage도 사용한다. 유럽 클라우드 중 최초 그룹에 속해 Blackwell Ultra AGX P300과 GB300을 프로덕션에서 운용했다.
   4. 핵심 차별점: 실리콘에서 서빙까지 이어지는 수직 통합(vertical integration)이 이 발표의 중심 연결고리다.

1.2. 폐쇄형 API와 셀프 호스팅 사이의 세 번째 선택지

1. 폐쇄형 API의 장점과 한계

   1. 빠른 시작: API를 호출하기만 하면 되므로 도입은 쉽다.
   2. 조정 불가능성: 특정 사용 사례에 맞게 모델을 튜닝하기 어렵고, 모델과 인프라가 블랙박스로 남는다.
   3. 공유 자원과 비용: 다른 사용자와 인프라를 공유하며, 비용이 사용량에 따라 직선적으로 커지고 내부 최적화 여지가 작다.

2. 셀프 호스팅의 장점과 부담

   1. 완전한 통제: 모델을 직접 선택·수정·운영할 수 있다.
   2. 대규모 엔지니어링 프로젝트: 계속 운영할 전담 팀이 필요하다.
   3. 제품 출시 지연: 실제 제품을 시작하기도 전에 인프라를 프로덕션에 올리는 데 수개월이 걸릴 수 있다.

3. Token Factory가 제시하는 세 번째 경로

   1. 두 선택지의 결합: 셀프 호스팅의 제어력·성능과 관리형 추론 서비스의 단순성을 결합한다.
   2. 역할 분리: Nebius가 어려운 인프라 작업을 맡고 고객은 제품에 집중한다.
   3. 세 가지 해방: 고객이 모델의 성능(performance), 비용(cost), 행동(behavior)을 직접 조절할 수 있다.
   4. 시장 배경: proprietary model과 open model의 지능 격차가 빠르게 줄어들어, 오픈 모델을 프로덕션에서 제대로 운용하는 능력이 중요한 경쟁력이 됐다.

2. 모델 추론을 실제 프로덕션 시스템으로 바꾸는 전체 루프

추론을 한 번 성공시키는 것과 관찰·개선·재배포가 반복되는 AI 제품을 운영하는 것은 서로 다른 문제다.

2.1. Token Factory의 네 계층

1. Inference 계층

   1. 모델 선택: GLM, Kimi, DeepSeek 등을 포함해 60개가 넘는 모델을 제공한다.
   2. 운영 방식: 실시간 inference와 batch inference를 지원하고, 필요하면 dedicated endpoint를 제공한다.
   3. 모델 변형: 빠른 실행을 원하는지 등 요구에 따라 모델의 여러 flavor를 선택할 수 있다.
   4. 애플리케이션 기능: structured output, function calling, batch API를 제공한다.

2. Data Lab 계층

   1. 프로덕션 신호 수집: 고객이 프로덕션에서 얻은 completion과 inference 로그를 가져올 수 있다.
   2. 분석과 정제: SQL 데이터 작업, 데이터셋 필터링, 데이터셋 버전 관리를 지원한다.
   3. 재사용: 정제한 데이터를 export하고 batching할 수 있다.

3. Post-training 계층

   1. 모델 적응: 로그에서 synthetic dataset을 만들어 모델을 특정 행동에 맞게 fine-tune, distill, optimize한다.
   2. 튜닝 방법: LoRA 또는 full fine-tuning을 사용한다.
   3. 고급 최적화: 고객 요구에 맞춘 custom speculative decoding 도구를 제공한다.
   4. 수치 최적화: 필요에 따라 on-demand quantization과 calibration을 수행한다.

4. Deployment 계층

   1. 프로덕션 반영: 학습·튜닝한 모델을 Nebius가 소유한 인프라에 배포한다.
   2. 실행 투명성: 고객은 모델이 어디서 실행되는지, 어떤 칩을 쓰는지, 어떤 quantization 수준인지 확인하고 통제할 수 있다.

2.2. 여러 도구를 잇는 대신 하나의 지속적 개선 루프를 만든다

1. 기존 방식의 마찰

   1. 도구 조합: 대부분의 팀은 inference, training, data tooling을 각각 다른 도구로 연결해야 한다.
   2. 반복 속도 저하: 도구 사이의 연결과 배포 과정이 iteration을 어렵게 하고 제품 개선 속도를 늦춘다.

2. Token Factory의 데이터 흐름

   1. 순환 구조: inference에서 데이터를 수집하고, training으로 보내고, training 결과를 다시 production으로 배포한다.
   2. 매 주기의 개선: 반복할 때마다 AI가 더 구체적인 사용 사례에 맞고, 더 빠르고, 더 저렴해진다.
   3. 핵심 구분: "모델을 실행하는 것"과 "실제 프로덕션 AI 시스템을 실행하는 것"의 차이는 이 지속적인 loop에 있다.

2.3. 고객이 직접 처리하지 않아도 되는 세 가지 운영 층

1. Optimization

   1. 엔진 수준 조정: latency, throughput, cost를 실제 모델 엔진 수준에서 적극적으로 튜닝한다.
   2. 동일 모델의 차이: 같은 오픈 모델도 어떤 provider에서 실행하느냐에 따라 비용과 성능이 완전히 달라질 수 있다.

2. Infrastructure

   1. 하드웨어 운영: Nebius가 하드웨어를 소유하고 계속 가동한다.
   2. 행동 제어: 수직 통합된 스택을 직접 다루기 때문에 고객에게 모델 행동에 대한 제어력을 주고 인프라 관리는 맡는다.

3. Enterprise readiness

   1. 보안 요구: 오픈 모델을 실행하려면 보안 환경에서 동작하도록 보장해야 한다.
   2. 기업 필수 조건: security, compliance, reliability는 대기업이 프로덕션에 출시하기 전에 요구하는 기본 조건이다.
   3. 운영 부담의 이전: 다른 AI provider는 이 조건들을 고객이 직접 해결하게 만들지만, Token Factory는 이를 대신 처리하는 것을 목표로 한다.

3. 오픈 모델의 성능을 결정하는 하드웨어·서빙·모델 최적화

Sujee Maniyam은 좋은 inference가 좋은 모델에서 시작하지만, 최상의 성능에는 그 뒤의 인프라가 반드시 필요하다고 강조한다.

3.1. 오픈 모델의 경쟁력과 모델 선택권

1. 지능 격차의 축소

   1. Artificial Analysis 벤치마크: 검은색 막대는 proprietary model, 파란색 막대는 open model을 나타낸다.
   2. 경쟁력: 오픈 모델은 여러 proprietary model과 실제로 경쟁하며 때로는 더 나은 결과를 낸다.
   3. 선택의 변화: 지능만을 위해 proprietary model을 계속 쫓을 필요가 줄어들고, 비슷하게 똑똑하면서 대부분 더 저렴한 오픈 모델을 선택할 수 있다.

2. 고객에게 생기는 효과

   1. 선택권: 고객은 원하는 provider에서 오픈 모델을 실행할 수 있다.
   2. vendor lock-in 완화: 특정 proprietary API에 묶이지 않는다.
   3. 토큰 경제성: token economics를 개선해 비용을 절감할 수 있다.

3. Teacher와 student 모델

   1. 대형 teacher 모델: 매우 강력하고 똑똑하지만 크고 비싸다.
   2. 소형 student 모델: 대형 teacher 모델을 사용해 더 작은 모델을 훈련할 수 있다.
   3. 발표 구조: 성능 최적화를 hardware layer, serving layer, optimizing layer의 세 층으로 나눠 설명한다.

3.2. NVIDIA 하드웨어와 모델별 서빙 엔진

1. 하드웨어·커널·런타임의 결합

   1. 최신 칩 접근: NVIDIA와 긴밀히 협력해 최신 칩셋을 확보한다.
   2. 소프트웨어 최적화: 최신 하드웨어를 가져오는 데 그치지 않고 kernel과 runtime도 최적화한다.
   3. 부동소수점 표준: 최신 NVIDIA 칩에서 모델 성능을 잘 끌어내기 위해 NVIDIA floating-point standard를 받아들인다.

2. 모델마다 맞는 엔진이 다르다

   1. 오픈소스 엔진 활용: 여러 오픈소스 serving engine을 사용한다.
   2. 내부 fork: 내부적으로 fork를 보유하고 지속적으로 수정·최적화한다.
   3. 엔진 선택: 모든 모델이 모든 엔진에서 똑같이 잘 실행되지 않으므로, 모델별로 가장 잘 맞는 엔진에 배포한다.
   4. 고객 경험: 고객은 GPU나 엔진을 고르는 일을 신경 쓰지 않고 API를 사용하면 된다.

3.3. LLM에 맞춘 cache-aware routing

1. 무작위 load balancing이 통하지 않는 이유

   1. 입력의 변화: 초기 LLM 사용에서는 한 줄짜리 작은 입력과 짧은 출력이 흔했다.
   2. 현재의 입력: coding agent가 대규모 codebase를 받아 refactor, summarize, analyze하는 경우처럼 입력이 매우 커졌다.
   3. 출력의 변화: 출력도 작은 것부터 큰 것까지 폭이 커져 요청별 workload가 달라졌다.
   4. 단순한 방식의 문제: GPU에 무작위로 보내면 요청이 cache를 가진 GPU에 도착할지 보장되지 않는다.

2. cache-aware router의 작동

   1. 나쁜 배치: 왼쪽 상태에서는 서로 다른 색으로 표시된 cache가 여러 GPU에 파편화돼 cache rate가 낮다.
   2. 좋은 배치: 오른쪽 상태에서는 같은 색의 cache가 모여 있어 cache가 더 일관적이다.
   3. 라우팅 판단: router가 cache가 저장된 위치를 알고 요청을 해당 GPU로 보낸다.
   4. 결과: inference 때 cache hit가 좋아지고 속도가 크게 향상된다.

3.4. Speculative decoding으로 큰 모델의 생성 비용 줄이기

1. 토큰 생성의 병목

   1. 순차 생성: LLM은 토큰을 하나씩 생성한다. 1, 2, 3, 4처럼 다음 토큰을 순서대로 만들기 때문에 큰 모델은 오래 걸린다.
   2. 기본 아이디어: 빠르고 저렴한 작은 모델을 draft model로 사용해 토큰을 먼저 만들고, 큰 모델이 결과를 검증한다.

2. 시니어 엔지니어와 주니어 엔지니어의 비유

   1. 역할 분담: 시니어 엔지니어가 주니어 엔지니어에게 작업을 맡기고 결과를 검증하는 것과 같다.
   2. 정상 경로: 큰 모델이 draft를 승인하면 많은 토큰을 빠르게 얻는다.
   3. 최악의 경로: 큰 모델이 마음에 들지 않으면 토큰을 다시 생성한다.
   4. 실제 효과: 대부분의 경우 작은 모델의 빠른 생성과 큰 모델의 검증을 결합해 좋은 성능을 낸다.

3. 고객 데이터로 draft model을 개선한다

   1. 일반 데이터 효과: synthetic data나 일반적인 데이터로 draft model을 훈련해도 최대 30% 향상을 관찰했다.
   2. 자체 데이터 효과: 고객의 실제 프로덕션 데이터로 작은 모델을 훈련하면 더 좋아진다.
   3. 제품화: Token Factory는 프로덕션 데이터를 수집하고 draft model을 대신 훈련하는 기능을 거의 한 번의 클릭으로 제공하려 한다.

3.5. KV cache로 반복 계산을 제거한다

1. 캐시의 기본 원리

   1. 비싼 생성: 특히 토큰을 한 번에 하나씩 만들 때 생성 비용이 크다.
   2. 불변성: 한 번 만든 토큰은 보통 바뀌지 않으므로 같은 토큰을 반복 생성할 필요가 없다.
   3. 예시: "the cat sat on"이라는 prompt에서 다음 단어를 만들면 생성한 토큰을 cache에 저장하고, 다음에 같은 맥락을 조회할 때 다시 생성하지 않고 cache를 읽는다.

2. 측정된 효과와 메모리 문제

   1. 속도 향상: 캐싱으로 5~10%가 아니라 5~10배의 speed-up을 관찰했다.
   2. 메모리 부담: 큰 입력과 긴 token window에서는 KV cache가 많은 메모리를 차지한다.
   3. GPU memory 보호: GPU memory는 귀중하므로 모든 cache를 GPU에 계속 둘 수 없다.

3. 자동 offload

   1. 저장 위치 이동: Token Factory는 KV cache를 GPU memory에서 일반 memory로 자동 offload할 수 있다.
   2. 재사용: 힘들게 만든 cache를 버리지 않고 필요할 때 다시 가져온다.
   3. 운영 단순화: cache를 언제 옮기고 불러올지 고객이 직접 관리하지 않아도 된다.

3.6. Prefill과 decoding을 분리한다

1. 두 단계의 서로 다른 성격

   1. Prefill: 입력 context를 채우는 단계로 compute-intensive하다.
   2. Decoding: 실제 토큰을 생성하는 단계로 memory-intensive하다.
   3. 공유 GPU의 충돌: 두 단계를 같은 GPU에서 처리하면 compute resource를 놓고 경쟁한다.

2. Disaggregated serving

   1. 전용 GPU 분리: 한 GPU 집합은 prefill을 담당하고 다른 GPU 집합은 decoding을 담당한다.
   2. KV cache 전달: 두 단계 사이에서 KV cache를 전송한다.
   3. 운영 결과: 각 단계가 자기 특성에 맞는 자원을 사용하면서 성능이 좋아진다.

3.7. 품질을 보존하는 quantization

1. 정밀도와 효율의 교환

   1. 정밀도 축소: quantization은 모델의 precision을 낮춰 실행 효율을 높인다.
   2. 과도한 축소의 위험: 너무 멀리 가면 모델 quality가 저하된다.

2. sweet spot 탐색

   1. 실험 기반 결정: 모델을 효율적으로 실행하면서 성능 저하를 크게 만들지 않는 quantization 수준을 반복 실험으로 찾는다.
   2. 플랫폼 내장: quantization을 포함한 최적화가 플랫폼에 이미 들어 있어 고객이 직접 모든 조합을 시험하지 않아도 된다.

4. 프로덕션 사용자에게 남는 실행 경로

API 뒤에서 하드웨어·엔진·라우터·캐시·모델 튜닝이 함께 작동해야 초대형 모델을 실제 서비스 속도로 운영할 수 있다.

4.1. 추상화 뒤에 숨은 전체 최적화

1. 고객이 보는 것

   1. 단순한 API: 고객은 GPU 종류, serving engine, cache 배치, prefill 분리를 직접 선택하지 않고 API를 사용한다.
   2. 숨은 작업: 그 뒤에서는 엔진 선택, cache-aware routing, speculative decoding, KV cache 관리, prefill/decode 분리, quantization이 수행된다.

2. 대형 모델 시대의 요구

   1. 규모 변화: 1조(trillion) 파라미터급 모델까지 등장하는 상황에서는 단순히 GPU를 늘리는 것만으로 충분하지 않다.
   2. 플랫폼의 역할: 여러 최적화를 한꺼번에 조합해 latency, throughput, 비용을 함께 관리해야 한다.

4.2. 직접 사용해 볼 모델과 개발 도구

1. 시험 기회: 발표자는 Token Factory 플랫폼에서 사용할 수 있는 credit을 제공하겠다고 안내한다.
2. 모델: 최신 오픈소스 모델인 GLM-5.2, Kimi K2.7 계열 등을 사용해 볼 수 있다고 소개한다.
3. 코딩 활용: Sujee는 최근 코딩에 이 모델들을 많이 사용했고 잘 작동한다고 말한다.
4. 통합 대상: Cursor나 OpenCode를 사용하는 개발자는 코딩 작업에 모델을 쉽게 연결할 수 있다.

4.3. 마무리와 커뮤니티

1. 질문 창구: 화면 하단의 Discord 채널에 질문을 올리거나 Sujee와 Dylan에게 직접 메시지를 보내면 답변하겠다고 안내한다.
2. 시간 농담: Sujee는 발표를 "여기서 멈추겠다"고 말한 뒤 남은 시간이 10초뿐임을 확인했고, 정확히 시간에 맞췄다는 분위기 속에서 청중의 웃음이 나왔다.
3. 후속 대화: 발표 후 현장에서 두 발표자에게 다가와 더 이야기하고 질문해 달라는 말로 마무리했다.

주요 발언 모음

"훌륭한 inference는 훌륭한 모델에서 시작하지만, 그것만으로는 충분하지 않다. 뒤에서 받쳐 주는 훌륭한 인프라가 필요하다."

"모델을 실행하는 것과 실제 프로덕션 AI 시스템을 실행하는 것은 다르다."

"캐싱으로 5~10%가 아니라 실제로 5~10배의 속도 향상을 봤다."

"작은 모델이 토큰을 생성하고 큰 모델이 검증하는 방식은 시니어 엔지니어가 주니어 엔지니어에게 일을 맡기고 결과를 확인하는 것과 같다."

"같은 오픈소스 모델도 서로 다른 provider에서 돌리면 비용 측면에서 완전히 다른 결과가 나올 수 있다."

핵심 데이터 & 수치

• 20억 달러: NVIDIA가 몇 달 전 Nebius에 투자한 금액으로 소개됐다.
• 2030년 말 5GW: Nebius가 목표로 제시한 NVIDIA 시스템 규모다.
• 60개 이상: Token Factory가 제공한다고 밝힌 모델 수다.
• 최대 30%: 일반 데이터로 draft model을 훈련했을 때 관찰한 개선 폭이다.
• 5~10배: KV cache를 활용했을 때 관찰한 inference speed-up이다.
• 10초: Sujee가 발표를 끝낼 때 남아 있던 시간으로, 발표 마무리의 농담으로 사용됐다.

핵심 요약 (20줄)

1. 오픈 모델의 프로덕션 성능은 모델 지능뿐 아니라 실리콘부터 서빙까지 이어지는 전체 스택의 최적화에 좌우된다.

2. 폐쇄형 API는 도입이 쉽지만 모델 조정권과 인프라 투명성이 부족하고 사용량에 따라 비용이 직선적으로 증가한다.

3. 셀프 호스팅은 통제력을 제공하지만 전담 팀과 대규모 엔지니어링이 필요해 제품 출시가 늦어진다.

4. Nebius Token Factory는 셀프 호스팅의 제어력과 관리형 추론 서비스의 단순성을 결합한다.

5. Nebius는 자체 데이터센터와 bare-metal 인프라를 EU와 미국에서 운영하며 NVIDIA 시스템을 직접 관리한다.

6. NVIDIA의 20억 달러 투자와 2030년 말 5GW 목표는 Nebius의 하드웨어 확장 전략을 뒷받침한다.

7. Token Factory는 inference, Data Lab, post-training, deployment를 하나의 지속적인 개선 루프로 연결한다.

8. 60개가 넘는 모델, dedicated endpoint, structured output, function calling, batch API를 제공한다.

9. 프로덕션 completion과 inference 로그는 필터링·버전 관리 후 synthetic data와 모델 튜닝에 재사용된다.

10. Artificial Analysis 비교에서 오픈 모델은 proprietary model과 경쟁하고 일부는 더 나은 결과를 보인다.

11. 오픈 모델의 지능 격차 축소는 vendor lock-in을 줄이고 token economics를 개선할 선택권을 만든다.

12. 모델마다 최적의 serving engine이 다르므로 내부 fork와 커널·런타임 튜닝으로 배포 조합을 고른다.

13. 대규모 codebase를 처리하는 LLM workload에는 무작위 load balancing보다 cache-aware routing이 적합하다.

14. Cache-aware router는 요청을 관련 cache가 있는 GPU로 보내 cache 일관성과 inference 속도를 높인다.

15. Speculative decoding은 작은 draft model이 토큰을 만들고 큰 모델이 검증해 순차 생성 비용을 낮춘다.

16. 일반 데이터로 draft model을 훈련해도 최대 30% 개선을 관찰했고 고객 데이터로 훈련하면 더 좋아질 수 있다.

17. KV cache는 이미 만든 토큰의 재생성을 없애며 실제로 5~10배 speed-up을 만들 수 있다.

18. GPU memory가 부족하면 KV cache를 일반 memory로 자동 offload했다가 필요할 때 다시 불러온다.

19. Prefill은 compute-intensive하고 decoding은 memory-intensive하므로 서로 다른 GPU 집합으로 분리할 수 있다.

20. 적정 quantization과 전체 최적화를 조합하면 고객은 복잡한 인프라를 관리하지 않고도 빠르고 저렴한 오픈 모델 서비스를 운영한다.

결론 및 시사점

1. 오픈 모델 도입의 핵심 질문은 "어떤 모델이 가장 똑똑한가"에서 "어떤 모델·하드웨어·엔진·데이터 루프 조합이 우리 프로덕션에 가장 적합한가"로 이동한다.
2. 모델을 한 번 배포하는 데서 끝내지 말고 inference 로그를 관찰하고, 실제 데이터로 draft model과 post-training을 수행하고, 업데이트를 다시 배포하는 폐루프를 설계해야 한다.
3. cache-aware routing, speculative decoding, KV cache, prefill/decode 분리, quantization은 각각의 작은 트릭이 아니라 latency·throughput·cost를 함께 결정하는 서빙 시스템의 구성 요소다.
4. 하드웨어를 소유하고 엔진부터 배포까지 통제하는 수직 통합은 같은 오픈 모델을 다른 provider보다 빠르고 싸게 운영하게 만드는 기반이다.
5. 고객은 모델과 행동을 통제하면서도 데이터센터와 GPU 운영을 직접 떠안지 않는 managed inference 경로를 선택할 수 있다.