요약(TL;DR)— 오픈 웨이트 (open-weight) 모델을 로컬에서 실행하면 실제 비용은 API 비용에서 평가 부채 (evaluation debt)로 전환됩니다. 양자화 (Quantization), 엔진 선택, 그리고 버전 변화는 모두 모델의 동작을 조용히 변화시키며, 대부분의 팀은 이러한 변경을 수행한 후 다시 테스트하지 않습니다. 로컬 AI의 어려운 점은 가중치 (weights)를 설치하는 것이 아니라, 벤더가 대신 수행해주던 지속적인 평가 (continuous eval) 파이프라인을 구축하는 것입니다.

오픈 웨이트 모델에 대한 모든 홍보는 똑같은 방식으로 끝납니다: 가중치를 다운로드하고, 추론 엔진 (inference engine)을 연결하면 자유로워진다는 것입니다. 속도 제한도 없고, 벤더 종속성 (vendor lock-in)도 없으며, 갑작스러운 서비스 중단 (deprecation)도 없습니다. 하지만 그 홍보에서 빠진 점은 벤더가 토큰을 제공하는 것 외에도 당신을 위해 무언가를 하고 있었다는 사실입니다. 그들은 변경 사항이 배포되기 전에 모든 변경 사항에 대해 평가 스위트 (eval suites)를 실행하고 있었습니다. 당신이 자체 호스팅을 시작하는 순간, 그 작업은 사라지지 않습니다. 그것은 당신의 몫이 되며, 거의 아무도 이를 위한 예산을 책정하지 않습니다.

양자화 (Quantization)는 압축이며, 압축은 손실적이다

일반적인 하드웨어에서 로컬 AI가 실행 가능한 전체 이유는 양자화 (Quantization) 때문입니다. 풀 정밀도 (full precision)의 밀집 모델 (dense model)은 대부분의 팀이 보유하지 못한 GPU 메모리를 필요로 하지만, 동일한 가중치의 4비트 또는 8비트 양자화 버전은 단일 카드에 들어갑니다. GGUF, AWQ, GPTQ와 같은 포맷은 이 과정을 거의 기계적인 수준으로 만들었습니다— 방식을 선택하고, 스크립트를 실행하면, 대부분 동일하게 동작하는 더 작은 모델을 얻게 됩니다.

"대부분"이라는 단어가 당신을 걱정시켜야 할 단어입니다. 양자화 (Quantization)는 함수 근사치 (function approximator)에 적용되는 손실 압축 (lossy compression)이며, 손실은 균등하게 분포되지 않습니다. 손실은 어려운 작업에 중요한 바로 그 지점들, 즉 다단계 추론 (multi-step reasoning), 수치 정밀도 (numeric precision), 희귀 토큰 (rare tokens), 긴 문맥 검색 (long-context retrieval)에 집중되는 경향이 있습니다. 양자화된 모델은 가벼운 스모크 테스트(smoke test)—이메일 작성하기, 이 단락 요약하기—는 통과할 수 있지만, 당신의 제품이 실제로 의존하는 좁은 범위의 동작에서는 조용히 성능이 저하되었을 수 있습니다.

원본 가중치(weights)를 학습시킨 벤더들은 풀 프리시전(full-precision) 체크포인트를 대상으로 평가 하네스(eval harness)를 실행했습니다. 그들은 커뮤니티가 결국 만들어낼 모든 양자화(quantization) 레벨에 대한 결과물을 거의 공개하지 않는데, 그 이유는 그들이 해당 결과물을 만든 것이 아니기 때문입니다. 그 결과물은 다운스트림(downstream)의 누군가가, 종종 스크립트와 기도(a script and a prayer)에 의지해 만들어낸 것입니다. 만약 당신이 그 결과물을 프로덕션(production) 환경에서 실행하고 있다면, 그것이 여전히 기준을 충족하는지 알 수 있는 파이프라인 내의 유일한 당사자는 바로 당신뿐입니다. 대부분의 팀은 이를 확인조차 하지 않습니다.

엔진은 중립적인 파이프가 아니다

양자화(Quantization)가 주목받는 이유는 그것이 의도적이고 가시적인 선택이기 때문입니다. 반면 추론 엔진(Inference engine) 선택은 거의 주목받지 못하지만, 마땅히 그래야 합니다. vLLM, TGI, llama.cpp, SGLang와 같은 서빙 스택(serving stacks)은 처리량(throughput) 이상의 부분에서 차이가 납니다. 연속 배치(Continuous batching) 전략, KV 캐시 제거(KV cache eviction) 정책, 프리픽스 캐싱(prefix caching), 샘플링(sampling) 구현, 그리고 기본 중단 동작(default stopping behavior)은 모두 엔진마다 다르며, 이 모든 요소는 단순히 지연 시간(latency)의 차이가 아니라 행동의 차이로 나타나는 방식으로 출력 분포(output distributions)를 변화시킬 수 있습니다.

더 나은 초당 토큰 수(tokens-per-second)를 쫓아 서빙 엔진을 교체한다면, 당신은 모델이 긴 대화를 처리하는 방식, 메모리 압박 상황에서 컨텍스트(context)를 잘라내는 방식, 또는 온도(temperature)가 0일 때 출력이 얼마나 결정론적(deterministic)인지에 대한 방식까지도 바꾸었을 수 있습니다. 이 중 그 어떤 것도 모델 카드(model card)에는 들어있지 않습니다. 이는 가중치(weights)로부터 세 단계 아래에 있는 구현 세부 사항(implementation detail)이며, 모두가 단순한 인프라 변경이라고 생각했던 마이그레이션(migration)이 진행된 지 3주 후에 지원 티켓(support ticket)으로 변하게 되는 바로 그런 종류의 문제입니다.

