Intern-Decision-2B가 조용히 Hugging Face에 출시되었다. 카드의 GitHub 링크가 방금 404 오류를 멈췄다.

오늘 이른 시간에, internlm/Intern-Decision-2B의 모델 카드는 더 많은 정보를 위해 세 곳을 가리켰고, 그중 두 곳은 죽어 있었습니다: 데모 Space는 HTTP 401을 반환했고, github.com/internlm/Intern-Decision은 클릭한 누구에게나 404를 반환했습니다. 08:58 UTC 기준으로 두 번째 링크 뒤의 저장소가 존재합니다 — 공개 상태이고, 커밋 세 개가 쌓여 있으며, 훈련 코드, 두 개의 추론 백엔드, 10,751개의 테스트 행이 포함된 평가 번들, 96개 사례의 캘리브레이션 벤치마크 및 재현 가이드를 담고 있습니다. 이것이 이 모델이 2026년 9월 26일 05:36 UTC에 Hugging Face에 나타난 이후 이 모델에 대해 바뀐 유일한 점이며, 이는 Intern-Decision-2B를 "README에 접근할 수 없는 체크포인트"에서 "실제로 검사하고, 재현하고, 논쟁할 수 있는 체크포인트"로 옮기기에 충분합니다.

가중치 자체는 변경되지 않았고 모호하지도 않습니다. Intern-Decision-2B는 2,213,241,664개 파라미터의 멀티모달 구조화 의사결정 모델이며, Qwen/Qwen3.5-2B — 2026년 2월 28일자의 알리바바 베이스 — 에서 미세 조정되었고, Apache-2.0에 따라 공개되었으며 업스트림 Qwen 라이선스가 LICENSE-QWEN이라는 이름으로 그 옆에 보존되어 있습니다. 이것은 InternLM이 40초 만에 내놓은 세 가지 크기 중 중간 크기입니다: Intern-Decision-0.8B가 05:35:57에, 이것이 05:36:19에, Intern-Decision-4B가 05:36:37에 나왔습니다. 그중 어느 것에도 여전히 어떤 종류의 발표도 없습니다.

중간 크기가 별도의 글을 쓸 가치가 있는 이유는, 바로 이 크기에서 패밀리가 더 이상 예측 가능하게 동작하지 않기 때문이다. InternLM 자체 수치에 따르면 그것은 세 모델 중 가장 빠르고, 세 모델 중 캘리브레이션이 가장 나쁘다. 그리고 두 사실 모두 무엇이든 4.5기가바이트를 다운로드하기 전에 이해할 가치가 있다.

무엇이 확인된 사실이고, 무엇이 단지 공급업체의 말뿐인가?

두 가지 범주가 있으며, 이 둘은 구분해 두어야 합니다.

확인했습니다. 파일 목록 또는 HTTP 응답이기 때문입니다: 파라미터 수(2,592개의 F32와 2,213,239,072개의 BF16 가중치); 샤드 맵(3.76GB 언어 샤드, 612.5MB 비전 타워, 50.3MB 프로젝터, 약 4.43GB의 텐서와 대략 4.46GB의 리포지토리); 라이선스 쌍; 베이스 모델; 그 아래의 아키텍처(Qwen3_5ForConditionalGeneration: 24개 레이어, 히든 크기 2,048, 8개의 쿼리 헤드 대 2개의 키-값 헤드, 헤드 차원 256, 3개의 선형 어텐션 레이어 대 1개의 전체 어텐션 레이어의 반복 패턴, 유지된 다중 토큰 예측 레이어 하나, 그리고 262,144 위치 임베딩 상한); 리포지토리의 존재; 그리고 huggingface.co/collections/internlm/intern-decision의 모델 컬렉션이 이제 정상적으로 열리고 세 개의 체크포인트를 모두 나열한다는 사실.

