데이터가 회사 밖으로 나가지 않는 업무 자동화를 사내 GPU 한 대로 검증했습니다

사내 GPU 한 대 위에서 업무 에이전트 열 종이 동시에 도는 구성

랙 한 대, 워크로드 열 종. 이 글에서 실제로 돌린 구성입니다.

데이터를 밖으로 내보낼 수 없는 조직에서 AI 도입이 막히는 지점은 대개 모델 성능이 아닙니다. 성능은 이미 충분한데, 그 성능을 쓰려면 계약서와 장애 로그와 고객 문의를 남의 API로 보내야 한다는 것이 문제입니다. 그래서 검토는 자주 같은 자리에서 멈춥니다. 모델을 우리 울타리 안에 두면 업무가 정말 돌아가느냐.

그 질문에 답하려고 27B 모델을 NVFP4로 줄여 사내 GPU에 올리고, 재무 마감부터 인프라 장애 진단까지 업무 에이전트 10종을 화면 녹화로 돌렸습니다. 10건 모두 완주했고 외부 API 호출은 0건입니다. 단일 요청 지연은 양자화 전 bf16 원본보다 오히려 빨랐습니다.

소버린 구성이라는 말은 세 가지가 동시에 참일 때만 성립한다고 봅니다. 데이터가 실제로 안 나가야 하고, 그 울타리 안에서 업무가 끝까지 되어야 하고, 결함을 발견했을 때 우리가 고칠 수 있어야 합니다. 앞의 두 개는 이번에 확인했습니다. 정작 판단이 갈리는 곳은 세 번째입니다.

열 건 중 다섯 건에서 한국어 답변에 간체자가 섞였고, 같은 조건에서 상용 모델 두 팔은 0건이었습니다. 우리가 진 축입니다. 다만 체크포인트가 우리 것이라 이 결함은 기다릴 대상이 아니라 학습 층에서 처리할 작업이 됩니다. 남의 API였다면 발견하고도 문의를 넣는 것 말고 할 수 있는 일이 없습니다. 세 번째 조건은 이렇게 결함이 나왔을 때 비로소 확인됩니다.

비용도 함께 실었습니다. 같은 워크로드를 상용 API 정가로 환산하면 Claude Opus 5 기준 123배, GPT-5.6 Sol 기준 135배입니다. 지시 이행률은 Claude Sonnet 5, Haiku 4.5와 동률이었습니다.

여기서 말하는 완주는 답변 문장이 그럴듯하게 나왔다는 뜻이 아닙니다. 에이전트가 파이썬을 직접 작성해 격리된 도커 샌드박스에서 실행하고, 웹을 아홉 번 검색해 근거를 모으고, 사내 위키를 조회하고, 스무 번의 도구 호출을 거쳐 스스로 종료 판단을 내린 것까지 포함합니다. 아래 영상은 전부 그 과정을 실시간 속도 그대로 담았습니다. 재생 속도를 손대지 않았으므로 걸린 시간이 곧 실제 걸린 시간입니다.

무엇을 돌렸나

열 개 케이스는 새로 만든 것이 아니라 플랫폼에 이미 들어 있던 업무 에이전트를 그대로 썼습니다. 데모를 위해 특별히 조율한 에이전트가 아니라는 점이 오히려 중요합니다. 각 에이전트는 자기 페르소나와 도구 권한을 이미 갖고 있었고, 우리는 모델만 바꿔 끼웠습니다.

케이스	에이전트	턴	스텝	입력 토큰	출력 토큰	소요
분기 마감 계산	재무	2	3	11,733	1,346	16.0초
파드 장애 진단	인프라 진단	3	6	22,293	13,841	108.2초
Go 핸들러 보안 리뷰	Codex 코딩	10	20	104,869	11,339	99.4초
주간 업무 보고	주간 보고 자동화	2	3	11,428	1,571	16.5초
온프레미스 제안 골자	영업	2	3	14,385	3,417	28.2초
독소 조항 검토	법무	1	1	7,908	3,370	26.0초
RFP 대응 매트릭스	PM	5	20	51,780	3,332	38.5초
SQL 작성과 자체 검증	데이터	2	3	13,279	9,094	70.4초
이중 청구 응대	고객지원	1	1	8,899	2,833	22.0초
경쟁 인텔리전스	마케팅	4	13	43,539	2,697	26.6초

