7개 산업 사례, 전부 채점.

이런 프로젝트를 맡을 수 있다는 점이 저희의 드문 강점입니다. 모델은 고객사 자체 하드웨어에서 돌고, 제3자에게는 아무것도 도달하지 않습니다. 예전에는 그 대가가 일관성이었습니다. 현재 모델에서는 그렇지 않습니다 — 로컬 열은 호스팅 모델 둘 중 더 나은 쪽과 문항별로 대등하고, 두 모델보다 빠르게 답합니다.

대부분의 조직이 여기에 해당하고, 많은 곳이 그것을 모릅니다. 이 데이터에는 보관지 제약이 없으므로 승인된 호스팅 모델이 적합합니다 — 운영할 것이 없고, 구입할 하드웨어가 없고, 도입도 더 빠릅니다. 필요 없는 인프라를 팔기보다 그렇게 말씀드립니다.

대부분의 조직에는 프라이빗 모델이 필요하지 않고, 저희는 그렇게 말합니다. 정책이 이미 승인된 AI 공급사를 허용한다면, 호스팅 프런티어 모델이 가장 손이 덜 갑니다. 구입할 GPU도, 운영할 것도 없고, 정확도는 위와 같습니다. 대부분의 고객사에게는 여전히 이것이 기본값입니다. 다만 이 문항들에서 가장 빠른 것은 아닙니다.

저희가 하지 않는 것은, 그 선택에 아무 결과가 없는 척하는 일입니다. 그 구성에서는 프롬프트와 에이전트가 읽은 쿼리 결과가 고객사와 해당 제공사 간 계약에 따라 모델 제공사로 전송됩니다. 상당히 많은 워크로드에서 이는 전적으로 수용 가능하며 기존 벤더 검토로 이미 커버됩니다. 그렇지 않은 경우도 있고, 그것이 저희가 다룰 수 있다는 점에서 드문 사례입니다.

호스팅 — 저희 기본값

운영할 것도 구입할 하드웨어도 없고, 토큰 단위 과금입니다. 여기서 측정한 단일 구성 중 가장 정확하지만, 차이는 크지 않습니다. 데이터는 모델 공급사에 도달합니다. 대부분의 고객사에게 대체로 적합합니다.

고객사 하드웨어에서

데이터를 정말로 외부로 보낼 수 없을 때. 제3자에게 아무것도 도달하지 않고, 하드웨어가 갖춰지면 토큰당 비용도 없습니다. 정확도는 어떤 오픈 모델을 돌리는지에 크게 좌우됩니다. 로컬 열은 한 대의 장비에서 돌아가는 36B 전문가 혼합 모델이며, 30B 코더 모델에서 이것으로 옮기면서 호스팅 모델과의 격차가 완전히 사라졌습니다. 따라서 교훈은 「더 큰 모델이면 나아진다」가 아닙니다. 어떤 모델인지, 어떻게 튜닝되었는지가 크기보다 훨씬 중요했습니다.

혼합

배치가 성숙하면 대개 이게 정답입니다. 제한 데이터는 로컬, 나머지는 승인된 API로. 벤더 단위가 아니라 유스케이스 단위로 결정합니다.

나중에 전환

설정 한 줄입니다. 한 번 고르면 계속 매여 있는 것도 아니고, 저희에게 종속되는 것도 아닙니다.

명백한 가정을 뒤집는 결과가 하나 있어 짚어둘 만합니다. 이전 측정에서는 호스팅 모델 두 개가 로컬보다 정확했고 또 느렸습니다. 그 지연은 모델 때문이 아니라 왕복 횟수 때문이라고 봤습니다 — 이것은 에이전트 루프이며, 스키마를 발견하고 테이블을 설명하고 질의를 실행하기까지 여러 번 호출해야 하고, 모델이 외부에 있으면 그 호출마다 인터넷을 건넙니다. 로컬 모델을 교체해 그 해석을 검증했습니다. 현재 모델은 호스팅 모델 중 더 나은 쪽과 문항별로 대등하며, 약 230초에 답합니다. 상대는 391초와 403초입니다. 비용은 왕복이었습니다. 「호스팅은 빠르고 로컬은 안전하다」는 정리는 처음부터 너무 단순했습니다 — 이 문항들에서는 이제 로컬이 더 빠릅니다.

OpenAI 20–21/21 × 3 · 374–411s DeepSeek 21/21 × 3 · 329–591s Local 20–21/21 × 4 · 215–242s

결과는 모델, 하드웨어, 그리고 실행마다 달라집니다. 여기 있는 각 모델은 여러 번 채점했고, 표의 수치는 단일 측정이 아니라 그 실행들의 범위와 중앙값입니다 — 다만 모두 같은 날 측정한 값이며 보증이 아닙니다. 같은 로컬 모델이 같은 문항을 한 번은 맞히고 다음 번에는 틀리는 것을 저희도 봤습니다. 표가 하나의 결론이 아니라 실행 횟수를 세는 이유가 바로 그것입니다. 특정 모델이 중요하다면, 정직한 답은 웹페이지의 표를 믿는 것이 아니라 이 채점 문항을 그 모델에 직접 돌려보는 것입니다 — 고객사 스키마에서 함께 하겠습니다.