¿Comprar tokens, alquilar GPUs o tener el rack en propiedad?

Hasta hace poco, alojar tú mismo un modelo de frontera no era una pregunta seria. Los modelos de pesos abiertos iban una generación por detrás de los propietarios, así que no había nada que calcular.

Luego la brecha se cerró. No del todo, pero hasta unos treinta puntos Elo. Kimi K3 salió con pesos abiertos y está segundo en la arena de código frontend con 1682, detrás de Claude Opus 5 Max con 1712 y por delante de todo lo demás¹. Sus pesos caben, sobre el papel, en un solo nodo de ocho GPUs. Puedes descargarte el modelo esta noche sin pagar nada.

La caja ya es otra historia. Suponiendo que puedas asumir la inversión. Y suponiendo que, cuando hagas las cuentas, resulte que merece la pena.

Así que modelé cuatro formas de ejecutar la misma carga: un rack en tu oficina, hardware propio en un centro de colocation, GPUs dedicadas alquiladas y APIs de pago por token. A esta última la llamaré el contador de aquí en adelante.

La respuesta no es “compra el rack”. Por debajo de unos 44 ingenieros, el contador sigue siendo lo más barato. Entre 44 y 95 más o menos, ganan las GPUs alquiladas. Por encima, tener hardware empieza a compensar, y con 750 ingenieros le gana al contador por algo así de seis a uno.

El número que lo decide es la utilización. Un rack comprado a tres años cuesta lo mismo a las tres de la madrugada, sirva tokens o caliente el edificio.

K3 es solo el ejemplo con el que trabajo. El mismo método vale para lo que salga después.

Cuatro formas de comprar inferencia

Opción	Tienes en propiedad	Alquilas	Pagas por
Rack en la oficina	GPUs, infraestructura eléctrica, refrigeración	nada	Capex, electricidad, un electricista, espacio, personal
Rack en colocation (tu hardware, el edificio de otro)	GPUs	Espacio, energía, refrigeración	Capex, alquiler del rack por kW2, personal
GPUs dedicadas / alquiladas	nada	GPUs enteras por horas	Horas reservadas, personal
El contador (API por token)	nada	nada	Tokens

Según bajas por esa tabla, tu compromiso fijo se reduce y tu flexibilidad crece. Lo que cedes es control y, a escala suficiente, economía unitaria. Encontrar dónde se invierte ese intercambio es todo el ejercicio.

Antes de la hoja de cálculo, sin embargo, una pregunta más básica: ¿puedes meter una de estas máquinas en una oficina?

¿Se puede?

En la segunda temporada de Silicon Valley, los servidores de Gilfoyle se incendian. El equipo le echa demasiada carga a Anton, se pasa de amperios, salta el diferencial general y arde todo. Todo el mundo lo recuerda como un chiste sobre la soberbia. Aquí lo vamos a tratar como un comentario sobre ingeniería eléctrica.

Perdona si no has visto Silicon Valley. Es un clásico moderno, adelantado a su tiempo.

K3 tiene 2,8 billones de parámetros, 104 mil millones activos por token, 896 expertos, y viene cuantizado a MXFP4 directamente desde el entrenamiento³. Son 1390 GB de pesos sobre el papel. Un nodo B200 de ocho GPUs te da 1440 GB, así que sobre el papel cabe con 50 GB de sobra. Los informes sobre el checkpoint real lo sitúan más cerca de 1,56 TB una vez que cuentas todo lo que no es un peso cuantizado, y en ese caso no cabe en absoluto. Este es el sueño húmedo de r/selfhosted: el segundo mejor modelo de código del planeta, zumbando en un armario, tuyo.

Entonces lees la hoja de especificaciones.

Especificaciones, un DGX B200	Valor	Qué significa en una oficina
Consumo	14,3 kW4	Dos placas de inducción, todos los fuegos, para siempre
Circuito en anillo del Reino Unido	7,4 kW	Un servidor quiere dos circuitos enteros para él solo
Calor emitido	~48.800 BTU/h	Tres o cuatro aires acondicionados domésticos, a tope
Caudal de aire	2145 CFM4	No es un armario. Es una sala de máquinas
Peso	130 kg4	Sin contar el rack, las PDU y la refrigeración
Dos nodos por rack	2x 380V trifásico 32A4	Vas a llamar a un electricista, no a comprar una regleta