업무 에이전트 10종의 실행 시간과 스텝 수

오래 걸린 케이스는 모델이 느린 것이 아니라 도구를 많이 부른 것입니다.

열 건 합계는 입력 290,113 토큰, 출력 52,840 토큰입니다. 소요 시간은 서버가 기록한 실행 추적 기준이고, 영상 길이는 화면 렌더링과 마지막 문장을 읽을 여유까지 포함하므로 몇 초씩 깁니다.

열 개 케이스

재무: 숫자를 지어내지 않고 계산합니다

분기 부문별 매출을 주고 증감률을 구하되 계산은 반드시 코드로 하라고 지시했습니다. 에이전트는 파이썬을 작성해 샌드박스에서 실행하고 그 결과로 표를 만듭니다. 전체 매출이 6.70퍼센트 늘었는데 인프라 부문만 4.80퍼센트 줄었다는 점을 따로 짚어냅니다.

언어 모델에 산술을 맡기면 그럴듯한 오답이 나오는 문제가 여기서 사라집니다. 모델은 계산하지 않고 계산기를 씁니다.

재무 에이전트가 분기 증감률을 code_execute로 실제 계산합니다. 하단에 실행 모델과 사용 도구가 표시됩니다.

데이터: 자기가 쓴 SQL을 스스로 검증합니다

월별 매출과 전월 대비 증감률을 구하는 SQL을 요청했습니다. 여기서 에이전트는 SQL만 내놓지 않고 샘플 데이터를 만들어 파이썬으로 돌린 뒤 assert로 기대값과 대조합니다.

그 과정에서 스스로 경계 조건을 발견합니다. 전월 매출이 0이면 증감률이 무한대가 되므로 NULLIF로 막아야 하고, 거래가 없던 달을 아예 빼는 버전과 달력상 모든 달을 채우는 버전은 답이 다릅니다. 에이전트는 두 버전을 모두 만들어 돌려보고 어느 쪽을 쓸지 결정해 달라고 되묻습니다. 요구사항의 빈틈을 실행으로 찾아낸 셈입니다.

오른쪽 터미널에서 assert가 통과하고 exit 0으로 끝납니다. SQL이 맞다는 주장이 아니라 증거입니다.

인프라 진단: 확인할 수 없으면 확인할 수 없다고 말합니다

파드가 Running 0/1로 멈췄는데 파드 목록에는 아무것도 없다는 상황을 던졌습니다. 에이전트는 가능성 높은 원인 세 가지를 우선순위대로 세우고 각각을 확인할 명령을 답니다.

주목할 부분은 그 다음입니다. 에이전트가 샌드박스에서 kubectl을 실제로 실행해 보고 사용할 수 없다는 사실을 확인한 뒤, 진단을 직접 수행하려면 kubeconfig를 전달하거나 커넥터를 등록해 달라고 요청합니다. 없는 클러스터에 접속한 척하지 않습니다. 이 케이스는 열 건 중 가장 오래 걸렸는데, 느린 이유가 모델이 굼떠서가 아니라 사내 위키 조회와 코드 실행을 포함해 세 턴을 돌기 때문입니다.

터미널에 KUBECTL_UNAVAILABLE이 찍히고, 에이전트는 그 사실을 답변에 반영합니다.

코딩: SQL 인젝션이 있는 핸들러를 스무 스텝에 걸쳐 뜯습니다

문자열 결합으로 쿼리를 만드는 Go 핸들러를 주고 검토를 시켰습니다. 열 턴, 스무 스텝, 입력 104,869 토큰으로 열 건 중 가장 무거운 작업이었습니다. 긴 컨텍스트를 유지한 채 도구를 반복 호출하는 구간에서 양자화 모델이 흔들리는지 보려던 케이스입니다. 끝까지 놓치지 않았습니다.