공급업체가 보고했으며 재현되지 않음: 모든 정확도 수치, 모든 지연 시간 수치, 그리고 캘리브레이션 온도. 논문도, arXiv 항목도, 출시 게시물도, 변경 로그도, 독립적 평가도 없습니다 — "Intern-Decision"이라는 문자열을 검색해도 이 모델에 관한 결과는 아무것도 나오지 않습니다. 데모 Space는 여전히 401을 반환하는데, 이는 공개되지 않았다는 뜻이지 고장 났다는 뜻이 아닙니다. 2B 체크포인트에는 좋아요 1개와 다운로드 0회가 있습니다. InternLM 외부에서는 아무도 이것을 실행해 본 적이 없습니다.

추론 계약, 일어나는 순서대로

저장소에서 가장 많은 정보를 담고 있는 파일은 카드가 아닙니다. 바로 src/inference/engine.py와 함께 제공되는 inference.py입니다. Hub에 있는 이 둘은 프롬프트가 아니라 계약을 문서화하기 때문입니다.

• 제공할 것: state — 판단 대상이 되는 자료 — questions 스키마, 그리고 선택적으로 최대 8개의 이미지. 질문은 1~16개, 각각 최대 62개의 선택지.

• 각 질문의 선택지는 단일 토큰 기호에 매핑됩니다: A–Z, 그다음 a–z, 그다음 0–9. 62개 선택지 상한은 설계상의 선호가 아니라, 컨트랙트가 지정할 수 있는 단일 토큰 기호의 수와 정확히 일치합니다.

• 시스템 프롬프트, 상태, 스키마, 그리고 완전한 어시스턴트 JSON 스켈레톤은 각 필드마다 {{2}}<decision>{{/2}}{{3}} 플레이스홀더 하나와 함께 렌더링됩니다. 체크포인트의 채팅 템플릿과 빈 사고 블록은 그대로 유지됩니다.{{/3}}<decision> 플레이스홀더 하나와 함께 렌더링됩니다. 체크포인트의 채팅 템플릿과 빈 사고 블록은 그대로 유지됩니다.

• 인과적 순방향 패스가 한 번 실행됩니다. 로짓은 각 플레이스홀더 바로 앞 위치에서 읽힙니다 — 그 이후가 아니라, 생성된 토큰 위치에서도 아닙니다.

• 해당 필드의 허용된 후보 심볼에 대해서만 소프트맥스를 취하고, 체크포인트의 캘리브레이션을 적용한 다음, 그 심볼들을 원래 옵션 값으로 다시 매핑합니다.

이 카드는 이것이 무엇인지에 대해 단도직입적으로 밝힙니다: "이 API는 구조화된 후보 점수 산정을 수행합니다. 이것은 generate()를 호출하거나 자유 형식 텍스트를 샘플링하지 않습니다." DecisionEngine(max_length=8192)는 크기 초과 입력을 잘라내지 않고 거부하므로, 맞지 않는 요청은 마지막 문단을 조용히 잃어버리는 대신 요란하게 실패합니다. 백엔드 목록도 솔직합니다 — backend="hf"가 기본값이며 Hugging Face 리포지토리에서 유일하게 구현된 백엔드입니다. 알아둘 가치가 있는데, GitHub 릴리스에는 XTuner 백엔드도 함께 제공되며 둘은 수치적으로 동일하지 않기 때문입니다. InternLM 자체 평가 가이드에서도 그렇게 말합니다: "커널과 BF16 차이는 확률을 바꿀 수 있고 때때로 레이블도 바꿀 수 있습니다."

가운데의 이상

세 개의 체크포인트를 InternLM 자체 표에 나란히 놓으면, 그 모양이 이야깃거리가 될 만큼 충분히 이상하다.

• 일곱 개 스위트 평균 — Intern-Decision-0.8B 79.38, Intern-Decision-2B 84.68, Intern-Decision-4B 90.02. 가중치가 커질수록 예상하듯이 순서가 매겨져 있습니다.

