El artículo detalla 12 áreas específicas donde el estándar de la API compatible con OpenAI diverge entre diferentes motores de inferencia y proveedores alojados, provocando fallos silenciosos o comportamientos inesperados. Aunque las formas básicas de solicitud y la transmisión en streaming funcionan de manera fiable, diferencias sutiles en el manejo de parámetros, respuestas de error y soporte de funciones pueden romper aplicaciones.

  • Los parámetros desconocidos a menudo se omiten silenciosamente en lugar de rechazarse con un error 400.
  • Los modelos de razonamiento pueden requerir `max_completion_tokens` en lugar de `max_tokens`, con una aceptación inconsistente.
  • Las estadísticas de uso de tokens frecuentemente están ausentes en las respuestas de streaming a menos que se soliciten explícitamente mediante `stream_options`.
  • El soporte para llamadas a herramientas varía significativamente, con muchos servidores que carecen de llamadas paralelas nativas o adherencia estricta al esquema.
  • Las implementaciones del modo JSON difieren entre la validación básica de objetos y la decodificación restringida con esquemas.
  • El manejo del desbordamiento de contexto oscila desde errores 400 duros hasta la truncación silenciosa de los prompts del sistema.
  • Los valores de `finish_reason` incluyen adiciones específicas del proveedor más allá del estándar stop, length y tool_calls.
  • Los envoltorios de error y las respuestas de limitación de tasa (429, 503 o 200 con errores en el cuerpo) son inconsistentes.
  • La configuración de temperatura en modelos de razonamiento puede ser ignorada internamente a pesar de ser aceptada.
  • El manejo de entradas multimodales varía en límites de tamaño, tipos MIME y el parámetro `detail`.
  • Los puntos finales de incrustación carecen de portabilidad debido a la dimensionalidad y normalización diferentes.

Las claves de idempotencia rara vez son compatibles, y los encabezados de ID de solicitud utilizan nombres inconsistentes.

El autor recomienda utilizar un script de prueba para verificar la conformidad del proveedor con respecto a estos comportamientos específicos, ya que las versiones de los modelos cambian con frecuencia y los fallos silenciosos pueden ser difíciles de depurar en producción.