Bajo los supuestos ilustrativos utilizados aquí, una Antminer KS5 Pro funcionando a 21 TH/s y 3,150 W generaría aproximadamente $4.17 por día después de una comisión de pool del 2%, dejando aproximadamente $0.39 después de la electricidad a $0.05/kWh. Ese saldo no es beneficio neto: excluye el precio de compra, la depreciación, el alojamiento, el mantenimiento, la refrigeración externa y otros costos. Es el resultado de un escenario, no una cotización de ganancias actuales ni un pronóstico.

Una estimación útil de rentabilidad de la Antminer KS5 Pro depende de entradas que varían de forma independiente: las reducciones del subsidio de Kaspa, el hashrate de la red, el precio de KAS, el consumo eléctrico medido y el tiempo de inactividad. El modelo a continuación muestra cómo reemplazar esas entradas y distinguir el tiempo de inactividad por apagado de las fallas que interrumpen la minería mientras la unidad sigue consumiendo energía.

Confirmar el modelo exacto del dispositivo

Antes de realizar cualquier cálculo, se debe confirmar el modelo exacto del hardware y la versión del firmware, ya que Bitmain comercializa varias unidades de la serie Antminer KS con diferentes especificaciones. Según la hoja de especificaciones publicada por Bitmain, la KS5 Pro está clasificada con un hashrate de 21 TH/s, un consumo eléctrico de 3,150 W medido en la toma de corriente a 25°C de temperatura ambiente, y una eficiencia energética resultante de 150 J/TH (Bitmain, Especificaciones de la KS5 Pro). Estos son valores típicos del fabricante bajo una condición de prueba declarada, no resultados garantizados para cada implementación.

La misma hoja de especificaciones indica una tolerancia de ±3% en el hashrate y de ±5% tanto en la potencia en la toma de corriente como en la eficiencia energética. Esto significa que una unidad podría razonablemente medir entre aproximadamente 20.4 y 21.6 TH/s, y entre aproximadamente 2,993 W y 3,308 W, mientras sigue cumpliendo con la especificación publicada. Para una prueba de rentabilidad, debe usarse la lectura del propio medidor o PDU del operador en lugar de la cifra nominal siempre que sea posible, ya que el valor nominal solo representa un resultado típico bajo las condiciones de prueba del fabricante. A los 3,150 W nominales, el funcionamiento continuo consume 3.15 kW × 24 horas = 75.6 kWh por día; esta cifra se recalcula proporcionalmente si la potencia medida en la toma de corriente difiere de la clasificación nominal.

El consumo eléctrico de la Antminer KS5 Pro también debe entenderse como una cifra de potencia en la toma de corriente, no como una estimación a nivel de chip. No incluye la infraestructura de refrigeración, las pérdidas del PDU u otras cargas de la instalación, las cuales un modelo de costos de alojamiento o colocación necesitaría agregar por separado.

Recopilar las entradas actuales de la red

Las condiciones de la red de Kaspa cambian continuamente, por lo que una estimación de ingresos necesita el hashrate de la red, el subsidio por bloque, la tasa de producción de bloques y el precio KAS/USD. Este ejemplo de trabajo asume un hashrate de red de 339.50 PH/s y un subsidio de 2.06017223 KAS por bloque. Estas son entradas de modelo ilustrativas, no una instantánea verificada de la red. El objetivo de Kaspa de 10 bloques por segundo da aproximadamente 864,000 bloques por día para este cálculo teórico (Kaspa, KIP-14).

Para el precio, el ejemplo utiliza el cierre diario de KAS/USD de $0.03861142 para el 13 de octubre de 2026, UTC, según figura en la página de datos históricos de CoinGecko, consultada el 14 de octubre de 2026. Combinar ese precio histórico con entradas de red asumidas crea un escenario ilustrativo, no una reconstrucción de las ganancias reales en esa fecha.

Para una estimación operativa, reemplace los valores asumidos con datos de red obtenidos de fuentes verificadas y registre la hora de recopilación y la zona horaria, la ventana de estimación del hashrate de la red, el subsidio aplicable y la marca de tiempo del precio. Al conciliar un día completado, use entradas representativas de ese mismo período en lugar de una sola lectura actual.

Calcular la estimación basada únicamente en el subsidio

Use las mismas unidades para el hashrate del minero y el de la red: 339.50 PH/s = 339,500 TH/s.

