무검열 Hy3 모델 API

"어떤 모델을 써야 하나"를 둘러싼 논쟁은 대개 천장에 관한 것입니다. 어느 쪽이 코드를 가장 잘 쓰고, 가장 어려운 수학을 풀고, 가장 긴 에이전트 실행에서 이기느냐죠. 구조화 파이프라인은 그렇게 굴러가지 않습니다. 하루에 문서 10만 건에서 필드를 뽑아내는 작업에 필요한 것은 한 번 눈부신 모델이 아니라 매번 같은 형태로 정확한 모델, 그리고 JSON 객체가 와야 할 자리에 절대 문단을 돌려주지 않는 모델입니다. Hy3-W8A16이 여기 있는 이유가 그 성질입니다.

01Hy3는 무엇이고 어디서 왔나

Hy3는 Tencent Hunyuan 팀의 오픈 웨이트 추론·에이전트 모델로, 2026년 7월 6일에 관대한 라이선스로 전체 공개되었고 가중치는 Hugging Face에 올라갔습니다. Tencent의 이전 Hunyuan-Large 전문가 혼합 작업의 계보를 잇습니다. 아키텍처는 희소 MoE입니다. 총 2,950억 파라미터 중 전문가 192개에 대한 top-8 라우팅으로 토큰당 약 210억 개가 활성화되고, 80개 레이어 트랜스포머에 그룹 쿼리 어텐션을 쓰며, 추측 디코딩을 위한 별도의 3.8B 다중 토큰 예측 레이어가 붙어 있습니다. 네이티브 컨텍스트는 256K로, 우리가 노출하는 262,144 토큰과 정확히 같습니다. 더 큰 것을 자른 것도, 더 작은 것을 로프로 늘린 것도 아닙니다.

토큰 단위로 비용을 내는 사람에게 중요한 숫자가 그 희소성 비율입니다. Hy3는 2,950억 파라미터 모델의 지식을 지니면서 순전파당 연산은 대략 210억 파라미터 모델 수준으로 합니다. 우리가 이 모델을 더 세게 압축하지 않고 8비트로 제공할 수 있는 이유이기도 합니다. 이 정도로 희소한 모델의 8비트 빌드는 자체 GPU 클러스터에 여전히 들어가고 여전히 빠릅니다.

Tencent가 잘한다고 보고한 영역

Tencent가 공개한 평가 표는 Hy3의 강점을 순수 코딩이 아니라 에이전트 검색, 툴 오케스트레이션, 긴 컨텍스트 검색에 분명히 놓습니다. 그들이 보고한 수치는 이렇습니다.

약한 막대도 일부러 보여 줍니다. Tencent 자신의 비교에서도 Hy3는 코딩에서 GLM-5.2에 뒤집니다. SWE-bench Verified에서 78.0 대 84.2, DeepSWE에서 28.0 대 46.2입니다. 워크로드가 자율적인 다중 파일 소프트웨어 엔지니어링이라면 모델 리서치 인덱스의 나머지를 먼저 읽으세요. 텍스트를 읽고 구조를 내보내는 일이라면 이 프로필은 이상적에 가깝습니다.

파이프라인 작업에 가장 중요한 수치는 신뢰성에 관한 것입니다. Tencent는 Hy3의 환각률을 5.4%로 보고하는데, 이전 세대의 12.5%에서 내려온 값이고 상식 오류도 25.4%에서 12.7%로 떨어졌습니다. 그들이 밝힌 학습 원칙 — 근거가 있으면 답하고, 없으면 없다고 분명히 말한다 — 은 원본에 언급조차 없는 필드에 그럴듯한 값을 지어낼 수도 있는 추출 모델에게 바로 원하는 성향입니다.

이 절의 모든 수치는 Tencent가 자체 테스트로 보고한 값이며, 집필 시점에 독립적인 제3자 검증은 아직 진행 중이었습니다. 확정된 결론이 아니라 방향을 가리키는 값으로 다루세요.

02W8A16이 뜻하는 것과 구조화 출력에서 중요한 이유

게이트웨이의 모든 모델은 양자화 접미사를 답니다. 장식이 아니라, 서비스되는 가중치가 연구소가 공개한 체크포인트에서 얼마나 떨어져 있는지 알려 줍니다.