벤더는 지속적인 평가를 수행하지만, 당신은 아마 그렇지 않을 것이다

호스팅 모델 제공업체들은 평가를 상시 파이프라인(standing pipeline)으로 취급합니다. 모든 체크포인트, 모든 서빙 변경 사항, 모든 양자화(quantization) 또는 증류(distillation)는 고객용 엔드포인트(endpoint)에 도달하기 전에 일련의 벤치마크(benchmarks)와 내부 회귀 테스트(internal regression suites)를 거칩니다. 이 프로세스는 API 사용자에게는 보이지 않으며, 바로 그 점 때문에 마치 존재하지 않는 것처럼 느껴지는 것입니다. 하지만 그것은 존재합니다. 당신이 직접 비용을 지불하지 않을 뿐입니다. 그것은 토큰 가격에 이미 포함되어 있습니다.

동일한 모델 제품군 (model family)을 자체 호스팅(Self-host)하면, 직접 구축하지 않는 한 그러한 파이프라인은 사라집니다. 대부분의 로컬 AI 스택은 단 한 번만 평가됩니다. 즉, 누군가가 몇 개의 프롬프트 (prompts)를 실행해 보고, 결과가 마음에 들어서 배포하는 도입 시점입니다. 그 이후의 모든 변경 사항—새로운 양자화 (quantization), 동일 모델의 더 최신 포인트 릴리스 (point release), 교체된 추론 엔진 (inference engine), 확장된 컨텍스트 윈도우 (context window)—은 테스트를 거치지 않은 채 진행됩니다. 스택은 계속 실행됩니다. 아무것도 충돌(crash)하지 않기 때문에 아무도 성능 저하 (regression)를 알아차리지 못합니다. 모델은 단지 이전에 잘했던 일을 조금씩 못하게 될 뿐이며, 이러한 침식은 사용자가 불평을 하거나 다운스트림 지표 (downstream metric)가 조용히 하락하기 전까지는 보이지 않습니다.

스택을 실제로 소유한다는 것의 의미

로컬 AI 배포를 진정으로 소유한다는 것은 인프라 제어권만을 의미하지 않습니다. 그것은 승인 게이트 (promotion gate)입니다. 새로운 양자화 수준, 새로운 엔진 버전, 동일 모델 제품군의 새로운 체크포인트 (checkpoint) 등 어떠한 변경 사항도 프로덕션 (production)에 적용되기 전에, 일반적인 공개 벤치마크 (public benchmark)가 아닌 실제 작업 분포 (task distribution)를 반영하는 고정되고 버전이 지정된 평가 세트 (eval set)를 통해 실행되어야 합니다. 일반적인 벤치마크는 모델이 여전히 산술 연산을 할 수 있는지는 알려주지만, 모델이 귀하의 특정 인보이스 (invoice) 형식에서 항목을 여전히 추출할 수 있는지에 대해서는 아무것도 알려주지 않습니다.

이 평가 세트는 방대할 필요는 없습니다. 대신 안정적이어야 하고, 일관되게 점수가 매겨져야 하며, 서비스의 유닛 테스트 (unit tests)를 다루는 것과 동일하게 회귀 테스트 스위트 (regression suite)로 취급되어야 합니다. 현재 프로덕션 빌드의 출력값을 베이스라인 (baseline)으로 저장하세요. 새로운 후보 모델을 교체한 후가 아니라, 교체하기 전에 해당 베이스라인과 차이점 (diff)을 비교하십시오. 누군가의 노트북에서 수행하는 일회성 점검 (spot-check)을 신뢰하기보다는, 트래픽의 일부를 대상으로 새로운 빌드를 카나리 (Canary) 배포하여 비교하십시오.

이는 모델 허브에서 새로운 GGUF 파일을 가져와 서버를 그곳으로 지정하는 것보다 더 많은 작업이 필요합니다. 하지만 이것이

Open-weight models(오픈 웨이트 모델)은 진정한 구조적 승리입니다. 토큰당 과금이 없고, 요청하지 않은 불투명한 모델 교체가 없으며, 데이터 거주성(data residency)과 지연 시간(latency)에 대한 완전한 통제권을 가집니다. 이 점들은 의문의 여지가 없습니다. 대부분의 로컬 AI 도입 계획에서 과소평가된 부분은 이 거래의 운영적 측면입니다. 여러분은 타인의 평가 파이프라인(eval pipeline)에 대한 의존성을 제거하는 것이 아닙니다. 대신, 직접 파이프라인을 구축하고, 이를 지속적으로 실행하며, 모든 양자화(quantization), 엔진 업그레이드, 체크포인트 업데이트를 프로덕션(production)에 도입될 가치를 증명해야 하는 변경 사항으로 취급하는 업무를 물려받는 것입니다.

이 단계를 건너뛰는 팀들은 로컬 AI의 이점인 비용, 통제권, 독립성을 누리다가, 무엇이 변했는지 알려줄 벤더의 상태 페이지(status page)도 없이 조용한 성능 저하(regression)가 모든 사용자에게 동시에 배포되는 순간을 맞이하게 됩니다. 해결책은 오픈 웨이트(open weights) 채택에 대해 더 많은 주의를 기울이는 것이 아닙니다. GPU 예산을 책정할 때 평가 하네스(eval harness)를 위한 예산도 동시에 책정하는 것입니다.