Shannon 3.1

대부분의 모델 출시는 성능 주장을 일단 믿으라고 요구하고, 벤치마크 표가 논쟁을 정리해 주기를 기다립니다. 이번 것은 확인하기가 더 쉽습니다. 탭 두 개를 열고 같은 프롬프트를 shannon-3과 shannon-3.1에 넣은 뒤 지켜보세요. 답이 도착하는 속도 차이는 미묘하지 않으며, 렌더링 눈속임도 아닙니다. Shannon 3.0은 의도적으로 제한되어 있었습니다. Shannon 3.1은 그렇지 않습니다.

01Shannon 3.1에서 실제로 바뀐 것

Shannon 3.0은 이 제품군을 정의하는 요소, 즉 반복 추론 루프를 도입했습니다. 모델은 첫 생각으로 답하지 않습니다. 생각하고, 초안을 쓰고, 그 초안을 질문에 비추어 스스로 검토하고, 개선합니다. Lite는 그 루프를 한 번 실행하고, Pro는 초안 작성 전 지식 수집 단계를 포함한 전체 루프를 실행합니다. 이 설계는 Shannon 3 리서치 아티클에 자세히 설명되어 있으며, 3.1에서 바뀐 부분은 하나도 없습니다.

바뀐 것은 그 아래의 기계 장치입니다. Shannon 3.0은 서드파티 추론 호스트를 통해 서비스되었습니다. 모델을 출시하기에는 합리적인 방식이지만, 운영하기에는 제약이 많은 방식입니다. 남의 서빙 설정, 남의 큐, 남의 컨텍스트 상한, 그리고 초당 몇 토큰까지 허용되는지에 대한 남의 판단을 그대로 물려받게 됩니다. Shannon 3.1은 우리가 직접 구성한 서빙 스택 위에서 자체 GPU 클러스터로 실행되며, 이 글에 나오는 모든 핵심 수치는 그 하나의 결정에서 파생된 결과입니다.

	Shannon 3.0	Shannon 3.1
실행 위치	서드파티 호스트	자체 GPU 클러스터
컨텍스트 윈도우	32,768	196,608
출력 스트리밍	페이싱 / 속도 제한	엔진 전속력
가중치	호스트 기본값	4비트 NVFP4
디코딩	표준	추측 디코딩
추론 루프	생각 → 초안 → 검토 → 개선	변경 없음
거절 레이어	없음	없음
모델 ID	shannon-3, shannon-3-pro	shannon-3.1, shannon-3.1-pro

02Shannon 3.1이 10-15배 빠르게 느껴지는 이유

속도 수치는 사람들이 가장 먼저 묻는 항목이므로, 그것이 어디서 오는지 정확히 밝힐 가치가 있습니다. 독립적인 기여 요인이 두 가지 있고, 그중 더 큰 쪽이 덜 화려한 쪽입니다.

속도 게이트를 제거했습니다

Shannon 3.0의 출력은 페이싱 레이어를 거쳤습니다. 토큰은 엔진을 떠나 붙잡혀 있다가 일정에 따라 여러분의 연결로 방출되었습니다. 이는 사고나 버그가 아니었습니다. 공유 추론 호스트가 병목일 때, 출력을 페이싱하면 부하가 고르게 퍼지고, 긴 생성이 슬롯을 독점하는 것을 막으며, 스트림이 폭발적으로 몰리는 대신 예측 가능하고 읽기 좋은 리듬으로 도착합니다. 방어할 만한 엔지니어링 선택이었고, 동시에 모든 사용자에게 매 응답마다 실제 벽시계 시간을 치르게 했습니다.

Shannon 3.1에는 속도 게이트도 노출 페이싱도 없습니다. 토큰은 엔진이 생성하는 즉시 여러분의 스트림에 기록됩니다. 엔진이 빠르게 생성하고 있다면, 빠르게 생성되는 모습을 그대로 보게 됩니다. 모델과 여러분의 터미널, 채팅 창, SSE 리더 사이에 완충 버퍼가 없습니다. 2,000 토큰짜리 분석이나 생성된 코드 파일처럼 긴 답변이라면, 이 요인 하나만으로도 여러분이 체감할 개선의 대부분이 설명됩니다.

