특화 AI를 빌려 쓰는 데서 벗어나기: Fireworks AI의 학습-배포 루프

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

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==폐쇄형 모델의 지능을 매번 임대하는 대신, 오픈 모델을 자체 데이터로 계속 학습시키고 같은 플랫폼에서 서비스하는 train-to-deploy 루프를 구축하면 비용과 품질을 동시에 통제할 수 있다.==

• 오픈 모델은 이미 대부분의 실사용 영역, 특히 프로그래밍에서 production-ready 수준에 도달했다.
• 모델 자체의 차이보다 데이터 정제, 평가 함수, 하이퍼파라미터, 학습 방식과 추론 최적화가 품질 격차를 결정한다.
• 학습과 추론을 분리하지 않고 같은 인프라에서 연결하면 새 체크포인트를 무중단으로 배포하고 사용자 피드백을 다음 학습으로 되돌릴 수 있다.

오픈 모델을 선택하는 이유는 단순한 비용 절감에 그치지 않는다. Fireworks AI가 제시하는 핵심은 모델 선택, 특화 학습, 추론 엔진 최적화, 운영 모니터링, 재학습을 하나의 반복 가능한 시스템으로 묶는 것이다. 이 구조에서는 범용 모델을 한 번 배포하고 끝내는 방식이 아니라, 실제 워크로드에서 수집한 데이터와 피드백으로 동일한 모델 계열을 계속 개선한다.

1. 폐쇄형 모델에서 오픈 모델로 이동하는 세 가지 진실

오픈 모델 전환은 모델을 바꾸는 단발성 마이그레이션이 아니라, 프로토타이핑부터 운영 학습까지 이어지는 구조적 변화다.

1.1. 비용 압박에서 시작되는 전환

1. 폐쇄형 모델 사용의 현실

   1. 발표자는 청중에게 ChatGPT나 Anthropic 같은 폐쇄형 모델을 사용하는지 물었고, 대부분이 사용한다고 답했다.
   2. 이어서 비용이 너무 빠르게, 과도하게 커지고 있다고 느끼는지 물었으며 역시 상당수가 그렇다고 응답했다.
   3. 이 비용 압박 때문에 여러 팀이 폐쇄형 프로토타이핑에서 오픈 모델 프로토타이핑으로 옮겨가고 있다.

2. 전환의 목표

   1. 오픈 모델을 선택하는 이유는 가격이나 성능 중 하나만이 아니라 두 요소를 함께 개선하려는 데 있다.
   2. 단순히 모델을 내려받아 호스팅하는 것만으로는 충분하지 않으며, 특정 사용 사례에 맞춘 학습과 추론 최적화가 필요하다.

1.2. 오픈 모델에 관한 세 가지 기본 사실

1. 첫 번째 사실: 오픈 모델은 production-ready다

   1. 현재 오픈 모델은 대부분의 측면에서 실제 제품에 투입할 수 있는 수준이다.
   2. GLM 5.2 같은 모델은 특히 프로그래밍 사용 사례에서 이 사실을 잘 보여준다.

2. 두 번째 사실: 품질 격차는 customization에서 줄어든다

   1. 오픈 모델이 폐쇄형 모델의 품질을 아직 완전히 따라가지 못하는 경우에도, 차별화 요소는 모델의 원래 가중치만이 아니다.
   2. 데이터셋을 정제하고, 적절한 학습 방식을 고르고, 평가 함수와 하이퍼파라미터를 조정하고, 추론을 최적화하면 특정 워크로드에서 폐쇄형 모델에 맞먹는 품질을 만들 수 있다.

3. 세 번째 사실: AI 아키텍처가 일회성 배포에서 연속 루프로 바뀐다

   1. 기존 방식은 모델을 제공하고 배포한 뒤 작업을 끝내는 구조였다.
   2. 새 방식은 같은 오픈 모델을 학습하고(inference 전 단계), 서비스하고, 사용자의 새 데이터와 피드백을 수집한 뒤 다시 학습하는 연속 루프다.
   3. Fireworks의 역할은 이 ongoing training과 대규모 호스팅을 더 쉽고 비용 효율적으로 연결하는 것이다.

2. Fireworks의 규모와 고객 성과

Fireworks는 모델 학습과 대규모 추론을 같은 운영 흐름 안에서 제공하며, 실제 고객의 속도와 품질 개선을 사례로 제시한다.

2.1. 운영 규모