Una inconsistencia que reconozco: las cifras de consumo, peso y caudal de aire son de NVIDIA para el DGX B200, su aparato integrado, mientras que los $450.000 que modelo son un precio de calle para un HGX B200 de 8 GPUs, la placa alrededor de la cual un OEM construye un servidor. Un DGX cuesta de lista cerca de $515.000. Uso el precio más barato con el consumo de la máquina más cara, lo que favorece al autoalojamiento en capex y lo penaliza en electricidad.

Anton no hizo saltar ese diferencial porque un guionista quisiera fuego en el tercer acto. Saltó porque eso es lo que pasa cuando cuelgas una carga industrial de un cableado doméstico.

Un nodo, por cierto, es el caso generoso, y lo es también de una segunda manera. Esos 50 GB de margen no dejan nada para la caché KV, la memoria de trabajo que necesita un modelo para sostener una conversación larga, así que un despliegue real en producción necesita más aceleradores que esto. Moonshot recomienda 64 o más⁵. Son ocho de estas cajas, 114 kilovatios, en tu oficina. Más que una sala de servidores, un microrreactor nuclear esperando a que alguien anuncie una Serie A a su alrededor.

He modelado el nodo único de todos modos, porque es lo más barato que podría contener los pesos de forma plausible. Ojo con esto: no es el peor caso. El personal y la obra eléctrica son casi fijos, así que más nodos los reparten y la economía mejora. Un resultado con un nodo es la prueba más dura a la que se enfrenta el autoalojamiento, no la más fácil.

Y luego está el suministro. La asignación de Blackwell va primero a los compradores más grandes, así que conseguir una significa hacer cola detrás de Musk.

Necesitas un Gilfoyle

Gilfoyle es el de sistemas. Es el dueño de los racks, no se fía de nadie y es el único del edificio que sabe por qué arde el clúster.

Lo que nos lleva a mi ficción favorita de cualquier plan de negocio de autoalojamiento: una fracción de ingeniero.

No puedes contratar a 0,3 personas. El puesto consiste en ejecutar vLLM o SGLang en producción, saber qué es el paralelismo de expertos, depurar NCCL a las dos de la madrugada y mantener varios cientos de gigabytes de mixture-of-experts calientes y sirviendo. Robert Half sitúa la mediana de un ingeniero de machine learning en Londres en £102.000 y el cuartil superior cerca de £119.000⁶. He modelado £120.000, a propósito una contratación de cuartil superior, porque la mediana no puede hacer este trabajo.

También tendrá opiniones. Sobre tu gasto en la nube, sobre el teclado que exige, sobre el capital que se le debe a la única persona del edificio que entiende lo que ahora depende de todos. Ese es el coste real de gestionarlo tú mismo, y no aparece en ninguna hoja de especificaciones de GPU.

Necesitas a dos, porque uno solo es un punto único de fallo con pasaporte y opiniones muy firmes sobre las vacaciones.

Línea	Valor (GBP)
Salario base (cuartil superior)	£120.000
Multiplicador de costes (seguridad social de la empresa, pensión, equipo)	1,3
Coste total por persona	£156.000
Personas necesarias	2
Total anual	£312.000 (unos $396.000)

Esa cifra no se deprecia. No se abarata, y le da igual que tu hardware esté ocupado.

La carga decide más que el hardware

La mayoría de las cuentas de autoalojamiento que he visto se calculan contra el chat, que es el peor caso posible para tener hardware y no se parece en nada a lo que hace un equipo de desarrollo todo el día.

El código agéntico consume 4,17 millones de tokens por tarea, con una proporción entrada-salida de más o menos 153:1⁷. Nada de lo que sigue importa más que esa proporción, salvo la utilización.

