⚡ 3줄 요약
- 모델 선택의 승부처는 벤치마크 점수가 아니라 내 작업에서 쓸 데이터·비용·실행 환경이다.
- 추론은 지연시간과 처리량이 서로를 잡아먹는 트레이드오프다 — 둘을 분리해 재지 않으면 최적화가 헛돈다.
- 배포에서 진짜 사고를 내는 건 모델이 아니라 fallback·관측성·롤백 같은 운영 설계다.
모델 도입의 승패는 리더보드 순위가 아니라, 내 작업의 데이터·비용·실행 환경에서 갈린다. AI 모델을 고를 때 다들 리더보드 1위부터 본다. 그런데 리더보드 최상단 모델을 그대로 붙였다가 청구서를 보고 후회하는 일이 훨씬 흔하다. 벤치마크 점수는 “이 모델이 어떤 시험을 잘 봤다”는 기록일 뿐, “내 서비스에서 싸고 빠르게 돌아간다”는 보장이 아니다. 이 분야는 모델 이름이 아니라 모델 선택 → 추론 최적화 → 배포·운영 → 비용이라는 네 개의 층으로 움직인다. 이 글은 그 지도를 그린다.
모델 선택 — 매개변수 수는 답이 아니다
가장 먼저 버려야 할 습관이 “파라미터 큰 게 좋은 모델”이라는 감각이다. 매개변수 수는 능력의 상한을 시사할 뿐, 내 업무에서의 실제 유용성과 직결되지 않는다. 봐야 할 건 세 가지다.
- 평가 범위 — 그 모델이 성능을 낸 벤치마크가 내 작업과 닮았나. 수학·코딩 벤치마크 1등이 고객 상담 요약도 1등이라는 법은 없다.
- 학습·정렬 방식 — 무슨 데이터로, 어떤 목적에 맞춰 다듬어졌나. 같은 크기라도 정렬(alignment) 방향이 다르면 결과 성격이 완전히 달라진다.
- 실행 조건 — API로만 쓸 것인가, 직접 서빙할 것인가. 라이선스, 가중치 공개 여부, 컨텍스트 길이가 여기서 갈린다.
특정 벤치마크의 우위는 특정 시험지에서의 우위일 뿐이다. 이 사실 하나만 붙잡아도 과대광고에 휘둘리는 일이 크게 준다.
추론 최적화 — 지연시간과 처리량은 한 몸이 아니다
추론(inference) 최적화에서 사람들이 가장 자주 뒤섞는 두 지표가 지연시간(latency)과 처리량(throughput)이다. 지연시간은 “한 요청이 답을 받기까지 걸리는 시간”, 처리량은 “단위 시간에 처리하는 요청 수”다. 문제는 이 둘이 대개 반대로 움직인다는 점이다.
대표적인 게 배칭(batching)이다. 여러 요청을 묶어 GPU에 한꺼번에 태우면 처리량은 크게 오른다. 하지만 묶이길 기다리는 개별 요청 입장에선 지연시간이 늘어난다. 그래서 “빨라졌다/느려졌다”를 뭉뚱그리면 안 된다. 사용자가 답을 기다리는 대화형 서비스라면 지연시간을, 대량 배치 처리라면 처리량을 우선에 둬야 한다.
⚠️ 가장 흔한 함정
“비용부터 줄이자”며 양자화·배칭을 한꺼번에 켜는 것. 지연시간과 처리량을 분리해서 측정하지 않으면, 어느 최적화가 효과를 냈고 어느 게 사용자 경험을 망쳤는지 영영 모른다. 최적화는 하나씩 켜고 하나씩 재는 것이다.
추론 층에서 알아둘 개념 지도는 이렇다. 각각이 건드리는 병목이 다르다.
| 기법 | 주로 줄이는 것 | 대가로 감수하는 것 |
|---|---|---|
| 배칭 | 처리량 (GPU 활용률↑) | 개별 요청 지연시간↑ |
| 양자화(quantization) | 메모리·연산 비용 | 미세한 정확도 손실 |
| KV캐시 관리 | 긴 문맥에서의 메모리 | 캐시 관리 복잡도 |
| 프롬프트 캐싱 | 반복 입력의 지연·비용 | 캐시 무효화 설계 부담 |
긴 문맥을 다룰수록 KV캐시가 GPU 메모리를 잡아먹어 병목이 된다. 그래서 “컨텍스트를 얼마나 길게 넣느냐”는 기능 문제가 아니라 비용·메모리 문제다. 문맥 창이 크다고 무턱대고 다 채우면 그대로 청구서에 찍힌다.
이미지·비디오 모델 — 품질만 보면 배포에서 터진다
생성 모델을 고를 때 샘플 이미지의 화질만 비교하는 건 절반짜리 판단이다. 실무에선 다른 축이 발목을 잡는다.
- 입력 구조 — 텍스트만 받나, 참조 이미지·마스크·컨트롤 신호까지 받나.
- 편집 가능성 — 한 번 뽑고 끝인가, 부분 수정·반복 편집이 되나. 실서비스에선 이게 품질보다 중요할 때가 많다.
- 메모리·인코딩 — 특히 비디오는 프레임 수만큼 메모리와 인코딩 부담이 곱해진다. 데모는 되는데 배포는 안 되는 전형적 지점이다.
배포·운영 — 사고는 모델이 아니라 여기서 난다
모델을 잘 골라도 운영 설계가 부실하면 서비스는 무너진다. 배포 전 반드시 손에 쥐고 있어야 할 목록은 이렇다.
| 확인 항목 | 왜 중요한가 |
|---|---|
| GPU·CPU 환경 | 모델이 실제 하드웨어에서 메모리 안에 올라가는지 |
| fallback 경로 | 모델·API가 죽었을 때 사용자에게 뭘 보여줄지 |
| 관측성(observability) | 지연·비용·오류를 실시간으로 볼 수 있는지 |
| 캐시 전략 | 같은 요청을 매번 새로 계산하지 않는지 |
| 롤백 | 새 모델이 이상하면 즉시 이전으로 되돌리는지 |
| 데이터 보호 경계 | 민감 데이터가 외부 API로 새지 않는지 |
이 목록에서 가장 자주 빠지는 게 fallback과 롤백이다. 잘 될 때만 상정하고 배포하면, 모델 하나 흔들릴 때 서비스 전체가 같이 흔들린다.
🎯 FEEDON의 선택 — 우리라면 이렇게 한다
우리라면 큰 모델부터 지르지 않는다. 작고 싼 모델로 먼저 파이프라인 전체를 세우고, 지연·비용·품질을 실제 트래픽으로 잰다. 그다음 병목이 잡히는 지점에서만 더 큰 모델이나 최적화를 얹는다.
순서는 늘 같다 — 내 작업에 맞는 평가 → 작은 모델로 측정 → 병목에 맞춘 최적화 → fallback·롤백까지 갖춘 배포. 리더보드 1위에서 거꾸로 내려오지 말고, 내 요구에서 올라가라. 위에서 내려오면 정작 뭘 필요로 했는지 끝까지 모른다.
고르는 순서 — 4단계 체크리스트
- 내 작업과 닮은 평가 기준이 있는 모델을 후보로 추린다 (벤치마크 1위가 아니라).
- 가장 작고 싼 후보로 파이프라인을 먼저 완성하고 지연·비용·품질을 잰다.
- 병목이 지연인지 처리량인지 비용인지 분리해 확인하고, 거기에 맞는 최적화만 켠다.
- 배포 전 fallback·관측성·롤백·데이터 경계를 점검한다. 이게 없으면 아직 배포 준비가 안 된 것이다.
가격·사양·모델 성능은 빠르게 바뀔 수 있으며, 도입 전 공식 자료로 재확인이 필요하다.
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.
