API модели Hy3 без цензуры

Большинство споров «какую модель выбрать» — про потолок: кто лучше пишет код, решает самую сложную математику, выигрывает самый длинный агентный прогон. Структурированные конвейеры устроены иначе. Задача, извлекающая поля из ста тысяч документов в день, не нуждается в модели, гениальной однажды, — ей нужна такая, которая каждый раз корректна в одной и той же форме и никогда не возвращает абзац там, где должен быть JSON-объект. Именно ради этого свойства здесь Hy3-W8A16.

01Что такое Hy3 и откуда она взялась

Hy3 — модель для рассуждений и агентной работы с открытыми весами от команды Hunyuan в Tencent, полностью выпущенная 6 июля 2026 года под разрешительной лицензией, с весами, опубликованными на Hugging Face. Она продолжает линию более ранней работы Tencent над Mixture-of-Experts — Hunyuan-Large. Архитектурно это разреженная MoE: 295 миллиардов всех параметров, из которых примерно 21 миллиард активируется на токен через маршрутизацию top-8 по 192 экспертам, на 80-слойном трансформере с grouped-query attention, плюс отдельный слой multi-token prediction на 3,8B для спекулятивного декодирования. Нативный контекст — 256K, ровно те 262 144 токена, которые мы предоставляем, а не усечение чего-то большего и не растянутое через rope расширение чего-то меньшего.

Эта пропорция разреженности — важнейшее число для всякого, кто платит за токены: Hy3 несёт знания модели на 295B, выполняя за один прямой проход примерно арифметику модели на 21B. Это же причина, по которой мы можем позволить себе обслуживать её в 8 битах, а не сжимать сильнее: 8-битная сборка настолько разреженной модели всё равно помещается и всё равно работает быстро на нашем собственном GPU-кластере.

В чём, по данным Tencent, она хороша

Опубликованные Tencent таблицы оценок помещают сильные стороны Hy3 чётко в области агентного поиска, оркестрации инструментов и извлечения из длинного контекста, а не в чистое кодирование. Их заявленные цифры:

Слабые полосы мы показываем намеренно. Hy3 уступает GLM-5.2 на кодировании в собственном сравнении Tencent — 78.0 против 84.2 на SWE-bench Verified и 28.0 против 46.2 на DeepSWE. Если ваша нагрузка — автономная разработка ПО по многим файлам, сначала прочтите остальной указатель исследований по моделям. Если же это чтение текста и выдача структуры, профиль близок к идеальному.

Цифра, которая важнее всего для конвейерной работы, относится к надёжности: Tencent сообщает о доле галлюцинаций 5,4% против 12,5% в предыдущем поколении, при падении ошибок здравого смысла с 25,4% до 12,7%. Заявленный ими принцип обучения — отвечать, когда есть свидетельства, и прямо говорить, когда их нет, — это ровно тот нрав, который нужен модели извлечения, которая иначе выдумает правдоподобное значение для поля, ни разу не упомянутого в источнике.

Все цифры в этом разделе сообщены самой Tencent по её собственным прогонам; независимая сторонняя проверка на момент написания ещё не была завершена. Считайте их указывающими направление, а не окончательными.

02Что означает W8A16 и почему это важно для структурированного вывода

Каждая модель на шлюзе несёт суффикс квантизации. Это не украшение — он говорит, насколько далеко обслуживаемые веса отстоят от чекпойнта, выпущенного лабораторией.

Уровень	Что делает	Точность
3BIT-REAP	3-битные веса плюс REAP — метод отсечения экспертов, удаляющий редко маршрутизируемых экспертов MoE перед квантизацией	Самое сильное сжатие
W4A16-AUTOROUND-REAP	4-битные веса / 16-битные активации через AutoRound — обучаемое округление, возвращающее точность по сравнению с наивным округлением к ближайшему, — плюс отсечение 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 токена. Неограниченный массив оборвётся посреди объекта. Ограничивайте длину массивов или дробите вход.
• Не убирайте системное сообщение. Схема ограничивает форму; промпт всё ещё управляет смыслом — что считается «критическим», какая дата побеждает, если их две, надо ли нормализовать единицы.
• Всё равно валидируйте. Поддержка схемы повышает долю успешных ответов; она не заменяет валидатор и очередь недоставленных сообщений.

04Почему «без цензуры» — свойство надёжности, а не только контента

У Hy3 на шлюзе нет слоя отказов и нет фильтрации вывода. Обычно об этом говорят применительно к контенту: вы можете обрабатывать исследования безопасности, анализ вредоносного ПО, разборы эксплойтов, медицинские и юридические корпуса, взрослый материал, документацию по снижению вреда или расшифровки враждебных пользователей без того, чтобы модель решала за вас, что она предпочла бы этого не делать.

Есть и вторая, более механическая причина, почему это важно. Отказ — это нарушение схемы. Фильтрованная модель, которая отказывается, не возвращает ваш объект с флагом "unavailable" — она возвращает прозу. «Я не могу помочь с этим запросом». Эта строка не является объектом incident; она не проходит ваш валидатор и попадает в очередь недоставленных сообщений рядом с настоящими ошибками разбора, где вам теперь приходится отделять отказы по политике от реальных дефектов формата.

