Что такое Xing4.0-29B-A4B и почему о ней заговорили
В начале ноября 2026 года в сообществе LocalLLaMA разобрали pull request #31589 в ggml-org/llama.cpp: он добавляет поддержку архитектуры xing4_0. За техническим номером стоит Xing4.0-29B-A4B, MoE-модель от China Telecom Artificial Intelligence Technology Co., Ltd. Серия Xing раньше называлась TeleChat, так что это продолжение линейки китайского телеком-оператора, а не сторонний форк.
Короткий ответ для тех, кто пришёл за сутью. У модели 29 млрд общих параметров и около 4 млрд активируемых на каждый токен. Нативный контекст 256K токенов с расширением до 512K. Архитектура обозначена как mHC + MLA + MTP, назначение сформулировано прямо: многошаговое планирование, вызов инструментов и длинные цепочки рассуждений. Разработчик заявляет, что это первая модель такого масштаба, полностью обученная на платформе Ascend NPU с фреймворком MindSpore.
Практическая сторона: поддержка в llama.cpp открывает путь к GGUF-квантам и запуску через llama-cli и llama-server на обычном железе, без Ascend. Оговорка сразу: все характеристики ниже взяты из описания PR. Независимых тестов, замеров скорости и опубликованных требований к VRAM в доступных источниках нет, так что воспринимайте материал как разбор анонса с техническими деталями.
Аббревиатура A4B расшифровывается как active 4B, то есть 4 млрд активных параметров. Эта цифра определяет стоимость вычислений на токен, тогда как 29B задаёт объём памяти под веса.
29B всего, 4B на токен: как работает MoE в этой модели
MoE (Mixture of Experts) делит блок прямого прохода на набор экспертов. Роутер на каждом токене выбирает, какие из них задействовать, и считает только их. Отсюда расхождение между 29B и 4B: в памяти лежат все веса, а в матричных умножениях участвует примерно седьмая часть.
Вывод по железу простой: VRAM считается от 29B, потому что загрузчик читает все эксперты. Квант, подобранный по активным 4B, не влезет, даже если по скорости модель ведёт себя как компактная.
Число экспертов, top-k и размер промежуточных слоёв в описании PR не раскрыты. По этим параметрам нельзя судить, насколько гранулярно роутер распределяет нагрузку и как это скажется на скорости. Для оценки памяти хватает 29B, для оценки скорости данных нет.
Контекст 256K и расширение до 512K: что это на практике
256 000 токенов это порядка 180-200 тысяч слов, то есть сотни страниц текста в одном запросе. Расширение до 512K требует отдельной настройки и пропорционально большего объёма памяти под KV-cache.
Зачем такой объём: агентный цикл накапливает историю. План, вызов инструмента, вывод, исправление, повторный вызов - каждый шаг добавляет токены, и на двадцатом шаге окно 8K уже не спасает. Длинный контекст позволяет держать всю трассу в одном запросе и не терять исходную инструкцию.
Цена известна: KV-cache растёт линейно с длиной контекста. На бытовой видеокарте 256K почти всегда нереалистичны, на практике работают с 8K-32K. Абсолютные цифры зависят от конфигурации слоёв, которую Research Pack не приводит, поэтому точный расчёт памяти под кэш без файла config.json не сделать.
Поддержка Xing4.0-29B-A4B в llama.cpp: что именно добавили
PR #31589 добавляет распознавание архитектуры xing4_0 в загрузчике и конвертере llama.cpp. На практике файл модели можно перегнать в GGUF и открыть через llama-cli, llama-server или любой интерфейс поверх llama.cpp. CPU и GPU поддерживаются штатным путём через ggml, отдельный бэкенд для Ascend не нужен.
Источник сведений один: описание pull request. Публичных тестов скорости и качества под эту архитектуру нет, поэтому статус поддержки стоит проверять по состоянию PR, а не по обещаниям в заголовках.
Что может пойти не так: PR может быть не влит в main на момент чтения; конвертер может требовать свежей версии; квантизация отдельных тензоров может поддерживаться не для всех типов; длинный контекст упрётся в память раньше, чем в код. Диагностика одна: смотреть лог загрузки модели и первую ошибку в нём.
GGUF и квантизация: какие форматы реально доступны
Готовых GGUF-сборок в доступных источниках нет. Искать их стоит в репозиториях сообщества на Hugging Face, сверяя дату загрузки с датой появления PR: файл, сделанный старым конвертером, новую архитектуру не подхватит.
Ориентир по размеру: 29 млрд параметров в 4-битном кванте дают примерно 15-17 ГБ весов «на бумаге» (29 млрд умножить на ~4.5 бита и разделить на 8). Это арифметическая оценка, не измерение. Дальше добавляются буферы рантайма, накладные расходы и KV-cache.
- Q4_K_M - базовый выбор: минимальная память при заметной, но не катастрофической потере качества.
- Q5_K_M, Q6_K - если есть запас 20-25 ГБ под веса и хочется меньше деградации.
- Q8_0 - около 30 ГБ под веса, для домашней машины редко оправдан.
Гибридные кванты с разным числом бит для экспертов и attention-слоёв дают лучший баланс, но их поддержка зависит от того, как это сделано в конкретной сборке. Внутренний материал про запуск MoE весом 204 ГБ на одной видеокарте показывает, как в llama.cpp работает выборочная выгрузка экспертов: приём применим и здесь, если версия поддерживает regex-оффлоад.
Пошаговый локальный запуск: от клонирования до первого запроса
- Клонируйте репозиторий ggml-org/llama.cpp и переключитесь на коммит, где есть изменения из PR #31589. Проверка простая: в исходниках упоминается xing.
- Соберите проект с поддержкой своей платформы.
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -jДля CPU сборка идёт без флага GGML_CUDA, для Apple Silicon используется Metal через GGML_METAL.
- Подготовьте GGUF: скачайте готовый квант или конвертируйте исходные веса.
python convert_hf_to_gguf.py <путь-к-модели> --outfile xing4-q8.gguf --outtype q8_0- Проверьте загрузку коротким запросом.
./build/bin/llama-cli -m xing4-q4_k_m.gguf -c 8192 -ngl 99 -p "Привет, кто ты?"- Для API поднимите сервер и проверьте OpenAI-совместимый эндпоинт.
./build/bin/llama-server -m xing4-q4_k_m.gguf -c 16384 -ngl 99 --host 127.0.0.1 --port 8080Флаг -c задаёт контекст. Начинать с 256K не нужно: стартуйте с 8K-16K, убедитесь, что модель отвечает и не падает по памяти, и увеличивайте окно шагами по 8K. Если загрузчик ругается на неизвестную архитектуру, версия llama.cpp старая или собрана не из того коммита.
Требования к железу: сколько VRAM и RAM нужно под 29B MoE
Сценариев два: всё на GPU и гибрид GPU+CPU. Для 29B в 4-битном кванте закладывайте 16-20 ГБ под веса с накладными расходами, плюс KV-cache. Верхняя граница зависит от контекста и от того, сколько слоёв уедет в системную память.
Практические ориентиры, посчитанные от размера весов: 24 ГБ VRAM вроде RTX 3090 или 4090 - рабочий минимум для короткого контекста и одного пользователя; 48 ГБ и больше - комфортный режим с запасом на 32K и небольшой батч; CPU-only возможно, но для агентных цепочек из десятков шагов ожидание станет главной проблемой. Про раскладку слоёв между двумя картами и расчёт KV-cache есть отдельный разбор на 48 ГБ VRAM.
Системная RAM нужна под выгрузку экспертов: если веса не помещаются целиком, llama.cpp держит часть в памяти хоста. 64 ГБ - разумный минимум для гибрида, 128 ГБ дают свободу экспериментов. Про выбор кванта и движка под такой объём есть материал про 2×RTX 5080 и 128 ГБ RAM.
| Память под веса | Квант | Контекст | Что ожидать |
|---|---|---|---|
| 12-16 ГБ VRAM + 64 ГБ RAM | Q4_K_M с частичной выгрузкой | 4K-8K | Работает, но медленно: для чата годится, для длинных агентных цепочек не всегда |
| 24 ГБ VRAM | Q4_K_M | 8K-16K | Один пользователь, вменяемая скорость |
| 32-48 ГБ VRAM | Q4_K_M или Q5_K_M | 32K | Запас под длинные документы и агентные трассы |
| 64 ГБ VRAM и больше | Q6_K, Q8_0 | 64K-128K | Максимум качества кванта, 256K всё равно упирается в кэш |
Таблица даёт ориентир по памяти, а не обещание токенов в секунду. Скорость зависит от числа активных экспертов, пропускной способности памяти и распределения слоёв.
Почему длинный контекст дороже, чем кажется
KV-cache хранит ключи и значения для каждого токена в каждом слое. Память под него растёт линейно: удвоили окно, удвоили кэш. MLA в архитектуре снижает цену одного токена за счёт сжатия в латентное представление, но рост не отменяет.
Рецепты: держать контекст по задаче, а не «на всякий случай»; проверить поддержку квантованного KV-cache в своей сборке (флаги --cache-type-k и --cache-type-v); в агентах обрезать историю и пересказывать её, а не тащить целиком. Точный размер кэша на токен для Xing4.0 в доступных источниках не приведён, поэтому считать его можно только по файлу конфигурации модели.
CPU+GPU offload и выбор квантизации под свою память
Флаг -ngl задаёт, сколько слоёв отправить на GPU. Значение 99 означает «все», и при нехватке памяти загрузка упадёт с OOM или драйвер уйдёт в своп. Для MoE полезнее оставить на GPU attention и служебные слои, а экспертов отдать на CPU: вычислений на токен меньше, обмен по PCIe дешевле, чем полная выгрузка весов.
Правило подбора: сначала определите бюджет памяти, потом квант, и только затем длину контекста. Обратный порядок заканчивается падением на загрузке или на первом длинном запросе.
Архитектура mHC + MLA + MTP: что стоит за аббревиатурами
MLA (Multi-head Latent Attention) сжимает ключи и значения в латентное пространство меньшей размерности. Для длинного контекста это прямой выигрыш по памяти: кэш на токен меньше, значит 256K становятся ближе к реальности.
MTP (Multi-Token Prediction) означает, что модель учится предсказывать несколько следующих токенов, а не один. На инференсе это открывает путь к спекулятивному декодированию и ускорению генерации, на обучении даёт более плотный сигнал. Реальный эффект зависит от того, использует ли движок MTP-головы: llama.cpp и vLLM могут вести себя по-разному.
mHC в описании PR не расшифровывается. Придумывать расшифровку не станем: публичных деталей мало, а гадать об архитектурном компоненте бессмысленно. Известно одно: под него сделали fused-операторы на Ascend C, то есть блок вычислительно тяжёлый, и его имело смысл ускорять под NPU.
Почему MLA и MTP важны именно для агентов
Агентный цикл это последовательность шагов с растущей историей: план, вызов инструмента, результат, рефлексия, следующий вызов. Каждый шаг дописывает контекст. MLA удешевляет хранение истории, MTP потенциально ускоряет генерацию очередного шага, вместе они сокращают время до завершения задачи.
Стабильность на длинном контексте в описании модели заявлена прямо: связность задачи и устойчивость исполнения при больших окнах. Проверять её стоит на своих сценариях, потому что длинные цепочки ломаются не на первом шаге, а на двадцатом, когда модель теряет исходную инструкцию.
Обучение на Ascend NPU и MindSpore: что это значит для пользователя
Модель обучена на платформе Ascend NPU с фреймворком MindSpore, адаптация выполнена под кластеры Ascend 910C через MindSpore/MindFormers: перенос функций mHC и разработка fused-операторов. Разработчик формулирует это как первый случай, когда модель такого масштаба полностью обучена на Ascend NPU с MindSpore, о чём сказано в описании PR.
Цифра, которая привлекает внимание: пропускная способность обучения выросла примерно на 96% относительно настроек out-of-the-box. Достигнуто многоуровневой кооптимизацией: тонкая настройка обмена данными между экспертами MoE, selective recomputation (выборочный пересчёт активаций вместо их хранения), автоматическое слияние графов и операторов DVM, fused-операторы mHC на Ascend C. Абсолютных значений производительности нет, поэтому 96% говорят только об относительном выигрыше от настройки, а не о сравнении Ascend с NVIDIA.
Для того, кто запускает модель локально, факт обучения на NPU значит немного: инференс идёт через llama.cpp, vLLM, SGLang или KTransformers на обычных GPU и CPU. Из этого факта нельзя делать выводы о качестве модели, зато он объясняет, почему часть тулинга ориентирована на MindSpore: рецепты обучения и дообучения выросли в этом стеке.
Экосистема: дообучение и инференс помимо llama.cpp
Заявленная поддержка: LLaMA-Factory и MindFormers для дообучения, SGLang, vLLM и KTransformers для инференса и развёртывания. Детали интеграций в описании не раскрыты, поэтому совместимость версий придётся проверять по факту.
LLaMA-Factory vs MindFormers: что выбрать для fine-tuning
LLaMA-Factory это привычный путь, если железо на NVIDIA или AMD и нужен LoRA без погружения в китайский стек. MindFormers подойдёт тем, у кого Ascend и нужна нативная поддержка. Перед стартом проверьте, есть ли в выбранной версии шаблон для архитектуры xing4_0: без него обучение упрётся в несовпадение имён слоёв.
Агентные фреймворки: OpenCode, Claude Code, OpenClaw, Hermes
Для OpenCode, Claude Code, OpenClaw и Hermes выполнена целевая адаптация и выравнивание форматов. На практике это значит меньше клея между моделью и фреймворком: формат вызова инструментов и ответов согласован. С путём через llama.cpp всё равно нужен llama-server с OpenAI-совместимым API, и стоит проверить, умеет ли конкретный фреймворк работать с локальным эндпоинтом и как он передаёт system prompt.
Если сравниваете движки под агентные пайплайны, полезен разбор llama.cpp или vLLM: сильные стороны у них разные, и для продакшн-нагрузки выбор не очевиден.
Для каких задач дообучать Xing4.0-29B-A4B
В описании модели перечислены четыре прикладных направления: классификация интентов, понимание таблиц, аудит контрактов и QA по базам знаний. Логика одна: лёгкая кастомизация на собственных данных под вертикальную задачу.
Классификация интентов и QA по базе знаний
Для классификации интентов 29B обычно избыточна: если классов десяток и тексты короткие, хватит модели на 3-8B. Запас ёмкости начинает работать, когда интентов сотни, формулировки тонкие, а классы пересекаются. LoRA через LLaMA-Factory здесь дешевле полного дообучения.
QA по базе знаний упирается в поиск, а не в размер модели. Длинный контекст позволяет положить в промпт больше чанков, но без ретривера и нормальной разметки документов качество не появится. Окно 256K не заменяет RAG, оно расширяет бюджет на контекст.
Аудит контрактов и работа с таблицами
Аудит контрактов - сценарий, где 256K выглядят логично: документ подаётся целиком, без нарезки, и модель видит связи между пунктами. На локальном железе это упирается в память: 256K контекста редко достижимы, на практике работают с 32K-64K, что покрывает большинство договоров среднего размера.
Таблицы - отдельная история. Качество зависит от токенизации чисел, структуры разметки и обучения. Обещать хороший результат на финансовых таблицах без проверки на своих данных нельзя: публичные наборы мало что говорят о вашей вёрстке и ваших формулировках.
Ограничения, риски и с чем сравнивать
Свежая поддержка в llama.cpp это код в PR, а не отполированный продукт. Возможны баги в конвертере, не все ускорения на месте, поведение на разных бэкендах отличается. Длинный контекст дорог по памяти, и 256K на бытовой карте остаются цифрой из спецификации.
Лицензия и условия коммерческого использования в доступных источниках не указаны: проверяйте их в репозитории модели до того, как строить на ней продукт. Независимых бенчмарков и сравнений с конкурентами по состоянию на начало ноября 2026 года нет, всё известное идёт из описания PR.
Сравнивать по классу стоит с другими китайскими MoE: семействами Qwen и DeepSeek близкого размера, а также с моделями, где активных параметров 3-4 млрд. Критерии простые: сколько памяти под веса, какой контекст держится без деградации, как ведёт себя tool calling, есть ли готовые GGUF и рецепты дообучения.
Кому модель подойдёт, а кому - нет
Берите, если: есть 24 ГБ VRAM и больше; вы строите агента с длинной историей и хотите локальный OpenAI-совместимый эндпоинт; планируете дообучение под вертикальную задачу через LLaMA-Factory; готовы к шероховатостям свежей поддержки и умеете читать логи llama.cpp.
Проходите мимо, если: 8-12 ГБ VRAM и апгрейд не планируется; нужен проверенный продакшн-стек с документацией и предсказуемым поведением; задача решается моделью на 3-8B с коротким входом; критична юридическая чистота лицензии, а условия вы ещё не проверили.
Что сделать дальше: посмотреть состояние PR #31589, проверить наличие GGUF-сборок под нужный квант, поднять llama-server на 8K контекста и прогнать свой сценарий - вызов инструмента, длинный документ, таблицу. По результатам решать про дообучение и перенос в продакшн.