솔직히 밝혀 둘 결과 하나: 스트림이 이제 덩어리지게 도착합니다. 추측 디코딩(아래 참조)은 수락된 토큰을 짧은 연속 구간으로 방출하므로, 텍스트가 메트로놈처럼 한 단어씩 나오는 대신 눈에 띄는 덩어리로 도착할 수 있습니다. 3.0의 매끄러운 리듬에 맞춰 UI를 만들었다면 그대로 동작합니다. 토큰 순서와 내용은 영향을 받지 않습니다. 다만 타자기 같은 느낌을 선호했다면 클라이언트 쪽에서 직접 완만하게 처리하는 편이 좋습니다. 우리는 대부분의 사람이 그 몇 초를 되찾는 쪽을 택하리라 봅니다.

엔진 자체가 빨라졌습니다

게이트를 없애는 것은 게이트 뒤에 있는 것이 빠를 때만 도움이 됩니다. 두 번째 기여 요인은 03절에서 설명하는 서빙 스택입니다. 자체 클러스터의 최신 세대 FP4 네이티브 가속기 위에서 돌아가는 4비트 NVFP4 가중치와 추측 디코딩입니다. 이 둘이 함께 게이트 제거로 드러난 천장을 끌어올립니다.

종단 간 응답 지연의 상대 비교, Shannon Lab 내부 평가, 2026년 9월. 범위는 프롬프트 길이와 티어에 따라 달라집니다. Lite의 짧은 프롬프트는 하단에, Pro의 긴 생성은 상단에 가깝습니다.

03추측 디코딩이 실제로 하는 일

"추측 디코딩 추론"은 마케팅 용어로 남용되므로, 여기서는 그 메커니즘을 그대로 설명하겠습니다.

언어 모델은 보통 순전파 한 번에 토큰 하나를 만들어냅니다. 그 패스를 지배하는 것은 연산이 아니라 메모리 대역폭입니다. 무엇을 계산하든 가중치를 읽어야 하고, 읽는 시간이 계산 시간보다 훨씬 깁니다. GPU는 연산 유닛을 놀린 채 메모리를 기다리는 데 대부분의 시간을 씁니다. 500 토큰을 생성한다는 것은 그 지연을 순차적으로 500번 지불한다는 뜻입니다.

추측 디코딩은 이 순차성을 공략합니다. 작고 값싼 초안 모델이 다음에 올 법한 토큰을 네 개나 여덟 개쯤 짧게 연속으로 제안합니다. 그러면 메인 모델이 그 구간 전체를 단 한 번의 배치 순전파로 평가하는데, 비싼 부분(가중치 읽기)은 어차피 한 번만 일어나므로 토큰 하나를 평가하는 것보다 비용이 거의 늘지 않습니다. 메인 모델이 동의한 제안 토큰은 모두 수락되어 즉시 방출됩니다. 처음 불일치가 나오는 지점에서 구간이 잘리고, 거기서부터 일반 디코딩이 재개됩니다.

실제 효과는 수락률이 만듭니다. 상용구, 코드 구조, 논증을 잇는 연결 문장처럼 예측 가능한 텍스트에서는 초안 모델이 잘 맞혀서 긴 구간이 한꺼번에 확정됩니다. 정말 어려운 토큰에서는 수락률이 떨어지고, 시스템은 평범한 한 번에 한 토큰 디코딩으로 우아하게 되돌아갑니다. 이 비대칭성이야말로 우리가 원하는 것입니다. 쉬운 부분을 가속하고 어려운 부분은 건드리지 않습니다.

4비트 가중치가 같은 문단에 들어가는 이유

병목이 메모리 대역폭이므로, 가중치를 줄이는 것은 메모리 사용량뿐 아니라 속도에 직결되는 지렛대입니다. NVFP4는 블록 단위의 세밀한 스케일링을 갖춘 4비트 부동소수점 형식이며, 이 덕분에 예전 4비트 정수 양자화 방식이 잃었던 정확도를 유지할 수 있습니다. 순전파마다 읽어야 할 바이트가 대략 4분의 1이 된다는 것은 메모리를 기다리는 시간도 그만큼 줄어든다는 뜻이고, 196K 윈도우가 요구하는 롱 컨텍스트 KV 캐시를 위한 여유도 훨씬 커집니다.

