오픈웨이트 모델인데 내 장비에선 못 돌립니다

새로 나온 대형 언어 모델을 코딩 작업에 쓸 수 있는지 확인하는 일이 의사결정 테이블에 올라왔습니다. 검토를 시작한 이유는 성능 발표가 아니라 가중치가 공개됐다는 점이었습니다. 로컬에 올릴 수 있으면 추론 비용 구조와 데이터 통제가 완전히 달라지기 때문입니다.

그런데 요구 사양을 계산해보니 그 전제부터 성립하지 않았습니다. 결론부터 적으면 도입하지 않기로 했습니다. 근거는 성능이 나빠서가 아니라, 오픈웨이트라는 속성이 우리에게 이점으로 실현되지 않는다는 것이었습니다.

활성 파라미터만 보면 계산이 틀립니다

요즘 대형 모델 상당수는 MoE(Mixture of Experts) 구조입니다. 전체 파라미터를 한 덩어리로 쓰지 않고 여러 전문가 블록으로 나눈 뒤, 입력마다 그중 일부만 골라 계산합니다. 그래서 발표 자료에는 총 파라미터와 별도로 활성 파라미터가 같이 적힙니다.

여기서 착시가 생깁니다. 활성 파라미터가 총량의 일부라면 메모리도 그만큼만 있으면 될 것 같지만, 실제로는 총 가중치를 전량 메모리에 올려둬야 합니다. 어느 전문가를 부를지 정하는 라우팅은 입력이 들어온 뒤에 결정되고, 그전까지는 어느 블록이 필요할지 알 수 없기 때문입니다.

야간 당직 병원에 비유하면 계산이 빨라집니다. 밤새 실제로 진료하는 의사는 두세 명이지만, 어떤 환자가 올지 모르니 전 과목 의사가 병원 안에 대기하고 있어야 합니다. 계산량은 당직 인원만큼이고 자리는 전 인원만큼 필요합니다. 필요할 때마다 디스크에서 읽어오는 방식도 가능은 하지만, 토큰마다 수십 기가를 옮기게 되어 실사용 속도가 나오지 않습니다.

이 기준으로 계산하니 상위 모델은 1.6조 파라미터 급이라 데이터센터 GPU 노드가 있어야 했습니다. 경량판도 양자화를 거친 뒤 70~80GB였습니다. 개인 장비는 물론이고 소규모 팀이 굴리는 워크스테이션 밖의 숫자입니다.

로컬이 막히면 비교표가 통째로 바뀝니다

선택지는 셋이었습니다.

(A) 로컬 구동   → VRAM 요구량에서 탈락. 검토 종료
(B) API 사용    → 가능. 단 이때 "오픈웨이트"는 이점이 아니다
                  비교 대상이 기존 상용 API로 바뀐다
(C) 도입 보류   → 채택

(A)가 막히는 순간 (B)의 성격이 달라집니다. 가중치가 공개됐다는 사실 자체는 그대로지만, 그 사실에서 기대했던 것이 전부 (A) 안에 들어 있었습니다.

남는 항목이 하나뿐이면 비교표에서 오픈웨이트 열은 지우는 편이 맞습니다. 열을 남겨두면 어느 순간 가산점처럼 쓰이는데, 실현되지 않는 이점에 점수를 주는 표는 결정을 흐립니다. 지운 뒤에는 기존 상용 API와 같은 표에서 성능 대비 가격만 놓고 비교하게 됩니다.

같은 모델을 두고 80.6%와 8%가 나왔습니다

성능 자료를 모으는 단계에서 숫자 두 개가 크게 갈렸습니다. 제공사가 발표한 SWE-bench 점수는 80.6%였고, 독립 평가에서 에이전트 루프로 측정한 pass@1은 8%였습니다. 열 배 차이라 어느 한쪽이 틀렸다고 보기 쉬운 간격입니다.