열 턴에 걸친 코드 리뷰입니다. 긴 도구 호출 사슬에서 컨텍스트가 유지되는지 보는 케이스입니다.

마케팅: 웹을 실제로 검색합니다

엔터프라이즈 에이전트 시장 동향을 묻되 반드시 웹 검색을 실제로 호출하라고 지시했습니다. 에이전트는 검색과 페이지 열람을 반복해 열세 스텝을 밟습니다. 학습 데이터에 있던 기억을 되뇌는 것과 지금 웹에서 가져온 근거를 구분하려는 케이스입니다.

web_search와 web_fetch를 반복 호출해 근거를 모읍니다.

PM: 요건별로 대응 여부와 확인 필요 항목을 가릅니다

RFP 필수 요건 여섯 개를 주고 대응 매트릭스를 요청했습니다. 스무 스텝을 밟으면서 답할 수 있는 항목과 확인이 필요한 항목을 따로 표로 나눕니다. 제안서 작업에서 가장 위험한 것이 확인되지 않은 항목을 대응 가능으로 적는 일인데, 그 구분을 에이전트가 유지합니다.

요건 여섯 개에 대한 대응 매트릭스와 확인 필요 목록을 분리해 정리합니다.

법무: 독소 조항을 위험도와 함께 짚습니다

책임 전면 면제, 고객 데이터의 서비스 개선 목적 이용, 3년 자동 갱신에 180일 전 해지 통보, 공급자 소재지 준거법. 네 조항을 주고 검토를 시켰습니다. 도구 호출 없이 한 턴에 끝나는 순수 판단 작업이고, 그래서 양자화가 추론 품질에 미치는 영향이 가장 직접적으로 드러나는 케이스입니다.

도구 없이 한 턴에 끝나는 판단 작업입니다.

고객지원: 사실 확인 체크리스트까지 붙입니다

결제가 두 번 청구됐고 사흘째 답이 없다는 화난 문의에 대한 응대 초안을 한국어와 영어로 요청했습니다. 에이전트는 두 언어 초안을 쓴 뒤 발송 전 체크리스트를 덧붙입니다. 초안에 환불 완료라고 적혀 있으니 실제로 환불이 처리된 상태에서만 보내라는 경고와, 사흘 무응답은 SLA 위반 신호이므로 내부 에스컬레이션이 필요하다는 지적입니다. 시키지 않은 일인데 시켰어야 할 일입니다.

한국어와 영어 초안 아래에 발송 전 확인 사항이 붙습니다.

영업: 데이터 반출 제약을 제안의 축으로 삼습니다

제조 대기업이 사내 문서 검색과 업무 자동화를 검토하는데 데이터 외부 반출이 금지되어 있고 경쟁사는 퍼블릭 클라우드 SaaS를 제안한 상황입니다. 첫 미팅용 제안 골자를 만들게 했습니다.

제약 조건을 약점이 아니라 제안의 축으로 재구성합니다.

주간 보고: 가장 가벼운 축

한 주 한 일을 나열해 주면 팀장에게 보낼 보고서로 다듬는 작업입니다. 열 건 중 가장 짧게 끝났습니다. 매일 반복되는 잡무 하나가 16.5초라는 뜻입니다.

가장 가벼운 케이스입니다.

속도는 어디에서 빨라지고 어디에서 안 빨라지나

순수 디코딩 속도만 재면 NVFP4 양자화본이 초당 124에서 131 토큰, bf16 원본이 초당 88에서 91 토큰입니다. 약 1.40배입니다. 동시성 1, 반복 3회, 출력 256 토큰 조건입니다.

그런데 이 1.40배가 에이전트 턴 전체에 그대로 나타나지는 않습니다. 짧은 케이스 세 개를 두 모델로 각각 다섯 번씩 돌려 중앙값을 재봤습니다.

