Inferencia local en Mac: 12 tok/s, prefill de 8k y punto de equilibrio de costos

Costos

La compensación es aritmética, no de gustos: la inferencia local cuesta hardware amortizado más energía, el servicio por API cuesta tokens, y lo local solo gana cuando (costo de la máquina ÷ tokens esperados) está por debajo del precio de la API por token. El modelo objetivo es un modelo de mezcla de expertos Qwen3.8-Flash-Next de 125B parámetros, de 104 GB en disco en 4 bits, y se transmite desde SSD en lugar de cargarse por completo en memoria. Los requisitos de hardware declarados son Apple Silicon, macOS 14 o posterior, unos 110 GB de disco libre y un Mac de 512 GB como mínimo realista. Esos requisitos convierten al disco en la primera restricción. Los prompts largos crean un cuello de botella de prefill, con 8.000 tokens que tardan aproximadamente un minuto en un Mac de 48 GB y más de tres minutos en un Mac de 16 GB. Si la máquina no puede contener los pesos, no puede hacer prefill dentro de la paciencia del usuario o no puede decodificar a una velocidad que el producto pueda tolerar, el precio del token es irrelevante. Si puede, el precio del token se convierte en el único número que importa.

Estima la vida útil de la máquina en meses, el consumo de energía mientras sirve, el volumen esperado de tokens y la tarifa de la API en dólares por millón de tokens. Compara el costo local mensual dividido entre los tokens esperados con el costo de la API por token. La línea local incluye depreciación, almacenamiento, refrigeración y tiempo de ingeniería. La línea de API incluye gasto en tokens, límites de tasa y el margen que estás dispuesto a pagar por elasticidad. Si la línea local es menor y la línea de latencia es aceptable, lo local es una decisión de economía unitaria, no un pasatiempo.

La trampa es tratar la máquina como gratuita después de la compra. Un servidor local es un costo fijo que debe amortizarse entre suficientes solicitudes. El tráfico bajo hace explotar el costo local por token. El tráfico alto puede hacerlo parecer barato, pero solo si la carga de trabajo se mantiene dentro de los límites térmicos, de almacenamiento y de latencia de la máquina. El punto de equilibrio es un rango donde se cruzan el costo de hardware, la energía y el volumen de tokens.

La regla

• Disco: confirma que la máquina tiene espacio para los pesos, los registros y el sistema operativo antes de prometer un despliegue.
• Decodificación en caliente: verifica si la UX objetivo puede tolerar la tasa de tokens en la máquina real.
• Prefill: prueba el prompt más largo que esperas, no el prompt promedio, porque la latencia del primer token es la espera visible.
• Compatibilidad con API: verifica que el endpoint funcione con tu cliente existente, las plantillas de prompt y el manejo de errores.
• Costo: compara el costo amortizado de la máquina más la energía con los tokens de API en el volumen esperado, y vuelve a hacer la cuenta cuando el volumen cambie.

Modelos

Aunque la capa de memoria parezca adecuada, la huella de los pesos puede hacer inutilizable una unidad pequeña. Para un producto, el objetivo de despliegue no es solo una familia de chips; es una clase de almacenamiento. Una máquina que puede iniciar el modelo pero no tiene espacio para pesos, registros y el sistema operativo no es un servidor viable.

La cuantización es la razón por la que esto es posible en absoluto: un modelo comprimido es más pequeño y más rápido de mover, pero también es una aproximación con pérdida de los pesos originales. La pregunta de producto no es si el modelo funciona; es si la calidad después de la cuantización es aceptable para la función. Conviértelo en una comprobación de calidad testeable: prueba el modelo con los propios prompts de la función, no con un benchmark genérico, y exige que los propios prompts de la función pasen. Si la función necesita razonamiento de contexto largo, uso de herramientas o extracción precisa, ejecuta esos prompts como conjunto de aceptación. Si la función es un asistente ligero, un generador de borradores o un resumidor privado, la compensación puede valer la pena.

Servicio

El prefill es la parte por la que los usuarios esperan antes de que aparezca el primer token. Es la latencia más difícil de ocultar. Una función que envía documentos grandes, historiales de chat largos o contexto recuperado se sentirá lenta incluso si la decodificación es aceptable. La decisión de producto es limitar la longitud del prompt, resumir antes de enviar o enrutar las solicitudes de contexto largo a una ruta más rápida. Si el SLA no puede absorber la espera de prefill, el servicio local no es un reemplazo directo para un endpoint alojado.