저희는 둘 다 맞는 값으로 봤습니다. 잰 대상이 다르기 때문입니다. 앞의 수치는 문제와 저장소가 주어진 상태에서 패치를 만들어내는 단발 과제를 잽니다. 뒤의 수치는 도구를 부르고 그 결과를 읽고 다음 행동을 정하는 반복 과정을 잽니다. 반복 과정에서는 중간 한 스텝만 어긋나도 그 뒤가 전부 어긋나 성공률이 가파르게 떨어집니다.

우리 용법이 에이전트 루프였습니다. 그래서 독립 평가 쪽을 더 신뢰했습니다. 제공사 벤치가 잘못됐다는 판단이 아니라, 제공사가 잰 것이 우리가 쓸 방식과 다르다는 판단입니다. 반대로 단발 코드 생성이 주 용법인 팀이라면 같은 자료를 보고 반대로 결정하는 편이 맞습니다.

발표 수치와 받을 수 있는 물건이 다릅니다

자료를 더 보다가 하나가 더 걸렸습니다. 성능이 개선된 최신 판은 API로만 제공되고, 공개된 가중치는 몇 달 전 프리뷰 시점의 것이었습니다. 발표 수치는 최신 판 기준인데 다운로드 링크는 옛 판을 가리키는 상태였습니다.

이 어긋남은 생각보다 자주 나옵니다. 모델 페이지 하나에 발표 자료와 가중치 저장소가 나란히 걸려 있으면 같은 물건으로 읽히기 때문입니다. 로컬 구동을 전제로 검토하는 쪽이면 벤치 표에 적힌 판이 실제로 받을 수 있는 판인지 한 번 확인해두는 편이 낫습니다. 이 확인을 건너뛰면 받아서 돌려본 뒤에야 수치가 안 나오는 이유를 찾게 됩니다.

결정과 재검토 조건

지금은 도입하지 않기로 했습니다. 세 가지가 겹친 결과입니다. 로컬 구동이 사양에서 막혔고, API로 쓰면 오픈웨이트가 이점으로 남지 않고, 우리 용법에 가까운 평가 수치가 낮았습니다.

다만 보류이지 배제가 아닙니다. 그래서 재검토 조건을 같은 문서에 적어뒀습니다. 정식판과 경량판이 나오면 사양을 다시 계산하고, 그때 공개 가중치와 발표 수치가 같은 판인지 확인하고, 에이전트 루프 기준 독립 평가가 새로 나왔는지 봅니다. 조건을 적어두지 않으면 보류는 그냥 잊힙니다.

모델 선정 순서

같은 계산을 다시 하게 될 것 같아 순서로 정리했습니다.

이 모델을 우리 장비에서 실제로 띄울 수 있는지 총 가중치 기준으로 계산합니다. 활성 파라미터가 아닙니다

못 띄운다면 비교표에서 오픈웨이트 열을 지웁니다. 상용 API와 같은 표에 놓고 비교합니다

벤치마크는 누가 쟀는지와 무엇을 쟀는지를 같이 봅니다. 용법이 에이전트 루프면 루프 평가를 봅니다

개선판이 API 전용이고 공개 가중치가 옛 판이면, 벤치 수치와 받을 수 있는 물건이 다릅니다

보류로 정했다면 재검토 조건을 같은 문서에 적어둡니다

경험상 3번과 4번이 가장 자주 어긋납니다.

다시 쓸 것은 숫자가 아닙니다

이 결론은 조건이 바뀌면 뒤집힙니다. 데이터센터 GPU 노드를 이미 보유한 조직이면 (A)가 살아 있어 결론이 정반대가 됩니다. 양자화 손실을 감수하고 경량판을 돌리는 선택지도 있고, 그 경우에는 벤치 수치와 실제 성능이 또 한 번 갈립니다.

그래서 위에 적은 사양과 점수는 몇 달이면 낡습니다. 다시 쓸 수 있는 쪽은 계산 절차입니다. 오픈은 라이선스 속성이지 실행 가능성 보증이 아닙니다. 실행할 수 없는 모델의 라이선스는 우리 비교표에서 아무 일도 하지 않습니다.