GPT-6 Luna vs GPT-5.6 Luna: cómo planificar una migración medible
En las cargas de trabajo de Luna, la unidad útil suele ser el registro aceptado: una factura con los campos correctos, un ticket con la etiqueta adecuada o una transformación completada que supera la validación aguas abajo. Una respuesta que se parsea como JSON puede seguir siendo incorrecta. Una factura de tokens baja puede esconder una cola de reintentos mayor.
Línea base documentada y candidato sin verificar
| Elemento | GPT-5.6 Luna | GPT-6 Luna, revisado el 20 de septiembre |
|---|---|---|
| Identidad oficial | gpt-5.6-luna | No aparece ninguna entrada específica del modelo en el catálogo |
| Posicionamiento documentado | Trabajo de gran volumen y sensible al coste | Sin verificar |
| Entrada / salida | Texto e imagen / texto | Sin publicar en las fuentes revisadas |
| Contexto / salida máxima | 1.050.000 / 128.000 tokens | Sin publicar en las fuentes revisadas |
| Esfuerzo de razonamiento | none, low, medium (por defecto), high, xhigh, max | Sin verificar |
| Streaming, function calling, salidas estructuradas | Figuran en la referencia upstream del modelo | Sin verificar |
| Tu resultado de procesamiento | Hay que medirlo con tus registros | Para esta guía no se ha realizado ninguna medición |
Estos hechos establecen la identidad y un contrato de partida. No demuestran que un futuro Luna vaya a conservar el mismo comportamiento de esquema, a costar menos ni a procesar tu cola más rápido.
Construye un conjunto de registros que refleje la cola real
Parte de la distribución de tu propia carga de trabajo. Un conjunto de pruebas equilibrado no tiene por qué contener el mismo número de casos de cada categoría: si un formato de cliente concentra la mayor parte del volumen, necesita una representación significativa. Al mismo tiempo, incluye los fallos poco frecuentes cuyo coste sea lo bastante alto como para bloquear el despliegue.
Guarda un ID de registro estable, la versión de la entrada, la salida esperada, los valores nulos permitidos, las reglas de validación y cualquier decisión de escalado. Elimina el contenido sensible cuando tu entorno de evaluación no esté autorizado a procesarlo. Conserva junto al conjunto de datos las revisiones del prompt, del esquema, del preprocesamiento y del posprocesamiento.
Divide el conjunto en una parte pequeña de desarrollo y una comprobación reservada. Usa la primera para reparar errores evidentes del harness y afinar el candidato. Usa la segunda para ver si la configuración afinada generaliza. Afinar contra todos los registros y presentar después esos mismos registros como una prueba nueva exagera la confianza.
Agrupa los resultados por segmento de la carga de trabajo. La precisión global puede parecer saludable mientras un idioma, una plantilla de documento o una etiqueta de poco volumen se vuelven poco fiables. Pondera la puntuación global con la mezcla de tráfico que esperas enviar y muestra además por separado los segmentos críticos.
Seis tareas repetibles y sus reglas de aceptación
| Carga de trabajo | Incluye estos casos | Regla de aceptación |
|---|---|---|
| Extracción de facturas o formularios | Valores ausentes, totales contradictorios, varias fechas, páginas escaneadas | Los campos obligatorios coinciden con la referencia; los valores ausentes siguen ausentes; los totales cumplen las comprobaciones definidas |
| Clasificación de tickets | Etiquetas parecidas, temas mezclados, casos urgentes poco frecuentes | Etiqueta y escalado correctos; mide los falsos positivos y los falsos negativos por clase |
| Resumen estructurado | Hilos largos, correcciones posteriores en el texto, preguntas sin resolver | Conserva el estado final y las acciones abiertas sin inventar una resolución |
| Normalización de datos | Unidades, configuraciones regionales, formatos de fecha, identificadores ambiguos | Valor normalizado correcto o incertidumbre explícita; ninguna suposición silenciosa en un campo ambiguo |
| Transformaciones de código repetidas | Entradas de código válidas y no válidas, archivos ya transformados | La salida pasa el parser y las pruebas, conserva el contenido no relacionado y puede reprocesarse sin riesgo |
| Búsqueda de registros asistida por herramientas | Registro inexistente, coincidencia duplicada, timeout tras la búsqueda | Asociación correcta del registro e incertidumbre explícita; ningún resultado de herramienta fabricado ni escritura duplicada |
Separa la validez del esquema de la corrección semántica. Por ejemplo, la respuesta sobre una factura puede usar las claves y los tipos correctos y, aun así, asignar al cliente el número fiscal del proveedor. Un único porcentaje de «JSON válido» oculta ese fallo.
Algunas tareas necesitan un revisor. Da a los revisores una rúbrica y oculta la etiqueta del modelo cuando sea viable. Registra los desacuerdos y resuélvelos con un criterio constante. Informa de cuántos registros se valoraron automáticamente y cuántos requirieron a una persona; una migración que aumenta la revisión manual cambia el coste de operación.
Comprueba la compatibilidad antes de escalar la concurrencia
Antes de lanzar una reejecución grande, confirma la identidad exacta del candidato y el endpoint admitido. Mantén configurable la selección de modelo para poder cambiarla sin reescribir cada productor de trabajos. No sustituyas un ID de petición documentado por un slug de búsqueda.
Comprueba los controles que usas de verdad, incluidos el esfuerzo de razonamiento, los límites de salida, el formato del esquema, el streaming y las respuestas de herramientas. Un parámetro que GPT-5.6 Luna acepta podría ser rechazado o interpretado de otra forma por un sucesor. Una respuesta HTTP correcta no prueba que se haya respetado un ajuste solicitado.
Ejercita los caminos de fallo como parte de esta pasada:
- Una salida truncada o mal formada debe fallar la validación y seguir una política de reintentos acotada.
- Un rechazo debe seguir siendo distinguible de una extracción vacía pero válida.
- Los rate limits deben provocar un backoff controlado, no una ráfaga de reintentos sin límite.
- Los streams parciales y los timeouts de red no deben contarse como registros aceptados.
- Los trabajos reejecutados deben conservar su identidad y evitar escrituras externas duplicadas.
Si falla un comportamiento necesario, corrige la integración o deja esa carga de trabajo en la ruta antigua antes de probar con más volumen. Las cifras de throughput obtenidas con una validación rota no son una comparación útil.
Mide el throughput de registros aceptados, no la velocidad bruta de respuesta
Ejecuta una escalera de concurrencia controlada usando la misma mezcla de registros y la misma política de reintentos en ambas configuraciones. La primera prueba pequeña detecta los fallos básicos; las ejecuciones mayores revelan el comportamiento de la cola y de los rate limits. No salgas de los límites documentados por el proveedor.
| Medición | Qué incluir |
|---|---|
| Registros aceptados por minuto | Solo los registros que superan tu regla de aceptación completa |
| P50 / P95 de extremo a extremo | Espera en cola, tiempo de petición, backoff, reintentos y cualquier escalado necesario |
| Antigüedad de la cola | El trabajo pendiente más antiguo y si el atraso crece bajo carga sostenida |
| Tasa de errores y reintentos | Fallos de transporte, de rate limit, de esquema y semánticos, por separado |
| Proporción de escalado | Registros enviados a otro modelo o a revisión manual |
| Coste por registro aceptado | Todos los intentos facturados y las llamadas de escalado del pipeline medido |
Mantén visibles la longitud de la salida y la configuración de razonamiento. Un candidato que produce respuestas mucho más largas puede cambiar tanto la latencia como el gasto. La caché de prompts y el calentamiento también pueden distorsionar una ejecución corta, así que indica si las cachés estaban calientes y evita mezclar condiciones distintas sin explicarlo.
Repite la prueba cuando sea viable y muestra el tamaño de la muestra y la duración. Una ráfaga breve no puede demostrar una capacidad de cola sostenida, y un P95 bajo obtenido con una muestra minúscula no es una garantía fiable para producción.
Calcula el coste de los registros utilizables
Coste de API por registro aceptado = gasto total de API del pipeline / registros aceptadosEl numerador incluye los intentos sin éxito y los reintentos. Si un modelo de escalado corrige el registro, incluye también su coste de API. Controla por separado el tiempo de corrección humana; si lo conviertes en dinero, declara la hipótesis de coste por hora. En una cola sin registros aceptados, informa del fallo en lugar de dividir entre cero.
Decide qué registros deben migrar, si es que alguno
Anota tu umbral para cada segmento importante antes de la prueba. Una puntuación total de éxito no debe imponerse a una regresión inaceptable en una etiqueta o un campo críticos. Elige los valores a partir de tus objetivos de servicio y de tus costes de error, no de un porcentaje universal de migración.
| Resultado | Acción |
|---|---|
| Falla la comprobación de contrato o de campos críticos | Deja la carga de trabajo en la ruta actual; documenta el fallo antes de volver a probar |
| La precisión pasa, pero falla el coste o el plazo de la cola | Investiga los reintentos, la longitud de la salida, el esfuerzo y el escalado; no amplíes todavía |
| Los segmentos rutinarios pasan; los difíciles empeoran | Plantea un reparto limitado solo si la regla de enrutamiento se puede probar y su sobrecoste está incluido |
| Todas las puertas exigidas pasan en la prueba | Inicia un piloto controlado con condiciones de parada y una vía de rollback que funcione |
| En el piloto suben los errores, el atraso o el tiempo de corrección | Detén la ampliación y haz rollback del segmento afectado |
La reejecución en sombra es útil cuando no puede producir efectos secundarios externos. En los trabajos reales, conserva los ID de trabajo e inspecciona el estado antes de reintentar tras un timeout. Una ruta de respaldo no debe provocar actualizaciones duplicadas solo porque se perdió la primera respuesta.
¿GPT-6 Luna o GPT-6 Sol para tareas repetidas?
Preguntas frecuentes
¿GPT-6 Luna es más rápido o más barato que GPT-5.6 Luna?
Esta guía no dispone de ninguna comparación verificada. El precio, el throughput y el comportamiento del nuevo modelo siguen sin verificar en las fuentes revisadas el 20 de septiembre de 2026.
¿Basta un JSON válido para aceptar un registro?
No. Valida los campos obligatorios, los valores y el sentido de la tarea, además del esquema. Una respuesta bien formada puede clasificar mal un registro o inventar un valor ausente.
¿Debería comparar los tokens por segundo?
Puede ayudar a diagnosticar una ejecución, pero los registros aceptados por minuto y la latencia de extremo a extremo describen mejor cuándo se vacía la cola. Incluye los reintentos y el escalado.
¿Los ejemplos de coste son tarifas reales de Luna?
No. Son totales hipotéticos de un pipeline para ilustrar el coste por registro aceptado. En una evaluación real, usa la factura vigente del proveedor.
¿Tienen que pasar todos los registros a la nueva generación?
No. Un traslado parcial puede ser adecuado si la regla de enrutamiento es fiable y el pipeline completo cumple sus objetivos. Deja en la ruta ya medida los segmentos que fallen o que no se hayan probado.
¿Qué debería hacerme volver atrás?
Usa las condiciones de parada elegidas antes del despliegue: regresión en campos críticos, atraso creciente, una tasa de errores o de reintentos inaceptable, trabajo de corrección adicional o un presupuesto de coste superado.
