ChatGPT 和 API 大范围故障

原文 ↗ Hacker News 讨论 ↗

ChatGPT 和 OpenAI API 的一次重大故障引发了广泛担忧：开发者、公司和个人在多快的时间里就开始依赖单一 AI 提供商来完成日常工作。评论者分享了各种备用方案——从 Azure OpenAI、Anthropic 和 Hugging Face 模型，到完全本地部署的 LLM——同时也指出了实际问题，如 embedding 不兼容、缺乏 SLA，以及支持体系不成熟。许多人认为这提醒大家应当尽快为冗余和可移植性做好设计，而另一些人则认为，最先进托管模型带来的生产力提升仍然超过了可靠性与锁定风险。

故障影响与依赖

  • 许多评论者表示自己无法工作或工作明显变慢，因为他们已经用 ChatGPT 取代了 Google/Stack Overflow 来做编码、脚本、文档和写作。
  • 有些人以玩笑方式看待这次故障（“PTO day”“辅助轮/拐杖”），但也有几位承认自己之前没意识到已经如此依赖它。
  • 也有人表示自己没受影响，因为他们不用 ChatGPT，或者仍然把知识“存放在脑子里”，有时还会对过度依赖提出反对。

替代方案与故障转移策略

  • 人们提到使用：Azure OpenAI（基本未受影响）、Anthropic Claude、Bard、通过 Azure 提供的 Kagi GPT-4、Phind、You.com、Hugging Face Spaces（例如 Zephyr），以及本地部署方案（Code Llama、Mistral、dolphin-mistral、Phind-CodeLlama）。
  • 对于 embeddings，建议包括：Azure OpenAI、Amazon Bedrock、SBERT、Instructor，以及在每个文档中存储多种 embedding 类型，以便切换。
  • 一些产品已经切换到了 Anthropic 或其他模型；另一些人指出，如果使用的是 OpenAI 特有功能（工具/function calling），这种切换会很困难。

本地与开源模型

  • 大家对自托管非常感兴趣，以避免故障和平台风险。
  • 普遍认为当前开源模型正在进步，但仍未达到 GPT-4 的质量；对于某些任务（摘要、更简单的编码、RAG）已经足够好，但还不够“通用”。
  • 硬件成本和稀缺性（例如 H100）是主要障碍；较小的模型可在消费级 GPU 上良好运行，部分甚至可在 CPU 上运行。

可靠性、SLA 与企业担忧

  • OpenAI 没有提供有意义的 SLA；几位用户提到非常糟糕的支持体验，以及持续数月都未解决的问题。
  • 一些企业正在转向 Azure OpenAI，正是为了更好的可靠性、SLA 和支持。
  • 也有人认为这只是快速增长阶段的正常现象；SLA 和稳健性会改进，但锁定风险和故障预案被低估了。

模型质量、审查与行为

  • 对新的 GPT-4 Turbo 看法不一：更便宜、更快，但在某些 NLP 任务上可能略差；也有人在低温度设置下仍报告其表现有波动。
  • 对比来看：GPT-4 常被认为整体最好；Bard 被认为在编码上较弱且过滤更激进；Claude 则被称为很好的备用选择。
  • 人们还担心内容过滤过严（尤其是暴力/战争主题），以及所有模型都存在幻觉问题。

更广泛的反思

  • 许多人认为这次故障是在警示：不要把关键工作流过度集中在单一 AI API 上。
  • 有人预测未来会出现嵌入式/本地部署模型以及多提供商抽象层；也有人指出长期依赖和技能退化的风险，尤其是对初级开发者而言。