Granite Switch 4.1.1: 모델 일부만 업데이트할 때 다시 시험할 것

작은 업데이트가 바꾸는 큰 질문

IBM은 2026년 10월 29일 Granite Switch 4.1.1을 소개하며, 기반 모델을 다시 학습하지 않고 음성 전사 모델과 Decision 어댑터를 갱신했다고 설명했다. 모델 카드에 적힌 4.1.1 릴리스 날짜는 10월 27일이다. 발표일과 모델의 릴리스 표기를 구분할 필요가 있다. IBM 발표 · 조사 커밋의 모델 카드

이 변화의 핵심은 모델 순위보다 개선하는 단위다. 공통 기반 모델을 새로 만들 때마다 모든 기능을 함께 교체하는 대신, 특정 판단 기능을 맡은 어댑터나 음성 입력 부분을 발전시킬 수 있다. 여러 기능을 한 서비스에서 운영하는 팀이라면 학습·검증·배포의 책임을 어떻게 나눌지 검토할 계기가 된다.

다만 공급자가 말하는 패치 버전의 호환성은 읽는 범위를 정해야 한다. 모델 카드는 Decision의 프롬프트 형식·호출·결과 읽는 방법이 유지된다고 명시한다. 호출하던 코드를 유지할 수 있다는 설명과 같은 입력에 같은 판단이 나온다는 보장은 다르다. 가중치를 개선했다면 경계에 있던 입력의 결과가 달라질 수 있으며, 그 변화가 우리 업무에서도 개선인지는 따로 평가해야 한다. 이것은 이 글의 분석이다.

이 글은 10월 30일 확인한 30B 합성 모델의 커밋 eb206725와 코드 저장소 43ccd291을 기준으로 구조와 업데이트 판단을 설명한다. 모델을 설치하거나 추론하지 않았다. 아래 자료는 직접 작성한 평가 설계이며, 성능 비교나 실행 결과로 제시하지 않는다.

무엇을 함께 묶고, 무엇을 바꿨나

Granite Switch의 어댑터는 공통 기반 모델에 덧붙여 특정 기능을 수행하게 하는 가중치다. 조사한 30B 모델은 guardian-core와 decision이라는 두 aLoRA 어댑터를 포함한다. 기반 모델은 granite-4.1-30b다. 어댑터 선택은 채팅 템플릿에 전달한 adapter_name에서 시작하며, 템플릿이 넣은 제어 토큰을 통해 모델 내부의 적용 구간이 결정된다. 모델 구성표 · 구조 설명

부분	맡는 일	이번 업데이트를 읽는 기준
기반 모델	공통 문맥 처리와 언어 생성의 바탕	IBM은 기반을 그대로 유지했다고 설명한다
Decision 어댑터	상태·질문·선택지를 받아 선택지 확률을 읽는 결정 기능	가중치 갱신, 호출·결과 읽기 형식 유지
Guardian Core 어댑터	주어진 판단 기준에 따라 위험 여부를 평가	포함 어댑터는 같음. 모든 요청에 자동으로 적용되는 필터라고 해석하지 않음
음성 전사기	소리를 문자로 바꿔 언어 모델 입력에 넣음	다국어·문장부호·대문자 출력으로 입력 텍스트가 달라질 수 있음

모델 카드의 설명은 하나의 서비스 주소로 대화·결정·음성 입력을 다룰 수 있다는 것이다. 모든 기능이 동시에 항상 켜진다거나, 어떤 기능을 쓸지 업무 대신 판단해 준다는 뜻은 아니다. 응용 프로그램은 어떤 요청에 어떤 어댑터를 선택하고 반환값을 어디에 사용할지 정해야 한다.

공식 코드 문서는 aLoRA가 기반 모델의 공통 KV 캐시를 이용하도록 구성돼, 어댑터를 바꾸는 흐름에서 앞부분 계산을 재사용할 수 있다고 설명한다. KV 캐시는 이미 읽은 문맥의 중간 계산을 담는 저장 공간이다. 여기서 재사용한다는 것은 같은 실행 흐름에서 문맥을 다시 계산하는 부담을 줄이는 구조다. 배포 버전을 바꾼 뒤 이전 서버의 캐시까지 안전하게 이어 쓸 수 있다는 운영 보장으로 확대하지 않는다. 실제 메모리·지연 절감도 이 글에서는 측정하지 않았다. aLoRA와 캐시 설명

한 서비스 주소 안에서도 음성과 판단은 순서대로 이어진다

음성 경로를 보면 업데이트 시험을 나눌 이유가 더 뚜렷해진다. 현재 코드 문서는 이를 alpha 단계의 전사 연쇄 처리로 설명한다. 소리를 작은 ASR 모델로 전사한 뒤, 전사문을 일반 텍스트 토큰으로 언어 모델에 넣는다. 음성 인코더와 언어 모델을 공동 학습한 직접 연결 구조로 설명하지 않는다. 음성 경로 설계

