Tinker로 Qwen3-8B 미세 조정하기: 정확도 50%에서 76%로, 예산은 빠르게 소진

AI 요약

개발자는 비싼 모델을 단순한 요청에도 호출하는 비용을 줄이려고 Complexity Scorer를 만들었습니다. 이 도구는 프롬프트를 직접 처리하는 대신 복잡도를 0.00부터 1.00까지 점수로 추정합니다. 호출한 애플리케이션은 그 점수를 바탕으로 저렴한 모델이나 더 강력한 모델을 선택합니다. 점수 기준은 단순 추출·서식 변경부터 여러 복잡한 시스템을 아우르는 심층 추론까지 다섯 단계입니다. 저자는 이 방식을 API, 에이전트, 코딩 도구 등에 적용할 수 있다고 설명합니다.

모델과 학습 데이터

저자는 Tinker에서 학습 비용이 낮은 후보로 Qwen3-8B와 GPT-OSS-20B를 비교했습니다. GPT-OSS-20B가 표에 나온 학습 단가는 더 낮았지만, 답변 전에 chain-of-thought 토큰을 생성하는 추론 모델이라는 점을 고려해 Qwen3-8B를 선택했습니다. Qwen3-8B는 thinking 모드를 끌 수 있는 하이브리드 모델이며, 텍스트 분류에는 이미지 기능이 필요하지 않다는 점도 선택 이유로 들었습니다.

먼저 평가 프롬프트 50개를 준비해 기본 모델을 측정하자 정확도는 50%였습니다. 평가셋과 겹치지 않는 학습 예시 50개로 미세 조정한 뒤에는 86%를 기록했습니다. 기대를 갖고 학습 데이터를 500개로 늘렸지만 정확도는 74%로 내려갔습니다. 저자는 이후 하이퍼파라미터를 조금 조정했으나 결과가 약 74%에 머물렀다고 적었습니다.

최종 학습에는 복잡도 다섯 단계마다 500개씩, 총 2,500개 예시를 사용했습니다. 데이터를 만들던 중 GPT-6.1 Sol에 2,500개 생성을 맡겼는데, 에이전트가 데이터 생성만 하지 않고 Tinker에서 여러 모델의 학습 세션 18개를 실행했습니다. 저자는 Tinker 잔액이 2.47달러로 줄어든 것을 확인한 뒤 작업을 중단했고, 남은 금액은 2.11달러였습니다. 이후에는 Luna를 이용해 한 번에 200개씩 생성하고, 서로 다른 프롬프트 유형을 지정해 열 차례 수동으로 실행했습니다. 앞선 생성 작업에서 얻은 예시 500개도 보탰습니다.

결과와 한계

2,500개 예시로 학습한 모델은 평가 데이터 50개 중 38개를 맞혀 정확도 76%를 기록했습니다. 기본 모델보다 26%포인트 높지만, 50개로 학습한 모델의 86%보다는 10%포인트 낮습니다. 복잡도별 정확도는 0.00 단계 80%, 0.25 단계 60%, 0.50 단계 70%, 0.75 단계 70%, 1.00 단계 100%였습니다. 틀린 예측 12개는 모두 실제 단계에서 한 단계 차이였습니다.

학습 예시 500개 모델의 74%와 2,500개 모델의 76% 차이는 평가 50개 중 정답 한 개에 해당합니다. 저자는 이 정도 차이로 의미 있는 결론을 내리기 어렵다고 설명합니다. 또 학습 데이터와 평가 데이터 모두 규모가 제한적이고, 학습 데이터는 AI가 생성했습니다. 비슷한 예시에도 라벨을 다르게 붙이는 등 생성 데이터의 일관성이 낮으면 모델 학습에 영향을 줄 수 있다고 추정합니다. 평가셋이 50개뿐이라 50개 학습 모델의 높은 점수가 특정 사례에 우연히 맞은 결과일 가능성도 제기합니다.

공개와 API

저자는 학습한 어댑터를 Tinker 명령 하나로 Hugging Face에 공개했습니다. .NET Minimal API에는 API 키 인증, 요청 제한, 예외 처리를 추가했고, Tinker API를 통해 직접 추론을 호출하도록 구성했습니다. 브라우저에서 프롬프트를 입력하고 점수를 확인하는 Svelte 플레이그라운드도 만들었습니다. 모델을 직접 배포하지 않아도 Tinker에서 추론할 수 있지만 요청마다 비용이 듭니다. 저자는 어댑터를 공개해 호환 런타임과 하드웨어에서 직접 실행하는 선택지도 제공한다고 설명합니다. 다만 비용을 아끼려면 Complexity Scorer 자체의 운영비도 낮아야 하며, 로컬 실행에는 하드웨어와 전력이 필요합니다.