케이스	우리 NVFP4	원본 bf16	비
재무 (도구 1회)	10.6초	12.6초	1.19배
주간 보고 (도구 3회)	9.9초	12.2초	1.23배
고객지원 (도구 없음)	11.3초	25.5초	2.26배

도구를 쓰는 케이스에서 배율이 1.2배 언저리로 내려앉는 이유는 단순합니다. 턴 시간에는 샌드박스를 띄우고 코드를 실행하고 웹을 다녀오는 구간이 섞여 있는데, 그 구간은 모델과 무관하게 양쪽이 똑같이 냅니다. 모델을 아무리 빠르게 만들어도 도커 컨테이너가 뜨는 시간은 줄지 않습니다. 그래서 에이전트 워크로드에서 양자화의 이득은 디코딩 속도 그대로가 아니라 전체 시간 중 디코딩이 차지하는 비중만큼만 돌아옵니다.

반대로 도구를 쓰지 않는 고객지원 케이스는 2.26배까지 벌어졌습니다. 다만 이 숫자는 디코딩 속도만으로 설명되지 않습니다. 1.40배보다 크기 때문입니다. 두 체크포인트가 같은 질문에 서로 다른 양의 토큰을 생성하므로, 이 배율에는 속도 차이와 생성량 차이가 함께 섞여 있습니다. 속도 개선치로 인용하기에는 부적절하고, 관측값으로만 남깁니다.

상용 API로 같은 일을 시키면 얼마인가

열 건을 돌리는 데 실제로 오간 토큰은 입력 290,113개, 출력 52,840개입니다. 이 워크로드를 상용 API 정가로 환산하면 이렇습니다. 우리 쪽은 B200 한 장을 빌린 시간으로 계산했습니다. 측정된 포화 처리량 초당 3,586 토큰 기준으로 14.7 GPU초가 들었고, 시간당 5.50달러이므로 0.0225달러입니다.

백엔드	이 워크로드 비용	우리 대비
GPT-5.6 Sol	$3.0358	134.9배
Claude Opus 5	$2.7716	123.1배
Claude Sonnet 5	$1.1086	49.3배
Kimi K3	$1.6629	73.9배
GPT-5.6 Terra	$1.2143	53.9배
Claude Haiku 4.5	$0.5543	24.6배
우리 NVFP4 27B (자체 서빙)	$0.0225	1배

같은 워크로드의 백엔드별 비용 비교

로그 눈금입니다. 막대 길이가 아니라 붙은 숫자를 보십시오.

배율이 커 보이지만 조건을 정확히 봐야 합니다. 상용 가격은 캐시 할인을 적용하지 않은 정가입니다. 실제 대규모 운영에서는 캐시 읽기가 입력 단가의 0.1배로 청구되고 그 항목이 청구서를 지배하므로, 캐시 적중률이 높은 워크로드에서는 격차가 크게 줄어듭니다. 반대로 우리 쪽 숫자에는 양자화 체크포인트를 만드는 비용과 카드가 놀고 있는 시간이 빠져 있습니다. 하루에 열 건만 돌린다면 GPU 한 장을 빌리는 편이 훨씬 비쌉니다. 이 비교가 의미를 갖는 지점은 카드를 채울 만큼 물량이 있을 때입니다. 상용 정가는 변동이 잦으므로 표의 값은 작성 기준일(2026-08-22) 시점이며, 예산을 세울 때는 각 제공사의 현재 가격 페이지를 확인하십시오.

덧붙이면 비용은 소버린 구성을 택하는 이유라기보다 반대 논거를 지우는 항목에 가깝습니다. 데이터를 못 내보내는 조직은 어차피 선택지가 좁고, 그 제약을 지키는 대가가 얼마인지가 실제 질문입니다. 이 표는 물량이 있는 조직이라면 그 대가를 치르지 않아도 된다는 뜻입니다.

Fable 5는 우리가 가진 공개 가격표에 없어서 표에서 뺐습니다. 모르는 값을 추정해 넣는 것보다 빈칸이 낫습니다.

