Con dos agentes por usuario intensivo, una máquina 4x B200 asume la carga de Claude Code de unas 200 suscripciones por un 30 % menos

¿Puede una sola máquina hacer el trabajo de Claude Code de 200 suscripciones? Medimos 100 agentes. Los 200 salen de un modelo construido sobre esas pruebas. Un servidor con cuatro tarjetas gráficas NVIDIA B200 en la nube de inferencekey corrió DeepSeek V4.1 Flash sobre DeepInfer, el motor que DeepSeek publicó como código abierto en octubre. Le añadimos la pieza con la que el motor no viene: una caché. Cien agentes sintéticos, dimensionados como sesiones reales de Claude Code, trabajaron a la vez, cada uno con casi medio millón de tokens de conversación encima. La mitad de sus respuestas empezó en unos 2,5 segundos y no falló ni una sola petición. Un simulador calibrado con esas pruebas sitúa la máquina en unos 400 agentes a la vez. Si vuestros usuarios intensivos usan dos agentes cada uno, eso es la carga de unas 200 suscripciones, por un 30 % menos.

Las 200 suscripciones suponen 2 agentes a la vez por usuario intensivo (400 agentes, modelado). Si todos los usuarios fueran tan intensivos como nuestro usuario de referencia, el simulador da unas 80.

Un agente de código sobre todo relee, y la caché hace que releer salga casi gratis

Cada vez que Claude Code da un paso (abrir un fichero, ejecutar un test, editar una línea), le manda al modelo la conversación entera otra vez. En nuestras pruebas esa conversación rondaba los 450.000 tokens, más o menos un libro de 1.300 páginas. El modelo escribe unos cientos de tokens de respuesta y, en el paso siguiente, el agente vuelve a mandar el libro entero, más una página nueva.

En nuestro último artículo de research medimos a un desarrollador muy intensivo durante un mes y vimos lo mismo: el 96,8 % de lo que leía su agente era material que ya había leído. Imaginad una estantería al lado del modelo. Lo que ha leído una vez se queda en la estantería y, la próxima vez, lo coge ya listo en lugar de volver a leerlo.

DeepInfer viene sin esa estantería. La propia página del proyecto de DeepSeek pone la caché entre las piezas que tenéis que construir vosotros. Sin ella, nuestra máquina leía menos de medio libro por segundo, cada conversación desde cero. Con la caché de inferencekey, leía cuatro libros por segundo. La factura de los agentes de código es sobre todo una factura por releer, y quien tiene la estantería pone el precio.

Misma máquina, mismo modelo: la caché convierte unos 200 K tokens leídos por segundo en unos 1,8 M.

Claude Code solo necesita unas pocas variables de entorno, y terminó una tarea real en 39 segundos

Unas pocas variables de entorno le dicen a Claude Code adónde mandar sus peticiones, qué clave usar y qué modelo pedir. Apuntadlas a vuestro endpoint de inferencekey y hablará con DeepSeek V4.1 Flash en lugar de con Anthropic, con los mismos comandos y las mismas herramientas.

Las variables de entorno apuntan Claude Code a vuestro endpoint. La caché de inferencekey guarda cada conversación en memoria de GPU y en RAM.

La estantería tiene dos baldas. La rápida vive en la propia memoria de las tarjetas gráficas y guarda unos 57 millones de tokens, más o menos 120 conversaciones de nuestro tamaño. Detrás hay una segunda balda en la memoria normal del servidor, unas diez veces más grande, con 617 millones de tokens, para las conversaciones que se han quedado quietas un momento.

El 24 de octubre, Claude Code 2.1.310 configurado así terminó una tarea real pequeña en 39 segundos. La tarea era implementar una función llamada parse_duration para que pase un fichero de 15 tests. El agente hizo 14 llamadas a herramientas (leer ficheros, ejecutar los tests, editar el código) y pasaron los 15 tests.

