실제 제품에 쓸 AI 모델 고르는 법

모델 선정은 대개 «순위 문제»로 접근된다. 제일 좋은 모델을 찾아서 쓴다는 것. 그 틀은 예측 가능한 결과 둘을 낳는다 — 단순한 일을 하는 비싼 시스템, 아니면 아무도 시험하지 않은 방식으로 실패하는 싼 시스템.

더 나은 틀은 «구매»다. 제약이 먼저, 후보 압축이 둘째, 시험이 셋째. 제약이 일의 대부분을 하고, 그것은 모델에 대한 의견이 아니라 «우리 제품의 성질»이다.

적합성을 정하는 여섯 가지

우리 과제에서의 품질. 일반 품질이 아니다. 아름다운 산문을 쓰는 모델이 구조화 필드 추출은 못할 수 있고, 수학 추론이 좋은 모델이 분류에는 불필요하게 느릴 수 있다. 일반 순위는 «무엇을 시험할지» 고르는 선별이지 시험의 대체물이 아니다.

요청당 비용. 입력·출력 토큰으로 값이 매겨지고, 우리 실제 트래픽을 곱한다. 중요한 숫자는 «예상 물량에서의 월 지출»이고, 나중이 아니라 «먼저» 계산할 가치가 있다. 추론형 모델은 내부 숙고를 출력 토큰으로 청구하므로, 과제 하나를 끝내는 실효 비용이 표시 단가의 몇 배가 될 수 있다는 점도 함께 본다.

지연. 하나가 아니라 둘이다. 첫 토큰까지의 시간이 스트리밍 화면에서의 체감 반응성을 정한다. 총 생성 시간이 배치 작업의 처리량을 정한다. 상호작용 제품은 앞엣것을, 야간 파이프라인은 뒤엣것만 신경 쓴다.

컨텍스트 창. 실제 입력 분포의 95백분위를 잰다. 드문 최대치에 맞춰 고르는 것은, 한 달에 몇 번 쓰는 용량의 값을 «모든 요청»에서 치르는 일이다.

연동 능력. 도구 호출 안정성, 스키마 강제 출력, 스트리밍 동작, 필요하면 이미지·음성 입력. 이 항목들은 일반 품질 점수가 시사하는 것보다 모델 간 편차가 훨씬 크고, «얼마나 잘되는가»가 아니라 «되기는 하는가»를 가르는 성질인 경우가 잦다.

배포·데이터 제약. 데이터를 어디서 처리해도 되는지, 보존 조건은 어떤지, 지역 엔드포인트가 있는지, 우리 환경에서 돌릴 수 있는지. 엔지니어링 팀 밖에서 결정되는 경우가 많고, 다른 모든 성질과 무관하게 후보를 지운다.

우리 사례로 시험한다

후보가 둘셋이면 결정은 시험이 낸다. 그리고 그 시험은 정교할 필요가 없다.

우리 트래픽에서 실제 사례 50건을 뽑아 후보마다 돌리고, 평균이 아니라 «사례별»로 비교한다. 평균은 거의 아무것도 말해 주지 않는다. 흥미로운 정보는 «각 모델이 어느 사례를 틀렸는가», 그리고 «그 사례가 중요한가»다. 전체적으로는 조금 약해도 비싼 범주에서는 절대 안 틀리는 모델이 더 나은 선택이고, 어떤 총점도 그것을 말해 주지 않는다.

실무 경고 둘. 첫 회차에는 후보마다 같은 프롬프트를 쓴다 — 공정한 기준선을 위해. 그다음 결정 전에 선두 후보용으로 프롬프트를 조금 다듬는다. 모델마다 반응하는 것이 다르고, 한쪽에 맞춰 다듬은 프롬프트는 다른 쪽을 실제보다 낮게 보이게 만들기 때문이다. 그리고 지연과 비용을 같은 실행에서 함께 잰다 — 세 차원이 세 번의 실험이 아니라 한 번의 실험에서 나오게.

트래픽 대부분은 «가장 센 모델»이 필요 없다

재무적 결과가 가장 큰 관찰이고, 거의 모든 제품에서 쓸 수 있다.

실제 트래픽은 난이도가 균일하지 않다. 고객지원 비서는 많은 수의 정형 질문과 적은 수의 정말 어려운 질문에 답한다. 분류 파이프라인이 보는 것은 대부분 명백한 사례다. 그 전부를 가장 센 모델에 보내는 것은, 가장 쉬운 일에 «가장 어려운 사례의 값»을 치르는 것이다.

표준 처방은 라우팅이다. 작고 빠른 모델이 대부분을 처리하고, 확신 신호·범주·검증 실패가 «어렵다»고 알릴 때 큰 모델로 올려 보낸다. 절감은 대개 크고 — 돈이 있는 자리가 물량 많은 쪽이니까 — 필요한 사례에 대한 품질 천장은 유지된다.

라우팅에도 비용은 있다. 평가할 모델이 둘, 유지할 라우팅 규칙 하나, 그리고 «라우터가 어려운 사례를 작은 모델로 보내는» 새 실패 유형. 물량이 크면 값을 하고 어떤 문턱 아래에서는 안 한다. 그 문턱은 우리 트래픽 고유의 값이고, 계산하는 데 반나절이면 된다.

«바뀔 것»을 전제로 고르기

무엇을 고르든 대체된다. 1년 뒤의 모델은 더 싸거나 빠르거나 나을 것이고, 지금의 결정이 나중에 다시 보기 «비싼» 것이 되면 안 된다.

비용을 낮게 유지하는 습관 셋. 프롬프트·도구 정의·출력 파싱을 우리 코드에 둔다 — 업체를 바꾸는 일이 재작성이 아니라 설정 변경이 되도록. 평가셋을 유지한다 — 새 후보 평가를 «프로젝트»가 아니라 «하루짜리 작업»으로 만드는 것이 그것이다. 그리고 모델 버전을 명시적으로 고정한다 — 움직이는 별칭을 따라가지 말고. 동작 변화가 «발견되는 것»이 아니라 «일정에 넣는 것»이 되도록.

마지막 항목은 강조할 만하다. 업체의 최신 별칭을 따라가는 시스템은 모든 동작 변화를 자동으로 물려받는다 — 정성껏 다듬은 프롬프트를 깨뜨리는 변화까지. 버전을 고정하고, 새것이 나오면 평가셋을 돌리고, 의도적으로 올린다.

짧은 방법

1. 다섯 제약을 «숫자»로 적는다.
2. 그것을 만족하는 후보만 남긴다 — 대개 둘셋.
3. 실제 사례 50건을 각 후보에 돌리며 «사례별 품질 + 지연 + 비용»을 함께 잰다.
4. 선두 후보용으로 프롬프트를 다듬고 다시 돌린다.
5. 최고 점수가 아니라 통과한 것 중 가장 싼 것을 고른다.
6. 버전을 고정하고, 평가셋을 유지하고, 새것이 나오면 다시 본다.

돈이 가장 많이 절약되는 자리는 5번이고, 사람들이 건너뛰는 단계도 5번이다. «가장 센 것»을 고르는 쪽이 «충분한 것»을 고르는 쪽보다 안전하게 느껴지기 때문이다. 요청 단위로, 1년 단위로 보면 대개 그렇지 않다.