이행률과 한국어 품질은 어떤가

싸다는 것만으로는 아무 의미가 없습니다. 시킨 일을 그대로 하는지, 한국어가 멀쩡한지가 먼저입니다. 같은 열 개 케이스를 같은 에이전트로 세 백엔드에 각각 돌려 세 가지를 셌습니다.

완주율부터 보면 변별력이 없습니다. 세 백엔드 모두 10건을 전부 끝냈습니다. 그래서 더 까다로운 축을 봤습니다. 열 개 프롬프트 중 네 개는 외부에서 확인 가능한 의무를 명시합니다. 재무와 데이터 케이스는 계산을 반드시 코드 실행으로 하라고 했고, 마케팅 케이스는 웹 검색을 실제로 호출하라고 했고, 고객지원 케이스는 한국어와 영어 두 버전을 요구합니다. 지켰는지 여부는 도구 호출 기록과 답변 문자로 판정됩니다.

	완주	지시 이행	한글 순도	한자 누수	열 건 총 소요
우리 NVFP4 27B	10/10	4/4	99.33%	11자	325.7초
Claude Sonnet 5	10/10	4/4	100.0%	0자	351.2초
Claude Haiku 4.5	10/10	4/4	100.0%	0자	373.8초

이행률은 세 백엔드가 동률입니다. 총 소요는 우리가 가장 짧았지만 케이스별 편차가 커서 이 차이를 우열로 읽으면 안 됩니다. 회당 1회 측정이라 노이즈 안입니다.

진짜 차이는 한글 순도에서 나왔고, 우리 쪽이 졌습니다.

우리 모델이 진 지점

열 건 중 다섯 건에서 답변에 간체자가 섞였습니다. 총 11자입니다.

재무 케이스는 “최대 증분(절대값)을贡献”이라고 썼고, 코딩 케이스는 “클라이언트가断开되어도”라고 썼습니다. 주간 보고는 “本周의 장애 2건”, 데이터는 “8월로正确地 이어짐”입니다. 법무 케이스의 “초期货보다 긴 점”은 특히 나쁩니다. 期货는 선물거래를 뜻하는 단어라 문맥상 의미까지 어긋납니다.

답변의 결론과 수치는 전부 정확했고 열 건 모두 완주했으므로 치명적 결함은 아닙니다. 그러나 한국어로 고객에게 나가는 문서라면 이대로는 못 씁니다. Claude 두 팔은 같은 조건에서 0건이었습니다. 원인은 양자화가 아니라 기반 모델의 다국어 혼입 성향으로 보이며, 양자화 전 bf16 원본에서도 같은 계열이 관찰됩니다.

그래서 한국어 산출물에는 결정론적 순도 게이트를 파이프라인에 두고 있습니다. 한글과 한자와 가나를 세는 것은 모델 판단이 아니라 산술이므로, 이런 결함은 사람이 읽기 전에 코드가 먼저 잡는 편이 맞습니다. 근본 해결은 서빙 층이 아니라 학습 층의 몫이고, 그것이 다음 문단에서 Maxis를 언급하는 이유입니다.

이 숫자들이 무엇을 말하고 무엇을 말하지 않나

측정 조건을 밝히지 않은 처리량 수치는 의미가 없으므로 범위를 분명히 해둡니다.

두 엔드포인트 모두 max_model_len이 262,144로 동일하고, 둘 다 컴파일이 켜진 상태입니다. 컴파일을 끈 엔드포인트는 같은 조건에서 초당 7.4 토큰까지 떨어지는데 두 팔 모두 88 토큰 이상이므로 이 축은 정리됐습니다. 다만 max_num_seqs는 사내망 밖에서 파드 스펙을 읽을 수 없어 확인하지 못했습니다. 이 값은 동시 처리 중인 시퀀스 수를 제한하는 노브인데, 동시성 1에서는 제한할 대상이 없으므로 단일 요청 지연에는 영향을 주지 않습니다.

