KT 믿:음 K 2.5 Pro 32B: Qwen을 직접 운영하는 것보다 무엇이 나을까

KT가 2026년 8월 19일 내놓은 KT NPU LLM 스테이션은 리벨리온의 ATOM-Max NPU, 자체 LLM인 믿:음 K 2.5 Pro, 운영 API 플랫폼을 한 서버형 제품으로 묶었다. 이름에 ‘소버린 AI’가 붙지만 구매 담당자가 먼저 던져야 할 질문은 원산지가 아니다. 32B 모델은 양자화하면 고사양 Mac이나 GPU 워크스테이션에서도 돌아가는데 기업이 왜 별도 NPU 장비를 사야 하는가, 그리고 그 장비가 Qwen 같은 오픈웨이트 모델을 직접 운영하는 것보다 실제로 비용과 운영 위험을 줄여 주는가다. 제품 구성은 공식 발표로 확인되지만 가격과 운영 처리량은 아직 구매 판단에 필요한 만큼 공개되지 않았다. 출처: KT, 기업용 소버린 AI 제품 출시, KT, 국산 NPU·LLM 일체형 플랫폼으로 기업 AX 정조준

이 글은 ‘국산이니까 선택한다’는 논리를 쓰지 않는다. 기업용 LLM 구축은 모델 파일을 내려받아 실행하는 일이 아니라 지식 접근권한, 프롬프트와 응답 로그, 문서 갱신, API 인증, 성능 격리, 장애 복구를 함께 운영하는 일이다. 비교 단위도 ‘믿:음 K 대 Qwen’ 하나가 아니라 모델과 가속기, 서빙 소프트웨어, 통합 책임, 보안 통제, 3년 운영비를 합친 서비스여야 한다.

모델, 장비, 운영을 먼저 떼어 놓고 보자

믿:음 K 2.5 Pro는 320억 파라미터 규모의 Dense 모델이고 컨텍스트 길이는 128K 토큰이다. KT는 업무 자동화·고객 응대·내부 업무에 쓰는 B2B 중심 모델로 설명한다. 믿:음 2.0 계열에서 Base와 Mini는 가중치가 공개됐지만, 2.5 Pro의 가중치가 공개 저장소에 배포됐다는 근거는 확인되지 않는다. 직접 가중치를 받아 원하는 추론 엔진에 올려 보는 오픈웨이트 모델과는 평가·변경·이전 방식이 다를 수 있다는 뜻이다. 출처: Mi:dm K 2.5 Pro 기술보고서, KT Enterprise 믿:음 K 제품 페이지

KT NPU LLM 스테이션은 그 모델에 ATOM-Max와 운영 API 플랫폼을 결합한 완제품이다. 구매자가 실제로 사는 것은 NPU 자체보다 검증할 대상과 연락할 창구가 줄어든다는 조건이다. 자체 구축이라면 가속기 조달, 드라이버와 런타임, 모델 변환, 서빙 엔진, 관측성, 보안 패치, 장애 분석을 각각 맞춰야 한다. 일체형은 적어도 특정 모델·특정 가속기·특정 API 경로의 호환성을 공급사 쪽이 맡는다.

다만 이 장점은 계약서에 적혀야 실체가 생긴다. 지원 모델 버전, API 호환 범위, 임베딩·재순위화 모델 포함 여부, 취약점 패치 주체, 원격 지원의 네트워크 경로, 장애 시 교체 기준이 빠져 있으면 일체형은 설치 편의에 그친다. 반대로 Qwen 직접 운영은 그 통합 부담을 지는 대신 모델 교체, 양자화 방식, 인프라 선택, 서빙 엔진의 통제권을 갖는다.

‘국내에서 처리한다’와 ‘안전하다’도 같은 말이 아니다. 사내에 설치해도 문서 권한을 무시한 RAG 검색, 과도한 관리자 권한, 외부 도구 호출, 평문 로그, 탈취된 API 키는 그대로 유출 경로가 된다. 반대로 외부 클라우드도 계약과 리전, 접근 통제, 보존 정책에 따라 위험을 줄일 수 있다. 온프레미스의 가치는 보안이 자동으로 완성된다는 데 있지 않고, 네트워크와 데이터 경계를 조직이 직접 설계하고 감사할 수 있다는 데 있다.

