La prueba de DeepSeek H200 cuestiona la afirmación de ser «80 veces más barato»
DeepSeek afrontó una prueba práctica de costes después de que The Call Center Doctors alquilara cuatro GPU Nvidia H200 para examinar la afirmación de que el modelo es «80 veces más barato».
La consultora intentó servir DeepSeek V4.1 Flash a sus agentes de programación en lugar de usar Claude Opus 5.5 a través de Claude Code. Su prueba original concluyó que unos pesos de modelo económicos no daban como resultado un sistema funcional económico.
La prueba de DeepSeek H200 puso de manifiesto una brecha entre el precio por token y el coste de completar trabajo real de software. El servidor alquilado manejó rápidamente cargas de trabajo sintéticas, pero su rentabilidad se deterioró cuando el equipo reprodujo el tráfico real de programación.
A la tarifa habitual de alquiler bajo demanda, el servidor costaba aproximadamente el doble que enviar la misma carga de trabajo a la propia API de DeepSeek. La consultora también concluyó que sus suscripciones existentes a Claude Code seguían siendo competitivas al medir cambios de código completados en lugar de precios por token.
Estos hallazgos proceden de la carga de trabajo, la configuración y las mediciones internas de una sola empresa. No constituyen una referencia universal para ninguno de los dos modelos. DeepSeek nunca recibió permiso para escribir código de producción durante la prueba, lo que limita cualquier comparación directa del trabajo completado.
Aun así, el experimento importa porque utilizó tráfico de agentes de programación desplegados, en vez de un benchmark aislado. Midió contexto repetido, concurrencia, latencia, trabajo operativo y el perímetro de seguridad en torno a la ejecución autónoma de código.
La conclusión central es sencilla. Las bajas tarifas de API de DeepSeek siguieron siendo atractivas, mientras que autoalojar el mismo modelo en GPU prémium produjo una rentabilidad peor para esta carga de trabajo concreta.
El resultado obliga a los compradores a definir qué significa «más barato» antes de cambiar de proveedor. Una tarifa baja por token de salida puede ser relevante, pero no describe el rendimiento, la fiabilidad, el esfuerzo de ingeniería ni la entrega exitosa.
La prueba de DeepSeek H200 sustituyó una afirmación de precio por una prueba de carga de trabajo
La consultora probó un sistema de inferencia completo, no solo la cifra impresa junto a un millón de tokens.
The Call Center Doctors construye y opera entornos de centros de llamadas para otras empresas. También utiliza agentes de programación para mantener el software que respalda ese trabajo.
El 27 de septiembre, la empresa alquiló un servidor con cuatro aceleradores Nvidia H200. Descargó DeepSeek V4.1 Flash y configuró el modelo como backend para agentes conectados normalmente a Claude Code.
La prueba se centró en dos afirmaciones habituales sobre los modelos de pesos abiertos. La primera sostiene que unas tarifas por token más bajas se traducen directamente en menores costes operativos. La segunda afirma que las organizaciones pueden evitar los márgenes de los proveedores alquilando GPU y sirviendo el modelo por sí mismas.
DeepSeek ofrece a los compradores motivos para investigar esas afirmaciones. El lanzamiento del modelo describe V4.1 Flash como un modelo de mezcla de expertos diseñado para una inferencia más rápida y un mayor rendimiento.
Un modelo de mezcla de expertos activa solo una parte de su red para cada token. Ese diseño puede reducir el cómputo frente a ejecutar todos los parámetros en cada solicitud.
DeepSeek afirma que su arquitectura activa menos parámetros mientras procesa entradas y salidas. También señala que el modelo necesita menos memoria de alto ancho de banda para su caché clave-valor que la generación anterior.
Una caché clave-valor almacena datos intermedios de atención de tokens anteriores. Reutilizar esos datos hace que el contexto repetido sea más económico que procesar toda la secuencia como entrada nueva.
Por ello, la consultora eligió hardware adecuado para una inferencia intensiva en memoria. Cada H200 incluye 141 GB de memoria de alto ancho de banda, según las especificaciones de H200 de Nvidia.
Entre las cuatro GPU, esa capacidad bastó para cargar y servir el modelo tras varios cambios de configuración. Sin embargo, lograr un servicio estable requirió cinco arranques.
Cada reinicio exigió otro periodo de carga del modelo. Una optimización consumió memoria inesperada, otra ejecución se congeló y una configuración posterior falló con una concurrencia mayor.
El quinto intento se estabilizó con un límite de concurrencia menor y la mayor parte de la memoria disponible comprometida. Esta secuencia operativa pasó a formar parte del resultado económico.
Una API alojada oculta las descargas del modelo, la asignación de memoria, el software de servicio, la planificación de capacidad y los arranques fallidos. Una máquina alquilada expone cada tarea al cliente.
Una vez estable, el servidor rindió bien durante pruebas aisladas de un minuto. Procesó con especial rapidez la entrada en caché y generó miles de tokens por segundo en toda la máquina.
Ese resultado respaldó inicialmente el argumento a favor del autoalojamiento. Cuatro H200 tenían un rendimiento bruto considerable, y el diseño orientado a caché de DeepSeek se comportó como se esperaba.
El problema apareció cuando el equipo dejó de probar una categoría de token a la vez. Sus agentes de programación no enviaban una secuencia equilibrada de entrada nueva, entrada en caché y salida.
Suministraban repetidamente conversaciones largas, resultados de herramientas, contexto de archivos y razonamientos anteriores. La mayor parte de cada solicitud consistía en texto que el modelo ya había visto.
Esa carga de trabajo alejó la prueba de la velocidad teórica de salida. Obligó a la máquina a dedicar casi todo su tiempo a procesar el contexto necesario antes de generar la siguiente respuesta.
Por tanto, el evento no fue una carrera convencional de modelos. Fue una prueba de si unas tarifas de inferencia atractivas sobrevivían al contacto con el tráfico real de un sistema de agentes.
Por qué el contexto de los agentes consumió las cuatro H200
Los agentes de programación a menudo dedican mucho más cómputo a leer su historial que a escribir el siguiente token útil.
Los registros de septiembre de la consultora contenían 388.500 millones de tokens leídos y 393 millones de tokens escritos. De la entrada, 374.200 millones de tokens eran relecturas en caché.
Eso significa que más del 96 por ciento de la entrada registrada repetía contexto anterior. Por cada token de salida, los agentes suministraban unos 41,6 tokens de entrada nueva y 1.042 tokens en caché.
Una solicitud media releía aproximadamente 196.000 tokens. Este patrón importa porque la entrada en caché es económica por token, pero nunca es computacionalmente gratuita.
El servidor alquilado procesaba cada token en caché más rápido que cada token nuevo. Sin embargo, los agentes suministraban tantos tokens en caché que esos pequeños costes se acumularon hasta convertirse en la carga de trabajo dominante.
La empresa midió aproximadamente 1,9 microsegundos de tiempo de servidor por token en caché. Un token de entrada nuevo requería unos 60 microsegundos, mientras que un token de salida necesitaba unos 189 microsegundos.
Aplicar esas mediciones a la mezcla de tráfico de producción produjo un límite combinado cercano a 213 tokens de salida por segundo. Ese fue el resultado agregado para todos los agentes que compartían las cuatro GPU.
Según la consultora, la fórmula coincidió con la prueba en vivo dentro de un margen del tres por ciento. Esa coincidencia reforzó el modelo de carga de trabajo, aunque una parte independiente no lo ha replicado.
La empresa estimó que la máquina podía procesar aproximadamente 20.000 millones de tokens totales al día con esta mezcla. Su día más activo de septiembre alcanzó los 51.000 millones de tokens.
La capacidad se convirtió, por tanto, en una segunda restricción. Un servidor no podía absorber el pico registrado, incluso si su rentabilidad habitual de alquiler hubiera sido favorable.
El contraste entre pruebas aisladas y mixtas explica por qué el rendimiento de los titulares puede inducir a error. La máquina generó más de 5.000 tokens por segundo cuando la salida se midió de forma aislada.
Los agentes reales no pueden operar solo con salida. Deben suministrar continuamente instrucciones, código, archivos, registros, respuestas de herramientas y mensajes anteriores.
Los agentes de larga duración amplifican ese desequilibrio porque las conversaciones crecen con el tiempo. Cada llamada posterior puede contener gran parte del mismo historial más una pequeña cantidad de información nueva.
Los descuentos de caché reducen el cargo por esos tokens repetidos. No eliminan el ancho de banda de memoria, los retrasos de planificación ni el coste de oportunidad de ocupar un servidor.
Esta distinción también complica las comparaciones entre modelos. Un modelo más capaz podría completar una tarea con menos intentos, prompts más cortos o menos revisión.
Un modelo más barato podría seguir ganando si utiliza un contexto similar y logra resultados comparables. Podría perder si requiere más reintentos, explicaciones más largas o la verificación de otro modelo.
La prueba de DeepSeek H200 no respondió por completo a esa cuestión de calidad porque DeepSeek sirvió principalmente como revisor de solo lectura. Sí mostró por qué las tarifas por token de salida por sí solas no pueden responderla.
La métrica que importa depende del trabajo. Un sistema de resúmenes por lotes podría priorizar el rendimiento total, mientras que un agente interactivo también necesita baja latencia y un uso fiable de herramientas.
Una operación de programación se preocupa por los cambios completados, el tiempo de revisión, las regresiones, la seguridad y la espera de los desarrolladores. La eficiencia de tokens es solo una variable de ese resultado.
Los registros de la consultora ofrecieron una advertencia útil para otros compradores. Antes de seleccionar hardware, los equipos deben perfilar la proporción entre entrada nueva, contexto en caché y salida generada.
Sin esa proporción, un benchmark puede optimizar la parte más pequeña de la carga de trabajo. Una prueba de generación rápida puede decir poco sobre un agente que dedica la mayor parte de su tiempo a leer.
El autoalojamiento de DeepSeek perdió frente a la API de DeepSeek
El resultado más claro no fue DeepSeek frente a Claude, sino la infraestructura alquilada de DeepSeek frente al servicio gestionado de DeepSeek.
La tarifa habitual de servidor bajo demanda produjo un coste diario aproximadamente entre dos y 2,4 veces el valor del mismo tráfico a través de la API de DeepSeek. Ese cálculo asumía una utilización continua.
El alquiler puntual utilizado durante el experimento era mucho menor. A esa tarifa temporal, el servidor solo se acercaba a la paridad con el servicio gestionado de DeepSeek mientras operaba a plena carga.
La capacidad puntual conlleva una contrapartida de disponibilidad. Los proveedores pueden recuperarla cuando cambia la demanda, lo que dificulta tratarla como infraestructura de producción fiable.
Eso ocurrió casi inmediatamente después del experimento. El proveedor recuperó la máquina a los pocos minutos de la prueba final.
La alternativa bajo demanda evitaba ese riesgo de interrupción, pero debilitaba la rentabilidad. También cobraba mientras el modelo cargaba, se reiniciaba, esperaba tráfico o se mantenía por debajo de la utilización máxima.
La API gestionada de DeepSeek distribuye esos periodos inactivos entre muchos clientes. El proveedor puede agrupar solicitudes, compartir hardware y operar su propia pila de servicio a mayor escala.
Su tarifario de API también distingue entre entrada en caché, entrada nueva y salida. El tráfico fuera de horas punta recibe tarifas más bajas que el tráfico de horas punta entre semana.
Ese calendario ofrece a los compradores otra vía de optimización. Las cargas de trabajo por lotes flexibles pueden alejarse de los periodos punta sin requerir una máquina dedicada.
El servidor alquilado no tenía un ajuste equivalente según la demanda. Su contador horario continuaba independientemente de que los agentes produjeran trabajo útil.
La comparación no establece que el autoalojamiento sea siempre antieconómico. Las organizaciones pueden poseer hardware ya depreciado, negociar tarifas de capacidad más bajas o mantener una utilización constante en varias cargas de trabajo.
Los despliegues grandes también pueden optimizar kernels, cuantización, enrutamiento y planificación de lotes más allá de lo que logró un experimento breve. La propia DeepSeek invita a las organizaciones que planeen despliegues muy grandes a analizar opciones adicionales.
La privacidad puede justificar la operación local incluso cuando la inferencia alojada es más barata. Las cargas de trabajo reguladas pueden requerir controles de datos que superen los costes directos de cómputo.
La capacidad predecible también puede importar. Una empresa con demanda sostenida podría preferir infraestructura bajo su control, especialmente cuando una API externa impone límites o riesgos de disponibilidad.
Sin embargo, esas ventajas requieren una máquina estable, operadores experimentados, monitorización, conmutación por error y controles de seguridad. Nada de ello viene automáticamente con pesos abiertos.
La prueba también reveló un coste de especialización. Los ingenieros tuvieron que diagnosticar el consumo de memoria, los fallos de inicio, los límites de concurrencia y el comportamiento de serving antes de ejecutar la carga de trabajo útil.
Ese trabajo no se incluyó en la simple comparación de máquinas. Incluirlo haría menos favorable el breve experimento de autoalojamiento.
Esta es la principal lección para las empresas que consideran un despliegue autoalojado de DeepSeek. La comparación relevante es un servicio completo frente a otro servicio completo.
Los pesos del modelo son un componente. El alquiler de hardware, la capacidad ociosa, la orquestación, la observabilidad, la respuesta ante incidentes, la energía, el almacenamiento y el tiempo del personal completan el sistema.
La API de DeepSeek se beneficia de la misma eficiencia arquitectónica que el modelo descargable. También se beneficia de una infraestructura que DeepSeek puede operar para muchos clientes.
El autoalojamiento debe superar ambas ventajas. Evitar el margen de una API es insuficiente cuando el proveedor de la API tiene mejor utilización y experiencia de serving.
Para esta carga de trabajo, no las superó. La opción de pesos abiertos aportó control, pero la nube de DeepSeek ofreció la experiencia de DeepSeek más barata.
La afirmación de ser “80 veces más barato” comparaba modelos de compra distintos
La comparación principal se debilitó porque situaba las tarifas de una API pública junto al acceso por suscripción con uso intensivo.
La afirmación de ser “80 veces más barato” compara tarifas por tokens bajo supuestos concretos. No describe automáticamente cuánto paga cada usuario de Claude Code.
La consultora accedía a Claude mediante suscripciones, en lugar de la API medida de Anthropic. Anthropic confirma que los planes elegibles ofrecen acceso por suscripción a Claude Code, sujeto a límites de uso compartidos.
Una suscripción y una API responden a patrones de compra distintos. La suscripción agrupa el acceso dentro de límites definidos, mientras que una API cobra según el consumo medido.
La consultora afirmó que el uso de sus suscripciones equivalía a recibir un gran descuento respecto a las tarifas de la API pública. Esa diferencia absorbió la mayor parte de la brecha teórica de 80 veces.
Usando el tráfico de septiembre, la empresa calculó que la API de DeepSeek podía ir de ser algo más barata a más cara que sus suscripciones de Claude. El momento determinaba dónde caía el uso entre las tarifas punta y valle.
Los resultados comunicados también estimaron que la tarifa pública de la API de Claude habría generado una factura mucho mayor. Sin embargo, ese no era el producto que la empresa había adquirido.
Esta distinción es fácil de pasar por alto cuando las comparaciones reducen cada producto a una tarifa nominal por token. El mismo modelo puede venderse mediante suscripciones, contratos empresariales, plataformas cloud o APIs directas.
Cada canal tiene límites e incentivos económicos distintos. Una suscripción puede favorecer un uso individual constante, mientras que una API ofrece escala programable y una contabilidad detallada del uso.
Un contrato empresarial puede añadir capacidad negociada, compromisos de servicio o controles. El autoalojamiento sustituye el margen de servicio del proveedor por infraestructura y responsabilidad operativa.
Ninguna tarifa única captura los cuatro acuerdos. Los compradores deberían comparar la vía que realmente pueden adquirir y operar.
La consultora también calculó el coste de un cambio de código integrado. Sus agentes de Claude completaron 5.610 cambios integrados durante el periodo medido, de los cuales cinco fueron revertidos posteriormente.
Estimó que DeepSeek requeriría tokens adicionales, reintentos y comprobaciones basadas en Claude. Bajo esos supuestos, cada cambio aceptado costaría más con DeepSeek.
Esta estimación merece cautela. DeepSeek no realizó la misma tarea con permisos de escritura, por lo que el estudio no pudo observar su tasa real de éxito ni su uso total de tokens.
Los supuestos podrían ser demasiado severos si mejores prompts, software de serving o diseño de agentes mejoraran la salida de DeepSeek. Podrían ser demasiado optimistas si la revisión descubriera más defectos.
Aun así, el coste por cambio aceptado es un objetivo más útil que el coste por token de salida. Conecta el gasto de inferencia con software que supera la revisión.
La mejor unidad depende del flujo de trabajo. Los equipos de atención al cliente podrían medir los casos resueltos, mientras que los investigadores podrían medir los hallazgos verificados.
Una tarifa baja por token sigue siendo valiosa cuando los modelos requieren un trabajo similar para lograr esos resultados. Se vuelve menos decisiva cuando difieren la capacidad, la latencia o la carga de revisión.
La cifra de “80 veces” describe, por tanto, una comparación limitada, no un ahorro universal. The Call Center Doctors no refutó la tarifa publicada de DeepSeek.
En cambio, demostró que la aritmética de las tarifas puede derrumbarse cuando los productos, las cargas de trabajo y la calidad de los resultados difieren.
La seguridad impidió que DeepSeek escribiera código de producción
La limitación más importante del experimento fue también su advertencia operativa más relevante: DeepSeek nunca completó la tarea de programación prevista.
La empresa planeaba usar DeepSeek para agentes que escribieran código. Sus revisores encontraron después posibles vías para que el código generado escapara del sandbox previsto.
Un sandbox es un entorno de ejecución aislado que restringe a qué puede acceder el código no confiable. Debe impedir que un agente llegue a archivos sensibles, credenciales, redes o privilegios administrativos.
Una debilidad comunicada implicaba un archivo de configuración en un directorio temporal compartido. La empresa consideraba que el contenido manipulado allí podría permitir que el código generado se ejecutara con permisos elevados.
Por ello, la consultora mantuvo a los agentes constructores sin conexión. DeepSeek operó únicamente mediante entre 48 y 64 agentes revisores de solo lectura.
Esos revisores examinaron 2.377 carpetas de código y produjeron 32 informes de errores. Esa actividad demostró una capacidad de procesamiento útil, pero no probó la implementación autónoma.
El problema de seguridad no se presentó como un defecto en los pesos del modelo de DeepSeek. Se refería al entorno de agentes circundante de la consultora y a sus controles de ejecución.
Esta distinción importa. Cualquier modelo capaz de generar comandos puede exponer debilidades en una cadena de herramientas mal aislada.
Claude, DeepSeek u otro modelo pueden producir acciones inseguras cuando los agentes reciben acceso al sistema de archivos y al shell. El límite de seguridad debe asumir que la salida del modelo no es confiable.
En consecuencia, la prueba mezcló dos cuestiones separadas. Una concernía a la economía de inferencia de DeepSeek. La otra, a si el sandbox de agentes de la empresa estaba listo para la automatización con permisos de escritura.
Solo la primera cuestión recibió mediciones directas de carga de trabajo. La segunda detuvo la prueba de programación comparativa prevista.
Esto impide afirmar con contundencia que Claude produjo mejor código en el mismo experimento. El trabajo completado por Claude en septiembre era información histórica de producción, mientras que el trabajo de DeepSeek fue una prueba restringida.
También impide una medición justa del coste de DeepSeek por cambio integrado. El modelo nunca tuvo la oportunidad de generar cambios para su revisión y despliegue.
La empresa hizo referencia a benchmarks públicos de programación para sostener que Opus tenía una ventaja de capacidad. Los benchmarks pueden aportar contexto, pero no sustituyen un conjunto de tareas internas idéntico.
Un seguimiento riguroso proporcionaría a ambos modelos los mismos repositorios, herramientas, restricciones de seguridad, prompts y pruebas de aceptación. Los revisores seguirían sin conocer la identidad del modelo.
El estudio registraría cambios exitosos, regresiones, reintentos, latencia, uso de tokens, tiempo de revisión humana y vulneraciones de seguridad. Solo entonces podría comparar directamente los costes totales de entrega.
A pesar de esta limitación, el despliegue abortado deja una lección práctica. El coste de infraestructura significa poco cuando la capa de ejecución no puede exponer con seguridad las herramientas previstas del modelo.
Los sistemas de agentes amplían la superficie de ataque porque conectan la salida probabilística de un modelo con acciones deterministas. Una sola vía insegura puede importar más que miles de tokens baratos.
Por tanto, las empresas deberían probar la contención antes de calcular los ahorros del trabajo autónomo. El análisis de solo lectura y los agentes con permisos de escritura pertenecen a categorías de riesgo muy diferentes.
La seguridad también afecta a la economía. Un aislamiento más sólido puede requerir entornos desechables, credenciales restringidas, controles de red, registros y puntos de aprobación.
Esos controles consumen tiempo de ingeniería y añaden latencia. También pueden reducir la concurrencia o exigir infraestructura independiente.
El modelo con la tarifa de inferencia más baja podría no generar el menor coste de entrega segura. El sistema relevante incluye cada control necesario para confiar en su salida.
Qué significa la prueba de DeepSeek con H200 para los compradores de IA
La siguiente comparación debería centrarse en el trabajo aceptado, la utilización sostenida y la ejecución segura, en lugar de en un único precio por token.
La primera señal que conviene observar es una repetición controlada con permisos de escritura. DeepSeek necesita las mismas herramientas, repositorios, prompts y criterios de aceptación utilizados previamente con Claude.
Si completa cambios comparables con una revisión limitada, la conclusión negativa de la consultora se debilitaría. Si los reintentos y las correcciones siguen siendo elevados, se reforzaría el argumento del coste basado en resultados.
La segunda señal es la utilización sostenida durante varias semanas. Un servidor autoalojado se vuelve más atractivo cuando la demanda útil se mantiene cerca de la capacidad durante todo el día.
The Call Center Doctors midió un pico que superaba la capacidad de una máquina. Sin embargo, el tráfico variable todavía puede dejar costosos periodos de inactividad fuera de esos picos.
Una prueba más larga debería informar de la utilización por hora, la profundidad de la cola, la latencia hasta el primer token, las interrupciones y la fracción de tiempo dedicada a cargar o recuperar.
También debería separar la entrada en caché, la entrada nueva y la salida. Estas categorías interactúan de manera distinta con el ancho de banda de memoria y el batching.
La tercera señal es DeepSeek V4.1-Pro. DeepSeek afirma que su arquitectura Flash actual se extenderá hacia modelos más grandes, pero no ha proporcionado una fecha firme de lanzamiento.
Un modelo más potente podría cambiar la economía si completa más tareas con menos reintentos. También podría requerir más memoria u ofrecer menor rendimiento.
Los compradores deberían vigilar tanto la capacidad como los requisitos de serving. Una mejora en benchmarks no garantiza un menor coste de producción.
El logro actual de DeepSeek sigue siendo significativo. Sus tarifas oficiales hacen accesible la experimentación de gran volumen, y sus pesos descargables ofrecen flexibilidad de despliegue.
La prueba no eliminó esas ventajas. Delimitó las condiciones en las que se traducen en ahorros.
Para una demanda intermitente o incierta, la API gestionada de DeepSeek parece más racional que alquilar un servidor dedicado de cuatro GPU. Conserva las bajas tarifas por token sin transferir las operaciones de infraestructura al cliente.
Para datos sensibles, demanda predecible y sostenida, u optimización especializada, el autoalojamiento aún puede merecer evaluación. El caso de negocio debe incluir personal, fiabilidad, seguridad y capacidad no utilizada.
Claude Code plantea una propuesta distinta. Agrupa acceso al modelo, una interfaz de programación e infraestructura operada por el proveedor bajo límites de suscripción.
Ese empaquetado puede superar las comparaciones basadas en tokens para un uso individual intensivo. También puede volverse restrictivo cuando las organizaciones necesitan capacidad programable o control centralizado.
Por tanto, la presión recae en los equipos de compras y los líderes de ingeniería. Deben dejar de tratar “API”, “suscripción” y “autoalojado” como unidades de compra intercambiables.
Deberían comenzar con trazas de producción en lugar de ejemplos de proveedores. La traza más útil registra la longitud del contexto, los aciertos de caché, las salidas, la latencia, los fallos y los resultados aceptados.
Después, los equipos pueden reproducir cargas de trabajo representativas en sistemas competidores. La prueba debería incluir las condiciones operativas que importan después de una demo exitosa.
Esas condiciones incluyen concurrencia, variación del tráfico, reinicios, encolado, actualizaciones de modelos, supervisión y recuperación. Las pruebas de seguridad deben realizarse antes de que los agentes obtengan acceso de escritura.
Las métricas de resultados deben ajustarse al objetivo de la organización. Para los agentes de programación, incluyen cambios integrados, defectos, reversiones, tiempo de revisión y tiempo de finalización.
Para los agentes de soporte, las métricas útiles incluyen casos resueltos, escalaciones, satisfacción del cliente e infracciones de políticas. Para los agentes de investigación, los hallazgos verificados importan más que las páginas generadas.
La prueba de DeepSeek H200 es valiosa porque avanzó hacia ese estándar. Sustituyó una comparación abstracta de tasas por una distribución de contexto real e infraestructura real.
Sus limitaciones son igualmente instructivas. La breve duración, una única organización, el trabajo de seguridad inconcluso y el acceso desigual a producción impiden un veredicto universal.
La conclusión adecuada es más acotada. Cuatro H200 alquiladas no superaron la API de DeepSeek para esta carga de trabajo de agentes, y la API no ofreció una ventaja evidente de 80 veces frente a las suscripciones.
Eso basta para cuestionar afirmaciones simplistas. No basta para descartar DeepSeek, los pesos abiertos o la inferencia autoalojada.
Antes de cambiar una pila de IA, recopile una semana de tráfico representativo y calcule el coste por resultado aceptado. Después, repita la comparación con los controles de seguridad activados.
Pregunte si el modelo completa el mismo trabajo, no si su token más barato parece impresionante. La próxima prueba de DeepSeek H200 debería responder a esa pregunta más difícil.