따라서 위 숫자는 동시성 1에서 클라이언트가 관측한 벽시계 시간입니다. 처리량이 아니고 수용량도 아닙니다. 동시 요청이 몰릴 때의 거동은 별도 측정이 필요하며 이 글의 범위 밖입니다.

데이터가 정말 밖으로 안 나갔다는 것은 어떻게 아나

소버린 구성이라는 주장에서 검증이 필요한 부분은 여기 하나뿐입니다. 나머지는 다 보이는데 이것만 안 보이기 때문입니다. 화면만 봐서는 어느 백엔드가 답했는지 구분되지 않습니다.

그래서 판정을 화면이 아니라 서버 로그에서 합니다. 요청이 실제로 나갈 때 서버가 남기는 줄에 전송된 모델 식별자가 찍히고, 그것이 유일한 근거입니다. 라우터가 어느 모델로 결정했다고 적는 줄은 결정 기록이지 전송 기록이 아니어서 실제 전송값과 어긋난 사례가 있었고, 그래서 그 줄은 판정에 쓰지 않습니다.

이 검증은 형식적인 절차가 아닙니다. 이번 녹화에서도 세 케이스가 조용히 Claude Sonnet 5로 나갔고, 로그 대조 없이는 그대로 자체 모델 영상으로 나갈 뻔했습니다. 게이트가 mp4를 쓰기 전에 프레임을 폐기했기 때문에 그 영상은 남아 있지 않지만, 실행 추적은 그대로 남았고 오히려 이쪽이 더 쓸모 있습니다.

케이스	Claude Sonnet 5	우리 NVFP4 27B
PM 요건 매트릭스	67.2초 · 6턴 · 18스텝	38.5초 · 5턴 · 20스텝
마케팅 웹 검색	40.9초 · 3턴 · 8스텝	26.6초 · 4턴 · 13스텝
인프라 진단	45.8초 · 1턴 · 1스텝	108.2초 · 3턴 · 6스텝

앞의 두 건에서 우리 모델은 스텝을 더 많이 밟고도 더 빨리 끝냈습니다. 세 번째는 반대로 보이지만 읽는 법이 다릅니다. Sonnet은 한 스텝 만에 답하고 끝냈고 우리 모델은 여섯 스텝을 밟았습니다. 그 여섯 스텝 안에 샌드박스에서 kubectl을 실제로 실행해 보고 사용할 수 없다는 사실을 확인하는 과정이 들어 있습니다. 장애 진단에서 빠른 답과 확인된 답 중 무엇이 필요한지는 상황이 정합니다만, 두 숫자를 같은 축에 놓고 비교하면 안 된다는 점은 분명합니다.

열 건의 최종 녹화는 전송 모델이 ThakiCloud/Qwen3.8-27B-NVFP4-FP8ATTN 하나였고 외부 호출은 0건입니다. 영상 하단에 실행 모델이 표시되는 것도 같은 이유입니다. 어느 백엔드가 답했는지는 사후에 물을 수 있어야 합니다.

이 구분이 중요한 이유는 에이전트가 모델을 한 번만 부르지 않기 때문입니다. 글 앞부분 열 건 표의 합계는 32턴 73스텝이고, 스텝마다 모델 호출이 붙습니다. 거기에 라우팅 판정이나 제목 생성 같은 보조 호출이 따로 더 붙습니다. 그중 한 번이라도 밖으로 나가면 그 턴에 실린 계약서 문장이나 장애 로그가 이미 나간 것입니다. 메인 호출만 사내 모델로 돌려놓고 소버린이라고 부를 수는 없습니다. 실제로 이 프로젝트에서 가장 오래 잡고 있던 버그가 정확히 그 계열이었습니다. 메인 턴은 사내 모델로 가는데 분류기와 제목 생성기가 조용히 외부로 나가고 있었고, 로그를 세기 전에는 아무도 몰랐습니다.

소버린 구성은 어느 층까지 우리 것이어야 하나