티어	하는 일	충실도
3BIT-REAP	3비트 가중치에, 양자화 전에 라우팅이 드문 MoE 전문가를 잘라 내는 전문가 프루닝 기법 REAP을 더한 것	가장 많이 압축됨
W4A16-AUTOROUND-REAP	AutoRound — 최근접 반올림보다 정확도를 되찾는 학습된 반올림 — 로 4비트 가중치 / 16비트 활성값을 만들고 REAP 프루닝을 더한 것	중간
W8A16	8비트 가중치 / 16비트 활성값. 프루닝도, 학습된 반올림 보정도 없이 가중치를 그저 두 배 정밀도로 실어 나름	가장 높음

양자화 표류가 실제로 아픈 곳

REAP과 AutoRound는 순진한 압축이 잃는 것의 대부분을 되찾습니다. 다만 그 문장에서 "대부분"이 많은 일을 하고 있고, 남은 잔여는 고르게 떨어지지 않습니다. 저비트 양자화는 꼬리를 상하게 합니다. 확률이 낮고 특이성이 높은 결정들 말이죠. 산문에서는 거의 보이지 않습니다. 형용사가 달라져도 여전히 좋은 문장이니까요. 구조화 출력에서는 그것이 전부입니다. 스키마란 각각이 정확히 맞아야 하는 저확률 결정의 긴 사슬이기 때문입니다.

• 토큰 수준 문법. 닫는 중괄호, 쉼표, 따옴표. 각각이 토큰 하나이고, 잘못된 토큰 하나가 응답 전체를 무효로 만듭니다.
• 열거값 규율. 스키마가 "status"는 "open" | "closed" | "pending" 중 하나라고 했는데, 표류한 모델은 "Open"이나 "pending review"를 돌려줍니다. 의미는 가깝지만 어느 쪽으로도 유효하지 않습니다.
• 타입 규율. number 필드가 "1,240"으로, boolean이 "yes"로 돌아옵니다. 둘 다 문자열로 파싱되고 스키마 검증에 실패합니다.
• 롱테일 리터럴. 드문 고유명사, 부품 번호, 화학물질명, 비라틴 문자, 정확한 날짜 — 저비트 가중치가 흐려 놓는 바로 그 저확률 영역입니다.

이 중 어느 것도 4비트나 3비트 모델이 나쁘다는 뜻은 아닙니다. 대화 작업에서는 충실도 차이가 가격 차이만큼의 값을 못 하는 경우가 많습니다. 하지만 출력의 소비자가 사람이 아니라 검증기라면, 꼬리에서의 정밀도는 곧바로 파싱 성공률로 환산되고 파싱 성공률은 다시 재시도 예산과 p99 지연 시간이 됩니다. W8A16은 그 세금을 그만 내는 티어입니다.

03구조화 출력: json_schema와 response_format

Hy3는 구조화 출력 표면의 양쪽 절반을 모두 지원합니다. 카탈로그 전체에 해당하는 이야기가 아니므로 명시해 둘 만합니다.

모델	response_format	json_schema
Hy3 · W8A16	지원	지원
MiMo-V2.5-Pro · W8A16	지원	지원
inkling · W4A16-AUTOROUND-REAP	지원	없음
Laguna-S-2.1 · W4A16-AUTOROUND-REAP	없음	없음

두 기제의 차이는 사람들이 짐작하는 것보다 중요합니다. response_format: {"type": "json_object"}는 유효한 JSON만 요구할 뿐입니다. 형태는 모델이 고르므로 두 번의 호출이 각각 {"name": ...}과 {"full_name": ...}을 돌려줘도 둘 다 맞습니다. json_schema는 형태를 미리 제공합니다. 이름 붙은 필드, 타입, 열거값, 필수 목록, 중첩까지요. 그것이 코드로 상대할 수 있는 계약입니다.

OpenAI 호환 방언에서의 최소 호출은 이렇습니다.

POST /v1/chat/completions

