Tencent 혼원(混元)의 Hy4 공식 버전이 2026년 11월 4일에 출시되었다. Preview(대략 2026년 8월 말) 이후 업데이트된 내용 중 현장에서 가장 유용하다고 들은 부분은 '동일한 OpenAI 호환 호출로 이미지를 전달할 수 있다'는 점이다. 나는 2026년 11월 5일에 https://api.crazyrouter.com/v1에서 model을 hy4로 설정하여 전반적으로 테스트를 진행했다. 이 게이트웨이 목록에는 hy4만 있고, hy4-preview는 포함되어 있지 않다. 따라서 동일한 진입점에서 Preview와 병행 비교하는 것은 불가능하다. 공식에서 발표하는 증분 내용과 오늘 내가 직접 만져본 범위만을 나누어 작성하겠다.
독자층은 Aider / Cline / 자체 OpenAI 호환 클라이언트를 사용하여 model ID를 hy4로 교체하려는 사람들을 상정한다. 리포트 형식의 재게시가 아니라, 전환 전에 자신의 클라이언트에 적용할 체크리스트에 관한 이야기다.
실제 전환 과정은 짧다. Base URL과 model 이름을 맞추기만 하면 된다.
curl https://api.crazyrouter.com/v1/chat/completions \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
...
판단은 HTTP 상태 코드만으로 해서는 안 된다. 본문(choices[0].message.content)과 usage, 필요하다면 finish_reason도 확인해야 한다. 401 에러, 할당량 부족, 모델 미개방 등은 별도의 장애로 취급한다.
Aider나 Cline 같은 CLI/IDE 에이전트 측에서 OpenAI 호환 Provider를 추가하는 경우에도 하는 일은 같아서, base/key/model을 hy4로 맞추기만 하면 된다. 이미 Aider와의 연결 절차나 Cline 설정을 거쳤다면, 차이점은 모델 문자열에 집중된다.
Preview 버전은 텍스트 중심이었다. 공식 Hy4 버전에서 처음으로 강조되는 것은 시각적 입력이다. 만약 내 워크플로우에서 '주간 막대 그래프', '관리 화면 스크린샷', '디자인 주석' 등을 텍스트와 동일한 호출로 넣고 싶다면, 이곳이 전환의 이유가 될 것이다.
오늘은 내가 만든 Q1 매출 막대 그래프(북80 / 동160 / 남200 / 서120)를 hy4에 전달하고 각 지역의 수치만 물어봤다. 약 8.9초 만에 본문으로 80 160 200 120이 반환되었다. 이전 단독 시도에서도 최고값은 S 200으로 정확하게 나왔다. 라벨이 명확한 합성도는 별개이며, 흐릿한 사진이나 복잡한 UI는 또 다른 문제다. 내 업무 샘플로 다시 한번 돌려보는 것이 본 작업 전 최소 기준이다.
'이미지가 같은 경로를 통과할 수 있는가'가 Preview에서 공식 버전으로 넘어오면서 내가 손으로 확인한 주된 차이점이다. PC 조작(CLI/GUI)이나 장시간 에이전트 강화는 공식 주장으로 나와 있지만, 오늘은 미검증이므로 전환 근거로 사용하지 않겠다.
전환 당일에 가장 위험한 부분은 여기다. 상태 코드는 200이고 usage에도 출력 토큰이 기록되는데도 불구하고, 화면상의 본문이 비어있는 경우다. reasoning이 max_tokens를 소진하여 finish_reason이 length가 되는 패턴이다.
오늘의 같은 날 메모:
| max_tokens | 내용 | 결과 |
|---|
| 128~1024 | 추론 중심 프롬프트 | HTTP 200, 본문 공백, reasoning이 상한까지 소진 |
| ... | rows.sort()의 원지(in-place) 부작용을 지적하고 수정안 반환 | |
| 512 | 신분 확인 | '我是混元…版本号为Hy4.' (약 9.5초) |
| 256×12 | '답변만: 수신' | 전체 200, 전문 존재, 약 2.6~4.0초 (최소 2649 / 최대 3971 / 평균 ≈3156ms) |
클라이언트가 상태 코드만 보고 성공으로 간주하면, 공백 답변을 실제 서비스에 배포하게 된다. 전환 체크리스트에 'content가 비어있으면 실패', 'finish_reason=length이면 상한을 높여 재시도'를 추가해야 한다. 이것이 '공식 버전이 Preview보다 안정적'이라는 증거는 될 수 없다. 동일 게이트웨이에 대한 Preview 대조군이 없기 때문에 순위 비교도 하지 않는다.
위에 나열된 12회의 ping은, 오늘 진행한 짧은 왕복 테스트가 살아있음을 확인하는 것에 불과하다. 짧은 지시 + 충분한 상한이면 본문이 나온다. 반면, 추론을 많이 사용하는 긴 코딩 지시를 2048이나 8192로 설정해도 본문이 공백인 상태로 남아있는 경우도 같은 날 목격했다.
즉:
- 짧은 ping 통과 → 경로와 단기 작업의 건전성 확인
- 긴 프롬프트 + 타이트한 상한 → 공백 본문 리스크가 잔존함
실제 운영 환경(本番)에서는 '자신이 사용하는 프롬프트'로 제한을 단계적으로 테스트해야 한다. 256으로 통과했다고 해서, 에이전트가 생성하는 긴 문장이 충분하다고 단정할 수는 없다.
코딩 기능이 이번 업데이트의 주역은 아니다. 짧은 Python 부작용 질문(max_tokens=4096)에서는, rows.sort()가 호출한 원본 리스트를 파괴하는 점을 지적하며, sorted(...)나 max(..., default=None)으로 수정할 것을 제안했다. 개인적인 작은 수정 초안에는 사용할 수 있다. 대규모 레포지토리 개정은 측정하지 않았다.
프로그래밍 용도의 후보군을 나열하고 싶을 때는, coding 전용 모델 목록에서 hy4와 현재 주력 모델을 비교해 보는 정도의 사용만 하고 있다. 공식 버전이 나왔다고 해서 코딩 기능이 하룻밤 사이에 주역이 된다는 결론은 오늘의 데이터로는 나오지 않는다.
컴퓨터 조작이나 긴 에이전트 루프는 공식적인 신규 주장(기능)이지만, 미검증 상태이다. 샌드박스 없이 운영 권한을 부여하지 않는다.
사용 목적에 따라 판단한다.
- 이미 그림을 같은 호출에 넣고 싶다 →
hy4로 기울일 이유가 있다. preview에서 채워지지 못한 구멍이며, 오늘 내가 확인한 차이점 중 하나이다.
- 짧은 문장과 가벼운 코드 보조만으로 충분하다 → 공식 버전 의식(儀式) 때문에 ID를 바꿀 필요는 없다. 코딩 기능 쪽에 '극적으로 변했다'는 증거는 없다.
- 컴퓨터 조작이나 "HTTP가 계속 200"이라는 이유만으로 전면 전환 → 나는 그렇게 하지 않는다. 전자는 미검증이다. 후자는 오늘도 빈 본문(내용)을 보고 있다.
가격은 Tencent Cloud TokenHub의 공개표에서 확인했다. preview와 동일하며, 입력 ¥6 / 출력 ¥18 / 캐시 ¥0.3 (100만 token당)이다. 청구 내역 대조는 응답의 usage를 본다.
아직 preview 쪽에 있다면, 최소한 두 가지를 하는 것이 좋다. (1) 자신의 업무 다이어그램을 한 장 hy4에 넣고 읽히는지 확인한다. (2) max_tokens를 일부러 제한하여, 빈 본문을 성공으로 간주하고 있지는 않은지 클라이언트를 확인한다. 컴퓨터 조작과 특히 긴 에이전트는, 자신 측의 검증이 끝날 때까지 전환 근거로 삼지 않는다.