En tu propio hardware ayuda. El prefill, la lectura de tu prompt, y el decode, la escritura de la respuesta, son trabajos distintos con costes distintos. vLLM mide 26.200 tokens por GPU y segundo en prefill frente a 10.100 en decode⁸, así que el prefill es dos veces y media más eficiente. El código agéntico es casi todo prefill. El trabajo de tu equipo resulta ser justo aquello en lo que mejor rinden las GPUs.

En el contador también ayuda, porque los tokens de entrada son cinco veces más baratos que los de salida.

Componente	Cálculo	$/1 M de tokens
Entrada sin caché	0,30 × 0,9935 × $5	1,49
Entrada en caché (lecturas a 0,1×)	0,70 × 0,9935 × $5 × 0,1	0,35
Salida	0,0065 × $25	0,16
Mezcla, 70% de aciertos de caché		$2,00
Mezcla, sin caché	0,9935 × $5 + 0,0065 × $25	$5,13

Ese 70% es una suposición, no una medición, y es el segundo número más importante de este post. Reduce el contador a menos de la mitad, de $5,13 a $2,00. Si bajas la tasa de aciertos al 35%, el contador sale a $3,57, lo que desplaza todos los puntos de cruce de más abajo con fuerza hacia el autoalojamiento. Si vas hacia el otro lado, el contador gana casi en todas partes.

Dos cosas más sobre esos $2,00 antes de fiarte. Anthropic cobra más o menos 1,25x la entrada por escribir una entrada de caché, y yo he valorado cada token sin caché como una lectura normal. Si todo ese 30% sin caché fueran escrituras, el contador saldría a $2,37 en lugar de $2,00. La verdad está en algún punto intermedio.

Alguien preguntará por qué comparo K3 autoalojado con Opus 5 y no con la API del propio K3, que es más barata, a $3 y $15 por millón con aciertos de caché a $0,30⁹, unos $1,20 con esta mezcla de tokens. Porque para la mayoría de las empresas a las que apunta este post, mandar tráfico de producción a una nube china no es una opción real, diga lo que diga la lista de precios. No es un juicio técnico, es de compras, y se toma por encima de tu cabeza. La elección realista es ejecutar K3 tú mismo o comprarle Opus 5 a Anthropic, que es lo que comparan las tablas.

Es también, dicho sea de paso, el mismo instinto que lleva a la gente a autoalojar. Si te diera igual dónde corren los pesos, usarías la API y dejarías de leer.

Así que antes de usar nada de esto, ve a mirar tu tasa real de aciertos de caché. Importa más que el precio de una GPU.

Qué sirve realmente una caja

Para comparar cuatro opciones necesito dos números: cuánto trabajo procesa un nodo y cuánto genera un ingeniero. Ninguno es exacto, así que aquí va cada suposición, incluidas las que arruinan la fantasía.

Paso	Cálculo	Resultado
Parte de entrada en los tokens	153 ÷ 154	0,9935
Rendimiento mixto por GPU	media armónica de 26.200 de prefill y 10.100 de decode con esa mezcla	25.932 tok/s
Reducción por K3 frente a un modelo tipo DeepSeek	104B parámetros activos frente a ~37B	× 0,35
Reducción por B200 frente a GB200	el benchmark se ejecutó en GB200	× 0,70
Reducción por tráfico real frente a benchmark	los benchmarks son ordenados, producción no	× 0,60
Rendimiento reducido por GPU	25.932 × 0,147	3812 tok/s
Por nodo	× 8 GPUs	30.496 tok/s
Capacidad anual al 100% de uso	× 31.536.000 segundos	962.000 M de tokens

Frente a eso, la demanda:

Paso	Cálculo	Resultado
Tareas por ingeniero y día	suposición de carga, no medida	6
Tokens por tarea	Bai et al.7	4,17 M
Días laborables al año	260 menos vacaciones y festivos	230
Tokens por ingeniero y año	6 × 4,17 M × 230	5755 M

A pleno rendimiento, un nodo sirve a unos 167 ingenieros. Con un ciclo de uso anual del 21%, más o menos un uso en horario de oficina, aguanta a unos 35.

La cifra exacta de capacidad es discutible y volveré a cuánto podría equivocarme. Una vez comprado el hardware, la utilización aplasta cualquier otra variable.