{
  "model": "Hy3-W8A16",
  "messages": [
    {"role": "system", "content": "Extract fields from the incident report. Use null for anything not stated."},
    {"role": "user", "content": "<report text>"}
  ],
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "incident",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "severity":  {"type": "string", "enum": ["low","medium","high","critical"]},
          "component": {"type": "string"},
          "occurred_at": {"type": ["string","null"], "description": "ISO-8601"},
          "affected_users": {"type": ["integer","null"]},
          "indicators": {
            "type": "array",
            "items": {"type": "object", "properties": {
              "kind":  {"type": "string", "enum": ["ip","domain","hash","cve"]},
              "value": {"type": "string"}
            }, "required": ["kind","value"]}
          }
        },
        "required": ["severity","component","occurred_at","affected_users","indicators"]
      }
    }
  }
}

실무 메모

• 모든 필드를 필수로 두고 null을 허용하세요. 선택 필드는 조용한 누락을 부릅니다. 필수이면서 null이 가능한 필드는 "없음"을 명시하게 만들고, 그것은 여러분이 대응할 수 있는 정보입니다.
• 자유 문자열보다 열거값이 낫습니다. 값 집합을 닫을 수 있는 곳은 전부 닫으세요. 스키마의 실제 통과율을 가장 크게 끌어올리는 변경입니다.
• 16,384 토큰 출력 상한 아래를 유지하세요. 제한 없는 배열은 객체 중간에서 잘립니다. 배열 길이를 제한하거나 입력을 쪼개세요.
• 시스템 메시지를 남겨 두세요. 스키마는 형태를 구속하지만 의미는 여전히 프롬프트가 지배합니다. 무엇이 "critical"인지, 날짜가 둘 나오면 어느 쪽이 이기는지, 단위를 정규화할지 같은 것들이죠.
• 그래도 검증하세요. 스키마 지원은 통과율을 높이지, 검증기와 데드레터 큐를 대신하지 않습니다.

04"무검열"이 콘텐츠만이 아니라 신뢰성의 성질인 이유

게이트웨이의 Hy3에는 거절 레이어도, 출력 필터링도 없습니다. 흔한 설명은 콘텐츠에 관한 것입니다. 보안 연구, 악성코드 분석, 익스플로잇 보고서, 의료·법률 코퍼스, 성인물, 위해 감소 문서, 적대적 사용자 대화록을 모델이 대신 "하지 않는 편이 낫겠다"고 결정하는 일 없이 처리할 수 있다는 것이죠.

중요한 이유가 하나 더, 더 기계적인 것이 있습니다. 거절은 곧 스키마 위반입니다. 필터가 걸린 모델은 거절할 때 "unavailable" 플래그가 붙은 객체를 돌려주지 않습니다. 산문을 돌려줍니다. "해당 요청은 도와드릴 수 없습니다." 그 문자열은 incident 객체가 아닙니다. 검증기를 통과하지 못하고 진짜 파싱 오류들 옆의 데드레터 큐에 떨어지며, 이제 여러분은 정책상 거절과 실제 형식 오류를 갈라내야 합니다.

더 나쁜 것은 거절이 무작위로 흩어지지 않고 콘텐츠와 상관관계를 갖는다는 점입니다. 코퍼스의 4%가 보안 사고 보고서이고 모델이 그 대부분을 거절한다면, 처리량을 4% 고르게 잃은 것이 아니라 한 범주를 통째로 잃은 것입니다. 그 데이터 위에 세운 대시보드는 정작 자신이 드러내려던 것을 조용히 과소 보고하게 됩니다. 범주 모양으로 뚫린 구멍은 균일한 잡음보다 비쌉니다. 아무도 그것에 대해 알림을 울리지 않으니까요. 거절 경로를 없애면 남는 것 — 형식 오류, 절단, 모호한 텍스트 — 은 주제와 무관하고, 따라서 측정할 수 있습니다.

05컨텍스트, 출력 상한, 그리고 예산 짜는 법

게이트웨이의 모든 모델은 같은 한도를 공유합니다.

컨텍스트는 공유 예산입니다. 프롬프트와 출력이 함께 262,144 안에 들어가야 하므로 한 번의 호출에서 실질적인 입력 상한은 약 245,000 토큰, 아주 대략 영어 18만 단어쯤입니다. 구조화 작업에서는 16,384 토큰 출력 상한이 더 빡빡한 한도이고 사람들이 놀라는 지점이기도 합니다. 레코드마다 객체 하나를 내보내는 스키마는 윈도우가 차기 훨씬 전에 이 상한에 부딪힙니다. 여기에 맞서는 패턴이 둘 있습니다.