KT 기술보고서가 제시한 동급 모델 성능 비교

KT는 2026년 3월 믿:음 K 2.5 Pro 기술보고서를 arXiv에 공개하면서 같은 평가 조건으로 돌린 비교표를 함께 실었다. 비교 대상은 아래와 같다. 보고서에는 Solar-Open-100B(MoE, 활성 12B)와 K-EXAONE-236B-A23B(MoE, 활성 23B)도 함께 실려 있지만, 여기서는 32B 안팎의 동급 후보만 추렸다.

Qwen3-30B-A3B만 MoE라는 점을 먼저 짚어야 한다. MoE는 전체 가중치를 모두 메모리에 올려 두되 토큰 하나를 만들 때는 일부 전문가 블록만 계산한다. Qwen3-30B-A3B는 128개 전문가 중 8개를 쓰고, 전체 30.5B 가운데 활성 파라미터는 3.3B다. 그래서 메모리 요구량은 30B급이지만 토큰당 연산량은 3B급에 가깝다. 32B Dense 모델과 파라미터 수만 놓고 ‘32B 대 30B’로 비교하면 필요한 메모리도 추론 비용도 함께 오해하게 된다.

영어·코딩·에이전트 평가

한국어 평가

두 표 모두 KT가 자체적으로 작성한 기술보고서(2026년 3월, arXiv)의 값이며, 세 모델 모두 추론(사고) 모드를 켠 조건에서 측정한 결과다. 굵은 글씨는 세 모델 중 최고값이다. †는 KT가 직접 돌린 값이 아니라 Artificial Analysis의 공개 결과를 인용한 항목이고, ‡는 KT가 자체 개발해 외부에 공개하지 않은 한국어 평가셋(Ko-Sovereign)이다. 독립 기관의 제3자 평가와 같은 성격으로 취급할 수 없다. 출처: Mi:dm K 2.5 Pro 기술보고서(arXiv:2603.18788)

표를 그대로 읽으면 결론은 하나로 모이지 않는다. Qwen3-30B-A3B는 수학과 경쟁 프로그래밍에서 뚜렷하게 앞선다. AIME 2025에서 16.67점, LiveCodeBench v6에서 4.17점 차이다. 지시 따르기(IFEval, Ko-IFEval)도 Qwen이 위다. 반대로 믿:음 K 2.5 Pro는 지식 기반 문제와 한국어에서 앞선다. MMLU-Pro와 GPQA-Diamond가 근소하게 높고, 한국어 평가에서는 KMMLU 4.5점, KoBALT 17.7점, CLIcK-L 6.8점 차이로 벌어진다. 코딩에서도 알고리즘 문제(LiveCodeBench)는 Qwen이, 함수 단위 구현(HumanEval+)은 믿:음 K가 앞선다.

가장 큰 차이는 τ²-Bench Telecom이다. 통신사 상담 시나리오에서 도구를 호출하며 대화를 끌고 가는 평가인데 89 대 28로 벌어진다. 다만 이 항목은 Artificial Analysis가 공개한 값을 KT가 가져온 것이고, HyperCLOVA X SEED Think도 87로 비슷하다. 통신 업무 도메인에 맞춰 학습한 국내 모델과 그렇지 않은 범용 모델의 차이로 읽는 편이 맞다. 같은 에이전트 계열이라도 터미널 작업을 다루는 Terminal-Bench에서는 세 모델 모두 한 자릿수에서 12점 사이로 낮고, 믿:음 K가 가장 낮다.

한 가지 더 봐야 할 조건이 있다. 위 점수는 모두 사고 모드를 켠 값인데, 보고서에 함께 실린 사고 모드 미사용 결과에서는 순위가 뒤집히는 항목이 여럿이다. MMLU-Pro는 믿:음 K 73.98 대 Qwen 78.67, HumanEval+는 82.90 대 88.40으로 Qwen이 앞선다. 사고 모드는 출력 토큰 수와 응답 지연을 늘리므로 곧 서빙 비용이다. 벤치마크 표를 볼 때 ‘어느 모드에서 잰 값인가’는 점수 자체만큼 중요하다.