따라서 전사기가 바뀌면 Decision 가중치가 같더라도 최종 판단이 달라질 수 있다. 부정어가 보존되거나 문장 경계가 바뀌면, 뒤에서 읽는 입력이 달라지기 때문이다. 반대로 전사문이 같아도 Decision 업데이트로 선택지의 순서가 달라질 수 있다. “최종 분류가 달라졌다”는 관측 하나로 어느 부분이 원인인지 알 수 없다.

공식 자료 사이의 차이도 여기서 걸러야 한다. 10월 29일 발표는 음성 전사를 10개 언어라고 소개하지만, 조사한 합성 모델 카드는 영어·프랑스어·독일어·스페인어·포르투갈어·이탈리아어·일본어의 7개 언어를 명시한다. 이 글은 해당 모델 카드의 좁은 범위로 다룬다. 그 목록에 한국어는 없다. 기반 언어 모델이 한국어를 다룬다는 사실을 한국어 음성 입력 지원으로 옮겨 읽으면 안 된다. 발표 · 합성 모델의 언어 목록

단일 서비스 주소도 자원 비용을 없애지는 않는다. 음성 문서는 전사기가 GPU 메모리를 사용할 때 vLLM의 KV 캐시 선할당과 여유 메모리를 함께 고려하도록 설명한다. 긴 전사문은 문맥을 차지하며, 요청이 허용 길이를 넘으면 길이 오류가 날 수 있다. 요청 경로가 단순해진 이점과 내부 자원을 관리할 일은 함께 남는다. 음성 처리 조건

사례: 설비 점검 음성 메모를 업데이트 전후로 비교하기

해외 설비팀이 영어 음성 메모를 남기고, 시스템이 점검 필요, 재가동 확인, 정보 부족 중 하나를 제안한다고 가정하자. 이 제안은 담당자의 검토 대기열을 정할 뿐, 설비를 직접 정지·재가동하지 않는다. 모델 출력과 현장 조작을 분리한 가상 업무 설계다.

시험 문장을 “Pump seven is not ready to restart. Inspection is still pending.”으로 직접 작성한다. 기대하는 업무 상태는 ‘점검 필요’다. 실제 녹음·모델 응답은 이 글에 없으며, 운영 평가에서는 사용 권한이 있는 원음과 사람이 확인한 전사문을 준비해야 한다.

우선 다음 두 경로를 비교한다. 업데이트 전후 결과 칸은 실제 시험 때 채운다.

비교 입력	고정할 것	확인할 결과
사람이 확정한 동일 전사문	문장·질문·선택지·업무 규칙	결정 기능에서 선택지별 값과 최종 제안이 어떻게 바뀌는가
동일한 원음	오디오 파일·질문·선택지·업무 규칙	전사문과 최종 제안이 함께 어떻게 바뀌는가

첫 행에서도 차이가 나면 전사기만의 영향으로 설명할 수 없다. Decision 경로의 가중치·템플릿·실행 설정부터 대조해야 한다. 첫 행은 같은데 둘째 행이 달라지면 전사문을 나란히 놓고 not, 설비 번호, 점검 완료 여부가 보존됐는지 확인할 이유가 생긴다. 다만 비결정적 출력이나 런타임 변화가 함께 있으면 이 비교만으로 원인을 확정할 수 없다.

첫 문장만 시험하면 업데이트를 쉽게 통과시킬 수 있다. 같은 설비의 반대 상태와 정보 부족도 추가한다. 아래는 모델이 실제로 반환한 답이 아니라 사람이 먼저 정할 판정 기준이다.

직접 작성한 메모	기대하는 업무 구분
“Pump seven is ready to restart. Inspection is complete.”	재가동 확인 제안. 실제 조작 승인은 별도
“Pump seven was not ready yesterday. Inspection is complete now.”	과거 상태와 현재 상태 구분
“Pump seven. Please check.”	재가동 가능 여부를 채워 넣지 않고 정보 부족으로 처리
“Pump eleven is ready. Pump seven is still waiting for inspection.”	설비별 상태를 분리하고 11번 상태를 7번에 붙이지 않음

가장 중요한 실패는 단순 오분류 수와 따로 기록한다. 예를 들어 점검 대기 메모를 재가동 확인으로 제안한 건수를 먼저 보고, 점검이 끝난 메모를 검토로 보낸 부담도 함께 본다. 어떤 오류를 허용할지는 실제 업무 담당자가 정해야 한다. 여기서는 합격률이나 자동 처리 기준 숫자를 만들지 않는다.

정밀한 원인 분석을 위해 이전 전사기와 새 Decision, 새 전사기와 이전 Decision을 교차 조합할 수도 있다. 그러나 그 조합이 공식적으로 지원되고 재현 가능하다는 확인이 선행돼야 한다. 이 글은 임의의 혼합 체크포인트가 작동한다고 주장하지 않는다. 처음에는 지원되는 이전·새 배포 묶음 두 개와 고정 전사문 비교만으로 시작하는 편이 조사 범위를 명확히 한다.