KAS/día teórico con disponibilidad total = (hashrate del minero ÷ hashrate de la red) × bloques por segundo × 86,400 × subsidio por bloque

Con las entradas asumidas:

(21 ÷ 339,500) × 10 × 86,400 × 2.06017223 ≈ 110.10 KAS/día

Ingresos estimados (USD/día) = KAS/día teórico × fracción de tiempo productivo × (1 − comisión de pool aplicable) × precio KAS/USD

La fracción de tiempo productivo es el número de horas de minería productiva dividido entre 24. Con disponibilidad total y una comisión de pool ilustrativa del 2%:

110.1024 × 1 × 0.98 × $0.03861142 ≈ $4.17/día

Esto estima únicamente los ingresos derivados del subsidio; se excluyen los ingresos por comisiones de transacción. Asume un hashrate constante mientras se mina productivamente y entradas de red constantes a lo largo del día modelado. Los créditos reales también dependen del trabajo aceptado y de las reglas de pago del pool. Si el hashrate medido ya incluye el tiempo de inactividad o el trabajo rechazado, no se deben deducir esas pérdidas nuevamente mediante un factor de disponibilidad adicional.

La comisión del 2% corresponde a la tarifa PPLNS en la documentación de ViaBTC citada; no es una comisión universal para todos los métodos de pago. Para ViaBTC PPS+, la comisión documentada para el componente de subsidio es del 4%, mientras que el componente de comisiones de transacción tiene una comisión separada del 2%. Reemplace la comisión según el método elegido y contabilice los ingresos por comisiones de transacción por separado (ViaBTC, ¿Cómo se calculan las ganancias?, consultado el 14 de octubre de 2026).

Separar la emisión de la dificultad

Existen dos mecanismos distintos que afectan a cuánto KAS puede esperar ganar un determinado hashrate, y no deben fusionarse en una única variable. El primero es el calendario de emisión de Kaspa: el subsidio por bloque disminuye según periodos mensuales de subsidio predeterminados, independientemente del hashrate de la red. El segundo es la dificultad, que se ajusta en respuesta a los cambios en el hashrate total de la red para que la tasa real de producción de bloques se mantenga cercana al objetivo del protocolo de 10 bloques por segundo. Un aumento del hashrate de la red incrementa la dificultad y reduce la cuota esperada de bloques de un minero con hashrate fijo; una reducción del subsidio disminuye la recompensa por bloque independientemente de la dificultad. Tratar estos factores como una sola variable oscurece cuál de ellos está impulsando un cambio en los ingresos esperados.

La actualización Crescendo de Kaspa de mayo de 2025 elevó el objetivo de tasa de bloques de 1 a 10 bloques por segundo y ajustó la dificultad para la nueva tasa. También dividió el subsidio por bloque entre la tasa de bloques, preservando el calendario de emisión en lugar de multiplicar la emisión por diez. Por lo tanto, las comparaciones históricas necesitan unidades coherentes por bloque, por segundo o por día; las recompensas por bloque previas a la actualización no pueden combinarse sin más con la tasa de bloques posterior a la actualización (Kaspa, KIP-14).

Para la prueba de sensibilidad a la emisión, suponga que el subsidio cae de 2.06017223 a 1.94454365 KAS/bloque, aproximadamente 5.61%, mientras todos los demás parámetros permanecen constantes. La estimación teórica entonces cae de aproximadamente 110.10 a 103.92 KAS/día antes de las comisiones del pool. Estos valores ilustran el efecto de un escalón mensual de subsidio; no se presentan como un subsidio actual verificado ni como un ajuste futuro con fecha concreta.

Los periodos de subsidio de Kaspa se determinan mediante cálculos de protocolo basados en la puntuación DAA, donde un mes de protocolo representa 30.4375 días. Por lo tanto, una fecha de calendario para la próxima reducción debe tratarse como una estimación y verificarse contra el progreso actual de la red, en lugar de indicarse como una fecha límite garantizada. El calendario de subsidio es independiente de los cambios en el hashrate de la red y en la dificultad (Kaspa, KIP-14).

Modelado de la potencia y el tiempo de inactividad

El coste de electricidad escala directamente con la potencia de pared medida y el tiempo de funcionamiento. Con los 75.6 kWh/día nominales del KS5 Pro, los costes diarios de electricidad ilustrativos a varias tarifas son:

Estas cifras cubren únicamente la electricidad del minero; excluyen la refrigeración externa, las tarifas de alojamiento (hosting), las comisiones del pool, el mantenimiento y cualquier otro coste operativo.

El tiempo de inactividad es donde una única cifra de ganancias diarias se desmorona con mayor claridad, porque no todo el tiempo de inactividad tiene el mismo efecto económico. Utilice la potencia medida para cada estado operativo:

Energía diaria (kWh) = potencia de minería (kW) × horas de minería productivas + potencia en estado de fallo (kW) × horas encendido pero improductivas + consumo apagado (kW) × horas apagado

Las tres categorías de tiempo deben sumar 24 horas. Para una unidad completamente desconectada, el consumo apagado es cero. La potencia en estado de fallo debe medirse; que un minero permanezca encendido no demuestra que siga consumiendo su potencia de minería completa.

Coste eléctrico diario = energía diaria × tarifa eléctrica

Balance después de la electricidad del minero = ingresos estimados tras la comisión del pool − coste eléctrico diario

Las siguientes tablas utilizan el ejemplo centrado solo en el subsidio mencionado anteriormente: aproximadamente $4.17/día con disponibilidad plena tras una comisión del pool del 2%, y electricidad a $0.05/kWh. Modelan dos supuestos de potencia específicos, no todos los comportamientos de fallo posibles.

Cuando un minero está completamente apagado, tanto el tiempo de minería como el consumo eléctrico disminuyen juntos:

Para el segundo escenario, suponga que el minero no puede enviar shares válidos durante el periodo no disponible pero continúa consumiendo los 3.15 kW completos. Bajo este supuesto, el consumo eléctrico se mantiene en 75.6 kWh/día mientras los ingresos de minería estimados disminuyen. Un fallo de conexión al pool, una interrupción de red o un fallo de configuración no demuestran por sí mismos este comportamiento de potencia; sustituya la potencia en estado de fallo asumida por un valor medido para el dispositivo y el firmware en uso.

Con un 90% de disponibilidad de envío de shares, el escenario de fallo con potencia completa produce un balance estimado de −$0.03/día, mientras que el escenario de apagado deja aproximadamente $0.35/día después de la electricidad del minero. La diferencia proviene del consumo de energía en estado de fallo asumido. Si el minero reduce su potencia durante un fallo, el resultado debe recalcularse utilizando ese consumo menor. Tarifas eléctricas más altas incrementan el coste de cualquier potencia que se siga consumiendo durante los periodos improductivos.

Una forma de reducir la frecuencia del segundo escenario es configurar varios endpoints de pool en orden de prioridad, de modo que se utilice automáticamente un pool de menor prioridad si uno de mayor prioridad deja de estar accesible; el manual del KS5 de Bitmain describe compatibilidad con hasta tres pools configurados en orden de prioridad descendente. Esto puede ayudar con un endpoint inaccesible, pero no resuelve un corte local de internet ni todos los fallos de configuración. Si vale la pena configurar esta opción de conmutación por error depende de la fiabilidad de monitoreo y conectividad propia de cada operación, y debe tratarse como una opción a considerar y no como un requisito fijo.

Conciliar los créditos reales de KAS

Una prueba de rentabilidad solo es útil si sus datos de entrada se comparan sobre ventanas de tiempo coincidentes y se mantienen separados los distintos tipos de medición. El hashrate local del minero, el hashrate estimado por el pool, las shares enviadas y las recompensas acreditadas describen cosas diferentes y no deben sustituirse entre sí.

La documentación de ViaBTC señala que su hashrate de pool en tiempo real se calcula a partir de un promedio móvil de 10 minutos, mientras que el panel propio de un minero puede actualizarse con mucha mayor frecuencia; una brecha persistente entre ambos también puede reflejar latencia de red, tasa de rechazo, compatibilidad de firmware o ajustes del dispositivo, en lugar de un error del pool (Soporte de ViaBTC, Why is the Hashrate Shown in the Mining Pool Lower than that of the Mining Machine). Comparar lecturas con distintas ventanas de promediado puede crear una discrepancia aparente sin que ello implique un problema real de rendimiento. Para una comprobación diaria de rentabilidad, compare el hashrate promedio, el consumo de energía y las recompensas acreditadas durante el mismo período completo de 24 horas, conservando y etiquetando todos los períodos de reinicio, calentamiento e interrupción. El Profit Detail de ViaBTC usa UTC+8, por lo que debe alinear la comparación con esa ventana de reporte. Si el objetivo es una prueba independiente de funcionamiento estable, filtre ambos conjuntos de datos a intervalos operativos idénticos y no presente ese resultado como la rentabilidad de todo el día.

