Reduce el costo de llamadas LLM sí/no como decisiones con precio

La compensación es entre tokens de salida y calidad de la decisión

Una llamada LLM sí/no suele facturarse como prosa generada, pero se parece más a una decisión con precio. La compensación es simple: pagas por tokens de entrada, tokens de salida, latencia y el costo de la clase de error equivocada. Si 1,000 llamadas usan 100 tokens de entrada cada una y la salida es gratuita, la factura es de $0.0042 antes de la latencia y el manejo de errores.

Jev, una API de modelo de decisión de TypeSafe, recibe texto y emite valores flotantes para etiquetas de categoría, respuestas sí/no, calificaciones y confianza. Esa forma importa porque un enrutador, un filtro de spam o un puntuador de relevancia necesita un número, no un párrafo.

TypeSafe cobra $0.042 por millón de tokens de entrada, o $42 por mil millones de tokens, y no cobra por tokens de salida. El precio de entrada está por debajo del GPT-5 Nano de OpenAI, un modelo pequeño de OpenAI, que cuesta $0.05 por millón de tokens.

El contrato de decisión viene antes del benchmark

Define la decisión en una sola línea: aprobar, rechazar, enrutar, puntuar. El resultado debe ser una etiqueta que un no ingeniero pueda leer. Si la etiqueta necesita un párrafo, el modelo está haciendo más que una decisión.

Define el umbral antes de mirar la precisión. El resultado debe ser un corte de confianza y una acción de respaldo. Para un endpoint sí/no, el umbral es el punto de decisión donde un sí equivocado cuesta menos que un no equivocado, o viceversa.

Registra la puntuación cruda, no solo la etiqueta. El resultado debe ser una tabla con entrada, puntuación, etiqueta y acción aguas abajo. Ese registro es lo que te permite reponerle precio a la clase de error después del lanzamiento. Mantén el contrato en el mismo repositorio que el prompt, porque el umbral es parte del modelo.

Cinco números deciden el cambio

Mide la llamada actual con los números que determinan el costo. La prueba son cinco números, no una comprobación por intuición.

1. Cuenta los tokens de entrada. El resultado debe ser un conteo p95 de tokens de entrada por llamada y un total mensual de tokens. Si tu prompt sí/no es un prompt corto de clasificación, los tokens de entrada dominan la factura.
2. Ponle precio al costo de salida. El resultado debe ser tokens de salida por llamada y dólares por cada 1,000 llamadas. Si la salida es gratuita, esta línea se elimina; si no, puede compensar los ahorros de entrada.
3. Mide la latencia p95. El resultado debe ser el tiempo p95 de extremo a extremo bajo carga, no la mediana. TypeSafe indica que Jev responde en 70 a 500 milisegundos de extremo a extremo; consultas comparables de frontera van de 3 a 329 segundos.
4. Clasifica el costo del error. El resultado debe ser una tabla de falsos positivos, falsos negativos y el valor en dólares de cada uno. Un sí equivocado en revisión de fraude cuesta más que un sí equivocado en clasificación de búsqueda.
5. Ponle precio al costo de indisponibilidad por llamada. El resultado debe ser el ingreso o costo de soporte perdido cuando el endpoint está caído brevemente. Si la decisión controla el checkout, el costo de indisponibilidad puede superar el costo de tokens en órdenes de magnitud.

Cambia solo cuando la decisión es estrecha

Las evaluaciones de flujo de trabajo de TypeSafe produjeron resultados 193.6x más rápidos y 444.6x más baratos, y TypeSafe llama a esos múltiplos el extremo superior de lo que las implementaciones reales deberían esperar. La referencia del benchmark promedió dos modelos de frontera, GPT-6 Astra y Fable 5.1; TypeSafe dice que eso sesga los resultados hacia modelos de OpenAI y Anthropic. Trata los múltiplos del titular como un techo, no como una línea base.

El modo de fallo es enrutar tráfico de extracción de fechas, aritmética o con mucha inyección de prompts a Jev como si fuera un LLM general. Jev actualmente tiene dificultades con números, fechas y contenido adversarial. Si la decisión necesita razonamiento libre, mantén el LLM. Si necesita una probabilidad calibrada para una clase estrecha, un endpoint de salida estructurada puede ser la opción más barata.

Ejecuta la prueba de cinco números con tu propio tráfico. Si los tokens de entrada, el costo de salida, la latencia, la clase de error y el costo de indisponibilidad apuntan todos en la misma dirección, cambia. El precio del token es solo el primer término en el costo total de la decisión. Registra el número desconocido en la misma tabla que los otros cuatro, y luego vuelve a ejecutar la prueba después de suficiente tráfico para estabilizar la clase de error.