La utilización decide

El hardware en propiedad cuesta lo mismo dormido que a tope. La depreciación corre, el alquiler del rack corre y tus dos Gilfoyles cobran igual. La electricidad es la única línea que sigue a la demanda, y resulta ser calderilla.

Utilización	Rack oficina $/1 M	Colo $/1 M	Contador $/1 M
5%	12,23	12,81	2,00
10%	6,14	6,40	2,00
21% (solo horario de oficina)	2,95	3,05	2,00
35%	1,79	1,83	2,00
50%	1,27	1,28	2,00
80%	0,81	0,80	2,00
100%	0,66	0,64	2,00

La línea de la oficina cruza el contador al 31,2% de utilización, la de colo al 32,0%.

Una advertencia que corresponde aquí y no al final: esa es una curva de un nodo. Dos ingenieros de plataforma y la factura del electricista no escalan con el número de nodos, así que con dos nodos el cruce baja a cerca del 21% y con cinco a cerca del 14%. Cuanto más grande eres, menos utilización necesitas para justificar tener el hardware.

Ahora compara con un equipo real. Ocho horas al día, 230 días al año, son 1840 horas de las 8760 posibles. Un ciclo de uso del 21%. Un equipo que trabaja en horario de oficina y luego se va a casa queda por debajo del punto de equilibrio, y el autoalojamiento pierde.

Así que la pregunta nunca fue si los modelos de pesos abiertos son lo bastante buenos, ni si las GPUs son lo bastante baratas. Las dos cosas están resueltas. La pregunta es si puedes llenar el turno de noche con trabajos por lotes, evals, reindexados y el CI que nadie mira. Con la caja al 35% estás ganando. Al 50% ganas con holgura. Si la dejas ociosa cada tarde, has comprado una estufa carísima con contrato de tres años.

Los análisis independientes de la capacidad aprovisionada de Azure sitúan el punto de equilibrio frente al pago por uso en torno al 80% de utilización sostenida¹⁰. Ni AWS ni Microsoft publican una cifra de equilibrio propia, así que tómalo como aritmética de terceros y no como una guía del proveedor. Está muy lejos de mi 31%, y no voy a fingir lo contrario. Miden cosas distintas: lo suyo es un producto con margen comparado con su propia lista de precios, lo mío es coste bruto comparado con la lista de un rival. Lo que comparten es la dirección: la capacidad reservada tiene que estar ocupada casi todo el tiempo antes de compensar.

Las GPUs alquiladas ganan en el medio

La utilización fija el precio unitario. El tamaño del equipo decide qué opción gana, porque es lo que reparte los costes fijos.

Con 25 ingenieros, un nodo está al 15% de uso y el contador gana de calle. Dos ingenieros de plataforma cuestan $396.240 al año. La factura entera de tokens que sustituirían es de $287.777. El personal cuesta más que el problema. Nada más de la hoja de cálculo merece la pena.

Con 60 ingenieros, un nodo trabaja al 36% de uso y la capacidad alquilada pasa por delante.

Línea anual (USD)	Oficina	Colo	Alquilada	Contador
Depreciación del hardware11	150.000	150.000	0	0
Infraestructura de energía	25.400	0	0	0
Electricidad	31.821	0	0	0
Alquiler del rack	0	69.564	0	0
Alquiler de GPU	0	0	138.382	0
Ingenieros de plataforma	396.240	396.240	396.240	0
Cargos por tokens	0	0	0	690.664
Total	603.461	615.804	534.622	690.664
Por ingeniero	10.058	10.264	8910	11.511
Por 1 M de tokens	1,75	1,78	1,55	2,00

Fíjate en lo que falta en esa tabla: un descuento de personal por alquilar. Cada opción autoalojada lleva dos ingenieros de plataforma completos, porque no puedes avisar a media persona a las dos de la madrugada, sea de quien sea el metal. Alquilar te ahorra el capex, al electricista y la cola detrás de Musk. No te ahorra la nómina.

Por eso la victoria es estrecha. Del más barato al más caro entre las cuatro opciones hay un 29%, cómodamente dentro del margen de error de mis propias suposiciones.

