El mismo modelo, dos alojamientos, respuestas distintas

Resumen §

Enrutamos un modelo de pesos abiertos, MiniMax-M3, a través de dos proveedores de inferencia alojada — Together AI y Ollama Cloud — dentro de una plataforma en producción para contratación pública. Una comparación no controlada mostró que un proveedor puntuaba 9.7 puntos más que el otro en la misma tarea y con el mismo prompt.

Controlar dos variables de nuestro propio banco de pruebas eliminó casi toda esa diferencia. La misma tarea, medida de nuevo, quedó a 0.5 puntos de distancia. Lo que sobrevivió al control fue un conjunto de diferencias distinto, menor y más específico.

El hallazgo práctico no es que un proveedor sea mejor. Es que una diferencia aparente entre proveedores es, por defecto, no medible: dos defectos corrientes del banco de pruebas produjeron una diferencia de 9.7 puntos, de los que quedaron 0.5 puntos tras corregirlos. Quien compare proveedores de inferencia alojada probablemente esté midiendo su propio montaje de pruebas.

1. Por qué surgió esto §

Los modelos de pesos abiertos se sirven cada vez más desde varios alojamientos. El mismo nombre de checkpoint aparece en distintos proveedores, y la suposición natural es que enrutar hacia el más barato o el más rápido es una decisión puramente comercial: que el modelo es el modelo.

Nuestra plataforma asigna modelos distintos a trabajos distintos (puntuación de oportunidades, resumen de documentos, redacción de propuestas, revisión adversaria, traducción, redacción de especificaciones). Construimos un banco de pruebas comparativo para hacer esas asignaciones con evidencia y no por preferencia: el mismo prompt se envía a N modelos, y un modelo juez, excluido de la competición, puntúa las respuestas anonimizadas y barajadas.

Al ejecutar ese banco de pruebas registramos que MiniMax-M3 puntuaba 78.5 en Ollama Cloud y 68.8 en Together en resumen en lenguaje claro. Mismos pesos, mismo prompt, mismo juez. Es una diferencia lo bastante grande como para enrutar tráfico de producción, así que intentamos explicarla.

2. Dos defectos del banco de pruebas §

2.1 Nunca se especificó la temperatura de muestreo §

Nuestro cliente enviaba {model, max_tokens, messages} y nada más. Ni temperature, ni top_p.

Cada proveedor aplica su propio valor por defecto cuando se omiten los parámetros de muestreo, y esos valores no son el mismo número. No estábamos haciendo la misma pregunta a los dos alojamientos. La comparación no medía el modelo; medía en parte dos regímenes de muestreo distintos.

2.2 El banco de pruebas no usaba los presupuestos de tokens de producción §

Cada tarea del banco de pruebas se ejecutaba con un tope fijo de 1,500 tokens de salida. Producción transmitía entre 1,200 y 6,000 según el trabajo.

Para los modelos de razonamiento esto no es una discrepancia menor. Un modelo de razonamiento gasta su presupuesto en razonamiento oculto antes de emitir un solo carácter visible, de modo que un presupuesto famélico no produce una respuesta más corta: no produce ninguna respuesta. En la tarea cuyo presupuesto de producción es 6,000, cuatro de seis modelos evaluados devolvieron razonamiento y ningún texto. El banco de pruebas los registró como fallos del modelo y recomendó el quinto mejor modelo para ese puesto.

El sesgo tiene dirección: privar de presupuesto favorece sistemáticamente a los modelos que menos piensan antes de responder.

3. Método §

Plataforma. Un SaaS multiinquilino en producción para descubrimiento de oportunidades federales estadounidenses y preparación de ofertas. Todos los prompts son los de producción, no paráfrasis: un prompt parafraseado mide el banco de pruebas, no el modelo.

Contendientes. together/MiniMaxAI/MiniMax-M3 y Ollama/minimax-m3:cloud — el mismo nombre de modelo tal como lo publica cada alojamiento.

Juez. OpenAI/gpt-5.6-luna, excluido del grupo de contendientes. Un juez que además compite puntúa cada respuesta 5–11 puntos más alto sin cambiar el orden, lo que hace incomparables las celdas; por eso se retira en lugar de señalarlo. Las respuestas se anonimizan y se barajan antes de puntuar; el juez ve el principio y el final del prompt, porque truncar solo por el principio ocultó una vez el documento en revisión e invirtió una columna entera de resultados.

Tareas. Nueve trabajos de producción: puntuación de idoneidad, resumen en lenguaje claro, preguntas para el comprador, redacción de una sección de propuesta, resumen de build, revisión adversaria, traducción al árabe, redacción de especificaciones de build y transcripción de páginas escaneadas.

Corpus. Tres licitaciones reales de distinta extensión y origen (73.9k, 86.9k y 17.6k caracteres), dos ejecuciones cada una.

Controles aplicados antes de la medición final.

1. Temperatura de muestreo fijada explícitamente en 0.2 para todos los proveedores.
2. Cada tarea ejecutada con el mismo presupuesto de tokens que le pasa su llamador en producción (1,200 / 2,000 / 2,500 / 4,000 / 6,000 según la tarea).