Хуже того, отказы коррелируют с содержанием, а не распределяются случайно. Если 4% вашего корпуса — отчёты об инцидентах безопасности и модель отклоняет большинство из них, вы потеряли не 4% пропускной способности равномерно — вы потеряли одну категорию, и дашборд, построенный на этих данных, тихо занижает ровно то, ради чего он существует. Дыры, повторяющие форму категории, обходятся дороже равномерного шума, потому что на них ничто не срабатывает как алерт. Уберите путь отказа — и всё, что останется (дефекты формата, обрывы, неоднозначный текст), не коррелирует с темой и, значит, поддаётся измерению.

05Контекст, потолок вывода и как их планировать

У всех моделей на шлюзе одни и те же лимиты:

Контекст — общий бюджет: промпт и вывод вместе должны уместиться в 262 144, поэтому практический потолок ввода в одном вызове составляет около 245 000 токенов, очень грубо — 180 000 английских слов. Для структурированной работы более жёсткий лимит — потолок вывода в 16 384 токена, и именно он застаёт людей врасплох: схема, выдающая по объекту на запись, упирается в него задолго до заполнения окна. Против этого работают два приёма:

• Широкий вход, узкий выход. Загоняйте в контекст целый договор, отчётность или окно логов и просите один компактный объект. Входные токены стоят вчетверо дешевле выходных, так что ценообразование поощряет много читать и мало писать.
• Режьте по границам записей, а не по числу байт. Делите там, где модель видит шов. Запись, разрезанная посреди предложения, даёт уверенно неверный объект, а не очевидный сбой.

Заявленная сила Hy3 в извлечении из длинного контекста — 73.4 на AA-LCR и скачок с 42,9% до 75,1% на MRCR по припоминанию в длинных диалогах — это ровно та способность, на которой держится первый приём, и это иной навык, чем хорошо писать.

06Минимальная цена и арифметика реального конвейера

Hy3 стоит $0.50 за миллион входных токенов и $2.00 за миллион выходных — минимум каталога, общий с MiMo-V2.5, MiMo-V2.5-Pro, DeepSeek-V4-Flash-0731 и MiniMax-M3. В пересчёте на типичные нагрузки:

Нагрузка	Вход / вызов	Выход / вызов	Стоимость / вызов	За 1M вызовов
Извлечение полей	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 задержки примерно удваивается для заметной доли трафика, а всё, что упало дважды, превращается в ручную работу. При миллионе вызовов в день это тысячи записей, которые кому-то придётся прочитать.

Отсюда и довод в пользу 8-битного уровня по минимальной цене: вы не платите здесь премию за точность, поэтому арифметика повторов — это бесплатные деньги. Если бы 3-битная модель была дешевле, был бы реальный компромисс для взвешивания — но Hy3 стоит столько же, сколько самое дешёвое в каталоге.

07Три диалекта API, одна модель

Hy3 доступна во всех трёх диалектах шлюза, со стримингом в каждом. Та же модель, те же веса, те же лимиты — берите тот, что совпадает с уже имеющимся у вас SDK.

Эндпойнт	Диалект	Когда использовать
/v1/chat/completions	OpenAI	У вас OpenAI SDK, LangChain или LlamaIndex. Направьте сюда базовый URL, поменяйте идентификатор модели.
/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	Текстовая работа, где вам нужна Pro-настройка линейки MiMo
MiMo-V2.5 · W8A16	Да	Да	$0.50 / $2.00	Всё, где есть изображения — сканы документов, скриншоты, фотографии

Если хоть часть вашего входа — изображение, решение принято за вас: Hy3 работает только с текстом — отправляйте отсканированные PDF, скриншоты и фотографии в MiMo-V2.5. Там, где вход действительно текстовый, профиль Hy3 — агентная работа с инструментами, припоминание в длинном контексте и низкая заявленная доля галлюцинаций — ложится на конвейерную работу наиболее прямо. Поскольку все три стоят одинаково, прогоните свою схему на двух из них по нескольким сотням реальных записей и сравните долю успешного разбора; это решит вопрос лучше любой таблицы, включая эту.

09Где Hy3 оправдывает своё место

• Высокообъёмное извлечение полей. Договоры, отчётность, отчёты об инцидентах, расшифровки, клинические записи, судебные материалы — везде, где результатом является типизированный объект на документ, а объём делает повторы дорогими.
• Классификация и маршрутизация в масштабе. Вывод по закрытым перечислениям, где вся ценность модели — никогда не изобретать девятнадцатую категорию.
• Корпуса по безопасности и threat intelligence. Разборы вредоносного ПО, раскрытия эксплойтов и образцы фишинга — материал, на котором фильтрованные модели срываются в отказ и где дыра формой в категорию сводит на нет всю затею.
• Агенты с вызовом инструментов, которые не должны застревать. 8-битная точность аргументов означает, что JSON, передаваемый в ваши функции, разбирается; искажённый вызов инструмента — это застрявший агент, а не чуть худший ответ.
• Анализ длинных документов в структуру. Целая отчётность на входе, один компактный объект на выходе.
• Модерация контента и исследования политик. Разметка материала, который фильтрованная модель отказывается читать, — постоянная проблема направления доверия и безопасности; модель без фильтра со строгой схемой решает её напрямую.

А где не оправдывает: всё, где есть изображения (берите MiMo-V2.5), и автономная разработка ПО по многим файлам, где собственные таблицы Tencent ставят Hy3 позади GLM-5.2 на SWE-bench Verified и заметно позади на 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, Нью-Мексико, США.