Fui a buscar a alguien que hubiera costeado esta opción frente a las otras tres y no encontré a nadie, lo que me desconcierta, porque alquilar GPUs no tiene nada de oscuro. Lambda, CoreWeave, Spheron y una docena más publican tarifas por hora de B200, y un agregador sigue a más de 26¹². El punto medio está a la venta, y para un equipo de 60 ingenieros les gana a los dos extremos.

Con 750 ingenieros, cinco nodos trabajan al 90% de uso y alquilar pierde por goleada, porque factura por horas y a esa utilización las pagas casi todas. Tener el hardware cuesta $1.494.059 en un colo o $1.565.997 en tu propia oficina, frente a $2.126.018 alquilado y $8.633.301 en el contador. Es el único sitio de todo el modelo donde tener el hardware es claramente lo correcto, y le gana al contador por algo así de seis a uno.

Fíjate, eso sí, en lo cerca que quedan las columnas de la oficina y del colo. Por encima de unos 95 ingenieros quedan a pocos puntos una de otra y se intercambian según el número de nodos. Dado que mi opción de oficina no paga alquiler, la lectura honesta es que son la misma respuesta, y la elección entre ellas va de a quién quieres para cambiar los filtros.

Tamaño del equipo	Opción más barata	Coste anual por ingeniero	Motivo principal
25	El contador	$11.511	El personal de plataforma cuesta más que toda la factura de tokens
60	GPUs alquiladas	$8910	Uso suficiente para querer capacidad, no suficiente para justificar el capex
750	Hardware en propiedad (colo)	$1992	La demanda casi continua encarece las horas de alquiler

Los tokens no son dinero

En la planificación tecnológica hay una suposición persistente, y lo digo como alguien que es claramente parte del problema: que los tokens son el nuevo barril de petróleo. La unidad universal de intercambio. Hay empresas enteras que ya hacen ciclos de planificación denominados en ellos.

Con toda la carga y a plena utilización, el nodo en propiedad de este modelo cuesta unos $0,66 por millón de tokens frente a $2,00 en el contador con caché. Solo la electricidad son 6,6 céntimos de eso, que es una décima parte del total y, qué fastidio, un factor de diez respecto al número de arriba. Los dos son correctos.

Línea	Cálculo	Valor
Potencia del nodo	14,3 kW × 8760 horas	125.268 kWh/año
A tarifas empresariales del Reino Unido13	× £0,25	£31.317
Con sobrecoste de refrigeración de oficina (PUE 1,6)	× 1,6	£50.107
En dólares	× 1,27	$63.636
Tokens producidos a pleno uso		962.000 M
Electricidad por 1 M de tokens		6,6 céntimos

Lo importante no es que alguien deba cobrar siete céntimos. El precio de un token incluye hardware, personal, riesgo, investigación y margen, y debe incluirlos. Lo importante es que un token es una abstracción de facturación al por menor sobre segundos de GPU, con un tipo de cambio fijado por quien lo vende. Si de verdad los tokens son el nuevo petróleo, los hiperescaladores son la OPEP, con la útil ventaja de que pueden revisar la física cada vez que los márgenes necesitan ayuda.

Y aquí es donde va esto a continuación, y es menos una predicción que un patrón que ya ha ocurrido una vez. El cómputo de IA se financiariza igual que el de la Web 2.0. EC2 salió con precio por hora de instancia y en pocos años el mercado real eran las instancias reservadas, los savings plans, el spot y los descuentos por uso sostenido. Los grandes compradores dejaron de pagar la tarifa bajo demanda hace años.

Ya está empezando. Bedrock vende rendimiento aprovisionado por hora de unidad de modelo, de $4,11 a $49,50 según el modelo, y la tarifa baja cuanto más tiempo te comprometes¹⁰. Azure vende lo mismo con la forma de unidades de rendimiento aprovisionado. Eso no son precios por token, son reservas de capacidad con una curva de compromiso.