• 단일 RTX 4090에서의 지연 시간 — 0.8B의 경우 평균 33.98ms, 2B의 경우 33.28ms, 4B의 경우 44.16ms입니다. 중간 크기가 세 가지 중 가장 빠른데, 그 차이는 단일 GPU에서는 노이즈로 볼 수 있을 만큼 작지만 평균, 중앙값(33.15ms), P95(33.55ms) 전반에서 일관됩니다.

• Brier 점수, 낮을수록 좋음 — 0.530, 0.437, 0.347. 적절한 채점 규칙이 보통 그렇듯이, 크기에 따라 단조롭게 변한다.

• 기대 보정 오차, 낮을수록 좋음 — 0.8B는 0.066, 이 2B는 0.100, 4B는 0.065. 중간 크기가 가장 나쁘고, 그 절반 크기 모델보다도 더 나쁩니다.

그 마지막 줄이 흥미로운 대목인데, 피팅된 온도들은 그것을 설명하기보다는 뒷받침한다. 각 체크포인트는 고유한 NLL 피팅 온도를 갖는다: 0.8B는 2.747760550703, 2B는 2.100509348278, 4B는 1.992418이다. 각각은 1,728개의 지정된 캘리브레이션 사례로, 1,693개는 홀드아웃한 상태에서, [0.01, 100] 범위의 역온도 탐색에서 음의 로그 우도를 최소화하여 피팅되었으며, 테스트 스위트 레이블은 의도적으로 피팅에서 제외되었다. 2B의 온도는 두 형제 모델의 온도 사이에 위치하는데, 이는 그 이상 현상이 피팅 아티팩트라면 예상할 수 있는 결과다. 그렇지 않다: 피팅된 값은 크기에 따라 단조롭지만, 캘리브레이션 후 오차는 그렇지 않다. InternLM 자체 측정에 따르면, 22억 개 매개변수 체크포인트는 자신이 얼마나 확신하는지 알려줄 때 세 모델 중 가장 신뢰할 수 없다.

그것이 결론이 되기 전에 두 가지 주의할 점이 있습니다. 동일 폭 10개 구간과 최대 확률 신뢰도를 사용하는 ECE는 이 표가 사용하는 작은 스위트에서 잡음이 많은 통계입니다 — Jevbench-Hard, 111개 항목이므로 전체 ECE 열은 100여 개의 질문과 구간화 선택에 달려 있습니다. 그리고 internlm/Intern-Decision-2B는 세 카드 중 4B 카드가 가진 추가 캘리브레이션 섹션을포함하지 않은 유일한 카드라서, 여기에는 문서가 더 많은 것이 아니라 더 적습니다. 0.100은 가중치에 대한 판정이 아니라 자체 temperature를 맞출 이유로 읽으세요.

저장소가 추가하는 것과 여전히 감추고 있는 것

GitHub 릴리스는 모델 카드보다 더 완전하며, 모델 카드 자체도 유익하다 — 논문 아티팩트를 의도한 연구소는 보통 결정론적 캘리브레이션 생성기와 해시 검증 평가 번들을 학습 런처와 함께 제공하지 않는다.

이제 공개된 것: 학습 코드와 masked-next-token 목표(정답 심볼은 레이블에만 나타나고 입력에는 결코 나타나지 않으며, 각 필드의 답은 해당 마커 바로 앞의 로짓으로 예측되고, 모든 필드는 하나의 순전파를 공유한다); SHA-256으로 검증된 해시와 행 수를 갖춘 일곱 개의 정확도 스위트; 채점 코드; 온도 피팅 및 리플레이 스크립트 — 여기서 리플레이는 0건의 결정을 바꾼다고 단정된다; 생성기와 오프라인 채점기를 포함한 96개 사례 분포 캘리브레이션 벤치마크; 그리고 POST /v1/decisions(/v1/jev의 별칭)로 루프백에서 제공되는 브라우저 데모.