정리하면 이 표는 승패를 가르지 않는다. 용도에 따라 유리한 쪽이 갈릴 뿐이다. 사내 규정 검색과 한국어 문서 이해가 중심이면 믿:음 K 쪽 강점이 업무와 겹치고, 수학·알고리즘 코딩·긴 지시문 준수가 중요하면 Qwen 쪽이 유리하다. 그리고 어느 쪽이든 이 표만으로 결정할 수는 없다. 자사 문서와 프롬프트로 같은 조건에서 다시 재야 한다.

2026년 8월에 Qwen을 검토한다면 대상이 달라진다

KT 기술보고서의 비교 대상은 Qwen3-30B-A3B다. 2026년 3월 시점에는 타당한 동급 상대였다. 그런데 지금 자체 구축을 검토하는 기업이 마주하는 Qwen은 그 모델이 아니다. 아래 세 모델은 공개 시점과 구조가 달라 같은 벤치마크 표에 점수를 섞을 수 없어 사양만 정리했다.

세 모델의 차이는 파라미터 숫자보다 구조와 컨텍스트에 있다. Qwen3.6-35B-A3B는 전체 35B를 메모리에 올리되 토큰당 약 3B만 계산하는 MoE라서, 메모리는 넉넉히 필요하지만 생성 속도는 활성 파라미터에 가깝게 나온다. Qwen3.8-27B는 27B를 전부 계산하는 Dense라 메모리는 덜 쓰고 토큰당 연산은 더 든다. 둘 다 비전 인코더를 포함한 멀티모달 모델이고 네이티브 컨텍스트가 262K로, 32K에서 출발하는 Qwen3-30B-A3B와는 사내 문서 RAG를 설계하는 방식 자체가 달라진다. 출처: Qwen3.6-35B-A3B 모델 카드, Qwen3.8-27B 모델 카드

그래서 이렇게 나눠서 읽어야 한다. 믿:음 K 2.5 Pro가 출시 당시 동급 Qwen과 경쟁력 있는 결과를 냈다는 것과, 2026년 8월 현재 최신 Qwen 계열보다 우월하다는 것은 다른 주장이다. 앞의 표는 첫 번째만 뒷받침하고 두 번째는 아직 아무도 같은 조건으로 재지 않았다. 지금 신규 구매를 검토하는 조직이라면 KT 보고서의 비교 대상이 아니라 지금 내려받을 수 있는 최신 모델까지 포함해 PoC를 돌리는 것이 맞다.

32B는 얼마나 큰가

32B라는 숫자를 감으로 잡으려면 가중치를 담는 데 필요한 용량을 보면 된다. 파라미터 하나가 차지하는 바이트 수에 320억을 곱한 값이다.

다만 이 숫자는 가중치만 계산한 것이다. 실제로 돌리려면 대화 이력을 담는 KV Cache, 추론 런타임이 쓰는 작업 공간, 운영체제와 서빙 프로세스 몫이 더 필요하다. 컨텍스트를 길게 쓸수록 KV Cache가 커지므로 여유는 넉넉히 잡아야 한다. 그래도 4비트로 줄인 30~32B급 오픈웨이트 모델은 통합 메모리를 넉넉히 단 Apple Silicon Mac이나 GPU 워크스테이션에서 충분히 실행된다.

한 가지 오해를 미리 막아 두자. 이건 동급 32B 오픈웨이트 모델을 기준으로 한 이야기다. 믿:음 K 2.5 Pro 자체를 내려받아 Mac에서 돌릴 수 있다는 뜻이 아니다. 앞서 적었듯 2.5 Pro의 가중치 공개는 확인되지 않는다. ‘32B는 개인 장비에서도 돌아간다’는 문장은 Qwen3.8-27B나 Qwen3.6-35B-A3B 같은 Apache-2.0 모델에 해당한다.

개인 로컬 실행과 기업 서빙은 다른 문제다

그러면 32B가 개인 장비에서도 돌아가는데 왜 NPU 서버가 필요한가. 답은 모델 크기에 있지 않고 동시성에 있다. 한 사람이 한 세션으로 순차 질문하는 것과, 수십에서 수백 명이 동시에 쓰는 서비스는 메모리와 지연시간이 걸리는 지점이 아예 다르다.

기업 서비스에서는 모델 가중치보다 KV Cache가 변수다. 가중치는 모든 요청이 공유하지만 KV Cache는 대화마다, 사용자마다 따로 쌓인다. RAG는 검색한 문서 조각을 프롬프트에 붙이고 에이전트는 도구 결과와 중간 상태를 계속 더하므로 이 부담이 빠르게 커진다. 컨텍스트 100만 토큰을 지원한다는 모델이 곧바로 100명의 동시 세션을 감당한다는 뜻은 아니다.