El método de pago también afecta a qué tan de cerca seguirá un resultado de período corto al modelo teórico anterior. Las opciones actuales publicadas por ViaBTC para la minería de KAS son PPS+ y PPLNS, con una comisión del 2% indicada para PPLNS en su documentación de cálculo de ganancias; PPS+ aplica una comisión documentada del 4% al componente de recompensa de bloque y del 2% al componente de comisiones de transacción (Soporte de ViaBTC, How are profits calculated). Bajo PPLNS, una ventana de medición corta puede divergir de la estimación teórica basada en la cuota de red porque las recompensas reales dependen de qué bloques encuentre el pool durante esa ventana; bajo PPS+, el componente de subsidio se paga mediante PPS y está menos expuesto a la suerte de corto plazo del pool en encontrar bloques, mientras que el componente de comisiones de transacción utiliza la contabilidad PPLNS. Vuelva a verificar los términos aplicables al ejecutar el modelo (Soporte de ViaBTC, KAS Mining).

Conciliar el KAS realmente acreditado con el modelo de este artículo implica comprobar: el subsidio exacto y el hashrate de red vigentes durante el período medido, la potencia de pared y el tiempo de actividad medidos por el propio operador (no la cifra nominal), la tasa de shares rechazadas que muestra el panel del minero o del pool, y las reglas contables del método de pago. Una brecha entre el modelo y el resultado acreditado no es automáticamente un error: puede reflejar la suerte del pool bajo PPLNS, un subsidio distinto al utilizado en el modelo, o un tiempo de inactividad que no se registró. Aislar cuál de estos factores explica la brecha es más útil que tratar al modelo o al total acreditado como la única cifra correcta.

Preguntas frecuentes

¿Son 21 TH/s y 3150 W un resultado garantizado para cada unidad KS5 Pro?

No. Se trata de las especificaciones típicas del fabricante publicadas por Bitmain a 25 °C de temperatura ambiente, con tolerancias publicadas de ±3% en hashrate y ±5% en potencia de pared y eficiencia; los resultados reales dependen de la unidad individual y de las condiciones de operación.

¿Por qué el mismo porcentaje de tiempo de actividad produciría resultados de rentabilidad diferentes?

Porque el consumo eléctrico depende de la potencia consumida durante el período de no disponibilidad. Un minero totalmente apagado no consume electricidad de minería durante ese tiempo. Un minero encendido pero improductivo puede seguir consumiendo energía, pero esa cantidad debe medirse. El escenario de fallo con potencia plena en este artículo supone 3,15 kW durante todo el período; ese supuesto no es una consecuencia universal de perder la conectividad.

¿El subsidio de Kaspa disminuye según un calendario fijo como el halving de Bitcoin?

Kaspa también tiene un calendario de emisión predeterminado, pero implementa las reducciones en pasos mensuales en lugar de los pasos plurianuales del halving de Bitcoin. Su protocolo utiliza períodos de subsidio basados en la puntuación DAA, por lo que debe verificar el subsidio aplicable y tratar la fecha calendario de un ajuste futuro como una estimación.

¿Por qué podría diferir el hashrate reportado por el pool del panel propio del minero?

El hashrate del lado del pool normalmente se calcula como un promedio móvil sobre una ventana indicada (por ejemplo, 10 minutos), mientras que el panel local del minero puede actualizarse con mayor frecuencia; las diferencias también pueden reflejar latencia de red, shares rechazadas, firmware o la configuración del dispositivo.

Referencias

• Soporte de Bitmain. "Especificaciones del KS5 Pro".
• CoinGecko. "Datos históricos de Kaspa".
• Soporte de ViaBTC. "Por qué el hashrate mostrado en el pool de minería es menor que el de la máquina minera".
• Soporte de ViaBTC. "Cómo se calculan las ganancias".
• Soporte de ViaBTC. "Minería de KAS".
• Kaspa. "KIP-14: El hardfork Crescendo".
• Bitmain. "Manual del KS5", septiembre de 2024.