Adaptación Ascend 910B: Guía Técnica 2026

En pocas palabras: La adaptación del Ascend 910B para DeepSeek exige alinear drivers, operadores CANN y frameworks. Según Mingxin, esta coadaptación reduce la carga a 150 segundos (9.3× más rápido) usando NVMe-oF, evitando el fallback a CPU en contextos largos.

La adaptación Ascend 910B exige una verificación sistemática de tres capas: drivers, operadores y frameworks. Según datos medidos por Mingxin (reporte R9), coadaptar el almacenamiento con la pila de inferencia reduce la carga de DeepSeek-70B de 1399 a 150 segundos, logrando una aceleración de 9.3× frente al protocolo NFS tradicional.

DeepSeek es un modelo de lenguaje grande desarrollado por la empresa china DeepSeek, diseñado para tareas de generación y comprensión de texto. Su arquitectura prioriza la eficiencia computacional y el bajo costo de inferencia en entornos de producción.

El Ascend 910B es un chip de procesamiento neuronal (NPU) desarrollado por Huawei que utiliza la arquitectura heterogénea CANN como base de su software. A diferencia de las GPUs de NVIDIA, no comparte el ecosistema CUDA, lo que obliga a una migración profunda del stack de inferencia para modelos como DeepSeek.

¿Por qué la migración a Ascend 910B no es una simple recompilación?

Subís el modelo, lo probás en local, funciona bárbaro, lo mandás a producción y de repente todo se rompe porque el tokenizer no era el mismo, las dependencias cambiaron y nadie documentó nada. Eso pasa cuando intentás correr cargas de trabajo diseñadas para CUDA en hardware Ascend sin entender la arquitectura subyacente.

Según la documentación oficial de CANN, esta plataforma actúa como la capa de programación heterogénea equivalente a CUDA, pero con lógica de diseño independiente en sus librerías de operadores, compilación de grafos y gestión de memoria. No alcanza con cambiar la línea de comando o reemplazar la tarjeta gráfica; necesitás una adaptación sistemática que toque los cimientos del software.

Si alguna vez configuraste un cluster HPC sabés que el diablo está en los detalles de bajo nivel. Acá ocurre lo mismo: una desalineación mínima entre el driver del host y el firmware de la NPU invalida cualquier optimización superior. El problema acá es que muchos equipos tratan la migración como un ejercicio de portabilidad binaria, cuando en realidad es una reingeniería del pipeline de ejecución. Complementá con comparación entre Google y DeepSeek.

Checklist de adaptación de drivers y firmware para NPU

La primera barrera de entrada siempre es la comunicación hardware-software. Los drivers de Ascend gestionan el reconocimiento del dispositivo, la asignación de memoria y los enlaces de comunicación RoCE, que funcionan distinto a los enlaces PCIe/NVLink de las GPUs tradicionales.

Síntomas claros de mala adaptación en esta capa:

• Dispositivo no reconocido: El sistema operativo ve la placa pero el runtime de Ascend no inicializa la NPU.
• Fallos de memoria: Errores de asignación al intentar cargar pesos grandes en la VRAM/HBM de la NPU.
• Timeouts de comunicación: Latencia excesiva o cortes en la transferencia Host-NPU debido a incompatibilidad de versiones de firmware.

Antes de tocar una sola línea de código del modelo, verificá que la versión del driver en el host coincida exactamente con la del firmware instalado en la placa Atlas 910B. Si saltás este paso, vas a perder horas debuggeando errores “fantasma” que en realidad son problemas de compatibilidad básica.

Auditoría de operadores: cómo evitar el fallback silencioso a CPU

Ponele que le pedís a tu modelo que haga una operación matemática compleja y esperás que la NPU la procese en nanosegundos. ¿Qué pasó si el operador específico no existe en la librería CANN? Exacto, el sistema cae a la CPU, y ahí sí que se rompió todo.

La librería de operadores de Ascend es robusta, pero no cubre el 100% de las implementaciones personalizadas que usan frameworks modernos. Cada nodo computacional de tu grafo de inferencia debe tener un mapeo directo a un operador nativo de CANN. Si no lo tiene, tenés dos opciones: fusionar operadores existentes para lograr la misma funcionalidad o escribir manualmente el kernel para la NPU. Ya lo cubrimos antes en diferencias con OpenAI y DeepSeek.

Ojo con esto: el fallback a CPU suele ser silencioso. No ves un error rojo, solo notás que el throughput bajó a niveles ridículos. Para detectar estos cuellos de botella, usá herramientas de profiling específicas de Ascend que te muestren qué nodos se ejecutan en la NPU y cuáles terminan en la CPU. Un análisis operatorio exhaustivo es la única forma de garantizar que el cómputo pesado quede donde debe estar.

Configuración del framework de inferencia (vLLM) para backend Ascend

Una vez que los drivers están ok y los operadores mapeados, llega el turno del framework. Herramientas como vLLM necesitan habilitar explícitamente el backend de Ascend para que la lógica de scheduling corra sobre la NPU y no emule GPU.

Un punto crítico aquí es la gestión de la KV Cache. En arquitecturas CUDA, estrategias como PagedAttention (publicada en 2023) optimizan la fragmentación de memoria. Pero la administración de memoria de Ascend tiene características distintas, y aplicar la estrategia de paginación estándar de NVIDIA puede resultar ineficiente o incluso contraproducente.

Tenés que ajustar la estrategia de memoria del framework para que respete los límites y latencias propias de la HBM de la 910B. Si no hacés esto, el modelo funcionará, pero nunca vas a acercarte al pico teórico de throughput disponible en el hardware. Más contexto en normas de seguridad de Microsoft Intune.

