LLM 제공사의 API 기반 서비스나 클라우드 제공사의 서버리스 관리형 AI 서비스는 개발자가 생성형 AI 애플리케이션을 시작할 때, 선택할 수 있는 가장 간단한 방법입니다. GPU를 직접 준비하거나 모델을 설치할 필요 없이 API를 연결하면 되고, 모델 업데이트와 추론 환경도 제공사가 관리하기 때문이죠.

그러나 모든 기업과 개발팀이 AI를 이런 방식으로 사용할 수 있는 것은 아닙니다. 보안 요구가 높은 환경에서는 인터넷과 분리된 폐쇄망에서 AI를 운영해야 할 수 있고, 사용량이 많아지면 API 비용도 부담이 될 수 있습니다. 토큰 단위로 API 비용을 계속 지불하는 것이 나을지, GPU를 직접 운영하며 *오픈 웨이트(Open Weight) 모델을 직접 구동하는 것이 나을지 고민하는 개발팀도 많습니다.

*오픈 웨이트(Open Weight):인공지능 모델이 학습을 통해 얻은 가중치(Weights)와 편향(Biases) 등 매개변수 파일을 외부에 공개하여, 누구나 다운로드하고 활용할 수 있도록 제공하는 방식

하지만 이 선택은 모델의 공개 벤치마크 점수만으로 판단하기 어렵습니다. 그래서 여러 오픈 웨이트 모델을 직접 GPU 인스턴스에 배포하고, 조건을 하나씩 바꿔가며 성능을 측정했습니다. 테스트하면서 제가 궁금했던 건 단순했습니다. “모델이 크면 더 느릴까? GPU를 많이 쓰면 더 빨라질까? 같은 모델이라도 실행 방식을 바꾸면 얼마나 달라질까?” 그런데 실제 결과는 예상보다 훨씬 복잡했습니다.

테스트의 전제

이번 테스트의 목적은 특정 서비스 환경에서 최대 성능을 끌어내는 것이 아니라, 같은 GPU 환경에서 LLM 자체의 추론 특성을 비교하는 것이었습니다. 따라서 특정 모델에만 유리하게 작용할 수 있는 추가적인 튜닝은 최대한 배제했습니다.

또 동일한 GPU와 추론 환경을 기준으로 모델을 비교하고, GPU 수나 실행 정밀도처럼 성능에 영향을 주는 요소를 확인할 때는 한 번에 하나의 조건만 변경했습니다. 실제 서비스에서는 캐싱, 배칭, 추론 엔진 튜닝 등 여러 최적화를 추가할 수 있지만, 이번 테스트에서는 이런 요소가 모델 간 비교 결과에 섞이지 않도록 하는 데 초점을 맞췄습니다.

같은 환경에서 모델 자체를 비교하기

테스트 환경에서 중요한 GPU는 엔비디아 RTX PRO 6000 Blackwell Server Edition GPU 4장이 장착된 클라우드 인스턴스를 사용했습니다. GPU 한 장당 메모리는 96GB이며, 서버 전체에는 총 384GB의 물리 GPU 메모리가 있습니다. 인스턴스 비용은 시간당 12달러입니다.

추론 엔진은 vLLM으로 최대한 통일했습니다. 주요 테스트 대상은 gpt-oss-20b, gpt-oss-120b, Qwen3.8-27B, Gemma4:31b, Mistral-Small-4-119B였습니다. GLM-5.3-Flash와 Kimi-K3도 후보에 넣었지만, 이 두 모델은 뒤에서 설명할 호환성과 메모리 문제 때문에 동일한 조건의 성능 테스트까지 진행하지 못했습니다.

테스트도 한꺼번에 여러 조건을 바꾸지 않았습니다. 처음에는 GPU 한 장만 사용하고 모델만 바꿨습니다. 그다음 동시 요청 수를 늘렸습니다. 이후에는 모델과 요청 조건을 고정한 채 GPU 수를 1장, 2장, 4장으로 바꿨습니다. 마지막으로 같은 모델의 실행 정밀도를 바꿔봤습니다.

측정 지표는 크게 두 가지입니다. 초당 토큰 수(Tokens Per Second, TPS)는 모델이 얼마나 많은 출력 토큰을 만들어내는지를 보여줍니다. 첫 토큰 응답 시간(Time To First Token, TTFT)은 요청을 보낸 뒤 첫 번째 답변이 나타날 때까지 걸리는 시간입니다. TPS가 서버의 처리 능력이라면 TTFT는 사용자가 느끼는 기다림에 가깝다고 보면 됩니다.

