La respuesta rápida para equipos con H100 y RTX
DeepInfer no ha anunciado ni documentado oficialmente compatibilidad con H100. Tampoco existe compatibilidad oficial documentada con RTX. La versión actual está orientada a DeepSeek-V4.1-Flash y especifica hardware NVIDIA SM100 con CUDA 13, o Ascend 950 con CANN 9.2. El repositorio también exige Linux, GCC 13 o posterior y Python 3.12 (repositorio oficial de DeepInfer).
Que una plataforma “no aparezca en la lista” es una conclusión relevante para compras y planificación de producción, aunque no demuestra que un parche experimental no pueda llegar a compilar.
Qué hardware y software admite oficialmente DeepInfer
El límite de compatibilidad es más concreto que “una GPU NVIDIA” o “un modelo de DeepSeek”. Se trata de una generación específica de acelerador, una pila de software determinada y una ruta de modelo concreta.
| Componente | Compatibilidad documentada |
|---|---|
| Modelo | DeepSeek-V4.1-Flash |
| Checkpoint predeterminado | deepseek-ai/DeepSeek-V4.1-Flash-1017 |
| Acelerador NVIDIA | SM100, asociado a las GPU de centro de datos Blackwell |
| Cadena de herramientas NVIDIA | CUDA 13 |
| Acelerador Huawei | NPU Ascend 950 |
| Cadena de herramientas Huawei | CANN 9.2 |
| Requisitos del sistema anfitrión | Linux, GCC 13+, Python 3.12 |
| Modo de inferencia | Inferencia offline dentro del proceso |
Las preguntas y respuestas sobre despliegue de DeepSeek recogen topologías de referencia con 4 GPU SM100 para el prefill y 64 GPU SM100 para el decode dentro de un dominio scale-up. Son mediciones realizadas con SM100, no estimaciones de capacidad para H100.
Por qué SM100 no implica compatibilidad con H100 ni RTX
La lista oficial de DeepInfer no menciona H100, SM90 ni ningún modelo RTX. Que una GPU sea compatible con CUDA no basta para confirmar que también lo sea con DeepInfer.
El repositorio integra componentes sensibles a la arquitectura, como FlashMLA, DeepGEMM, DeepEP y operaciones de TileLang (documentación del proyecto). Una GPU reconocida por la herramienta puede fallar en tiempo de ejecución, generar resultados incorrectos o perder precisamente el rendimiento que justificaba la migración.
Por eso conviene separar tres afirmaciones:
- El código compila para una arquitectura.
- El modelo se ejecuta con resultados correctos y un comportamiento distribuido estable.
- El despliegue ofrece una latencia y un rendimiento útiles y validados.
Un build correcto solo permite confirmar la primera. Los materiales públicos de DeepInfer no ofrecen benchmarks con H100 o RTX, una receta oficial de compilación para SM90 ni una configuración RTX de consumo validada.
Opciones de migración para la infraestructura existente
Si tu clúster usa H100 u otro sistema Hopper
No sustituyas un stack de serving H100 que ya funciona solo para probar DeepInfer. Trátalo como un proyecto experimental de portabilidad, no como un despliegue con soporte oficial.
Un plan de migración razonable sería:
- Mantener sin cambios el servidor de modelos de producción.
- Crear una rama aislada con versiones fijadas de DeepInfer, CUDA, los drivers, el compilador y el modelo.
- Revisar las dependencias específicas de la arquitectura antes de compilar.
- Ejecutar pruebas de comparación numérica frente a un runtime de referencia que ya funcione.
- Medir la latencia de prefill, la latencia de decode, la concurrencia, el uso de memoria y la recuperación ante fallos.
- Promover el port únicamente si mejora la carga de trabajo que realmente importa al equipo.
La alternativa práctica es evaluar un runtime de serving que documente explícitamente tu configuración H100, como vLLM, SGLang o TensorRT-LLM. La elección debe depender del checkpoint exacto de DeepSeek, la cuantización, las funciones de la API y la topología distribuida que necesites, no de las cifras de DeepInfer con SM100.
Si tu equipo utiliza estaciones de trabajo o servidores RTX
La lista oficial de DeepInfer no incluye ningún modelo RTX. Además, su topología de referencia está pensada para inferencia a gran escala, así que una sola tarjeta RTX o un grupo pequeño de RTX no debe considerarse un sustituto económico de las configuraciones de 4 GPU para prefill o 64 GPU para decode.
Si el objetivo es desarrollar, evaluar o levantar un endpoint autogestionado de menor tamaño, utiliza un runtime generalista de inferencia local. Mantén DeepInfer en el radar por si aparece una adaptación específica para esa arquitectura, pero no hagas un presupuesto basado en una incidencia aún no integrada o en una afirmación de un foro.
Si tienes acceso a SM100 o Ascend 950
Esta es la única vía que encaja con la matriz oficial actual. Incluso en este caso, DeepInfer no es un servicio de API online completo: las notas oficiales de despliegue describen componentes de producción que todavía faltan, como la caché KV persistente, la orquestación de prefill/decode y el balanceo de carga entre réplicas.
Por eso DeepInfer encaja mejor en equipos que quieran estudiar o poner a prueba el motor, dispongan de la topología de aceleradores necesaria y estén preparados para construir el resto de la plataforma. No es automáticamente la mejor opción para una pasarela de API con múltiples modelos.
Limitaciones de despliegue que van más allá de la GPU
La compatibilidad del hardware es solo uno de los filtros de la migración. La versión pública se describe como inferencia offline, no como un servidor OpenAI-compatible terminado. Las piezas que faltan influyen directamente en la arquitectura:
| Capacidad ausente | Consecuencia operativa |
|---|---|
| Caché KV persistente o distribuida | La reutilización online en conversaciones de varios turnos debe resolverse fuera de DeepInfer |
| Desacoplamiento de prefill y decode | El operador debe encargarse de la orquestación y la asignación de cada etapa |
| Balanceo de carga entre réplicas | El enrutamiento y el balanceo basado en colas siguen siendo externos |
| HTTP, autenticación y herramientas | Siguen haciendo falta una pasarela de API y una capa de agentes |
El proyecto independiente deepseek-recipe traduce los formatos Messages, Chat Completions y Responses, pero no ejecuta la inferencia ni proporciona el servicio de producción completo.
Lista de comprobación antes de cambiar de hardware
Antes de aprobar una migración a DeepInfer, exige pruebas para cada uno de estos puntos:
- Compatibilidad oficial de arquitectura y build: ¿Aparece exactamente tu GPU en la lista y puede reproducirse el entorno fijado en una máquina limpia?
- Cobertura de kernels y corrección: ¿Los kernels de atención, GEMM y paralelismo de expertos generan las mismas salidas y mantienen respuestas estructuradas y un comportamiento correcto con contextos largos?
- Rendimiento distribuido: ¿La cantidad de GPU y la topología de interconexión previstas siguen siendo estables con tus objetivos de concurrencia y memoria?
- Completitud del servicio: ¿De dónde salen la caché KV, el enrutamiento, la autenticación, el transporte HTTP y el balanceo entre réplicas?
Si la respuesta a la primera pregunta es “no”, clasifica el proyecto como experimental. Si la respuesta a las preguntas sobre el servicio es “externo”, incorpora ese trabajo de ingeniería al coste de la migración.
Preguntas frecuentes sobre la compatibilidad de DeepInfer con H100
¿Puede DeepInfer ejecutarse en una NVIDIA H100?
La compatibilidad con H100 no está documentada oficialmente. La entrada actual para NVIDIA es SM100. Un port experimental podría ser posible, pero los materiales citados no incluyen una receta oficial de compilación para H100 ni un benchmark validado en H100.
¿DeepInfer es compatible con RTX 4090, 5090 u otras tarjetas RTX?
La compatibilidad con RTX no aparece en la lista oficial. Los materiales oficiales citados no ofrecen ninguna configuración RTX validada. Considera el despliegue en RTX como no compatible hasta que el proyecto documente la arquitectura y valide sus kernels.
¿Qué debería utilizar un equipo con H100?
Mantén o evalúa un runtime con compatibilidad explícita con H100 y compáralo con tu propio checkpoint y patrón de tráfico. vLLM, SGLang y TensorRT-LLM son puntos de partida prácticos, mientras que DeepInfer debe considerarse un objetivo futuro de portabilidad o un motivo para evaluar infraestructura SM100.
Trata cualquier port para H100 o RTX como experimental hasta que se documenten la arquitectura exacta, los kernels, la capa de servicio y los resultados con la carga de trabajo real.