저장소 자체의 표현에 따르면 명시적으로 제외되는 항목은 다음과 같습니다: "훈련 데이터, 비공개 캘리브레이션/검증 기록, 이미지, 준비 파이프라인, 모델 가중치는 포함되지 않습니다." 저장소에는 라이선스 파일이 전혀 없으므로, 가중치가 Apache-2.0임에도 코드의 조건은 명시되지 않습니다. 그리고 캘리브레이션 분할 구성 — 어떤 1,728개 사례가, 어디서 왔는지 — 은 공개되지 않은 채 남아 있으며, 이는 ECE 수치를 어디까지 확인할 수 있는지를 제한하는 유일한 누락입니다.

실제로 라우팅하는 크기들과, 라우팅하지 않는 하나의 크기

Intern-Decision-2B는 OrcaRouter에 없습니다. 이 모델의 모델 페이지는 404를 반환하며, 저희가 찾을 수 있는 한 어디에도 호스팅된 엔드포인트가 없고, 여기 있는 어떤 내용도 가용성 주장으로 해석되어서는 안 됩니다. 오늘 이 모델을 호출하는 유일한 방법은 체크포인트를 다운로드한 뒤 inference.py를 가중치 옆에서 실행하는 것입니다.

이 글에서 정말로 다루는 결정에 그것이 중요한 이유는, 아무도 서빙하지 않는 스코어러는 당신이 운영해야 하는 스코어러이기 때문입니다. 당신이 내리려는 폐쇄 집합 결정이 이 제품군이 하는 일 — 상태, 타입이 지정된 질문, 보정된 확률 — 과 형태가 비슷하다면, 호스팅 비교 대상은 TypeSafe's Jev 1.13, 즉 InternLM이 의도적으로 벤치마크 상대로 삼은 모델이며, OrcaRouter에서 100만 입력 토큰당 $0.042에 65K 컨텍스트와 첫 토큰까지의 시간 P50 178ms로 제공됩니다.

2.2억 개 파라미터 체크포인트를 로컬에서 실행하는 것과 호스팅된 분류기를 호출하는 것은 같은 구매는 아니지만 같은 문제입니다. 그리고공급자 정가가 0% 마크업으로 그대로 전달되는 하나의 키로 둘 다를 쓸 수 있다는 점이야말로, 아키텍처를 둘 중 하나에 걸어버리기보다 이 비교를 열어 두어야 하는 이유입니다.

이 그림을 바꿀 수 있는 것은 무엇일까요?

세 가지, 순서대로.

InternLM 외부의 누군가가 84.68 평균과 0.100 ECE를 재현해야 하며, 이제 저장소가 바로 그것을 가능하게 하는 것이며, 이것이 여기서의 실제 뉴스입니다. 시험은 공개되어 있고 해시로 검증되었습니다. 빠진 것은 오직 답안지뿐이며, 그 답안지는 이제 누구나 내려받을 수 있는 체크포인트입니다.

공급업체는 이것이 무엇을 위한 것인지 밝혀야 한다. 작동하는 학습 스택과 공개된 평가 번들은 갖췄지만 발표도, 코드 라이선스도, 호스팅 엔드포인트도 없는 모델은 아직 제품으로 결정되지 않은 연구 공개판으로 읽힌다. Apache-2.0 가중치는 한쪽을 주장하고, 빠진 코드 라이선스와 401 Space는 다른 쪽을 주장한다.

그리고 중간 크기는 존재할 이유가 필요하다. 2B가 0.8B보다 가지는 속도 우위가 실재하지만 미미하고, InternLM이 공개한 모든 지표에서 2B의 캘리브레이션이 세 모델 중 가장 약하다면, 대부분의 독자에게 정직한 권고는 4B를 위해 디스크 공간을 2.6배 지불하거나 더 작은 모델의 더 낮은 정확도를 받아들이라는 것이다. 2B를 옹호할 근거는 그것이 우연히도 가장 빠른 '빠른 모델'이라는 점인데, 이는 이 제품군의 마케팅이 만들어낸 프레이밍이 시사하는 것보다 더 빈약한 근거다.