테스트에서는 GPU와 추론 엔진뿐 아니라 입력 조건도 통제하려고 했습니다. LLM은 같은 모델이라도 질문의 길이와 생성하는 답변의 길이, 동시에 들어오는 요청 수에 따라 성능이 크게 달라지기 때문입니다.

테스트는 일반 질의, 한국어, 코딩, 추론, 요약, 긴 문맥 RAG 등 실제 기업에서 사용할 만한 워크로드를 기준으로 설계했습니다.

오픈 웨이트 모델 테스트 환경 표: GPU RTX PRO 6000 Blackwell 4장(총 384GB), 추론 엔진 vLLM, 비교 모델은 gpt-oss-20b·120b·Qwen3.8-27B·Gemma4 31B·Mistral-Small-4-119B 등, 측정값은 출력 TPS·P95 첫 토큰 응답 시간·오류율·토큰 비용

첫 번째 테스트에서 모델별 초당 출력 토큰을 측정했습니다

가장 먼저 GPU 한 장을 사용하는 TP=1 환경에서 모델만 바꿔봤습니다. 단일 요청을 보냈을 때 gpt-oss-20b는 약 250 tokens/s, gpt-oss-120b는 약 184 tokens/s를 기록했습니다. 반면 Qwen3.8-27B는 약 26 tokens/s, Gemma4:31b는 약 23 tokens/s였습니다.

모델별 초당 출력 토큰 막대그래프: gpt-oss-20b가 가장 높고 Qwen3.8-27B와 Gemma4:31b가 가장 낮음 — 모델별 초당 출력 토큰 <출처: 작가, Matplotlib으로 생성>

여기서 예상과 다른 결과가 나왔습니다.

“120B 급인 gpt-oss-120b가 27B인 Qwen3.8-27B보다 훨씬 빨랐습니다”

보통 모델 이름에 표시된 파라미터 수만 보면 120B 모델이 27B 모델보다 훨씬 무겁고 느릴 것이라고 생각하기 쉽습니다. 하지만 실제 추론 성능은 그렇게 단순하게 결정되지 않았습니다. 이 차이를 이해하려면 모델 구조를 볼 필요가 있습니다. Qwen3.8-27B와 이번에 테스트한 Gemma4:31b는 대부분의 파라미터가 계산에 참여하는 Dense 모델입니다.

반면 gpt-oss는 여러 전문가 가운데 일부만 선택해서 사용하는 전문가 혼합(Mixture of Experts, MoE) 구조입니다. 예를 들어 gpt-oss-120b는 전체 약 117B 파라미터를 가지고 있지만 토큰 하나를 처리할 때 활성화되는 파라미터는 약 5.1B입니다. 다만 활성 파라미터 수가 적다고 해서 전체 모델을 저장하는 데 필요한 메모리까지 작아지는 것은 아닙니다. 모델 전체 가중치는 GPU 메모리에 올라가야 하기 때문에, MoE에서는 ‘실행 계산량’과 ‘모델을 올리는 데 필요한 메모리’를 구분해서 봐야 합니다.

여기에 MXFP4와 같은 실행 형식과 추론 최적화도 영향을 줍니다. 또한 두 모델은 실행 정밀도도 다르기 때문에 이번 결과를 MoE와 Dense 구조의 차이만으로 설명할 수는 없습니다. 물론 이 결과만으로 “MoE가 Dense보다 빠르다”라고 일반화할 수는 없습니다. 다만 모델 이름에 붙은 전체 파라미터 수만 보고 필요한 GPU나 추론 속도를 예상해서는 안 된다는 점은 분명했습니다. 즉, 두 모델은 실행 정밀도도 다르기 때문에 이번 결과를 MoE와 Dense 구조의 차이만으로는 설명할 수 없습니다.

사용자가 늘어나면 차이가 더 커졌습니다

다음에는 모델과 GPU를 그대로 두고, 동시 사용자를 시뮬레이션하기 위해 동시 요청 수만 늘렸습니다. 이 테스트가 필요한 이유는 단일 사용자에게 빠른 모델과 여러 사용자를 동시에 처리할 때 효율적인 모델이 반드시 같지는 않기 때문입니다. 개인용 AI라면 한 명이 얼마나 빠르게 답을 받느냐가 중요하지만, 수십 명이 사용하는 사내 챗봇이나 AI API라면 서버 전체가 동시에 얼마나 많은 요청을 처리할 수 있는지도 중요합니다.