Claude Code 2.1.310, sin cambios, en nuestro endpoint: una tarea real hecha en 39 s con 14 llamadas a herramientas y 15 de 15 tests en verde. Una tarea pequeña, no un benchmark.

La escena del vídeo de arriba es la aplicación real haciendo esa tarea otra vez, reproduciendo las respuestas del modelo grabadas ese día mientras las herramientas se ejecutan de verdad.

El mérito es compartido. El equipo de DeepSeek entrenó DeepSeek V4.1 Flash, escribió DeepInfer y lo publicó con licencia Apache 2.0. La herramienta aiperf de NVIDIA puso a prueba nuestro simulador. Claude Code, de Anthropic, corrió encima. Lo nuestro es la caché, el adaptador que permite a inferencekey correr DeepInfer, la API que habla el idioma de Claude Code con vuestras propias claves y las mediciones.

100 agentes con medio millón de tokens cada uno: la mitad de las respuestas empieza en 2,5 segundos, cero errores

Con 100 agentes a la vez, cada uno con unos 450.000 tokens ya en la estantería, la mitad de las respuestas empezó en 2,55 segundos y ninguna falló. Ese es el tamaño de una sesión larga de Claude Code a última hora del día. Lo corrimos el 25 de octubre y, en una ventana de un minuto, la máquina atendió 237 turnos de agente. La respuesta de cada agente salía a unos 135 tokens por segundo, una página en pocos segundos.

100 agentes con la caché caliente: 0 errores y respuestas que empiezan en unos 2,5 s. El 5 % más lento espera detrás de conversaciones nuevas de 450K y se pasa del objetivo de 15 s.

Ahora, la parte que no pasó. Nuestro listón es estricto: el 95 % de los turnos tiene que empezar a responder en 15 segundos. Solo 2 de nuestras 8 pruebas lo superaron. Las 8 tuvieron cero errores. En esta prueba, el 83 % de los turnos cuya conversación ya estaba en la estantería empezó en 15 segundos. El 5 % más lento esperó 37 segundos o más, así que la prueba no pasó. En ese minuto llegaron siete conversaciones nuevas, y cada una necesitaba leer desde cero sus 450.000 tokens. Los turnos en espera se quedaron en cola detrás de ellas, como un grupo esperando a que el anterior recoja todo su equipo. Dar prioridad a los turnos que ya están en la estantería, o limitar cuántas conversaciones nuevas empiezan a la vez, probablemente ayudaría. No lo hemos probado.

Prueba de estrés en frío: 176 millones de tokens leídos desde cero en menos de 15 minutos, cero errores

Sin nada en la estantería, la máquina leyó conversaciones desde cero a un ritmo constante de 200.000 tokens por segundo sin un solo error. El 24 de octubre le dimos 399 conversaciones nuevas de unos 440.000 tokens cada una, de 16 en 16, con la caché vacía. Eso es más duro que cualquier mañana real, en la que las sesiones empiezan pequeñas.

En 14,6 minutos, 397 de ellas estaban leídas enteras y respondiendo: 176 millones de tokens. Contando desde que entraba cada una, la primera respuesta tardaba unos 14 segundos (mediana). Contando desde el inicio de la prueba, la mitad esperó más de seis minutos y la última casi 15. Las dos últimas seguían en la cola cuando se agotó nuestro límite de 15 minutos. Si un equipo entero llegara a la vez con conversaciones gigantes, el problema sería la cola, no los errores.

Prueba de estrés sin nada en caché: 397 conversaciones de 440K tokens, 176 M de tokens leídos desde cero en menos de 15 minutos, 0 errores.

En el día a día caben unos 400 agentes, según un simulador construido sobre 7.879 turnos reales

Todo lo anterior está medido. Esta sección está modelada, y la diferencia importa.

Caben unos 250 agentes si el 95 % de las respuestas tiene que empezar en 15 segundos, y unos 400 si valen 30 segundos. Con 400, una respuesta típica tarda unos 21 segundos en empezar, y 1 de cada 20 espera unos 30 segundos o más.

