AIREITERПубличный репозиторий на GitHub легко создает впечатление, будто соответствующий аппаратный стек уже доступен всем. Работа DeepSeek над Ascend действительно полезна и выглядит серьезно, но это не замена кластеру NVIDIA по принципу «одна команда — и готово»: текущий релиз сосредоточен на ядрах для Ascend 950 и требует CANN, torch_npu и совместимого оборудования.
Коротко: открытые компоненты, а не готовый кластер Ascend
DeepSeek опубликовала код для Ascend, включая DeepGEMM-Ascend — библиотеку ядер под лицензией MIT. Она сохраняет структуру API DeepGEMM, но рассчитана на NPU Huawei. В первой версии репозитория заявлена поддержка устройств Ascend 950, а в документации перечислены CANN 9.20, torch_npu, Python 3.10+, инструментарий C++20 и TileLang.
Этого достаточно, чтобы команда с доступом к совместимым системам Ascend могла изучать код, собирать его, проводить бенчмарки и подключать отдельные ядра к своим проектам. Но полноценным стеком для обучения или промышленной эксплуатации этот релиз не является.
Лаборатории с Ascend, облачные провайдеры и корпоративные команды уже могут оценивать код. Разработчик, располагающий только NVIDIA, может изучать реализацию или использовать проекты DeepSeek, ориентированные на NVIDIA, но запустить эти Ascend-ядра на H100 или пользовательской GeForce не получится.
Что именно выпустила DeepSeek
В open-infra-index DeepSeek распределяет инфраструктурные проекты по нескольким уровням. Изначально индекс в основном ориентирован на NVIDIA и Hopper: FlashMLA — ядро MLA-декодирования для Hopper GPU, DeepEP — библиотека коммуникаций для экспертного параллелизма, DeepGEMM — библиотека FP8 GEMM, DualPipe и EPLB отвечают за распределенные вычисления, а 3FS/Smallpond — за доступ к данным.
Специализированный релиз для Ascend меняет аппаратную платформу только для отдельных вычислительных участков, а не заменяет все уровни сразу. Самый наглядный публичный компонент — DeepGEMM-Ascend. Он включает:
- GEMM в форматах BF16, FP8 и FP4;
- вычисление логитов MQA;
- сгруппированные GEMM-операции и пути MegaMoE;
- ядро prenorm для mHC; и
- JIT-компиляцию и преобразования layout, специфичные для Ascend.
Проект заявляет совместимость API с DeepGEMM. Для инженеров, работающих с моделями, это важно, но CUDA-бинарники от этого не становятся переносимыми. Форматы матриц Ascend, упаковка коэффициентов масштабирования, компилятор, среда выполнения и API управления устройствами по-прежнему отличаются.
Карта компонентов: чем стек Ascend закрывает те же задачи, что и NVIDIA
В таблице сопоставлены роли компонентов, а не утверждается полная идентичность реализаций. Аналог решает похожую задачу, но может использовать другой API, коммуникационную инфраструктуру или стратегию построения ядер.
| Уровень | Подтвержденный код или зависимость для Ascend | Аналог в экосистеме NVIDIA | Ограничения |
|---|---|---|---|
| Матричное умножение | DeepGEMM-Ascend | DeepGEMM и ядра CUDA/Tensor Core | Та же роль GEMM, но другие аппаратные примитивы и форматы данных |
| Сгруппированные вычисления MoE | M-Grouped GEMM и MegaMoE в DeepGEMM-Ascend | MoE-layouts в DeepGEMM и специализированные ядра CUDA | Объединенные вычисления экспертов с платформенными ограничениями по формам и размерам |
| Распределение экспертов | В этом релизе не указана полноценная библиотека DeepSeek для dispatch на Ascend; используются коллективные операции Ascend и интеграции операторов | DeepEP с NVLink/RDMA | Задача на уровне системы похожа, но репозитории не являются взаимозаменяемыми |
| Attention и логиты | MQA logits в DeepGEMM-Ascend | FlashMLA для Hopper | Нагрузка похожа, но FlashMLA прямо ориентирована на Hopper |
| Связка с PyTorch | TorchNPU (torch_npu) | Бэкенд PyTorch для CUDA, среда выполнения CUDA и cuBLAS | TorchNPU вызывает Ascend NPU, а не эмулирует CUDA |
| Компилятор и инструменты для операторов | CANN и инструменты Ascend C/Bisheng | CUDA Toolkit, NVCC, PTX, cuBLAS, Triton | Синтаксис Python может выглядеть знакомо, но контракт взаимодействия с устройством меняется |
| Распределенная среда выполнения | Коллективные операции TorchNPU и инструменты Huawei для развертывания операторов | NCCL, сеть с поддержкой CUDA и ПО для кластеров NVIDIA | Инфраструктура, драйверы, коллективные операции и версии фреймворков остаются отдельными компонентами |
| Хранилище и работа с данными | Специализированный компонент DeepSeek для хранения данных в Ascend здесь не указан; хранилище предоставляет оператор | 3FS/Smallpond от DeepSeek и стек хранения оператора | В релиз ядер не входит соответствующий кластер хранения |
Иными словами, каждый компонент для Ascend закрывает определенную системную задачу, но не устраняет необходимость в экосистеме ПО NVIDIA.
Вычислительные ядра: DeepGEMM-Ascend и DeepGEMM
DeepGEMM-Ascend — самый конкретный связующий элемент релиза. В README библиотека описана как легковесная абстракция над примитивами Ascend MAD. Она скрывает fractal-layouts, требования к выравниванию, вычисление адресов и низкоуровневые параметры. Кроме того, проект использует специфичные для Ascend приемы, включая разреженную загрузку данных и конвейеризацию на основе корутин.
Требования заявлены достаточно четко: оборудование серии Ascend 950, CANN 9.20, torch_npu, Python 3.10 или новее, стандартная библиотека с поддержкой C++20, TileLang, а также зависимости для сборки, включая Tree-sitter. В инструкции по установке используются git clone --recursive, а затем pip install . --no-build-isolation.
В репозитории указано, что на тестовой системе Ascend 950DT загрузка для плотного GEMM достигает 99.8% заявленного аппаратного предела. Для одного случая BF16 приведен результат 431 TFLOPS при аппаратном пределе 432 TFLOPS; для случаев FP8 — 861 против 865. Это результаты отдельных ядер на выбранных формах матриц, а не сквозная производительность DeepSeek и не доказательство паритета с кластером NVIDIA.
Выполнение MoE: MegaMoE и распределение экспертов
В open-infra-index DeepSeek указывает инфраструктуру экспертного параллелизма для систем V3/R1. Поэтому важно не только то, насколько быстро выполняется одно матричное умножение. Токены нужно распределить, эксперты должны обработать их, а результаты — собрать между рангами.
Бенчмарк MegaMoE в DeepGEMM-Ascend объединяет dispatch экспертного параллелизма, два сгруппированных GEMM, SwiGLU и combine. В заявленной конфигурации используются EP8, top-k 6, один общий эксперт, а результаты усредняются по восьми рангам. Для случая с 384 экспертами и 16 384 токенами в README указаны 846.3 TFLOPS для одной конфигурации hidden/intermediate и пропускная способность коммуникаций 103.3 GB/s для другого приведенного случая.
Со стороны NVIDIA аналогом выступают DeepEP, MoE-layouts из DeepGEMM и окружающая их среда NCCL/NVLink/RDMA. Архитектурная задача похожа, но переносить показатели между производителями нельзя без совпадения числа токенов, маршрутизации экспертов, точности, количества рангов и условий работы сети.
Ядра для конкретных моделей: MQA logits и mHC prenorm
В проекте есть и ядра, которые легко не заметить, если описывать релиз просто как «порт GEMM». В README DeepGEMM-Ascend бенчмарк MQA logits обозначен как относящийся к пути DeepSeek Lightning Indexer. Для prefill и decode приведены случаи FP8 и FP4; для FP4 decode указано 124.2 микросекунды на описанной форме против 150.9 микросекунды для FP8.
В том же README ядро HC prenorm связано с модулем mHC DeepSeek, то есть Manifold-Constrained Hyper-Connections. Для указанных значений N и K пиковая пропускная способность памяти достигает 3,463 GB/s при M=8,192. Эти показатели демонстрируют оптимизацию под конкретные нагрузки, но не означают, что реализованы все операторы модели и все пути обслуживания.
Фреймворк и среда выполнения: CANN и TorchNPU против CUDA
В репозитории TorchNPU Huawei описывает TorchNPU как адаптер PyTorch для Ascend NPU. Среди заявленных возможностей — нативные и пользовательские API PyTorch, FSDP2, DTensor, коллективные операции, захват графов, профилирование, мониторинг WatchDog и функции управления памятью.
Концептуальный аналог в мире NVIDIA — PyTorch вместе со средой выполнения CUDA и библиотеками. На практике разница существенная: установка на Ascend требует совместимых версий CANN, драйвера, прошивки, Python, PyTorch и TorchNPU. В документации TorchNPU пример использует CANN 9.1.0, PyTorch 2.12.0 и torch-npu 2.12.0, тогда как для DeepGEMM-Ascend отдельно указана CANN 9.20. Это хороший повод сверяться с матрицей совместимости каждого репозитория и не смешивать команды из разных инструкций.
В собственной документации Huawei CANN описывается как программный слой, связывающий фреймворки с оборудованием Ascend, включая среду выполнения и инструменты разработки операторов. На практике CANN ближе к фундаменту платформы, чем к одной библиотеке уровня CUDA. Python-код модели может остаться привычным, но при этом потребуются специфичные для Ascend ядра, особенности работы с графами и отдельные процедуры отладки.
Что в этот релиз не входит
В исходном индексе открытой инфраструктуры DeepSeek перечислены проекты для хранения и работы на системном уровне, включая 3FS и Smallpond, а также описаны DualPipe, EPLB и архитектура системы инференса. Это важные ориентиры, но релиз ядер для Ascend не следует воспринимать как полный порт всех этих компонентов.
Для промышленного кластера по-прежнему понадобятся поставка и настройка оборудования, драйверы и прошивки, установка CANN, конфигурация межсоединений, поддержка распределенной среды выполнения, мониторинг, работа с чекпойнтами, восстановление после сбоев и оркестратор для обучения или обслуживания моделей. В руководстве Huawei Cloud по развертыванию DeepSeek инфраструктурная часть показана на примере инстансов, сетей, подсетей и групп безопасности. Эти сервисы нужны для развертывания, но в состав DeepGEMM-Ascend не входят.
Особенно важно учитывать эту границу при обучении. Публичные ядра могут убрать узкое место, но сами по себе не доказывают, что обучение модели фронтирного масштаба можно воспроизвести только по открытым репозиториям.
Кто уже может использовать этот стек
| Пользователь или организация | Можно ли использовать сейчас? | Что требуется | Практический вывод |
|---|---|---|---|
| Команда с оборудованием Ascend 950 | Да, для поддерживаемых ядер | Среда Linux, совместимые драйвер и прошивка, CANN 9.20, TorchNPU, компилятор и совместимая конфигурация Python/PyTorch | Наиболее подходящий ранний пользователь |
| Huawei Cloud или корпоративный оператор с ресурсами Ascend | Потенциально да | Поддерживаемый инстанс или кластер, точная матрица ПО и экспертиза по развертыванию | Подходит для контролируемого тестирования и обслуживания моделей |
| Исследовательская лаборатория со старым оборудованием Ascend | Не автоматически | Нужно подтвердить поддержку устройства; первая версия DeepGEMM-Ascend разрабатывалась и проверялась на серии Ascend 950 | Не следует предполагать совместимость с 910B/910C |
| Владелец рабочей станции только с NVIDIA | Нет, для Ascend-ядер | Документированное требование — оборудование Ascend | Используйте проекты DeepSeek для NVIDIA |
| Обычный разработчик PyTorch без доступа к ускорителю | Нет, если говорить о полноценном запуске | Можно изучать код и API, но воспроизвести аппаратные бенчмарки не получится | Доступ к документации не равен доступу к исполнению |
| Команда, ищущая готовую замену для обучения моделей фронтирного масштаба | Публичных подтверждений пока нет | Понадобятся полный кластер, системная интеграция и промышленная проверка, выходящие за рамки репозиториев ядер | Это инфраструктурная программа, а не установка через pip |
Практическая граница видна и в требованиях: документированный релиз по-прежнему привязан к оборудованию Ascend 950, CANN и torch_npu. Это гораздо более узкое утверждение, чем универсальная переносимость на любые ускорители.
Что доказывают опубликованные показатели — и чего они не доказывают
Показатель 99.8% для плотного GEMM — полезное свидетельство того, что заявленное ядро эффективно использует протестированное устройство на выбранных формах матриц. Таблицы MegaMoE дополнительно показывают, что инженеры DeepSeek работали не только над отдельным матричным умножением, но и над объединенными нагрузками с экспертным параллелизмом.
Однако ни один из этих результатов не отвечает на вопросы, которые в итоге важны для закупки оборудования или запуска обучения:
- Какова сквозная производительность в токенах в секунду на полной модели?
- Сколько стоит один токен при целевом размере батча?
- Насколько стабильны длительные запуски и перезапуски?
- Какие операторы переключаются на менее оптимизированные пути?
- Как межсоединения, память и энергопотребление сравниваются с планируемым кластером NVIDIA?
- Можно ли воспроизвести те же результаты вне исходной тестовой среды?
DeepSeek опубликовала серьезную работу над ядрами для Ascend, подробные требования к окружению и отдельные таблицы производительности. Релиз снижает программный барьер для команд, уже работающих в экосистеме Ascend, но аппаратные ограничения и требования к версиям никуда не исчезают.
FAQ
Полностью ли открыта инфраструктура DeepSeek для Ascend?
Нет. DeepGEMM-Ascend и связанная документация доступны публично, но опубликованные материалы не предоставляют единственный готовый кластер DeepSeek для обучения со всеми зависимостями и эксплуатационными инструкциями.
Можно ли запустить DeepGEMM-Ascend на GPU NVIDIA?
Нет. Проект рассчитан на оборудование Ascend 950. Пользователям NVIDIA стоит использовать проекты DeepSeek, ориентированные на NVIDIA.
Доказывает ли это, что DeepSeek обучает фронтирные модели на Ascend?
Нет. Это подтверждает, что DeepSeek опубликовала ядра для Ascend и провела бенчмарки отдельных нагрузок. Но публичного сквозного воспроизведения обучения фронтирной модели это не подтверждает.
Используйте этот стек уже сейчас, если у вас есть поддерживаемые ресурсы Ascend и команда, готовая самостоятельно решать вопросы совместимости CANN и TorchNPU. Если в распоряжении есть только оборудование NVIDIA, воспринимайте релиз как технический ориентир, а не как готовый к запуску бэкенд.