동시 요청을 32개까지 늘렸을 때 gpt-oss-120b는 전체 약 845 tokens/s, Qwen3.8-27B는 약 369 tokens/s를 기록했습니다. 단일 요청에서 나타났던 차이가 동시 요청이 늘어난 환경에서도 이어졌습니다.

동시 요청 수 증가에 따른 모델별 처리량 꺾은선그래프: gpt-oss-20b·120b가 상위권, Qwen3.8-27B·Gemma4:31b는 완만하게 증가 — 동시 요청 수 증가에 따른 모델별 전체 처리량 <출처: 작가, Matplotlib으로 생성>

여기까지 테스트하면서 첫 번째 기준이 생겼습니다. 모델의 크기로 성능을 예상하기보다 실제 사용할 모델과 GPU, 추론 엔진을 묶어서 측정해야 합니다.

모델은 그대로 두고 GPU 수를 늘렸다

GPU 1장, 2장, 4장을 차례로 비교했습니다

모델별 차이를 확인했으니, 다음에는 GPU 수를 바꿔봤습니다. 이번에는 gpt-oss-20b와 동시 요청 16개라는 조건을 고정했습니다. 바꾼 것은 하나의 모델을 몇 개의 GPU에 나눠 실행하느냐뿐입니다.

GPU 한 장을 사용하는 TP1에서는 약 1,248 tokens/s가 나왔습니다. GPU를 두 장으로 늘린 TP2에서는 약 1,749 tokens/s까지 올라갔습니다. 여기까지는 예상한 결과였습니다. 그런데 GPU를 네 장으로 늘리자 약 1,584 tokens/s로 오히려 떨어졌습니다. 즉, GPU 2장은 1장보다 약 40% 빨랐지만 GPU 4장은 2장보다 약 9% 느렸습니다.

gpt-oss-20b의 GPU 수별 처리량 막대그래프: TP1 1,248, TP2 1,749, TP4 1,584 tokens/s로 4장에서 오히려 감소 — gpt-oss-20b의 GPU 수에 따른 처리량 변화 <출처: 작가, Matplotlib으로 생성>

처음에는 GPU가 많아지면, 당연히 처리량도 계속 증가할 것으로 생각할 수 있습니다. 하지만 하나의 모델을 여러 GPU에 나누는 텐서 병렬화(Tensor Parallelism)에서는 GPU가 계산만 하는 것이 아닙니다. 서로 계산 결과를 주고받고 동기화하는 작업도 필요합니다.

이번 서버의 GPU 토폴로지도 확인했습니다. 네 GPU는 같은 NUMA 영역에 있었고 GPU 간 P2P 읽기와 쓰기도 정상적으로 지원했습니다. 다만 GPU끼리 연결되는 경로는 모두 PCIe Host Bridge를 거치는 PHB 구조였습니다. 이 결과만으로 PCIe가 TP4 성능 저하의 원인이라고 단정할 수는 없습니다. 하지만 GPU가 늘어나면서 증가한 통신과 동기화 비용이 추가 GPU에서 얻는 계산 이점을 일부 상쇄했을 가능성은 있습니다.

그래서 GPU 서버를 볼 때는 GPU 개수만 확인해서는 부족합니다. NVLink나 NVSwitch처럼 GPU 간 통신 대역폭이 높은 시스템에서는 여러 GPU에 하나의 모델을 분산하는 방식의 통신 부담을 줄이는 데 유리합니다. 반대로 PCIe 기반 서버에서 모델 하나가 GPU 한 장에 충분히 들어간다면 하나의 모델을 네 GPU에 나누는 것보다 각 GPU에 모델을 하나씩 실행하고 요청을 분산하는 방식이 더 효율적일 수도 있습니다.

결국 질문도 바뀌었습니다. “GPU가 몇 장 필요한가?”보다 “이 모델을 GPU 몇 장에 나누는 것이 좋은가?”가 더 정확한 질문이었습니다.

같은 모델도 FP8로 실행하니 달라졌습니다

GPU 수 다음에는 실행 정밀도를 바꿨습니다. 이번에는 Qwen3.8-27B의 원본 BF16 체크포인트와 FP8 양자화 체크포인트를 같은 GPU와 동시 요청 8개 조건에서 비교했습니다. BF16에서는 약 180 tokens/s, FP8에서는 약 271 tokens/s를 기록했습니다. 이번 테스트 환경에서는 FP8이 BF16보다 약 51% 높은 처리량을 보였습니다.