두 요소는 단순히 더해지는 것이 아니라 곱해집니다. 패스당 바이트가 줄고, 방출 토큰당 패스 수도 줄어듭니다. 이것이 게이트 없는 전속력 스트리밍을 페이싱으로 되찾아야 할 비용이 아니라 감당 가능한 서비스로 만듭니다. 3.0의 페이싱 레이어가 하던 일이 바로 그 비용 회수였습니다.

04196,608 토큰: 6배 윈도우가 열어 주는 것

Shannon 3.0의 윈도우는 32,768 토큰이었습니다. 문서가 아니라 작업 세션 정도의 크기입니다. 산문으로 대략 70-80페이지에서, 추론 루프가 자기 생각에 쓰는 몫을 빼고, 시스템 프롬프트를 빼고, 지금까지의 대화를 빼야 합니다. 실제 업무는 그 벽에 끊임없이 부딪혔고, 청킹·요약·자기 자료에 대한 검색 같은 우회책은 모두 지키려던 바로 그것을 훼손합니다. 196,608 토큰은 다른 범주의 문제입니다.

구체적으로는 영어 텍스트 400-500페이지 수준, 또는 테스트와 README를 포함한 중간 규모 코드베이스, 또는 한 프로젝트의 1년치 회의록, 또는 부속 서류를 모두 갖춘 계약서 일습을 하나의 대화에 담고, 하나의 질문으로 다룰 수 있다는 뜻입니다. 여러분과 자료 사이에 청킹 레이어가 끼지 않습니다.

• 저장소 전체에 대한 질문. 이미 의심하던 파일 세 개를 붙여넣는 대신, 코드를 통째로 올리고 왜 버그가 프로덕션까지 도달하는지 물어보세요. 모델은 여러분이 포함할 생각조차 못 한 파일을 찾아낼 수 있습니다.
• 검색 없는 장문 분석. 검색은 모델이 무엇을 볼 수 있는지 결정하는 손실 있는 사전 필터입니다. 196K에서는 검색을 건너뛰고 모델이 전부 읽게 할 수 있으며, 이는 정작 필요한 구절이 애초에 검색되지 않는 실패 유형 전체를 없앱니다.
• 일관성을 유지하는 대화. 긴 작업 세션이 더 이상 자기 시작 부분을 조용히 잃어버리지 않습니다. 세 번째 메시지에서 정한 제약이 여든 번째 메시지에서도 여전히 적용됩니다.
• 추론 루프를 위한 여유. 루프 자체의 사고, 초안 작성, 검토도 컨텍스트를 씁니다. 3.0에서는 이 단계들이 부족한 예산을 두고 여러분의 자료와 경쟁했습니다. 3.1에서는 넉넉히 들어가며, 품질 향상과 윈도우 확대가 함께 온 이유의 일부가 여기에 있습니다.
• 크고 혼합된 입력. 이미지, 추출된 문서 텍스트, 코드를 한 턴에 담을 수 있으며, 그중 무엇을 포함할 여력이 있는지 선별할 필요가 없습니다.

우리 모델을 포함해 모든 롱 컨텍스트 모델에 해당하는 솔직한 단서 하나: 큰 윈도우는 용량이지, 그 전체에 걸친 균일한 주의력의 보장이 아닙니다. 구조화는 여전히 도움이 됩니다. 질문을 끝부분에 두고, 문서에 이름표를 달고, 무엇을 찾아야 하는지 모델에 알려 주는 것은 5K에서는 별 차이가 없지만 150K 토큰에서는 결과를 측정 가능하게 개선합니다.

05Lite와 Pro: shannon-3.1과 shannon-3.1-pro

두 티어는 추론 루프를 얼마나 실행하는지에서 갈리며, 둘 중 하나를 고를 때 중요한 차이는 그것뿐입니다.

	shannon-3.1 (Lite)	shannon-3.1-pro (Pro)