1. 처리량

   1. Fireworks는 대규모 production 환경에서 약 30조(trillion) 토큰을 서비스하고 있다.
   2. 이 수치는 GLM 5.2 출시 전 기준이며, 발표자는 출시 이후 하루에 최소 5조 토큰이 추가됐다고 설명했다.
   3. 전 세계 10,000개 이상의 회사를 지원하고 초당 약 200,000건의 요청을 처리한다.

2. 조직 규모와 신뢰

   1. Fireworks는 최근 약 3억 2,700만 달러의 투자를 유치했다.
   2. 약 200명의 직원이 플랫폼과 모델 인프라를 운영한다.

2.2. 고객별 효과

1. Cursor — Composer 2

   1. Cursor의 Composer 2 모델은 Fireworks 플랫폼에서 학습되고 호스팅된다.
   2. FireAttention 엔진 덕분에 추론 속도가 13배 빨라졌다.

2. Vercel — 응답 시간

   1. Vercel은 Fireworks의 주요 고객으로, Fireworks가 모델을 fine-tune하고 플랫폼에서 호스팅했다.
   2. 그 결과 응답 시간이 40배 개선됐다.

3. Genspark — 품질 개선

   1. Genspark는 프롬프트만으로 시스템을 설계하게 하는 비슷한 영역의 제품을 만들고 있다.
   2. 폐쇄형 모델에서 오픈 모델로 옮길 때 가장 큰 장애물은 품질이었다.
   3. Fireworks는 데이터셋을 정제하고 평가 함수를 정의한 뒤 Reinforcement Fine-Tuning(RFT)을 수행했다.
   4. RFT가 끝난 뒤 Genspark 사용 사례의 품질이 12% 향상됐다.

3. 추론 성능을 만드는 FireAttention과 특화 최적화

대규모 서비스에서는 모델의 원래 품질만큼 모델이 GPU에서 실행되는 방식과 고객 워크로드에 맞춘 시스템 최적화가 중요하다.

3.1. FireAttention과 custom CUDA kernels

1. 모델과 GPU 사이의 실행 계층

   1. 모델은 GPU 위에서 실행되며, 모델 연산을 GPU에 연결하는 번역 계층이 CUDA kernel이다.
   2. Fireworks는 자체 추론 엔진인 FireAttention을 만들고, 그 안에 자체 CUDA kernel을 구축했다.

2. 워크로드별 최적화

   1. 고객은 입력·출력 토큰 수, 캐시 적중률(cache success rate), 목표 응답 시간 같은 조건을 제시한다.
   2. Fireworks는 CUDA kernel을 포함한 전체 추론 패키지를 해당 워크로드에 맞춰 조정한다.
   3. 목표는 같은 모델을 더 낮은 비용으로 실행하면서 고객이 요구하는 성능 목표를 달성하는 것이다.
   4. Vercel 사례처럼 응답 시간 목표가 명확한 고객일수록 모델·GPU·커널을 함께 최적화하는 효과가 커진다.

3.2. Speculative decoding과 draft model

1. 추론 가속 원리

   1. Fireworks는 attention과 reasoning 성능을 높이기 위해 speculative decoding 같은 기법을 사용한다.
   2. 작은 draft model이 다음 토큰 후보를 빠르게 제안하고, 주 모델이 후보를 검증하는 방식으로 주 모델의 모든 토큰 생성을 기다리는 비용을 줄인다.

2. 고객별 draft model 학습

   1. 고객은 fine-tuning과 유사한 방식으로 데이터셋을 Fireworks 플랫폼에 올리고 draft model의 프로토타입을 학습시킬 수 있다.
   2. 잘 학습된 프로토타입은 주 모델의 응답 시간을 줄이고 생산성을 높이며, 고객의 latency 요구 사항을 맞추는 데 도움을 준다.

4. 세 가지 학습 제품과 품질 격차 해소

Fireworks는 사용자 역량과 통제 수준에 따라 training agent, managed training, Training API라는 세 가지 경로를 제공한다.

4.1. Training agent — 초보 사용자도 시작할 수 있는 자동화

1. 입력과 자동 설정

   1. 사용자는 Fireworks에 업로드한 데이터셋과 학습 목표에 대한 설명을 연결한다.
   2. 사용할 모델을 고르면 agent가 데이터셋을 정제하고, 특정 워크로드에 맞는 하이퍼파라미터를 조정한다.
   3. 제품 관리자를 비롯해 AI 추론과 학습을 막 시작한 개발자에게 적합하다.