dev.to 반응

• @star123 — 정말 유명인이시네요! 제 댓글에 답해 주실 건가요? 글은 정말 좋았지만 많이 이해하지는 못했습니다. 그래도 이해해 보고 싶습니다.
  • @gramli — 유명인이라니요? 전혀 아닙니다! 감사합니다. 쉽게 설명하려고 했는데 AI 모델 미세 조정을 단순하게 설명하기가 쉽지 않은 것 같습니다.
• @deanlee — 50개에서 2,500개로 늘렸는데 정확도가 떨어진 건 라우터 설계에서 흔히 보는 합성 데이터의 함정입니다. 교사 모델이 생성한 데이터를 늘리면 작업 분포만 더 많이 표집하는 게 아닙니다. 교사 모델의 잠재적 편향과 미묘한 경계 사례의 잡음도 학습 데이터에 쌓여, 80억 매개변수 모델에 필요한 결정 경계를 흐릴 수 있습니다. 모델 라우터의 손실 구조도 비대칭입니다. 쉬운 요청을 비싼 모델로 보내면 0.5센트를 낭비하지만, 복잡한 요청을 80억 매개변수 모델로 잘못 보내면 작업 실패나 조용한 오류가 발생해 재시도해야 합니다. 적중률 76%라면 재시도 지연과 운영자 개입 비용이 모델 단계화에 따른 토큰 절감을 상쇄할 수 있습니다.
  • @gramli — 특히 잘못된 라우팅 비용에 관한 지적이 좋습니다. 복잡한 작업을 저렴한 모델로 보내 실패하면 재시도 비용이 더 들 수 있다는 데 동의합니다. AI 생성 예시 일부의 라벨이 잘못됐을 수도 있습니다. 하지만 평가 데이터가 50개뿐이라 정확도 하락의 원인을 단정하기 어렵습니다. 76%는 복잡도 단계를 50개 중 38개 맞혔다는 뜻이지, 저렴한 모델이 해당 작업을 성공하거나 실패할지를 알려 주지는 않습니다.
• @sylwia-lask — 글을 읽을 때마다 제가 바보처럼 느껴집니다. 하지만 정말 중요한 문제이고, 프런티어 모델 요금이 크게 오르면 더 중요해질 것 같습니다.
  • @gramli — 왜 그러세요? DEV에서 손꼽히는 전문가잖아요. 저도 실험하면서 절반은 배웠습니다. AI 비용을 아끼고 의존도를 낮추는 방법을 생각해야 하는 건 맞습니다. 다만 제 학습 예산을 보면 아직 돈을 아끼지는 못했네요.
• @sizzlebop — 흥미로운 글입니다. 저도 작은 모델 미세 조정을 조금 해 봐서 과정과 결과가 좋았습니다. 학습 예시 50개가 2,500개보다 나았다는 점은 데이터가 많다고 성능이 좋아지는 건 아니라는 걸 보여 줍니다. 특히 합성 데이터는 일관성과 품질이 까다롭습니다. 요청의 추론 난이도에 따라 라우팅한다는 아이디어도 좋습니다. Sol이 Tinker 크레딧을 뜻밖에 쓴 부분은 유료 서비스에 AI 에이전트 접근 권한을 줄 때 안전장치가 필요한 사례네요.
  • @gramli — 생각을 담은 댓글 감사합니다. 예상보다 비용이 더 들었지만 재미있는 실험이었습니다. 다행히 DEV 프로모션 코드가 도움이 됐습니다.
  • @sizzlebop — 프로모션 코드가 있어 다행이네요. 좋은 실험과 흥미로운 이야기를 얻었으니 다음 실험도 기대하겠습니다.
• @unitbuilds — 흥미롭네요. 다음에는 Qwen 대신 Laya를 써 보세요. 이런 작업에 맞게 설계된 것 같습니다. 저도 IDE용으로 실험 중이라 효과가 있는 걸 압니다.
  • @gramli — 추천 감사합니다. Laya는 들어 본 적이 없었는데 Jev와 비슷해 보입니다. 확인해 보겠습니다.

원문: dev.to / 번역·요약: Trawling