La pista está en lo que falta en esa página. Ningún modelo Claude actual tiene una tarifa publicada de rendimiento aprovisionado. El mercado reservado para modelos de frontera existe, pero se cotiza en vez de listarse, lo que te dice lo pronto que es todavía.

Sigue la línea hacia delante y dejas de comprar tokens. Reservas capacidad para tu base, te llevas el descuento por uso sostenido y desbordas al contador cuando hay picos. Los tokens pasan a ser el humo de una tubería que ya has pagado, y la cosa en la que presupuestas pasa a ser la hora de GPU, que al menos tiene detrás una curva de oferta real.

¿Deberíamos?

Parte de esto puede sonar a argumento para salir a comprar metal. No lo es, exactamente.

Estarías comprando un activo que se deprecia mientras el precio del contador baja. Opus 5 salió exactamente al precio de Opus 4.8, $5 y $25 por millón de tokens, y es un modelo claramente mejor¹⁴. La lista de precios no se movió mientras mejoraba lo que había detrás. Así que tu capex es una apuesta a tres años de que la inteligencia de frontera se abarata más despacio de lo que se desgasta tu hardware, y la frontera se ha movido en una escala de meses. El hardware que especifiques hoy se queda con la economía de hoy hasta 2029.

Las dos cosas son ciertas a la vez, entonces. Los tokens llevan un margen gordo, y comprar máquinas es una mala forma de escapar de él para la mayoría. La salida es que no hace falta comprar un rack para dejar de pagar precio de venta al público. Reserva la capacidad, no compres el edificio.

Dos cosas sobreviven a la aritmética, aunque solo una de forma limpia.

Soberanía. Si tus datos no pueden salir del edificio, no estás comparando contra $2,00, estás comparando contra nada, porque el contador no se te vende a ningún precio. Haz las cuentas de utilización igualmente, pero ya lo tienes decidido.

Latencia, pero menos de lo que esperas. Un modelo en el mismo rack te ahorra un viaje de ida y vuelta por la red. Son unos cuarenta milisegundos frente a los treinta y pico segundos que la cosa pasa pensando, así que para trabajo agéntico es ruido. Sí compensa en lo ajustado, autocompletado y sugerencias en línea, donde persigues un presupuesto de menos de 100 ms y la red es una parte real. Si esa no es tu carga, no lo metas en el caso de negocio.

Así que esto es lo que haría yo: dejar de elegir una de las cuatro. Reservar capacidad suficiente para cubrir tu base y medir el resto. El trabajo previsible y de alto volumen corre por la noche en la tubería que ya has pagado, con una utilización a la que gana dos a uno o mejor. El razonamiento difícil va al modelo de frontera en el contador, donde pagas por algo que no puedes reproducir ni depreciar.

En la práctica, la colocación y no la elección de modelo es la palanca económica principal. Ese fue el argumento que hice sobre enrutar entre modelos, una capa más abajo en la pila.

Dónde podría equivocarse este modelo

Cuatro cosas.

Mi reducción de rendimiento probablemente es demasiado dura, y corregirla favorece el alquiler. Rebajé el benchmark de vLLM en un factor de siete para cubrir que K3 es más grande, que el hardware es de refrigeración por aire y que el tráfico real es más desordenado que un benchmark. Son cuentas en una servilleta, y una comprobación aproximada con los FLOPs en bruto dice que la cifra real podría ser tres o cuatro veces mayor. Si lo recalculas con ese número, 200 ingenieros pasan de tener el hardware a alquilar, porque un hardware más rápido recorta de inmediato las horas de GPU alquiladas y no hace nada por el capex que ya has comprometido. Juega en contra de un rack, no a favor.

Las tareas por ingeniero y día son una conjetura. Usé seis. Determina la demanda absoluta y por tanto los resultados por tamaño de equipo. No toca la tabla de utilización, por eso esa es la afirmación más sólida y por eso la puse primero.

La configuración de nodo único es optimista, como señalé antes. Moonshot quiere 64 aceleradores para producción y yo modelé ocho, que es la lectura más generosa que podría pedir el autoalojamiento.