2. 지원 범위와 한계

   1. agent는 적절한 기본 모델과 설정을 선택하는 과정을 자동화해 학습 진입 장벽을 낮춘다.
   2. 현재 training agent는 RFT를 지원하지 않으므로 RFT용 평가 함수 설계, 데이터셋 정제, 하이퍼파라미터 조정까지 자동으로 수행하지는 않는다.
   3. 큰 RFT 사용 사례에는 Fireworks 팀이 평가 함수 정의와 데이터셋 정제를 직접 지원할 수 있다.

4.2. Managed training — 한 번의 생성으로 실행하는 학습

1. 기본 절차

   1. 사용자는 API 또는 UI에서 모델, 데이터셋, 하이퍼파라미터를 입력한다.
   2. 데이터셋을 선택하고 필요한 설정을 넣은 뒤 버튼을 클릭하면 managed training 작업이 시작된다.
   3. Fireworks가 제공하려는 핵심은 모델 학습을 여러 인프라 조작이 아닌 간단한 구성 작업으로 만드는 것이다.

2. 모니터링

   1. 대시보드에서 학습 진행 상황, 각 세션에서 모델이 얼마나 학습되는지, loss function의 변화를 확인할 수 있다.
   2. Weights & Biases API key를 연결하면 학습 모니터링 지표를 Weights & Biases로 내보낼 수 있다.
   3. 학습이 끝난 뒤 데이터셋, 하이퍼파라미터, loss 곡선을 다시 살펴보고 설정을 복제해 다른 조건으로 재현할 수 있다.

4.3. Training API — 학습 루프를 직접 설계하는 고급 경로

1. 사용자 정의 권한

   1. 머신러닝 엔지니어는 Training API로 자신만의 training loop를 정의할 수 있다.
   2. loss function도 직접 지정할 수 있으므로 조직의 특수한 목표와 데이터에 맞춰 학습 작업을 세밀하게 조정할 수 있다.
   3. 이 방식은 미리 정해진 managed training보다 훨씬 높은 통제력을 제공한다.

2. 지원하는 학습 방식

   1. 세 제품은 Supervised Fine-Tuning(SFT), Reinforcement Fine-Tuning(RFT), Direct Preference Optimization(DPO)을 지원한다.
   2. RFT에서는 좋은 evaluation function을 만드는 일이 핵심이며, Genspark 사례처럼 데이터 정제와 평가 함수 설계가 결과를 좌우한다.

5. 데이터 flywheel: 학습과 서비스가 서로를 개선하는 구조

학습 결과를 배포하고 운영 데이터를 다시 학습으로 가져오는 짧은 루프가 특화 AI의 지속적인 품질 향상을 만든다.

5.1. train → deploy → monitor → retrain

1. 배포까지의 거리 단축

   1. 학습이 끝난 모델은 한 번의 클릭으로 실제 작업 환경에 배포할 수 있다.
   2. 배포 후에는 토큰 수, 캐시 성공률, predictor를 학습한 경우 predictor의 성능 같은 지표를 모니터링한다.

2. 피드백의 재투입

   1. 운영 중 수집한 지표와 사용자 피드백을 다음 학습 데이터로 활용한다.
   2. 같은 플랫폼에서 기존 체크포인트에서 새 체크포인트로 재학습하고, 다시 호스팅하는 과정을 반복한다.
   3. 이 루프가 새 데이터와 피드백이 들어올 때마다 모델을 개선하는 data flywheel이다.

5.2. GPU 인프라와 hot loading

1. 연결된 인프라

   1. 학습과 대규모 호스팅을 이어주는 기반은 충분한 GPU 집합이다.
   2. Fireworks는 여러 cloud service provider 및 새로운 클라우드 서비스와 협력해 학습 계산 자원과 대규모 호스팅을 제공한다.

2. 새 가중치의 무중단 교체

   1. hot loading을 사용하면 새 체크포인트가 생겼을 때 서비스를 중단하지 않고 곧바로 live deployment로 전환할 수 있다.
   2. 기존에 사용하던 가중치를 새 endpoint의 가중치로 버튼 한 번에 교체할 수 있다.
   3. Cursor 모델을 학습할 때 처음 구현한 기능이었지만, 연속 학습이 필요한 일반 사용자에게도 유용해 공개 기능으로 확장했다.

5.3. Training과 serving 사이의 numerical fidelity