• 입력은 넓게, 출력은 좁게. 계약서, 신고 서류, 로그 구간 전체를 컨텍스트에 밀어 넣고 콤팩트한 객체 하나를 요구하세요. 입력 토큰은 출력 토큰의 4분의 1 비용이므로 가격 구조가 많이 읽고 조금 쓰는 쪽에 보상을 줍니다.
• 바이트 수가 아니라 레코드 경계에서 쪼개세요. 모델이 이음매를 볼 수 있는 곳에서 나누세요. 문장 중간에서 잘린 레코드는 명백한 실패가 아니라 자신 있게 틀린 객체를 만들어 냅니다.

Hy3가 보고한 긴 컨텍스트 검색 강점 — AA-LCR 73.4, 그리고 MRCR 장문 대화 회상에서 42.9%에서 75.1%로의 도약 — 이 바로 첫 번째 패턴이 기대는 능력이며, 글을 잘 쓰는 것과는 다른 기술입니다.

06최저가와 실제 파이프라인의 산수

Hy3는 100만 입력 토큰당 $0.50, 100만 출력 토큰당 $2.00에 있습니다. 카탈로그의 바닥이며 MiMo-V2.5, MiMo-V2.5-Pro, DeepSeek-V4-Flash-0731, MiniMax-M3와 같은 가격입니다. 대표적인 부하로 계산해 보면 이렇습니다.

워크로드	호출당 입력	호출당 출력	호출당 비용	100만 호출당
필드 추출	1,200	300	$0.0012	$1,200
문서 분류	3,000	120	$0.0018	$1,800
긴 문서를 스키마로 요약	40,000	900	$0.0218	$21,800
윈도우 전체 분석	240,000	2,000	$0.1240	$124,000

결정을 바꾸는 숫자는 표시 요율이 아니라 재시도 이후의 실효 요율입니다. 두 모델의 가격이 같은데 한쪽은 호출의 6%에서, 다른 쪽은 1.5%에서 검증에 실패한다면, 표류가 큰 모델은 호출을 약 4.5% 더 돌립니다. 견딜 만하죠. 피해는 꼬리에 있습니다. 재시도된 호출은 시간이 두 배 걸리므로 눈에 띄는 트래픽 구간에서 p99 지연 시간이 대략 두 배가 되고, 두 번 실패한 것은 수작업이 됩니다. 하루 100만 호출이면 누군가 읽어야 하는 레코드가 수천 건이라는 뜻입니다.

그래서 최저가에 놓인 8비트 티어의 논거는 이렇습니다. 여기서는 충실도에 프리미엄을 내지 않으므로, 재시도 산수는 공짜로 얻는 돈입니다. 3비트 모델이 더 쌌다면 저울질할 진짜 맞바꿈이 있었겠지만, Hy3는 카탈로그에서 가장 싼 것과 같은 값입니다.

07세 가지 API 방언, 하나의 모델

Hy3는 세 게이트웨이 방언 모두에서 호출할 수 있고 각각 스트리밍이 됩니다. 같은 모델, 같은 가중치, 같은 한도이니 이미 쓰고 있는 SDK에 맞는 쪽을 고르세요.

엔드포인트	방언	이럴 때 쓰세요
/v1/chat/completions	OpenAI	OpenAI SDK, LangChain, LlamaIndex를 쓰고 있을 때. 베이스 URL을 여기로 돌리고 모델 id만 바꾸세요.
/v1/messages	Anthropic	Anthropic SDK를 쓰고 있고 변환 계층 없이 콘텐츠 블록을 그대로 쓰고 싶을 때.
/v1/responses	Responses	타입 출력과 서버 측 상태를 갖춘 새 요청 형태를 원할 때.

Hy3는 툴 호출과 reasoning_effort를 포함한 추론도 지원합니다. 추출 작업에서는 보통 추론을 낮추는 것이 유효한 수입니다. 깨끗한 텍스트에 잘 정의된 스키마라면 사고 토큰은 여러분이 값을 치르는 출력 토큰이자 기다려야 하는 지연 시간이고, 얻는 것은 미미합니다. 강도 예산은 진짜로 모호한 입력에 쓰세요.

전체 요청·응답 레퍼런스, 파라미터 목록, 스트리밍 시맨틱, 인터랙티브 플레이그라운드는 API 문서에 있습니다.