Qwen3.8-27B의 BF16과 FP8 처리량 비교 막대그래프: BF16 180, FP8 271 tokens/s — Qwen3.8-27B 기본 구성(BF16)과 FP8 구성의 처리량 비교 <출처: 작가, Matplotlib으로 생성>

BF16은 하나의 값을 16비트로 표현하지만 FP8은 8비트를 사용합니다. 따라서 FP8 양자화를 적용하면 모델 가중치의 메모리 사용량과 메모리 대역폭 부담을 줄일 수 있고, FP8 연산을 지원하는 GPU에서는 추론 처리량을 높일 수 있습니다. 다만 모든 연산이 반드시 FP8로 수행되는 것은 아니며, 실제 성능 향상은 모델의 양자화 방식과 GPU, 추론 엔진의 FP8 지원 방식에 따라 달라집니다. 하지만 이 방식이 무조건 좋은 것은 아닙니다. 모델 품질이 달라질 수도 있고, GPU와 추론 엔진이 해당 형식을 얼마나 잘 지원하느냐에 따라서도 결과가 달라집니다. 따라서 이 결과 역시 “FP8을 사용하면 항상 51% 빨라진다”라는 의미는 아닙니다.

여기서 확인한 것은 같은 모델과 같은 GPU라도 어떤 정밀도로 실행하느냐에 따라 성능이 크게 달라질 수 있다는 사실입니다.

빠르게 실행되는 것만으로는 충분하지 않았다

모델은 실행됐지만 첫 응답까지 15초가 걸렸습니다

여기까지는 주로 TPS를 봤습니다. 하지만 실제 챗봇을 운영한다면 처리량만큼 중요한 숫자가 TTFT입니다. 사용자는 AI가 답변 전체를 얼마나 빨리 완성하는지만 보는 것이 아니라 답변을 언제 시작하는지도 체감하기 때문입니다.

Mistral-Small-4-119B는 GPU 네 장을 사용한 TP4 환경에서 정상적으로 실행됐습니다. 하지만 동시 요청 8개에서 P95 TTFT가 약 15.8초였습니다. 즉 일부 요청에서는 첫 글자가 화면에 나타날 때까지 15초 이상 기다릴 수 있다는 의미입니다.

모델별 P95 첫 토큰 응답 시간 막대그래프: Mistral-Small-4-119B-2603만 15,840ms로 압도적으로 높고 나머지는 400~700ms대 — 동시 요청 8개에서 모델별 P95 첫 토큰 응답 시간 <출처: 작가, Matplotlib으로 생성>

그렇다고 이 모델을 사용할 수 없다는 뜻은 아닙니다. 대량 문서를 밤새 처리하는 배치 작업이라면 첫 응답이 조금 늦더라도 전체 처리량이 더 중요할 수 있습니다. 반대로 고객 상담이나 사내 챗봇에서는 15초의 첫 응답 시간이 큰 문제가 될 수 있습니다.

그래서 모델의 TPS를 보기 전에 서비스의 목표를 정해야 합니다. 예를 들어, 대화형 서비스라면 ‘P95 TTFT 2초 이내’와 같은 서비스 수준 목표(SLO)를 먼저 정하고, 그 조건을 만족하는 범위에서 처리량을 비교하는 편이 훨씬 현실적입니다.

GPU 메모리가 충분해도 모델이 실행되지 않았습니다

또 하나 예상하지 못했던 문제는 소프트웨어 호환성이었습니다. GLM-5.3-Flash를 실행했을 때 처음 사용한 vLLM과 Transformers 조합에서는 모델 구조를 제대로 인식하지 못했습니다. Transformers를 업데이트해 다시 시도했지만 이번에는 기존 Gemma 실행 환경에 문제가 생겼습니다. GPU 수를 바꿔가며 시도했지만, 이번 테스트 환경에서는 다른 모델과 동일한 조건의 벤치마크까지 진행하지 못했습니다.