¿Cómo reducir el tiempo de carga de modelos en Huawei Atlas 910B?

A veces el cuello de botella no está en la computación, sino en mover los archivos. Los modelos grandes como DeepSeek tienen pesos que superan los cientos de gigabytes. Si cargás esos archivos desde un NAS tradicional vía NFS, el ancho de banda y la latencia del protocolo de red van a matar tu tiempo de inicio de servicio.

Datos concretos de pruebas realizadas por Mingxin (reporte R9) sobre la plataforma Huawei Atlas 910B demuestran el impacto brutal de la capa de almacenamiento:

Modelo	Tiempo con NFS (baseline)	Tiempo con NVMe-oF (FX100)	Aceleración
DeepSeek-32B	691 segundos	112 segundos	6.2×
DeepSeek-70B	1399 segundos	150 segundos	9.3×

Esta mejora no viene de modificar el cálculo en la NPU, sino de optimizar el enlace de I/O. Reemplazar NFS por un array all-flash con NVMe-oF permite que la lectura de pesos sea casi instantánea para el hardware. Si estás escalando servicios de inferencia, ignorar la capa de almacenamiento es dejar dinero y tiempo sobre la mesa.

Metodología de verificación: pruebas de presión y métricas TTFT

Que el modelo levante no significa que esté bien adaptado. Necesitás un proceso gateado de validación. Primero, corrés un baseline en un solo nodo para asegurar que no hay errores funcionales. Después, aumentás la concurrencia gradualmente mientras monitoreás dos métricas sagradas: Time to First Token (TTFT) y Throughput total. Cubrimos ese tema en detalle en uso práctico de ChatGPT en producción.

Es tentador mirar benchmarks de otras plataformas. Por ejemplo, reportes internos muestran mejoras de 29–40% en throughput y reducciones de 26–32% en TTFT usando almacenamiento acelerado en chips AMD Instinct MI308X. Pero tomalo con pinzas: esos números no son extrapolables directamente a Ascend 910B. La arquitectura de memoria y comunicación es distinta.

¿Alguien lo verificó de forma independiente en tu entorno? Todavía no. Hasta que no corras tus propios tests de estrés en la infraestructura Ascend específica, cualquier cifra externa es solo una hipótesis. Validá localmente antes de prometer SLAs de rendimiento.

Errores comunes en la adaptación de Ascend 910B

Muchos equipos cometen los mismos tropiezos al migrar a esta plataforma. Evitalos:

• Ignorar la versión del firmware: Actualizar solo el driver del host y olvidar el firmware de la NPU genera timeouts intermitentes difíciles de reproducir.
• Asumir compatibilidad total de operadores: Creer que todos los kernels de PyTorch/TensorFlow tienen equivalente en CANN lleva a sorpresas de rendimiento en producción.
• Descuidar la configuración de KV Cache: Usar parámetros de paginación genéricos en lugar de afinarlos para la memoria de Ascend degrada el throughput en contextos largos.
• Depender de NFS para pesos: Mantener el storage legacy hace que el tiempo de carga domine la latencia total del servicio, anulando la velocidad de la NPU.

Preguntas Frecuentes

¿Qué capas necesito adaptar para correr DeepSeek en Ascend 910B?

Necesitás adaptar tres capas fundamentales: drivers (para reconocer el hardware y gestionar memoria), operadores (mapear cada cálculo a la librería CANN) y frameworks (habilitar el backend Ascend en vLLM o similar). Omitir cualquiera de estas capas resulta en degradación severa del rendimiento o fallos de ejecución.

¿Cómo reducir el tiempo de carga de modelos en Huawei Atlas 910B?

Reemplazá el protocolo de almacenamiento NFS por NVMe-oF utilizando arrays all-flash. Pruebas medidas mostraron que esta optimización de la capa de I/O reduce la carga de DeepSeek-70B de 1399 segundos a 150 segundos, mejorando la disponibilidad del servicio casi diez veces.

¿Por qué mi modelo cae a CPU en vez de usar la NPU Ascend?

Esto sucede cuando un operador específico del modelo no tiene implementación nativa en la librería CANN de Ascend. El sistema detecta la falta de soporte y realiza un fallback automático a la CPU para mantener la corrección funcional, sacrificando enormemente la velocidad de inferencia.

¿Es necesario cambiar el almacenamiento para optimizar la inferencia?

Sí, especialmente para modelos de gran tamaño. Aunque la NPU acelere el cómputo, si la carga de pesos tarda minutos debido a un storage lento, el tiempo total de respuesta se dispara. Optimizar la ruta de datos hacia la memoria de la NPU es tan crítico como optimizar los kernels de cálculo.

Conclusión

Adaptar la pila de inferencia en Ascend 910B es un proyecto serio, no un plug-and-play. La clave está en tratar las tres capas (drivers, operadores, frameworks) como un sistema indivisible y sumar una capa de almacenamiento rápido que elimine cuellos de botella de I/O. Con la metodología correcta y verificación propia, podés lograr aceleraciones reales superiores a 9x en tiempos de carga y mantener el throughput alto en producción. No te quedes con los benchmarks ajenos: testeá en tu casa.

Fuentes

• Mingxin Tech – Ascend 910B Inference Stack Adaptation Checklist
• Huawei Ascend Community – Documentación de CANN Architecture
• Paper Académico – Efficient Memory Management for LLM Serving with PagedAttention