메모리 대역폭이 중요해지는 것도 이 지점이다. 토큰을 하나 만들 때마다 대규모 가중치를 반복해서 읽기 때문에, 표기된 연산 성능보다 메모리 이동이 먼저 병목이 된다. 첫 토큰까지 걸리는 시간은 프롬프트 길이와 사전 채우기 처리량이, 이후 생성 속도는 대역폭과 배치 스케줄링이 좌우한다. 사용자가 체감하는 것은 평균 tokens/s보다 요청이 몰릴 때의 p95·p99 지연시간과 실패율이다.

그래서 이 제품의 값어치는 ‘32B 모델을 실행할 수 있다’가 아니라 ‘32B급 모델을 기업 서비스 수준으로 얼마나 안정적이고 효율적으로 서빙하느냐’에 있다. 같은 목적에 GPU도 쓸 수 있다. NPU가 경쟁력을 가지려면 특정 모델·정밀도·배치·입출력 길이 조건에서 더 높은 처리량과 와트당 성능을 내고 소프트웨어 경로가 안정적이어야 한다. ‘NPU가 GPU보다 싸다’는 일반 명제는 성립하지 않는다.

ATOM-Max 사양에서 읽을 수 있는 것과 읽을 수 없는 것

리벨리온은 ATOM-Max 카드와 서버 사양을 공식 페이지와 브로슈어로 공개하고 있다. 카드 한 장은 GDDR6 64GB에 대역폭 1TB/s, FP16 128 TFLOPS, INT8 512 TOPS, INT4 1,024 TOPS이고 최대 소비전력은 350W다. 폼팩터는 FHFL 듀얼 슬롯, 호스트 인터페이스는 PCIe Gen5 x16이다. 서버는 두 가지 구성이 공개돼 있다. 출처: 리벨리온 ATOM-Max 제품 페이지, ATOM-Max Server 브로슈어(국문 v1.8, PDF)

서버 사양은 리벨리온 ATOM-Max Server 국문 브로슈어 v1.8 기준이다. 영문 브로슈어(v1.6)는 4U 구성의 시스템 메모리를 1.5~2.3TB 범위로 적고 2U 구성을 싣지 않는 등 판본 차이가 있어, 최신 국문 판본을 기준으로 삼았다. 마지막 열은 리벨리온이 제공 가능한 서버 구성일 뿐 KT 제품의 사양이 아니라는 점을 명시하기 위한 것이다.

정리하면 이렇다. 리벨리온의 최대 구성이 4U에 카드 8장, NPU 메모리 512GB라는 사실은 확인된다. 그러나 KT NPU LLM 스테이션이 2U인지 4U인지, 카드를 몇 장 넣는지, CPU와 RAM과 저장장치가 무엇인지는 공개 자료로 확인되지 않는다. 두 가지를 붙여 읽으면 리벨리온의 최대 사양을 KT 제품의 보증 사양으로 오인하게 된다. 리벨리온은 자사 내부 최적화 시험의 TPS와 와트당 TPS 비교도 제시하지만, 같은 자료가 정밀도와 최적화 구성을 포함한 내부 시험이고 결과는 시스템·소프트웨어 버전에 따라 달라질 수 있다고 적어 두었다. 그 수치를 믿:음 K나 Qwen의 실서비스 성능으로 옮겨 쓸 수는 없다.

카드 수는 속도만의 문제가 아니다. 32B 모델을 어떤 정밀도로 유지할지, 여러 모델을 동시에 올릴지, 긴 컨텍스트의 동시 사용자를 어디까지 잡을지에 따라 필요한 메모리 용량과 카드 간 병렬화 방식이 달라진다. 카드를 늘리면 처리량과 여유는 늘지만 전력, 냉각, 장비 비용, 장애 영향 범위, 운영 복잡도도 함께 늘어난다. 제안서에는 최소한 카드 수, 모델 정밀도, 병렬화 방식, 지원 최대 컨텍스트, 목표 동시 요청과 입출력 길이가 적혀 있어야 한다.

이 장비가 값어치를 하는 업무