Modelado: un simulador calibrado con 7.879 turnos reales admite 250 agentes si el 95 % de las respuestas empieza en 15 s, y 400 en 30 s.

Nuestras pruebas medidas eran duras a propósito: cada agente paraba solo tres segundos entre paso y paso. Las sesiones reales son más tranquilas, así que construimos un simulador de esta máquina. Lo calibramos con todos los turnos de las dos campañas de pruebas hasta que reprodujo lo que hizo la máquina real, incluido su punto de ruptura. Después lo alimentamos con 30 días de uso de Claude Code de nuestro usuario de referencia: 140.300 llamadas al modelo, con sus pausas reales.

La máquina no hace más trabajo con 400 que con 250. Responde unas 450 llamadas al modelo por minuto en ambos casos. Con más agentes, cada uno simplemente espera más y llama menos a menudo, cada 52 segundos en lugar de cada 34.

200 suscripciones si los usuarios intensivos usan dos agentes cada uno, y por debajo de unas 140 la máquina sale más cara

Los 200 del título se apoyan en una suposición: un usuario intensivo usa dos agentes a la vez, todo el día. Los 400 agentes del simulador divididos entre dos dan unas 200 suscripciones.

La pega es la velocidad. En Claude, los agentes de nuestro usuario de referencia llaman al modelo cada 27 segundos de media. Con 400 agentes en esta máquina, cada uno llama cada 52 segundos. Una tarea tardaría casi el doble.

Hay una forma más estricta de contar. Nuestro usuario de referencia es uno de nuestros usuarios más intensivos. En una hora punta media llama al modelo más o menos cada 11 segundos. A 450 llamadas por minuto, la máquina mantiene a unas 80 personas como él a toda velocidad. La máquina solo cuesta menos que las suscripciones de Claude Max 20x por encima de unas 140 suscripciones. Con la cuenta estricta de 80, cuesta 27.900 USD al mes frente a 16.000 en suscripciones, un 75 % más.

Eso sí, nuestro usuario de referencia no es típico. Además de sus propias sesiones, corre agentes autónomos para flujos de trabajo y tareas de negocio, así que un usuario normal de Claude Max carga menos la máquina. Los logs de Claude Code de vuestro equipo os pueden decir dónde estáis.

Unos 0,006 USD por millón de tokens, 80 veces menos que la API de Claude

La otra comparación es la API. El mes real de Claude Code de nuestro usuario de referencia, a los precios de lista de la API de Claude, salió por 12.365 USD por 26.200 millones de tokens, o 0,47 USD por millón. La máquina sale unas 80 veces más barata por token leído. Eso se apoya en los 1,8 millones de tokens por segundo de un minuto de mucha carga en nuestra prueba más dura, estirados sobre las 730 horas de un mes, así que tomadlo como el mejor caso.

27.900 USD al mes a 1,8 M de tokens por segundo son unos 0,006 USD por millón de tokens. Eso es unas 80 veces menos que un mes real de uso intensivo en la API de Claude.

La comparación es justa porque los dos lados son sobre todo relectura: el 96 % desde la caché en nuestra prueba, el 96,8 % en el mes real con Claude. Un equipo que duerme por la noche paga más por token útil. El 30 % y las 80 veces responden a preguntas distintas, así que no los multipliquéis.

Calidad: primero en LiveBench agentic coding, y las respuestas desde la caché coinciden con las nuevas

En un benchmark externo de código, DeepSeek V4.1 Flash queda primero. LiveBench tiene una categoría de código agéntico (agentic coding), en la que un modelo tiene que terminar una tarea real de programación paso a paso. El 10 de octubre, DeepSeek V4.1 Flash sacó 77,3 y quedó primero de 69 modelos. Claude Opus 5.5 sacó 71,7. Este benchmark no lo corrimos nosotros.

LiveBench agentic coding (livebench.ai, 10-10-2026): DeepSeek V4.1 Flash 77,3 frente a Claude Opus 5.5 71,7. Benchmark externo, no medido por nosotros.