중요한 것은 이것을 “GLM은 vLLM에서 실행되지 않는다”라고 해석하면 안 된다는 점입니다. 공식 지원 여부와 별개로 우리가 사용한 정확한 버전 조합에서 바로 동작하지 않았다는 것이 이번 테스트에서 확인한 사실입니다. 직접 LLM을 운영하면 이런 문제가 생각보다 중요합니다. GPU만 확보하면 끝나는 것이 아니라 엔비디아 드라이버, CUDA, vLLM, Transformers와 모델 코드의 버전을 함께 관리해야 합니다. 여러 모델을 운영한다면 모델별로 검증된 컨테이너 이미지를 만들고 버전을 고정하는 이유도 여기에 있습니다.

너무 큰 모델은 실행하기 전에 걸러냈습니다

Kimi-K3는 아예 서버를 실행하기 전에 사전 검사 단계에서 중단했습니다. 확인한 모델 체크포인트의 크기가 약 1.56TB였습니다. 물론 체크포인트 파일 크기와 실제 추론 시 필요한 GPU 메모리가 정확히 일치하는 것은 아니지만 차이가 너무 컸기 때문에 현재 구성에서 그대로 실행하는 것은 현실적이지 않다고 판단했습니다. 클라우드 GPU에서는 이런 사전 검사가 곧 비용 절감입니다. 수백 GB의 모델을 내려받고 GPU 서버를 몇 시간씩 사용한 뒤 메모리 부족을 확인하는 것보다, 모델의 크기와 데이터 형식, 예상 메모리를 먼저 확인해 실행 가능성이 낮은 구성을 걸러내는 편이 낫습니다.

결국 ‘가장 빠른 모델’을 찾는 테스트가 아니었다

토큰 생성 속도를 비용으로 바꿔봤습니다

모델을 실제 서비스에 사용할 수 있다는 판단이 서면, 그다음에 비용을 볼 수 있습니다. 이번 테스트에서는 달러당 출력 토큰 수(Tokens per Dollar)를 사용했습니다.

Tokens/$ = Output TPS × 3,600 ÷ 시간당 서버 비용

이번 서버는 시간당 12달러이므로 Output TPS에 300을 곱하면 대략적인 Tokens/$가 됩니다. 예를 들어, gpt-oss-20b는 GPU 한 장, 동시 요청 32개 조건에서 약 1,688 output tokens/s를 기록했습니다. 이를 서버 전체 가격인 시간당 12달러로 계산하면 1달러당 약 50만 개의 출력 토큰, 100만 출력 토큰당 약 1.97달러입니다.

이 계산은 GPU 한 장을 사용한 처리량에 전체 인스턴스 비용을 적용한 보수적인 단순 계산입니다. 실제 서비스에서는 나머지 GPU를 다른 모델 복제본이나 다른 요청 처리에 활용할 수 있으므로 실제 서버 전체의 Tokens/$는 달라질 수 있습니다.

모델별 달러당 생산 토큰 막대그래프: gpt-oss-20b·120b가 가장 높고 Qwen·Gemma·Mistral 계열은 크게 낮음 — <출처: 작가, 테스트 조건에서 계산한 모델별 달러 당 생산 토큰 - Matplotlib으로 생성>

여기에는 중요한 조건이 있습니다. 실제로는 GPU 한 장만 사용했지만, 비용 계산에는 GPU 네 장이 포함된 서버 전체 가격을 넣었습니다. 따라서 나머지 GPU 세 장까지 모델 복제본을 배치해 사용한다면, 서버 전체의 경제성은 달라질 수 있습니다. 반대로 자체 LLM에는 GPU 비용 외에도 저장 공간, 모니터링, 보안, 장애 대응과 엔지니어링 비용이 들어갑니다. 그래서 이 숫자를 상용 AI API 가격과 바로 비교해 어느 쪽이 싸다고 결론 내리기는 어렵습니다.

품질 → 서비스 속도 → 비용 순서로 봐야 합니다

테스트에서는 모든 모델의 업무 품질을 동일한 데이터 셋으로 평가하지 않았습니다. 따라서 gpt-oss-20b의 처리량이 가장 높았다고 해서 이 모델이 모든 업무에서 가장 좋다고 결론 내릴 수 없습니다. 실제 기업에서 모델을 고른다면 순서를 반대로 잡는 편이 낫습니다.

먼저 업무 품질을 만족하는지 확인합니다. 그다음 서비스가 요구하는 TTFT와 처리량을 만족하는지 확인합니다. 마지막으로 이 두 조건을 통과한 모델끼리 비용을 비교합니다. 예를 들어 저렴한 모델의 정확도가 업무에 필요한 수준보다 낮다면 높은 Tokens/$는 의미가 없습니다. 반대로 두 모델 모두 필요한 품질과 P95 TTFT를 만족한다면 그때는 1달러로 더 많은 요청을 처리하는 모델이 경제적인 선택이 됩니다.