1. 플랫폼을 나눌 때 생기는 문제

   1. 한 플랫폼 A에서 학습하고 플랫폼 B에서 호스팅하면 두 시스템의 디지털 수치 표현이 완전히 호환되지 않을 수 있다.
   2. 이 미세한 numerical difference가 모델 품질 차이로 나타나며, 학습 때 확인한 결과와 serving 때의 결과가 달라질 수 있다.

2. 동일 플랫폼의 이점

   1. Fireworks는 학습과 추론을 같은 플랫폼에서 제공해 학습 후 호스팅할 때 수치 차이가 생기지 않도록 보장한다.
   2. 동일한 training·reasoning 환경에서 새 모델을 곧바로 production scale로 배포할 수 있어 train-to-deploy 루프가 매끄러워진다.

6. 제품 데모에서 확인한 실제 작업 흐름

데모는 자동화된 학습 계획을 검토하는 단계와, 직접 설정한 managed training 결과를 배포하는 단계를 각각 보여준다.

6.1. Training agent 데모

1. 데이터와 목표 입력

   1. 사용자는 Fireworks 안에 있는 training dataset의 위치와 이름을 입력한다.
   2. 학습 데이터와 분리해 둔 assessment 또는 test dataset도 함께 제공한다.
   3. agent에게 fine-tuning을 수행하고 적절한 파라미터와 모델을 선택하라고 요청한다.

2. 계획 검토와 실행

   1. agent는 수행할 단계를 먼저 설명하고, SFT 계획과 기본 모델을 고른 이유를 제시한다.
   2. 데모에서는 Quant 38B 모델을 기본 모델로 선택했고, 하이퍼파라미터와 전체 학습 과정의 개요를 함께 보여줬다.
   3. 사용자가 계획을 승인하면 agent가 단계별로 실행하며 각 단계의 완료 여부와 현재 상태를 업데이트한다.

3. 결과와 다음 행동

   1. 학습이 끝나면 기본 모델, 하이퍼파라미터, 각 설정의 영향과 전체 설정을 요약한다.
   2. 정확도(accuracy)와 F1 score 같은 지표를 제공하고, 지금까지 한 작업을 다시 정리한다.
   3. 결과 다음에 권장되는 next step도 제시한다.

6.2. Managed training 데모

1. 학습 생성

   1. 모델과 데이터셋을 고른 뒤 assessment settings에서 평가 데이터셋을 선택한다.
   2. 필요하면 더 정확한 학습을 위해 optional hyperparameter 설정을 추가한다.
   3. 구성이 만족스러우면 Create 버튼을 클릭하고 학습 작업을 즉시 시작한다.

2. 결과 확인과 복제

   1. 완료된 작업을 열면 사용한 데이터셋, 하이퍼파라미터, 학습 중 모델의 loss 변화가 표시된다.
   2. 동일한 학습 과정을 다른 설정과 구성으로 clone하고 재현할 수 있다.

3. 커스텀 모델 배포

   1. 충분히 조정된 템플릿을 publishing 단계에서 선택하고 Publish를 누른다.
   2. 제공되는 deployment configuration 중 높은 throughput, 빠른 속도, 최소 설정을 선택할 수 있다.
   3. 이 템플릿은 throughput, 응답 시간, 첫 토큰이 나올 때까지의 시간(time to first token) 같은 일반 워크로드 지표를 기준으로 최적화돼 있다.

6.3. Training API와 마무리

1. Training API는 고객별 설정이 달라 한 가지 공통 데모를 보여주기 어렵지만, 공식 웹사이트 가이드에서 사용자 정의 training loop와 loss function을 만드는 방법을 확인할 수 있다.
2. 전체 흐름의 핵심은 학습, 추론, 호스팅을 분리된 도구의 조합으로 남겨두지 않고 하나의 반복 가능한 운영 과정으로 연결하는 것이다.
3. 남은 시간이 1분 정도였기 때문에 별도의 질의응답은 진행되지 않았고, 발표자는 간단한 개요를 마친 뒤 감사를 전하며 발표를 끝냈다.

주요 발언 모음

“오픈 모델은 대부분의 측면에서 production-ready다.”

“품질을 맞추는 차별화 요소는 모델을 어떻게 customize하고, train하고, optimize하느냐에서 나온다.”

“한 번 모델을 제공하고 끝내는 방식에서, 같은 오픈 모델의 training phase와 inference phase를 계속 개선하는 loop로 바뀌고 있다.”

“새 체크포인트가 생기면 downtime 없이 바로 live deployment로 갈 수 있다.”