활용처는 산업 이름이 아니라 업무 단위로 봐야 한다. 공공·금융·국방·제약·제조라는 라벨 자체가 온프레미스의 필요성을 증명하지는 않는다. 그 안에 외부로 내보내기 어려운 원문, 꾸준한 요청량, 승인 가능한 업무 경계, 변경 이력을 남겨야 하는 절차가 있어야 한다. 다만 이런 조건이 실제로 겹치는 조직이 대체로 저 산업군에 몰려 있는 것도 사실이다.

사내 문서 RAG와 규정·법률 질의응답

수천 건의 내규, 시행세칙, 상품 설명서, 품질 표준이 있고 직원이 ‘이 고객에게 적용되는 예외 조항이 무엇인가’를 묻는 상황이다. 입력에는 질문만이 아니라 직원의 소속과 업무 권한, 기준일, 대상 상품 같은 필터가 함께 들어가야 한다. 흐름은 문서 수집과 버전 관리, 권한 필터링 검색, 재순위화, 근거 문단과 함께 답변 생성, 인용 링크 제공, 피드백 기록 순서가 좋다. 출력에는 단정적인 답변 하나 대신 적용 조항과 기준일, 근거 문서, 불확실한 조건이 함께 담겨야 한다.

여기서 LLM은 검색 결과를 자연어로 정리할 뿐 최종 규정 엔진이 아니다. 문서가 갱신됐는데 색인이 늦거나, 사용자 권한보다 넓게 검색되거나, 비슷한 조항을 혼동하면 온프레미스든 아니든 똑같이 위험하다. 일체형 장비의 가치는 민감한 원문과 질의 로그를 내부망에서 처리하고 운영 API를 표준화한다는 데 있지만, 권한 동기화와 색인 삭제, 감사 로그 보존은 따로 설계해야 한다.

고객상담 지원

상담사가 통화 요약, 약관 검색, 다음 질문 제안에 LLM을 쓰는 경우다. 입력에는 상담 화면의 제한된 고객 정보와 최신 정책만 넣고, 모델이 직접 환불이나 한도 변경을 실행하지 못하게 막아야 한다. 출력은 상담사가 검토하는 초안과 근거, 금지 표현 경고가 적당하다. 짧은 요청이 많이 몰리고 응답이 늦으면 상담 흐름이 끊기므로, 데모에서 나온 최고 생성속도보다 혼잡 시간대의 대기열과 꼬리 지연시간이 중요하다. 앞서 본 τ²-Bench Telecom 점수가 이 업무와 가장 가까운 지표지만, 그 역시 자사 프롬프트 길이와 동시성으로 다시 재현해야 한다.

사내 코드·API·기술문서 기반 코딩 어시스턴트

개발자가 사내 저장소와 API 명세, 장애 이력에 질의하고 변경안을 받는 흐름이다. 좋은 시스템은 코드를 많이 생성하는 쪽이 아니라 접근 가능한 저장소 범위를 지키고, 테스트와 정적 분석 결과를 함께 보여 주며, 비밀키와 개인정보를 프롬프트·로그에서 다루는 규칙을 지키는 쪽이다. 망분리 환경에서는 외부 AI에 소스코드를 보낼 수 없어 자체 호스팅의 값어치가 분명해진다. 폐쇄망 설치를 전제로 한 코딩 보조 도구가 계속 나오는 것도 같은 수요다. 다만 이는 시장 흐름일 뿐 ATOM-Max의 성능 근거는 아니다. 출처: 유라클, 폐쇄망 지원 AI 코딩 보조 도구 CLI 출시

ERP·CRM과 연결된 업무 에이전트

구매 담당자가 ‘이번 분기 납기 지연 위험이 큰 발주를 요약하고 담당자에게 보낼 메일 초안을 만들어 달라’고 요청하는 흐름이다. 에이전트는 ERP를 읽고 납기 기준을 계산하며 CRM에서 담당자를 찾아 메일 초안을 만들 수 있다. 그러나 발주 변경, 메일 발송, 결재 등록은 모델의 자연어 판단에 바로 맡길 동작이 아니다. 읽기와 초안, 승인, 실행의 권한을 나누고 고위험 호출에는 사람의 확인을 둬야 한다. 도구 사용 벤치마크 점수는 출발점일 뿐이고, API 스키마가 바뀌었을 때 실패하는 방식, 중복 실행 방지, 트랜잭션 취소, 권한 상승 차단, 감사 추적을 함께 시험해야 한다.