Un índice más amplio de Artificial Analysis apunta en la otra dirección: Opus 5.5 saca 58 y Flash 39. Para un equipo que viene de Opus, esa diferencia es la advertencia honesta, así que probad Flash con vuestras propias tareas antes de cambiar.

Nuestra propia comprobación es que la estantería no cambia las respuestas. Escondimos un dato en un documento largo, de hasta 200.000 tokens, y lo preguntamos dos veces: una leyendo desde cero y otra servida desde la caché. Cinco documentos de cinco dieron la misma respuesta correcta de las dos formas. La versión desde la caché respondió en menos de un segundo. La de 200.000 tokens tardó 13 segundos leyendo desde cero.

Esa comprobación se ganó su sitio. Una versión anterior de nuestro adaptador no servía nada desde la caché, y esta comprobación lo pilló antes de que corriera ninguna prueba de carga. Lo arreglamos, y la versión arreglada servía las repeticiones entre un 95 y un 99 % desde la caché. Todas las cifras medidas de este artículo salen de ella.

Vuestro código va adonde decidáis

Con Claude, o con la API de DeepSeek, vuestro código y los datos que toca acaban en un proveedor de modelos. Con inferencekey en vuestras propias GPU, nunca sale de vuestra red. Con la nube de inferencekey, donde corrieron estas pruebas, va a nuestras GPU, no a Anthropic ni a OpenAI. En los dos casos las claves de API se quedan de vuestro lado, dentro de vuestra red. Si se filtra una, la rotáis allí. El precio y las pruebas de aquí son de la nube de inferencekey. No hemos puesto precio ni probado el caso on-premise.

200 agentes con 500K desbordan la balda rápida, así que unos 120 es el techo con ese tamaño

Con conversaciones de 500.000 tokens, la balda rápida es el techo. Con 200 agentes preguntando todos a la vez, sus conversaciones no cabían en la memoria de las tarjetas gráficas. La prueba se hundió: la mitad de las respuestas tardó más de dos minutos en empezar. No se perdió nada ni hubo errores, pero era inutilizable. A ese ritmo duro, se pueden servir a la vez unas 120 conversaciones de este tamaño.

La mayoría de las pruebas se saltó la API de inferencekey y llamó directamente al motor. La que sí la usó tuvo cero errores, pero sus respuestas más lentas tardaron 22 segundos en empezar, no 15. Fue una sola ventana corta, así que todavía no podemos decir cuánto cuesta el salto extra en conversaciones largas.

Merece la pena por encima de unas 140 suscripciones, si aceptáis respuestas más lentas en hora punta

Por encima de unas 140 suscripciones de Claude Max 20x, una máquina es una factura fija sin límite de uso por persona. El techo es compartido, unos 400 agentes, y seguís usando Claude Code. Por debajo de unas 140, las suscripciones cuestan menos. Si vuestro código no puede salir del edificio, el mismo montaje puede correr en vuestras propias GPU. Si tenéis diez desarrolladores, las suscripciones o la API de DeepSeek siguen siendo la opción más sencilla.

Probadlo vosotros

Seguid la guía de DeepInfer en 4x B200 para servir DeepSeek V4.1 Flash y apuntar Claude Code a él. Necesitáis cuatro tarjetas B200, o un workload en la nube de inferencekey, y una clave de API de inferencekey. Con los pesos en disco, nuestro workload estuvo listo en menos de dos minutos.

export ANTHROPIC_BASE_URL=https://api.inferencekey.com/endpoint/<project>/<workload>
export ANTHROPIC_AUTH_TOKEN=ik_live_...
export ANTHROPIC_MODEL=deepseek-v4.1-flash
export ANTHROPIC_DEFAULT_HAIKU_MODEL=deepseek-v4.1-flash
export ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-v4.1-flash
export ANTHROPIC_DEFAULT_OPUS_MODEL=deepseek-v4.1-flash
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
claude