“Training과 reasoning을 같은 플랫폼에서 수행하면 학습 후 호스팅할 때 numerical difference를 피할 수 있다.”

핵심 데이터 & 수치

• 약 30조 토큰: GLM 5.2 출시 전 Fireworks가 대규모 production에서 서비스하던 토큰 규모다.
• 하루 최소 5조 토큰 추가: 발표자는 GLM 5.2 출시 이후 처리량이 이 정도 더 늘었다고 설명했다.
• 10,000개 이상 기업: Fireworks가 전 세계적으로 지원하는 기업 수다.
• 초당 약 200,000건 요청: 플랫폼의 대략적인 처리 요청량이다.
• 13배 빠른 추론: Fireworks에서 학습·호스팅된 Cursor Composer 2가 FireAttention을 통해 달성한 속도 개선이다.
• 40배 응답 시간 개선: Vercel 모델을 fine-tune하고 호스팅한 뒤 관찰한 효과다.
• 품질 12% 향상: Genspark 사용 사례에서 데이터셋 정제, 평가 함수 정의, RFT를 거친 결과다.
• 약 3억 2,700만 달러 투자와 약 200명 직원: Fireworks가 제시한 회사 규모다.
• 정확도와 F1 score: Training agent가 학습 완료 후 제공하는 대표 평가 지표다.

결론 및 시사점

1. 오픈 모델 도입의 승부처는 모델 가격이 아니라 데이터와 학습·평가·추론을 연결하는 운영 루프다.
2. 일반 사용자는 training agent로 데이터셋 정제와 하이퍼파라미터 선택을 자동화할 수 있고, 팀의 전문성이 높아지면 managed training과 Training API로 통제 범위를 넓힐 수 있다.
3. SFT만으로 해결되지 않는 품질 문제에는 RFT와 좋은 evaluation function이 중요하며, Genspark 사례는 데이터 정제와 평가 설계가 12% 품질 개선으로 이어질 수 있음을 보여준다.
4. FireAttention, custom CUDA kernels, speculative decoding, 고객별 draft model은 모델 변경 없이도 latency와 비용을 개선하는 시스템 레이어다.
5. hot loading은 새 체크포인트를 무중단으로 운영에 반영하게 하고, numerical fidelity는 학습 결과와 실제 serving 결과의 차이를 줄인다.
6. AI 제품 팀은 모델을 한 번 선택해 고정하기보다 사용자 피드백과 운영 지표를 다음 학습에 되돌리는 train-to-deploy flywheel을 설계해야 한다.

핵심 요약 20줄

오픈 모델은 이미 대부분의 실사용 영역에서 production-ready 수준에 도달했다.

폐쇄형 모델의 급격한 비용 상승이 오픈 모델 전환을 촉진하고 있다.

오픈 모델의 품질 격차는 데이터와 customization으로 줄일 수 있다.

AI 아키텍처는 일회성 배포에서 train-to-deploy 연속 루프로 변하고 있다.

Fireworks는 학습과 대규모 호스팅을 하나의 플랫폼에서 연결한다.

Fireworks는 약 30조 토큰과 10,000개 이상의 기업을 처리한다.

플랫폼은 초당 약 200,000건의 요청을 처리한다.

Cursor Composer 2는 FireAttention으로 추론 속도를 13배 높였다.

Vercel은 Fireworks 최적화로 응답 시간이 40배 개선됐다.

Genspark는 RFT를 통해 특정 사용 사례의 품질을 12% 높였다.

FireAttention은 고객 워크로드에 맞춘 custom CUDA kernels를 사용한다.

Speculative decoding은 draft model과 주 모델의 검증을 결합해 추론을 가속한다.

Training agent는 데이터셋 정제와 하이퍼파라미터 선택을 자동화한다.

Managed training은 모델과 데이터셋을 선택한 뒤 버튼 한 번으로 학습을 시작한다.

Training API는 사용자 정의 training loop와 loss function을 허용한다.

세 학습 경로는 SFT, RFT, DPO를 지원한다.

운영 지표와 사용자 피드백은 다음 체크포인트 학습에 다시 투입된다.

Hot loading은 새 가중치를 downtime 없이 live deployment에 반영한다.

동일 플랫폼의 training과 serving은 numerical difference로 인한 품질 변화를 줄인다.

특화 AI의 핵심 경쟁력은 모델 선택보다 지속적인 학습-배포-피드백 루프다.