민감 문서의 분류·요약·검토

계약서, 인사 기록, 임상 문서, 설계 도면 설명처럼 외부 전송 자체가 문제가 되는 문서를 분류하고 요약하는 업무다. 요청량이 크지 않아도 데이터 성격 때문에 자체 처리가 강제되는 경우가 많다. 이 유형은 처리량보다 접근 통제와 로그 보존, 재현 가능한 결과가 더 중요하다.

반대로 필요 없을 수 있는 경우

보안 제약이 크지 않고, AI 사용량이 많지 않으며, 일반 문서 작성과 아이디어 정리가 주 용도이고, 항상 최신 최고 성능 모델을 써야 하는 조직이라면 자체 장비의 고정비를 정당화하기 어렵다. 이런 경우 ChatGPT·Claude·Gemini 같은 클라우드 AI의 사용량 과금과 관리형 보안 옵션, 또는 Qwen 오픈웨이트를 소규모로 직접 운영하는 쪽이 합리적인 출발점이다.

Qwen 직접 구축과 비교한 경제성

도입 가치를 한 줄로 쓰면 모델 성능 × 처리량 × 전력 × 데이터 통제 × 구축비 × 운영비 × 유지보수다. 문제는 이 곱셈에서 절반이 아직 빈칸이라는 점이다. 출시 발표와 관련 기사, 리벨리온 공식 자료를 모두 확인했지만 다음 항목은 어디에도 없다.

이 상태에서 “Qwen 직접 구축보다 싸다”, “GPU 대비 경제적이다”, “TCO가 낮다”, “비용 효율성이 검증됐다”고 말할 근거는 없다. 정확한 문장은 이쪽이다. KT의 일체형 제품은 구축·통합·운영 부담을 줄일 가능성이 있지만, 현재 공개된 가격과 실서비스 성능 정보만으로는 Qwen 오픈웨이트 모델을 직접 구축하는 것보다 총비용이 낮다고 판단하기 어렵다.

그래도 비교 자체는 가능하다. 가격을 억지로 추정하는 대신 같은 업무 수요와 서비스 목표를 놓고 3년 TCO 모델을 만들면 된다. 분모로는 장비 대수 대신 월간 성공 요청 수, 목표 지연시간 안에서 처리한 출력 토큰, 또는 줄인 검토 시간을 쓴다. 토큰당 비용도 입출력 길이, 캐시 적중률, 사고 모드 사용 여부, 재시도, 유휴 시간에 따라 크게 달라진다.

PoC는 네 가지 부하로 설계하는 편이 좋다. 짧은 질의가 많은 상담·검색형 부하, 긴 사내 문서를 붙이는 RAG 부하, 도구 호출과 재시도가 섞이는 에이전트 부하, 월말이나 장애 대응처럼 요청이 몰리는 피크 부하다. 각 부하에서 첫 토큰 지연, 생성 속도, p95·p99 응답시간, 성공률, 근거 정확도, 전력계 실측값, 운영자 개입 횟수를 모은다. 믿:음 K와 Qwen은 같은 지시문·검색 결과·출력 제한으로 맞추되, 각 모델에 유리한 설정으로 잰 결과도 따로 남긴다.

또 하나 흔한 함정은 ‘GPU 직접 구축’과 ‘NPU 일체형’을 불공정하게 비교하는 것이다. Qwen은 GPU에서만 도는 모델이 아니고, 지원되는 NPU 환경과 컴파일·런타임으로 직접 운영할 수도 있다. 반대로 믿:음 K도 일체형 장비 외의 배포 옵션이 계약상 존재하는지 확인할 수 있다. 질문을 “어느 모델이 어느 칩에서 빠른가”에서 “우리에게 필요한 모델과 업데이트 주기, 서빙 기능을 이 플랫폼이 지원하고 그 결과를 재현할 수 있는가”로 바꿔야 한다.

계약 전에 받아 둘 것

제안서만 요구하면 높은 수치와 넓은 호환성 표현이 남는다. 아래는 수용 기준으로 문서에 박아야 할 최소 항목이다.