추론	단일 패스	전체 루프 + 지식 수집
자기 검토	없음	있음
컨텍스트 윈도우	196,608	196,608
스트리밍	전속력, 게이트 없음	전속력, 게이트 없음
비전 & 문서	지원	지원
이미지 생성 도구	지원	지원
적합한 용도	대부분의 작업, 대량 처리	어려운 질문, 첫 초안으로 부족할 때

기본은 Lite를 쓰세요. 좋은 추론 모델의 한 번 패스면 실제 요청의 대다수를 처리할 수 있고, 3.1에서는 루프를 기다린다는 느낌이 들지 않을 만큼 빠릅니다. 첫 답변이 대개 교훈적인 방식으로 틀리는 질문 — 아키텍처 트레이드오프, 적대적 분석, 유능한 동료에게 하룻밤 재워 보라고 하고 싶은 종류의 문제 — 에는 Pro를 꺼내세요. Pro의 자기 검토 단계는 장식이 아닙니다. 여러분이 찾아내기 전에 모델이 자기 오류를 찾아내는 과정입니다.

06지능 32% 향상, 그리고 이 숫자를 읽는 법

Shannon Lab의 자체 평가는 Shannon 3.1을 Shannon 3.0 대비 지능 32% 향상으로 놓습니다. 이것이 무엇이고 무엇이 아닌지 분명히 하고 싶습니다.

이는 우리 수치이며, 우리 내부 평가 스위트에서, 사람들이 실제로 이런 모델에 가져오는 작업을 대표한다고 우리가 판단한 과제로 측정한 값입니다. 서드파티 벤치마크가 아니고, 우리는 하나의 내부 종합 점수로 리더보드 표를 만들거나 벤치마크별 세부 내역을 공개하지도 않습니다. 세부 내역은 내부 스위트가 갖지 못한 수준의 외부 비교 가능성을 암시하기 때문입니다.

대신 말할 수 있는 것은 그 향상이 어디서 오는지입니다. 그 부분은 신비롭지 않습니다. 컨텍스트 윈도우가 커지면 모델이 추론에 들어가기 전에 버려야 하는 자료가 줄어드는데, 긴 세션에서 지능이 떨어져 보이는 현상의 상당 부분은 사실 건망증입니다. 우리가 통제하는 서빙 스택은 모델이 호스트 기본값이 아니라 우리가 의도한 설정으로 돌아간다는 뜻입니다. 그리고 설계상 변하지 않은 추론 루프는, 입력과 32K 상한을 나눠 쓰며 짓눌리는 대신 이제 윈도우 안에서 제대로 돌아갈 공간을 얻었습니다.

07비전, 문서, 그리고 이미지 생성

Shannon 3.1은 이미지와 문서를 읽습니다. 스크린샷, 다이어그램, 사진, 스캔한 페이지, PDF와 텍스트 문서를 대화에 넣어 나머지 모든 것과 함께 추론하게 할 수 있습니다. 196K 윈도우와 결합하면 문서 전체를 다루는 워크플로가 실용적이 됩니다. 긴 보고서와 그 도표를 한 턴에 넣으면 되고, 모델이 어떤 페이지를 볼 수 있는지 미리 정할 필요가 없습니다.

이미지 생성과 편집은 채팅에서 도구 형태로 제공됩니다. 이미지를 요청하면 모델이 같은 대화 안에서, 지금까지 논의한 모든 맥락과 함께 도구를 인라인으로 호출합니다. 편집도 같은 방식입니다. 이미지를 건네고 바꾸고 싶은 점을 설명하면 됩니다. 따로 전환할 모드도, 새로 익힐 인터페이스도 없습니다.

08API에서 Shannon 3.1 호출하기

Shannon 3.1은 세 가지 API 방언 모두에서 제공되며, 각각 스트리밍을 지원합니다. 같은 모델, 세 가지 요청 형태입니다. 이미 쓰고 있는 SDK에 맞는 것을 고르세요.

엔드포인트	형태	스트리밍
/v1/chat/completions	OpenAI 호환	지원
/v1/messages	Anthropic 호환	지원
/v1/responses	Responses	지원