La opción de oficina recibe su edificio gratis. Paga el hardware, la instalación eléctrica y de refrigeración, y la electricidad. No paga alquiler, tasas comerciales, seguro, extinción de incendios, SAI, PDU, obra estructural para 130 kg por nodo ni una ampliación de suministro con el DNO, y por encima de unos dos nodos un edificio comercial del Reino Unido necesitará esa ampliación y no un electricista. El colo lo paga todo dentro de los £285/kW/mes. Esa diferencia es parte de por qué la oficina gana al colo en todas mis tablas, y deberías tratar las dos como más parecidas de lo que parecen. Cobrarle a la opción de oficina la mitad de la tarifa total del colo la deja aún por delante en todos los tamaños de equipo, que es la única razón por la que no he intentado inventarme una cifra.

Cada número tiene una fuente y un nivel de confianza en el libro de cálculo que hay detrás. Los de baja confianza son los tres que acabas de leer.

Así que la aritmética puede fallar en los bordes. La física no. Catorce kilovatios son catorce kilovatios aguante o no mi estimación de rendimiento, el calor tiene que ir a algún sitio y al electricista hay que seguir pagándole.

Podría comprar tokens y no volver a pensar en nada de esto. O podría pensar en todo, y acabar con un golpe de calor cableando otra tarjeta gráfica.

Footnotes

1. Arena WebDev leaderboard, 28 de julio de 2026, 492.170 votos. claude-opus-5-max 1712, kimi-k3-max 1682, claude-opus-5-high 1669, claude-fable-5 1628, gpt-5.6-sol-xhigh 1623, claude-opus-4-8-thinking 1568. Conviene tenerlo presente: la posición de K3 en código lo favorece. En el leaderboard principal de texto (27 de julio de 2026) kimi-k3-max es undécimo con 1486 ±10, detrás de claude-fable-5 (1508) y claude-opus-5-max (1495), y en empate estadístico con claude-opus-4-8-thinking (1484 ±5). Es un especialista en código, no el mejor modelo del mundo. ↩

2. Modelo el colo a £285 por kW al mes. Ese número me lo he sacado de la manga, porque no encontré una fuente lo bastante buena como para respaldarlo. Para lo que valga: el colocation mayorista del Reino Unido va de £150 a 300 por kW al mes a partir de 1 MW, en Londres al por menor se cotiza de £300 a 800 por armario y sube de £2.000 para densidad, y los racks de GPU de alta densidad llevan un sobrecoste al que nadie quiere poner cifra. Mi despliegue es de 14 a 72 kW, demasiado pequeño para precios mayoristas. Si sabes cuánto cuesta de verdad un rack de GPU de 30 kW en Londres, dímelo y lo corregiré. Trato la tarifa como todo incluido, con espacio, refrigeración, resiliencia y energía, porque cobrar electricidad medida encima duplicaría la línea más grande de una factura de colo. ↩

3. Moonshot AI, Kimi-K3 model card. Hugging Face. 2,8T de parámetros totales, 104B activos (16 de 896 expertos), pesos MXFP4 con activaciones MXFP8, contexto de 1.048.576 tokens. ↩

4. NVIDIA, Data Center Best Practices with DGX B200. Hoja de especificaciones. Potencia estimada del sistema 14,3 kW máx., peso >130 kg y 150 CFM por kilovatio, lo que da 2145 CFM por nodo (el documento cita 4290 CFM para un rack de dos nodos). Dos nodos por rack requieren 2 alimentaciones trifásicas de 380V y 32A. La cifra de calor es mi propia conversión, no de NVIDIA: 14,3 kW x 3412 = ~48.800 BTU/h. ↩ ↩² ↩³ ↩⁴

5. Moonshot AI, Kimi K3 launch post: “we recommend deploying Kimi K3 on supernode configurations with 64 or more accelerators”. Es una recomendación, no un mínimo. Moonshot no publica un número mínimo de GPUs. ↩

6. Robert Half, 2026 Salary Guide, machine learning engineer, London. Percentil 50 £102.000, percentil 75 aproximadamente £119.000. ↩