• 실제 서버 구성 — ATOM-Max 카드 수와 연결 구조, CPU·메모리·저장장치, 랙·전력·냉각 요구, 증설 방식
• 목표 동시 사용자 수에서의 처리량 — 입력과 출력 토큰 길이를 명시한 tokens/s, 첫 토큰 지연, p95·p99 지연, 오류율
• 해당 조건에서의 실측 전력 사용량
• 모델·장비·유지보수 비용과 증설 단가, 계약 종료 조건
• 같은 범위로 계산한 3년 TCO 견적
• Qwen 등 오픈웨이트 모델을 같은 장비에서 운영할 수 있는지, 가능하다면 지원 서빙 엔진과 정밀도 범위

이 목록은 구매를 늦추려는 형식주의가 아니다. LLM은 모델이 자주 바뀌고 서빙 소프트웨어가 빠르게 업데이트되는 영역이라, 첫 설치의 편의보다 1년 뒤 모델을 교체하거나 컨텍스트를 늘리거나 사용자 수를 두 배로 할 때의 비용이 더 크게 작용한다. 리벨리온은 vLLM, Triton Inference Server, TorchServe, Ray Serve와 Kubernetes·Docker 호환을 자사 서버 자료에서 밝히고 있다. 실제 KT 구성에서 어떤 버전이 지원되고 고객이 어디까지 운영권을 갖는지는 따로 확인해야 한다. 출처: ATOM-Max Server 브로슈어(국문 v1.8, PDF)

결론: 지금 확인된 것과 확인되지 않은 것

믿:음 K 2.5 Pro와 ATOM-Max 조합의 가장 분명한 장점은 한국어 LLM, 국산 NPU, RAG와 운영 환경을 하나의 제품으로 제공해 민감한 데이터를 외부로 보내기 어려운 조직의 구축 부담을 줄인다는 점이다. KT 기술보고서의 비교표도 이 모델이 한국어 이해와 지식 문제, 통신 도메인 에이전트 작업에서 동급 Qwen보다 앞선다는 것을 보여 준다. 사내 규정 검색과 문서 질의응답이 주 업무라면 이 강점은 실제 업무와 겹친다.

그러나 같은 표에서 Qwen은 수학과 알고리즘 코딩, 지시 따르기에서 앞섰고, 사고 모드를 끄면 일부 항목의 순위가 뒤집힌다. 게다가 그 비교 대상은 2026년 8월 기준으로 이미 두 세대 전 모델이다. 그리고 Qwen 같은 오픈웨이트 모델을 직접 운영하는 것보다 실제로 저렴하고 빠른지는 가격과 실서비스 처리량이 공개되기 전까지 판단할 수 없다.

그래서 구매자가 할 일은 벤치마크 승자를 고르는 게 아니라 자사 문서와 권한, 트래픽을 넣은 동일 조건 PoC와 3년 TCO를 요구하는 것이다. 그 검증에서 한국어 품질, RAG 근거 정확도, 동시 처리량, 전력, 지원 범위가 함께 기준을 넘으면 일체형의 편의는 실질 가치가 된다. 넘지 못하면 오픈웨이트를 직접 운영하거나 클라우드와 섞는 편이 낫다. 기업용 AI에서 중요한 것은 32B 모델을 돌릴 수 있느냐가 아니라, 필요한 성능을 얼마나 많은 사용자에게 얼마나 낮은 총비용으로 안정적으로 제공할 수 있느냐다.

참고 출처

• Mi:dm K 2.5 Pro 기술보고서 (KT Tech. Innovation Group, arXiv:2603.18788)
• KT ‘믿:음 K 2.5 Pro’ 인공지능 신뢰성 인증 획득
• KT Enterprise 믿:음 K 제품 페이지
• 리벨리온 ATOM-Max 제품 페이지
• 리벨리온 ATOM-Max Server 제품 페이지
• 리벨리온 ATOM-Max Server 브로슈어 (국문 v1.8, PDF)
• Qwen3-30B-A3B 모델 카드
• Qwen3.6-35B-A3B 모델 카드
• Qwen3.8-27B 모델 카드
• KT, 기업용 소버린 AI 제품 출시
• KT, 국산 NPU·LLM 일체형 플랫폼으로 기업 AX 정조준
• AI 대전환 시대, 기업이 마주한 두 가지 딜레마
• 유라클, 폐쇄망 지원 AI 코딩 보조 도구 CLI 출시