La clasificación usa la posición media, no la puntuación media: medido en nuestro corpus, todo el conjunto puntuó 39–66 en un anuncio y 78–94 en otro, de modo que promediar puntuaciones brutas registra sobre todo qué documentos le tocaron a cada modelo.

4. Resultados §

4.1 La diferencia desaparece en gran parte bajo control §

4.2 Resultados controlados, todas las tareas medibles §

Puntuaciones del juez, 0–100. Los fallos son llamadas que no devolvieron texto utilizable.

La redacción de especificaciones de build no pudo medirse: en cada ejecución al menos un contendiente no devolvió nada, dejando al juez una sola respuesta y ninguna clasificación que hacer. La declaramos no medida en lugar de presentarla como resultado.

Lo que sobrevive al control es una diferencia decisiva — puntuación de idoneidad, 10.0 puntos para Together — y una casi paridad en seis de las siete tareas restantes. Las dos tareas en las que Ollama Cloud va por delante se deciden por menos de un punto.

4.3 Las diferencias operativas son mayores que las de calidad §

Según la telemetría de producción del mismo periodo:

Ollama Cloud respondió aproximadamente 1.8× más rápido; Together falló aproximadamente 4× menos. Los fallos observados en Ollama Cloud incluyeron tiempos de lectura agotados y completados vacíos en los que el razonamiento consumió todo el presupuesto.

Esta comparación es observacional, no controlada: los dos endpoints no recibieron mezclas de tareas idénticas durante el periodo. La presentamos porque el tamaño del efecto es grande y consistente, no porque sea experimentalmente limpia.

4.4 Algunos modelos rechazan una temperatura fijada §

De siete modelos a los que fijamos el valor, dos lo rechazaron: las familias de razonamiento responden a una temperatura explícita con un error HTTP 400 y solo aceptan su propio valor por defecto. Uno de ellos era nuestro juez. Cualquier cliente que fije el muestreo debe detectarlo a partir del error y reintentar sin el parámetro, o perderá justamente los modelos más sensibles al muestreo.

5. Interpretación §

No establecimos por qué difieren los dos alojamientos allí donde todavía difieren. Cualquiera de las siguientes causas lo explicaría, y no pudimos verificarlas desde fuera: formato de cuantización, diferencias en la pila de servicio, revisión del checkpoint o parámetros de muestreo restantes que no fijamos (top_p, top_k, penalización por repetición).

Sí establecimos algo que consideramos más útil:

La diferencia que un banco de pruebas no controlado reporta entre dos proveedores puede ser varias veces mayor que la que sobrevive al control — y puede apuntar en sentido contrario.

Antes de los controles, nuestros datos decían: «enruta el resumen a Ollama Cloud, por 9.7 puntos». Después de los controles, esa tarea está empatada y la diferencia real está en otra parte por completo. Un equipo que actuara según la primera medición habría tomado una decisión de enrutamiento basada en un artefacto de su propio montaje de pruebas.

6. Recomendaciones prácticas §

Para quien compare proveedores de inferencia alojada:

1. Fije el muestreo explícitamente. Si no envía temperature, está comparando los valores por defecto de cada proveedor tanto como el modelo. Gestione los modelos que lo rechacen.
2. Dé al banco de pruebas los presupuestos de tokens de producción. Un benchmark con un presupuesto distinto al de producción mide un sistema distinto — y privar de presupuesto a los modelos de razonamiento convierte en silencio diferencias de calidad en recuentos de fallos.
3. Distinga una llamada fallida de una respuesta mala. El nuestro las confundía, y un fallo inducido por el banco de pruebas se leyó como una deficiencia del modelo.
4. Mantenga al juez fuera del grupo. Un juez que compite infla todas las puntuaciones sin cambiar el orden.
5. Clasifique por posición, no por puntuación media, si su corpus es heterogéneo. De lo contrario registrará sobre todo qué documentos le tocaron a cada modelo.
6. Nombre lo que no pudo medir. Una tarea que desaparece en silencio de una tabla de resultados parece no haberse pedido nunca.

Para equipos que elijan específicamente entre estos dos proveedores: en nuestra carga de trabajo la diferencia de calidad tras el control es pequeña y específica de cada tarea, mientras que la diferencia de latencia y fiabilidad es grande. Eso sugiere enrutar por características operativas — rápido donde espera una persona, fiable donde una llamada perdida cuesta trabajo — y no por puntuaciones agregadas de calidad.

8. Conclusión §

Dos proveedores que sirven el mismo modelo de pesos abiertos produjeron resultados medibles distintos. La mayor parte de la diferencia que observamos al principio era nuestra propia instrumentación. El residuo es real, pero menor y de forma distinta a lo que sugería la medición original, y es menor que las diferencias operativas entre los dos alojamientos.

Si está eligiendo entre proveedores para un modelo de pesos abiertos: controle primero su banco de pruebas y después mida. De lo contrario, la cifra sobre la que está a punto de actuar hablará sobre todo de usted.