7. Bai et al. (2026), How Do AI Agents Spend Your Money? Paper, Figura 1. El código agéntico promedia 4,17 M de tokens por tarea con una proporción entrada-salida de 153,85:1, frente a 1,33 del chat de código y 0,16 del razonamiento de código. El paper también da $1,86 por tarea, pero es un promedio de ocho modelos, la mayoría mucho más baratos que Opus 5, y sale a unos $0,45 por 1 M de tokens. Yo tomo el volumen de tokens y la proporción del paper y pongo yo el precio: la misma tarea en Opus 5 con un 70% de aciertos de caché cuesta unos $8,34. No leas las dos cifras de coste como comparables. ↩ ↩²

8. vLLM, Driving vLLM WideEP and Large-Scale Serving Toward Maturity on Blackwell (Part I), 3 de febrero de 2026. Enlace. 26,2K tokens de prefill y 10,1K de decode por GPU y segundo en GB200 para un MoE al estilo DeepSeek con 2K de entrada / 2K de salida. Dos cosas que conviene llevar junto al número: sale de una topología desagregada de 16 GPUs (cuatro instancias de prefill de dos GB200 cada una, una instancia de decode de ocho), y el rendimiento se estanca en torno a un tamaño de lote de 64K. Escalarlo linealmente a una sola caja de ocho GPUs refrigerada por aire es exactamente el error que mis reducciones existen para cubrir. ↩

9. Kimi K3 en la API de Moonshot cuesta $3 por millón de tokens de entrada y $15 por millón de salida, con aciertos de caché a $0,30, igual en todo el contexto de 1 M. Las tarifas circulan ampliamente, pero no he podido confirmarlas en la página de precios de Moonshot, así que tómalas como indicativas. Con la mezcla de tokens de este post salen a $1,20 por millón frente a $2,00 de Opus 5. ↩

10. AWS, Bedrock pricing. Las tarifas publicadas de rendimiento aprovisionado van de $4,11 a $49,50 por hora de unidad de modelo y cubren solo modelos antiguos (Llama 2 $21,18 por un mes, Cohere Command $49,50 por un mes frente a $23,77 por seis, Command Light de $8,56 a $4,11). Ningún modelo Claude actual tiene tarifa aprovisionada publicada. El equivalente de Azure es la unidad de rendimiento aprovisionado, cuya mecánica está documentada en Microsoft Learn, aunque la página no trae cifras en dólares. El equilibrio de ~80% es análisis de terceros, no una guía del proveedor, y ninguna de las plataformas publica un número así. ↩ ↩²

11. El precio de calle de un HGX B200 de 8 GPUs ronda los $400.000 a $500.000 y he modelado $450.000 con vida útil lineal de tres años y sin valor residual. Tómalo como suposición mía y no como cita: las únicas fuentes públicas son páginas de marketing de contenidos de proveedores, sin autor nombrado ni referencias primarias, y una de ellas admite que no existe un mercado secundario funcional con el que contrastar. Si tienes un presupuesto real, el tuyo gana al mío. ↩

12. Las tarifas publicadas por hora de B200 varían enormemente según proveedor y compromiso, más o menos de $2,14 a $27,04 por hora de GPU. Lambda lista $4,99 y Spheron $3,70 bajo demanda frente a $2,74 en spot, mientras que AWS p6 va a $14,24. getdeploying agrega más de 26 proveedores. He modelado $5,50, que cae entre los precios de neocloud y de hiperescalador y no coincide con ninguno, así que tómalo como una suposición de punto medio y no como un presupuesto. ↩

13. DESNZ, Quarterly Energy Prices, junio de 2026, tablas 3.4.1 a 3.4.2. Precio medio ponderado por volumen de electricidad no doméstica de 24,14p/kWh en el T1 de 2026, provisional, con Climate Change Levy y sin IVA. Lo he redondeado a 25p, lo que hace que las opciones autoalojadas parezcan algo peor y no mejor. PUE es la eficiencia en el uso de la energía, la proporción entre la potencia total de la instalación y la que llega realmente al equipo. ↩

14. Anthropic, Models overview. Opus 5 y Opus 4.8 se listan ambos a $5 por millón de tokens de entrada y $25 por millón de tokens de salida. ↩