main 대신 무엇을 기록해야 다시 돌아갈 수 있을까

모델 카드는 main이 최신 개정을 가리킨다고 설명한다. 이름만 같은 모델을 다시 내려받는 것으로 이전 시험을 재현할 수는 없다. 카드에는 새 태그 granite-switch-4.1.1-30b도 적혀 있으나, 10월 30일 익명 공개 메타데이터 조회에서는 그 태그 조회가 404였고 refs 목록에도 없었다. 이는 확인 시점의 조회 결과이며 영구 부재나 가중치 오류의 증거는 아니다. 이 글은 조회 가능한 전체 커밋 eb206725d03c0f1c409ce3aa512afe325fdf8731을 자료 기준으로 사용했다. 모델 다운로드·로딩 성공은 별도로 확인해야 한다. 태그 목록 조회

여기서 한 단계 더 확인할 부분이 있다. 조사한 config.json은 asr_enabled: true지만 asr_model_id는 null이다. 코드 문서는 이때 기본 전사 모델을 사용한다고 설명한다. 합성 모델 커밋을 고정했다고 외부 전사 모델의 실제 해석 버전까지 기록된 것은 아니다. 실행 환경에서 무엇을 받아 로드했는지 별도로 남겨야 한다. 문서에 없는 전사기 고정 옵션을 추측해 명령으로 제시하지 않는다. 조사 설정 · 기본 전사 모델 처리

다음처럼 다시 배포할 수 있는 한 묶음을 기록하는 것이 이 글의 제안이다. 패키지 관리 도구의 자동 보장이나 제품에 내장된 되돌리기 기능을 뜻하지 않는다.

배포 묶음 이름 / 조사·시험 날짜:
합성 모델 ID / 전체 커밋 / 내려받은 파일 해시:
실제로 로드한 전사 모델 / 커밋 / 파일 해시:
채팅 템플릿·어댑터 매핑 / 질문·선택지 정의:
granite-switch·추론 런타임·장치·정밀도·음성 처리 설정:
업무 규칙 / 사람 검토로 넘길 조건:
시험 입력 묶음 / 사람이 확인한 정답 버전:
이전 묶음 위치 / 되돌린 뒤 다시 확인할 입력:

체크포인트를 재구성하는 팀은 기반 모델과 개별 어댑터의 원본 커밋·구성 설정까지 보관한다. 이미 합성된 모델을 사용하는 팀은 배포 파일과 런타임·외부 전사기의 실제 조합부터 고정한다. 전자가 기능 조합의 자유를 주는 대신 관리할 관계도 늘린다.

업데이트 뒤 중요한 오분류가 생기면 모델 파일 하나만 바꿔 되돌리기보다, 검증한 이전 묶음을 복원하고 같은 입력을 다시 확인한다. 전사기나 템플릿은 새 상태로 둔 채 언어 모델만 되돌리면 이전 결과가 재현되지 않을 수 있다. 운영 중 캐시를 이어 쓰거나 어댑터를 무중단 교체하는 절차는 여기서 검증하지 않았다.

어느 팀에 모듈형 업데이트가 도움이 될까

여러 업무가 공통 문맥을 읽되 서로 다른 결정을 내려야 하고, 기능마다 개선 주기가 다르다면 Granite Switch의 구성이 검토할 만하다. 공통 기반을 유지하면서 기능을 발전시키고, 한 서비스 주소에서 연결하는 이점이 있다. 그 대가로 각 기능의 입력·출력 계약과 조합 버전을 관리해야 한다.

반대로 텍스트 답변 한 종류만 필요하거나, 이미 정형 데이터와 규칙으로 판단이 끝나는 업무라면 복수 어댑터 구성의 이점이 작을 수 있다. 음성과 언어 서비스의 장애·확장 주기를 완전히 분리해야 하는 팀도 별도 전사 서비스와 비교할 필요가 있다. 하나로 묶는 설계가 항상 운영상 유리한 것은 아니다.

첫 도입에서는 한 업무의 기존 경로를 유지한 채 후보 결과를 나란히 기록하고, 고정 전사문과 원음의 차이부터 확인할 수 있다. 업데이트 평가 기록지는 위 두 경로, 중요한 오류, 배포 묶음과 되돌릴 조건을 채우는 자체 제작 양식이다. 실행 코드나 완성된 품질 인증서는 아니다.

음성 모델별 출력과 언어를 고르는 단계라면 Granite Speech 선택법, 분류값을 자동 처리·사람 검토에 연결하는 단계라면 d1 결정 모델 분석으로 이어 읽을 수 있다. 이번 글의 역할은 그 기능들을 업데이트할 때 변경 부품과 업무 결과를 연결해 다시 비교하는 방법을 남기는 것이다. 기록지는 저장해 다음 개정에도 사용할 수 있고, 후속 분석은 AI 시스템 모음과 RSS에서 확인할 수 있다.