Grandes interrupciones en ChatGPT y la API

Artículo original ↗ Discusión en Hacker News ↗

Una gran interrupción de ChatGPT y de la API de OpenAI generó una amplia preocupación por la rapidez con que desarrolladores, empresas e individuos han empezado a depender de un único proveedor de IA para el trabajo diario. Los comentaristas intercambian opciones de respaldo —desde Azure OpenAI, Anthropic y modelos de Hugging Face hasta LLMs totalmente locales— y señalan problemas prácticos como embeddings incompatibles, falta de SLAs y soporte inmaduro. Muchos ven esto como una advertencia para diseñar ahora con redundancia y portabilidad, mientras que otros argumentan que las ganancias de productividad de los modelos alojados de última generación siguen superando los riesgos de confiabilidad y bloqueo con el proveedor.

Impacto de la interrupción y dependencia

  • Muchos comentaristas informan que no pueden trabajar o que están significativamente más lentos, porque han reemplazado Google/Stack Overflow por ChatGPT para programación, scripting, documentación y escritura.
  • Algunos lo toman con humor (“día de PTO”, “rueditas de entrenamiento/muleta”), pero varios admiten que no se habían dado cuenta de lo dependientes que se habían vuelto.
  • Otros dicen que no les afecta porque no usan ChatGPT o aún “almacenan conocimiento en la cabeza”, y a veces cuestionan la sobredependencia.

Alternativas y estrategias de conmutación por error

  • La gente menciona usar: Azure OpenAI (en gran medida sin afectación), Anthropic Claude, Bard, GPT‑4 de Kagi vía Azure, Phind, You.com, Hugging Face Spaces (por ejemplo, Zephyr) y configuraciones locales (Code Llama, Mistral, dolphin‑mistral, Phind‑CodeLlama).
  • Para embeddings, las sugerencias incluyen: Azure OpenAI, Amazon Bedrock, SBERT, Instructor, y almacenar varios tipos de embeddings por documento para permitir cambiar entre ellos.
  • Algunos productos ya hicieron failover a Anthropic u otros modelos; otros señalan que esto es difícil cuando se usan funciones específicas de OpenAI (herramientas/llamadas a funciones).

Modelos locales y de código abierto

  • Hay un fuerte interés en autoalojar para evitar interrupciones y el riesgo de plataforma.
  • El consenso es que los modelos abiertos actuales están mejorando, pero todavía no igualan la calidad de GPT‑4; son lo bastante buenos para algunas tareas (resumen, programación más sencilla, RAG), pero no tan “de propósito general”.
  • El costo y la escasez de hardware (por ejemplo, H100s) son barreras importantes; los modelos más pequeños pueden funcionar bien en GPUs de consumo o incluso en CPU para algunos casos.

Confiabilidad, SLA y preocupaciones empresariales

  • OpenAI no ofrece un SLA significativo; varios relatan experiencias de soporte muy deficientes y problemas sin resolver durante meses.
  • Algunas empresas se están moviendo a Azure OpenAI específicamente por mejor confiabilidad, SLA y soporte.
  • Otros sostienen que esta es una fase normal de rápido crecimiento; los SLA y la solidez mejorarán, pero el riesgo de bloqueo con el proveedor y la planificación ante interrupciones están infravalorados.

Calidad del modelo, censura y comportamiento

  • Opiniones mixtas sobre el nuevo GPT‑4 Turbo: más barato y rápido, pero quizá algo peor en algunas tareas de NLP; algunos informan variabilidad incluso con temperatura baja.
  • Comparaciones: GPT‑4 suele verse como el mejor en general; Bard se percibe como más débil en programación y más filtrado de forma agresiva; Claude es elogiado como un respaldo sólido.
  • Preocupaciones sobre filtros de contenido demasiado estrictos (especialmente temas de violencia/guerra) y sobre alucinaciones en todos los modelos.

Reflexiones más amplias

  • Muchos ven la interrupción como una advertencia sobre centralizar flujos de trabajo críticos en una sola API de IA.
  • Algunos predicen un futuro de modelos integrados/en local y capas de abstracción multi‑proveedor; otros señalan el riesgo de dependencia a largo plazo y atrofia de habilidades, especialmente para desarrolladores junior.