{
  "model": "shannon-3.1",
  "stream": true,
  "messages": [
    { "role": "user", "content": "Summarize this contract set and flag anything unusual." }
  ]
}

전체 추론 루프를 실행하려면 "shannon-3.1"을 "shannon-3.1-pro"로 바꾸세요. 이미 shannon-3을 호출하고 있다면 마이그레이션은 모델 ID 교체가 전부입니다. 요청과 응답 형태는 그대로이고, 기존 스트리밍 클라이언트도 계속 동작합니다. 예상해야 할 유일한 동작 차이는 02절에서 설명한 덩어리진 스트림입니다. 같은 토큰, 같은 순서로, 더 일찍 그리고 덜 고르게 도착합니다.

전체 파라미터 레퍼런스, 인증, 오류 시맨틱, 인터랙티브 플레이그라운드는 API 문서에 있습니다. 다른 모델 카드와 기술 문서는 Shannon 리서치에 있습니다.

09여전히 무검열이며, 그 점은 변하지 않았습니다

Shannon 3.1에는 거절 레이어가 없고 출력에 대한 콘텐츠 필터링도 없습니다. 이는 Shannon 라인의 나머지와 같은 태도이며, 자체 클러스터로 옮기면서도 바뀌지 않았습니다. 오히려 서빙 스택을 통제하면 보장하기가 더 쉬워집니다. 모델과 여러분 사이에 자기 정책을 가진 중간 호스트가 없기 때문입니다.

출력 경로 전체를 바꾼 릴리스라면 당연히 궁금해할 지점이므로 분명히 말해 둡니다. 페이싱 레이어를 제거했다는 것이 그 자리에 검열 레이어를 넣었다는 뜻은 아닙니다. 스트림을 검사하거나 고쳐 쓰거나 막는 것은 아무것도 없습니다. 모델이 만들어내는 것이 그대로 도착합니다. 우리가 아는 한 Shannon 3.1은 이 정도 크기의 컨텍스트 윈도우를 갖춘 무검열 AI 모델 중 가장 빠릅니다. 그리고 이 두 특성은 서로 연결되어 있습니다. 둘 다 남에게서 규정에 맞춘 용량을 빌리는 대신 우리 인프라를 직접 운영하는 데서 나오기 때문입니다.

무검열이 무책임과 같은 말은 아닙니다. 사용은 책임 있는 사용 정책의 적용을 받으며, 어려운 소재에도 응답하는 모델에 따라오는 의무는 그것을 책임 있게 다루는 일입니다.

10직접 비교해 보세요

여기 있는 모든 주장은 2분이면 확인할 수 있고, 우리는 여러분이 믿기보다 확인하기를 바랍니다.

1. 실제로 하는 업무에서 프롬프트를 하나 고르세요. 길수록 좋습니다. 윈도우와 스트리밍을 모두 시험하게 됩니다.
2. shannon-3에서 실행하세요. 첫 토큰까지 걸린 시간과 답이 완성될 때까지 걸린 시간을 기록하세요.
3. 동일한 프롬프트를 shannon-3.1에서 실행하고, 같은 두 수치를 기록하세요.
4. 그런 다음 시계는 잊고 두 답을 읽으면서, 어느 쪽을 원했을지 판단하세요.

속도 차이는 즉시, 그리고 분명하게 드러납니다. 곱씹어 볼 가치가 있는 것은 품질 차이입니다. 이는 긴 입력에서 가장 뚜렷하게 나타나는데, 3.0은 여러분이 생각한 것보다 적은 자료로 조용히 일하고 있었기 때문입니다.

11자주 묻는 질문

---

이 글의 성능 및 지능 수치는 2026년 9월 Shannon Lab이 내부 평가에서 자체 측정한 값이며, 서드파티 벤치마크 결과가 아니라 제품 수치로 제시됩니다. 컨텍스트 윈도우, 모델 ID, API 제공 여부는 제품 사양입니다. Shannon AI는 미국 뉴멕시코주의 Shannon Lab LLC가 운영합니다. 함께 읽기: Shannon 3 · Shannon 리서치 색인 · API 문서.