Granite 4.2 3B·8B·30B, 내 장비에는 어느 크기가 맞을까

IBM이 공개한 Granite 4.2 추론 모델은 3B, 8B, 30B 크기이며 모두 밀집형 구조예요. 입력에 따라 일부 전문가만 고르는 MoE¹가 아니라 모델의 밀집 파라미터 경로를 사용해요. 세 모델 모두 사고 모드와 도구 호출²을 지원하고 Apache 2.0 라이선스로 공개됐어요. 공통 기능을 지원하더라도 메모리 필요량과 우리 문의에 대한 답의 적합성은 모델마다 확인해야 해요.

처음 비교할 때는 반품 기한, 개봉 여부, 구성품 조건을 찾아 한두 문장으로 답하게 해요. 같은 질문과 원문을 3B·8B·30B에 주고, 필요한 조건을 빠뜨렸는지와 근거에 없는 내용을 보탰는지 기록해요. 이 작은 작업을 고정해 두면 모델 이름이나 응답 속도가 아니라 업무에 영향을 주는 차이를 볼 수 있어요.

짧은 규정 문장에서 반품 기한과 조건을 찾게 하고, 실제 문의 표현을 반영한 질문 열 개를 같은 순서로 준비해요. 답변마다 필수 조건이 빠졌는지, 원문에 없는 내용을 단정했는지 표시해요. IBM 모델 카드에는 한국어가 시험 언어로 포함돼 있지만, 사내 상품명이나 줄임말, 오래된 안내 문구가 검증됐다는 뜻은 아니에요.

예를 들어 사내 별칭 ‘구성품 세트’를 모델이 다른 물건으로 해석한다면 같은 표현을 여러 질문에 넣어 반복되는지 확인해요. 상담원은 답변에 붙은 근거 문장을 안내 원문과 직접 대조해요. 3B가 필요한 조건을 꾸준히 짚고 수정 부담도 작다면 더 큰 모델을 추가할 이유가 아직 없을 수 있어요. 결과가 애매하면 질문과 기준 답을 함께 보관해 다음 후보에도 그대로 써요.

IBM은 8B와 30B에 코드 수정, 터미널, 검색 같은 도구를 사용하는 에이전트 작업을 추가로 학습했다고 설명해요. 반품 문의에서 근거를 찾고, 요점을 정리하고, 답변 초안을 만드는 단계 중 어디서 끊기는지 먼저 확인해요. 도구 사용 학습은 고객지원 앱과 자동으로 연결된다는 뜻이 아니므로, 각 단계의 입력과 결과를 따로 살펴요.

실행 프로그램³이 모델의 채팅 템플릿과 도구 호출 형식을 지원해야 하고, 검색이나 티켓 작성 도구에 접근할 권한도 따로 설정해야 해요. 같은 문의를 8B와 30B에 주고 호출 요청이 실행기가 이해하는 형식으로 나가는지, 도구 실행 뒤 답변에 근거가 반영되는지 확인해요. 모델이 도구 사용을 제안한 것과 실행기가 실제로 검색을 수행한 것은 서로 다른 단계예요.

30B의 가중치 300억 개를 BF16⁴ 가중치당 2바이트로 계산하면 30,000,000,000×2=60,000,000,000바이트, 약 60GB예요. 4비트로 단순 계산한 값은 약 15GB예요. 둘 다 가중치만 놓고 본 이론적 하한이며, 모델이 실제로 필요로 하는 실행 메모리 전체를 뜻하지 않아요.

실행 중에는 파일 형식의 부가 정보, 버퍼, 문맥에 따라 커지는 KV 캐시⁵, 운영체제와 다른 앱의 사용량도 더해져요. 따라서 24GB 장비에서 4비트 파일을 열 수 있다는 사실만으로 긴 문의 문서까지 여유 있게 처리한다고 판단하지 않아요. 실제 모델 파일과 실행기, 사용할 문의 길이를 정하고 평소 앱을 켠 상태에서 검색부터 답변 완료까지 되는지 살펴요. CPU⁶ 오프로딩⁷이 일어나면 실행은 끝나더라도 대기가 길 수 있으니 메모리 사용량과 로그, 첫 토큰⁸, 완료 시간도 함께 봐요.

IBM 모델 카드는 기본 문맥 128K와 512K 확장을 안내해요. 긴 입력을 사용하려면 실행기의 확장 설정과 메모리 여유를 확인해야 해요. 짧은 반품 안내는 전체를 넣고 시작할 수 있지만, 여러 정책이 섞인 긴 파일은 질문과 무관한 부분도 처리하므로 첫 답변이 늦어질 수 있어요.

입력이 길어지면 첫 답변 전에 처리할 토큰이 늘고 KV 캐시에도 영향을 줘요. 여러 페이지에서 개봉·구성품·기간 조건을 찾아야 한다면 전체 입력과, 관련 구절을 검색해 필요한 부분만 전달하는 방식을 비교해요. 검색 방식은 문맥을 줄여도 예외 조항을 놓칠 수 있으니 선택된 구절에 상담원이 확인할 근거가 실제로 들어 있는지 봐요. 질문과 근거 문장을 고정하고 첫 토큰까지의 대기와 답변 생성 시간을 나누어 기록하면 입력 범위와 실행 설정을 조정할 근거가 돼요.

Granite 4.2에는 사고 모드, 비사고 모드, 짧게 생각하는 저노력 모드가 있어요. 규정 한 문장에서 조건을 찾는 일과 여러 예외가 얽힌 문의는 필요한 추론이 달라요. 같은 모델과 질문에서 모드만 바꾸고, 답이 핵심 조건을 보존하는지와 걸린 시간을 함께 비교해요.

BF16 원본과 4비트 변환본도 같은 메모리·품질 조건이 아니에요. 변환본은 배포자와 양자화⁹ 방식에 따라 달라질 수 있으므로 파일 이름만으로 답의 질이나 속도 배율을 정하지 않아요. 모델 ID, 파일 형식, 실행기, 문맥 길이, 사고 모드, 같은 열 개 문의를 기록해 어느 조건을 바꿨는지 남겨요. 그래야 품질이나 시간이 달라졌을 때 양자화 때문인지 모드나 실행 설정 때문인지 살펴볼 수 있어요.

3B가 짧은 문의에 충분하지만 여러 조건을 반복해서 놓친다면 8B에서 그 오류가 줄어드는지 같은 질문으로 확인해요. 도구를 쓰는 실제 업무가 8B에서 중단되고, 30B에서 근거와 결과가 개선될 때는 그 모델에 필요한 메모리 구성을 따져 볼 수 있어요. 세 모델의 차이가 문의 처리 결과를 바꾸지 않는다면 큰 장비가 해결할 문제도 분명하지 않아요.

마지막 비교표에는 모델 ID, 파일 형식, 실행기, 문맥 길이, 모드, 질문 묶음과 수정이 필요했던 답을 함께 적어요. 부족한 점이 한국어 용어인지 도구 호출인지 긴 문맥인지 구분하면 안내 문구 정리나 검색 방식 개선이 장비 교체보다 나은 해결책일 수도 있어요. 장비별 일반 속도 표를 Granite 4.2의 전용 측정 결과로 읽지 말고, 실제 작업에서 반복되는 실패가 더 큰 모델로 줄어드는지 확인한 뒤 선택해요.