모델을 사내에 올렸다고 소버린이 되지는 않습니다. 이번 실행에서 데이터가 한 번도 밖으로 나가지 않은 것은 세 층이 전부 같은 울타리 안에 있었기 때문이고, 한 층만 남의 것이어도 앞 절의 호출 어딘가가 새어 나갑니다.

업무를 실제로 자동화하는 층이 Paxis입니다. 에이전트를 정의하고 도구 권한을 부여하고 실행 루프를 돌립니다. 영상에서 보이는 에이전트 열 종, 샌드박스 실행, 스무 번짜리 도구 연쇄가 전부 이 층의 산출물입니다. 소버린 관점에서 더 중요한 것은 그 옆에 붙는 감사 기록입니다. 어느 도구가 언제 무엇을 들고 호출됐는지 사후에 물을 수 없으면 데이터가 안 나갔다는 말도 증명할 수 없습니다.

그 에이전트가 부르는 모델을 사내 GPU에서 서빙하는 층이 Metis입니다. NVFP4 양자화본과 bf16 원본을 같은 방식으로 올려두고 요청 시점에 갈아 끼울 수 있었기 때문에 이번 비교가 가능했습니다. 모델을 바꾸는 데 코드 변경이 필요했다면 이런 측정은 하루짜리 작업이 됩니다.

그리고 그 27B를 NVFP4로 줄여 21기가바이트에 담아낸 것이 Maxis 계열의 양자화 작업입니다. 체크포인트가 우리 것이라는 사실은 성능보다 결함을 만났을 때 더 크게 다가옵니다. 앞에서 본 간체자 혼입이 정확히 그 사례입니다. 서빙 설정을 아무리 만져도 그 결함은 안 없어지고 학습 데이터와 정렬 단계에서 손봐야 하는데, 그 단계에 손이 닿는지 여부가 곧 세 번째 조건입니다.

정리하면 업무를 자동화하는 것은 Paxis이고, 그것을 우리 울타리 안에서 실행 가능하게 만드는 것이 Metis와 Maxis입니다. 세 층이 같은 조직 안에 있으면 모델을 바꿔 끼우고 그 효과를 측정하는 일이 실험이 아니라 운영이 됩니다. 그리고 결함이 나왔을 때 고칠 수 있는 자리에 우리가 서 있게 됩니다.

남는 질문

동시 요청이 몰릴 때의 거동은 아직 재지 않았습니다. 단일 요청 지연이 좋다고 처리량이 좋다는 보장은 없고, 그 축은 max_num_seqs를 포함한 서빙 설정에 크게 좌우됩니다. 이 글의 숫자를 용량 계획에 그대로 쓰면 안 됩니다.

품질 축도 마찬가지입니다. 열 건이 모두 완주했다는 것은 열 건에서 실패하지 않았다는 뜻이지, 양자화가 품질에 영향이 없다는 뜻이 아닙니다. 간체자 혼입은 이미 확인된 결함이고 학습 층에서 다루고 있습니다. 적대적 조건에서의 거동은 별도로 측정하고 있습니다.

데이터를 밖으로 못 내보내는 조직이 실제로 물어야 할 질문은 양자화 모델이 상용 대비 몇 퍼센트냐가 아니라고 봅니다. 우리 업무 열 개 중 몇 개가 우리 울타리 안에서 끝나느냐, 끝나지 않는 것은 무엇 때문이냐, 그리고 그 원인이 우리가 손댈 수 있는 층에 있느냐입니다. 앞의 두 질문은 이 글에서 열 건으로 답했고, 세 번째는 간체자 열한 자로 답했습니다.

저 열 개 케이스 중 귀사 업무에 가장 가까운 것을 골라 같은 방식으로 재보시길 권합니다. 벤치마크 점수보다 그쪽이 훨씬 정직한 신호입니다.

이 글의 모든 수치는 2026년 8월 22일 사내 GPU에서 측정한 실측값이며, 실행 추적과 서버 로그로 대조했습니다.