Amazon Bedrock에서 파인튜닝을 검토하는 대부분의 팀에게, 올바른 답은 순서대로 검색, 프롬프트 캐시, 더 나은 프롬프트다. 파인튜닝은 이 세 가지를 다 써본 뒤에 고려할 도구이지, 그 전에 쓸 도구가 아니다. 이것은 이념의 문제가 아니라 청구서의 문제다. Bedrock에서 커스텀 파인튜닝된 모델은 Provisioned Throughput을 통해서만 서빙할 수 있고, 그 가격 모델이 애플리케이션 전체의 경제성을 바꿔놓는다.

파인튜닝은 진지한 선택처럼 느껴진다. 독점 데이터가 있으니 모델이 그것을 "알기를" 원해서 학습을 시킨다. 하지만 사람들이 파인튜닝하려는 대상 대부분은 가중치가 흡수해야 할 지식이 아니다. 추론 시점에 모델에 필요한 컨텍스트고, 따르라고 지시할 수 있는 포맷이며, 애초에 명확하게 작성되지 않았던 지시문이다. 이 셋 모두 더 저렴한 해법이 있다.

파인튜닝할 때 여러분이 짊어지는 비용

Bedrock에서는 커스텀 파인튜닝 모델을 종량제 온디맨드 가격으로 호출할 수 없다. 이를 추론하려면 Provisioned Throughput을 구매해야 한다. 시간 단위로 모델 유닛을 예약하는 방식이고, 가장 저렴한 약정도 월 단위 이상으로 돌아간다. 이제 여러분은 트래픽이 흐르든 아니든 예약 용량에 대해 비용을 지불한다.

이것이 비용 구조를 뒤집는다. 온디맨드 가격은 사용량에 따라 확장된다: 트래픽이 없으면 청구도 없다. Provisioned Throughput은 고정 하한선이다: 새벽 3시에 유휴 상태인 모델 유닛도 피크 시간대에 바쁜 유닛과 같은 비용이 든다. 스파이크성이거나, 낮은 볼륨이거나, 아직 제품-시장 적합성을 찾는 중인 워크로드라면, 쓰지도 않는 용량에 임대료를 내는 셈이다. 게다가 데이터가 변할 때마다 재학습하고, 모델을 버전 관리하고, 새 체크포인트마다 평가하는 MLOps 부담도 늘어나는데, 그것을 누군가는 영원히 떠맡아야 한다.

더 저렴한 스택이 실제로 해결하는 것

RAG는 지식을 다룬다

모델이 여러분의 문서를 근거로 답하는 것이 목표라면, 그것은 학습이 아니라 검색의 문제다. Bedrock Knowledge Base는 여러분의 콘텐츠를 임베딩하고 쿼리 시점에 관련 구절을 컨텍스트로 끌어온다. 새 문서가 생기면 재학습이 필요 없다: 인덱싱만 하면 몇 분 안에 검색 가능해진다. 파인튜닝은 지식을 가중치에 구워 넣지만, 데이터가 바뀌는 순간 그 가중치는 낡은 것이 된다. 검색은 지식을 지속적으로 업데이트 가능한 저장소에 유지하면서, 기본 모델에 대한 종량제 추론을 그대로 쓸 수 있게 해준다.

프롬프트 캐싱은 반복되는 컨텍스트를 다룬다

RAG와 퓨샷 프롬프팅에 대한 흔한 반론은 토큰 비용이다: 긴 시스템 프롬프트, 도구 정의, 검색된 컨텍스트를 매 호출마다 다시 보낸다는 것이다. 프롬프트 캐싱은 그 대부분을 없애준다. Bedrock은 프롬프트의 안정적인 접두부를 캐싱해서 반복되는 토큰이 크게 할인된 가격으로 청구되고 더 빠르게 서빙되도록 한다. 게다가 캐시 지속 시간이 이제 한 시간까지 늘어나서 사용자 세션이나 배치 작업 하나를 충분히 감당한다. 두툼한 프롬프트를 비싸게 만들었던 바로 그 문제를 캐싱이 고치도록 설계되어 있다.

더 나은 프롬프트는 행동과 포맷을 다룬다

놀랄 만큼 많은 파인튜닝 프로젝트가 실제로 원하는 건 모델이 일관된 JSON을 출력하거나, 특정 톤을 취하거나, 절차를 따르게 하는 것이다. 그것은 프롬프트의 문제다. 잘 고른 몇 개의 예시가 딸린 명확한 시스템 프롬프트만으로 대부분 해결되며, 학습 비용은 전혀 들지 않고 변경 주기도 재학습 실행이 아니라 몇 초 단위로 측정된다. 가중치를 바꿔야 한다고 결론짓기 전에 구조화된 프롬프팅과 퓨샷 예시를 먼저 소진하라.

비용 계산, 쉽게 풀어보면

일반적인 저에서 중간 볼륨 애플리케이션을 놓고 두 경로를 나란히 비교해보자.

Fine-tune path:
  training run (one-off)
  + Provisioned Throughput (fixed monthly floor, idle or not)
  + retraining + eval + versioning (ongoing engineering)

RAG + cache + prompts path:
  on-demand tokens (scales to zero when idle)
  + Knowledge Base storage + embedding (small, usage-based)
  + prompt cache (discounts the repeated prefix)

높고 꾸준하고 예측 가능한 볼륨이 아닌 이상, 두 번째 경로가 금액 면에서 더 저렴하고 엔지니어링 시간 면에서는 훨씬 더 저렴하다. Provisioned Throughput의 고정 하한선은 예약된 유닛을 계속 바쁘게 유지할 만큼 충분히 일정한 트래픽을 운영할 때만 본전을 뽑는다.

파인튜닝이 진짜로 정답인 경우

파인튜닝은 진짜 니치를 가진 진짜 도구다. 어떤 프롬프트로도 안정적으로 만들어낼 수 없는 행동이 필요할 때, 즉 특수한 출력 스타일, 기본 모델이 잘 다루지 못하는 도메인 어휘, 혹은 여러분의 볼륨에서 긴 프롬프트로는 맞출 수 없는 지연 시간과 토큰 예산이 필요할 때 파인튜닝하라. 그런 경우는 실제로 존재한다. 다만 그것은 예외이며, Provisioned Throughput의 고정 비용을 감수하기 전에 더 저렴한 스택이 측정 가능하게 실패한 지점을 가리킬 수 있어야 한다.

핵심 요약

Bedrock에서의 파인튜닝은 Provisioned Throughput을 의미하고, 이는 고정 비용 하한선과 끝없이 짊어져야 할 MLOps 책임을 의미한다. 팀들이 파인튜닝하려는 대상의 대부분은 지식, 반복되는 컨텍스트, 또는 불명확한 지시문이며, 이 셋은 검색, 프롬프트 캐싱, 더 나은 프롬프트로 더 저렴하게 해결된다. 저렴한 스택을 먼저 시도하고, 어디서 실패하는지 측정한 다음, 그때 비로소 학습에 비용을 지불하라.

다음으로 읽을 글

AWS 전반에 걸친 더 폭넓은 비용 최적화 전략은 ercan.cloud의 필드 노트에 있고, 허브는 ercanermis.com이다.