08세 W8A16 모델 중에서 고르기

최고 충실도 티어에 세 모델이 있고 전부 최저가입니다. 선택은 대체로 모달리티 문제입니다.

모델	비전	json_schema	입력 / 출력 가격	이럴 때 고르세요
Hy3 · W8A16	없음	지원	$0.50 / $2.00	텍스트 전용 구조화 파이프라인, 툴 오케스트레이션, 긴 컨텍스트 검색
MiMo-V2.5-Pro · W8A16	없음	지원	$0.50 / $2.00	MiMo 계열의 Pro 튜닝을 원하는 텍스트 전용 작업
MiMo-V2.5 · W8A16	지원	지원	$0.50 / $2.00	이미지가 들어가는 모든 것 — 스캔 문서, 스크린샷, 사진

입력의 어느 한 부분이라도 이미지라면 결정은 이미 나 있습니다. Hy3는 텍스트 전용이니 스캔한 PDF, 스크린샷, 사진은 MiMo-V2.5로 보내세요. 입력이 진짜로 텍스트라면, 에이전트 툴 사용과 긴 컨텍스트 회상, 낮게 보고된 환각률이라는 Hy3의 프로필이 파이프라인 작업에 가장 직접적으로 맞닿습니다. 셋의 가격이 같으니 실제 레코드 수백 건에 대해 여러분의 스키마를 둘에 돌려 보고 파싱 성공률을 비교하세요. 어떤 표보다 — 이 표를 포함해서 — 확실하게 결론이 납니다.

09Hy3가 제 자리를 얻는 곳

• 대량 필드 추출. 계약서, 신고 서류, 사고 보고서, 대화록, 임상 기록, 법원 기록 — 문서당 타입 객체 하나가 결과물이고 물량 때문에 재시도가 비싼 모든 곳입니다.
• 대규모 분류와 라우팅. 닫힌 열거값 출력이며, 모델의 가치 전부가 열아홉 번째 범주를 결코 지어내지 않는 데 있습니다.
• 보안·위협 인텔리전스 코퍼스. 악성코드 분석 보고서, 익스플로잇 공개, 피싱 샘플 — 필터가 걸린 모델을 거절로 몰아넣는 자료이고, 범주 모양의 구멍이 목적 자체를 무너뜨리는 영역입니다.
• 멈춰서는 안 되는 툴 호출 에이전트. 8비트 인자 충실도는 여러분의 함수에 건네지는 JSON이 파싱된다는 뜻입니다. 뭉개진 툴 호출은 조금 나쁜 답이 아니라 멈춰 선 에이전트입니다.
• 긴 문서를 구조로 바꾸는 분석. 서류 전체를 넣고 콤팩트한 객체 하나를 받습니다.
• 콘텐츠 모더레이션과 정책 연구. 필터가 걸린 모델이 읽기를 거부하는 자료에 라벨을 붙이는 일은 신뢰·안전 분야의 상시 과제이며, 엄격한 스키마를 갖춘 필터 없는 모델이 그것을 곧바로 해결합니다.

그리고 맞지 않는 곳은 이렇습니다. 이미지가 들어가는 모든 것(MiMo-V2.5를 쓰세요), 그리고 Tencent 자신의 표가 SWE-bench Verified에서 Hy3를 GLM-5.2 뒤에, DeepSWE에서는 한참 뒤에 놓는 자율적인 다중 파일 소프트웨어 엔지니어링입니다.

벤치마크 수치는 경쟁 모델 수치를 포함해 Tencent가 보고한 값이며, 집필 시점에 독립 검증은 진행 중이었습니다. 비용 수치는 우리가 공개한 $0.50 / $2.00 요율로 계산했습니다. 이 페이지의 어떤 숫자도 Shannon이 직접 돌린 벤치마크나 추정치가 아닙니다.

10자주 묻는 질문

---

출처: Tencent Hunyuan 모델 카드 · Hy3 저장소 · Hunyuan-Large: An Open-Source MoE Model (arXiv 2411.02265) · Hy3 출시에 대한 VentureBeat 보도. 파운데이션 벤치마크는 Tencent가 보고한 값이며 독립 검증 전의 잠정치입니다. Shannon AI는 미국 뉴멕시코주의 Shannon Lab LLC가 운영합니다.