이번 벤치마크를 진행하면서 가장 크게 바뀐 생각도 이 부분입니다. 처음에는 TPS → TTFT → 비용을 비교하면 모델을 고를 수 있을 것이라고 생각했습니다. 실제로 테스트해 보니 품질 → SLO → 비용 순서가 더 현실적이었습니다.

상용 AI와 오픈 웨이트도 같은 기준으로 볼 수 있을까?

여러 오픈 웨이트 모델을 직접 설치하고 테스트를 하면서 역설적으로 상용 AI 서비스의 장점도 더 분명하게 보였습니다. GPT, Claude, Gemini 같은 서비스를 사용하면 앞에서 경험한 GPU 메모리 계산이나 모델별 라이브러리 호환성, GPU 간 통신 방식 등을 대부분 고민하지 않아도 됩니다. API를 호출하면 되고 새로운 모델이 등장하더라도 기업이 직접 GPU 환경을 다시 설계할 필요가 없습니다.

그럼에도 기업이 오픈 웨이트 모델을 검토하는 이유는 분명합니다. 대표적인 것이 데이터 통제입니다. 기업 내부에는 소스코드와 설계 문서, 계약서, 연구 자료, 고객 정보처럼 외부 AI 서비스로 전달하기 어려운 데이터가 존재합니다. 특정 산업에서는 데이터가 어디에서 처리되는지, 누가 접근할 수 있는지, 어떤 모델 버전이 사용됐는지까지 조직이 직접 관리해야 할 수도 있습니다. 외부 인터넷과 연결되지 않은 폐쇄망에서는 오픈 웨이트 모델이 단순히 API 비용을 절감하는 방법이 아니라 해당 환경에서 생성형 AI를 사용할 수 있게 만드는 방법 자체가 될 수 있습니다.

결국 기업에서는 둘 중 하나를 고르는 것보다 함께 사용하는 방식이 더 현실적일 수 있습니다. 일반적인 반복 업무는 비용 효율이 높은 오픈 웨이트 모델로 처리하고, 외부 반출이 어려운 데이터는 기업이 통제하는 프라이빗 LLM으로 보냅니다. 높은 수준의 추론이 필요한 요청은 정책이 허용하는 범위에서 GPT · Claude · Gemini 같은 상용 모델로 전달할 수 있습니다. AI 게이트웨이가 요청의 성격에 따라 이런 경로를 선택하는 구조입니다.

마치며: 가장 좋은 것보다 우리에게 맞는 모델을 찾는 과정

이번 테스트에서는 기대했던 결과만큼이나 부정적인 결과도 많이 나왔습니다. 물론 진행한 테스트 방법이나 도구가 올바르지 않았을 가능성도 있습니다. 또 GPU를 늘렸는데 성능이 떨어졌고, 정상적으로 실행했지만 첫 응답이 너무 느린 모델도 있었죠. 소프트웨어 호환성 때문에 벤치마크 자체를 시작하지 못한 모델도 있었고요. 처음에는 이런 결과를 실패한 실험이라고 생각하기 쉽지만, 실제 개발 환경에서는 오히려 이런 데이터가 더 중요한 판단 근거가 됩니다.

테스트 결과 해석 표: 모델 속도 저하는 파라미터 수만으로 판단하기 어려움, GPU 4장 저하는 통신 비용 증가, FP8 처리량 증가는 정밀도 영향, TTFT 15.8초는 실행 가능성과 서비스 가능성의 차이, GLM 호환성 실패는 관리 비용 존재, Kimi 중단은 GPU와 모델 규모 불일치를 보여줌

그래서 개발자가 오픈 웨이트 모델을 검토한다면, 공개 벤치마크에서 가장 높은 점수를 받은 모델부터 찾기보단 AI 업무에서 필요한 품질을 만족하는지, 서비스가 요구하는 응답 속도를 지키는지, 그리고 그 모든 조건에서 비용이 합리적인가를 차례대로 확인하는 편이 좋습니다.

새로운 모델이 나올 때마다 순위표를 그저 따라가지 않고, 같은 조건에서 모델을 직접 검증하고 다시 비교할 수 있는 환경을 갖춘다면, 더 오래가는 AI 모델 선택의 기준이 되지 않을까 싶습니다.