ChatGPT, Claude และ Grok ล่มพร้อมกัน 3 ก.ย.: รู้สาเหตุแค่ไหน และทำไมธุรกิจไม่ควรฝากความหวังไว้กับ AI รายเดียว

ภาพที่ผู้ใช้เห็นในวันที่ 3 กันยายน 2026 คือบริการ AI รายใหญ่หลายรายใช้การไม่ได้ไล่เลี่ยกัน ทั้ง ChatGPT และ Codex ของ OpenAI, ผลิตภัณฑ์ Claude ของ Anthropic และ Grok ของ xAI แต่ข้อสรุปที่รอบคอบกว่าคำว่า “AI ทั้งอินเทอร์เน็ตล่ม” คือ เป็นเหตุขัดข้องหลายเหตุการณ์ที่ช่วงเวลาซ้อนกัน โดยแต่ละบริษัทระบุสาเหตุไม่เหมือนกัน และยังไม่มีการยืนยันต้นเหตุร่วมเดียว 334148

เกิดอะไรขึ้นบ้างในวันนั้น

เวลาจากสถานะผู้ให้บริการและรายงานภายนอกอาจไม่ตรงกันทุกจุด แต่ช่วงเหตุการณ์อธิบายได้ว่าทำไมผู้ใช้จึงรู้สึกว่าบริการล่มพร้อมกัน

• Grok: บันทึกเหตุของ xAI ระบุช่วงปัญหาตั้งแต่ 13:30–17:05 UTC ภายหลังมีรายงานว่า xAI เชื่อมโยงเหตุนี้กับการขัดข้องที่ศูนย์ประมวลผลในเมืองเมมฟิส 48
• Claude: Anthropic รายงานอัตราคำขอผิดพลาดสูงกว่าปกติ ครอบคลุม Claude หลายโมเดลและหลายบริการ ได้แก่ Claude.ai, API, Claude Code และ Claude Cowork ก่อนแก้ไขได้ภายใน 16:16 UTC หรือกินเวลาราว 3 ชั่วโมง 104148
• ChatGPT และ Codex: OpenAI ระบุว่า ความผิดพลาดในการกำหนดเส้นทางระบบ (routing error) ซึ่งเริ่มราว 07:43 น. เวลาแปซิฟิก ทำให้ผู้ใช้บางส่วนเข้า ChatGPT และ Codex ไม่ได้บนหลายแพลตฟอร์ม โดยเริ่มใช้วิธีแก้ไขสำเร็จราว 08:17 น. และติดตามผลต่อ 41

อาการที่ผู้ใช้รายงานมีตั้งแต่ล็อกอินไม่ผ่าน แชตใช้งานไม่ได้ ส่งพรอมป์ต์แล้วล้มเหลว ไปจนถึงปัญหาบนเว็บและแอป รายงานอ้างอิง Downdetector พบการแจ้งปัญหาเกี่ยวกับ ChatGPT มากกว่า 43,000 รายการราว 20:00 น. ตามเวลาอินเดีย ขณะที่ Claude กระทบทั้งผู้ใช้ทั่วไปและนักพัฒนาที่เรียกผ่าน API 2339

บริษัทต่าง ๆ บอกว่าอะไรคือสาเหตุ

คำอธิบายที่เปิดเผยต่อสาธารณะชี้ว่า ไม่ควรสรุปว่าเป็นเหตุระบบเดียวกัน

OpenAI: โฆษกของบริษัทระบุว่า ChatGPT และ Codex มีปัญหาจาก routing error ภายในโครงสร้างพื้นฐานของ OpenAI 41

Anthropic: สถานะสาธารณะระบุว่า Claude มีปัญหาด้านโครงสร้างพื้นฐาน และยืนยันว่าเกิดข้อผิดพลาดสูงในหลายโมเดลและหลายบริการ แต่ข้อมูลที่มีไม่ได้ระบุชิ้นส่วนเฉพาะที่ล้มเหลว 3948

xAI: รายงานภายหลังเหตุการณ์ระบุว่า Grok ได้รับผลกระทบจากเหตุขัดข้องที่ศูนย์ประมวลผลของบริษัทในเมมฟิส 48

คำอธิบายเหล่านี้ไม่ได้ปิดความเป็นไปได้ของจุดพึ่งพาร่วมทั้งหมด แต่ก็ ไม่ได้พิสูจน์ ว่ามีสาเหตุร่วมเดียวกัน

Azure หรือผู้ให้บริการโครงสร้างพื้นฐานร่วมเป็นต้นเหตุหรือไม่

คำตอบคือ ยังยืนยันไม่ได้ ไม่มีหลักฐานสาธารณะในข้อมูลที่ให้มาว่า Microsoft Azure, ผู้ให้บริการเครือข่าย, CDN, ระบบยืนยันตัวตน หรือซัพพลายเออร์รายอื่น เป็นสาเหตุของเหตุขัดข้องทั้งหมดในวันที่ 3 กันยายน

มีรายงานร่วมสมัยที่ตั้งข้อสังเกตถึง Azure เพราะให้บริการคลาวด์แก่บริษัทที่เกี่ยวข้อง แต่การมีผู้ให้บริการร่วมกันไม่ใช่หลักฐานเชิงเหตุและผล 42 เหตุขัดข้องที่เกิดใกล้กันอาจเป็นเหตุอิสระต่อกันได้ โดยเฉพาะเมื่อการประเมินอิงกับรายงานจากผู้ใช้ ไม่ใช่บันทึกเหตุทางเทคนิคชุดเดียวกัน

ดังนั้น ข้อสรุปที่เหมาะสมคือ สมมติฐานเรื่องโครงสร้างพื้นฐานร่วมยังไม่ได้รับการยืนยัน การกล่าวว่า Azure ล่มในภูมิภาคหนึ่งแล้วทำให้ทุกบริการล่ม จึงไม่ควรถูกมองเป็นข้อเท็จจริงจนกว่าจะมีคำยืนยันโดยตรงจากผู้ให้บริการหรือรายงานวิเคราะห์สาเหตุหลังเหตุการณ์ (postmortem)

แล้วประเด็น Anthropic กับ Colossus 1 ล่ะ

ข้อมูลที่มีไม่เพียงพอจะยืนยันทั้งขอบเขตการเข้าถึง Colossus 1 ของ Anthropic หรือยืนยันว่าเส้นทางให้บริการ Claude แก่ผู้ใช้จริงพึ่งพาศูนย์ดังกล่าวในช่วงเวลาที่เกิดเหตุหรือไม่ การที่ Grok มีเหตุขัดข้องในเมมฟิสเพียงอย่างเดียว จึงยังไม่แสดงว่าเป็นสาเหตุของปัญหา Claude 48

ในเชิงการวิเคราะห์ความน่าเชื่อถือของระบบ ข้อตกลงใช้กำลังประมวลผลเชิงพาณิชย์—even หากได้รับการยืนยัน—ก็ไม่ใช่หลักฐานว่าบริการที่ผู้ใช้เผชิญหน้ากำลังรันอยู่บนทรัพยากรนั้นในวินาทีที่ระบบล่ม

รายงาน ChatGPT มีปัญหาในอินเดียวันที่ 7 กันยายน รู้แน่ชัดอะไรบ้าง

วันที่ 7 กันยายน มีรายงานปัญหา ChatGPT อีกระลอก โดยข้อร้องเรียนส่วนใหญ่เกี่ยวข้องกับการสร้างเนื้อหา ขณะที่บางส่วนพบปัญหาบนเบราว์เซอร์และแอป รายงานหนึ่งบันทึกการแจ้งปัญหาราว 261 รายการ และระบุว่าปัญหาการสร้างเนื้อหาเป็นสัดส่วนหลัก 19

แต่ข้อมูลดังกล่าว ยังไม่ยืนยัน ว่าเป็นเหตุล่มทั่วประเทศอินเดียอย่างต่อเนื่อง ไม่ได้ระบุสาเหตุราก และไม่ได้เชื่อมโยงกับเหตุเมื่อวันที่ 3 กันยายน เครื่องมือตรวจสอบภายนอกยังรายงานว่าเข้าถึง ChatGPT ได้โดยไม่พบความผิดปกติราว 03:07 UTC ของวันนั้น ซึ่งสอดคล้องกับความเป็นไปได้ว่าเป็นปัญหาบางส่วน เป็นช่วง ๆ หรือกระทบต่างกันตามพื้นที่ มากกว่าจะเป็นหลักฐานของเหตุล่มทั่วประเทศต่อเนื่อง 22

บทเรียนสำหรับธุรกิจ: ใช้หลายโมเดล ไม่ได้แปลว่าระบบทนทานเสมอไป

เหตุการณ์นี้สะท้อนว่าเวิร์กโฟลว์ที่พึ่ง AI อาจหยุดชะงักได้รวดเร็ว ไม่ว่าจะเป็นงานบริการลูกค้า การพัฒนาซอฟต์แวร์ งานวิจัย การประมวลผลเอกสาร หรือระบบเอเจนต์อัตโนมัติ การสมัครใช้หลายผู้ให้บริการช่วยลดความเสี่ยงจากผู้ขายรายเดียว แต่ไม่รับประกันความต่อเนื่อง หากบริการเหล่านั้นพึ่งโครงสร้างพื้นฐาน เครือข่าย ระบบล็อกอิน เบราว์เซอร์ หรือจุดเชื่อมต่อเดียวกัน

แนวทางที่ควรมีในระบบงานสำคัญ ได้แก่

• ทางเลือกทำงานด้วยคนและคิวงานที่กู้คืนได้: อย่าให้คำขอที่ล้มเหลวสูญหายโดยไม่สามารถประมวลผลซ้ำ
• กลไกสลับผู้ให้บริการ: ส่งงานที่เหมาะสมไปยังโมเดลอีกค่ายได้ แต่ต้องเผื่อกรณีหลายค่ายได้รับผลกระทบพร้อมกัน
• การเรียก API แบบป้องกันความผิดพลาด: กำหนด timeout, retry แบบหน่วงเวลา, circuit breaker และงานที่ทำซ้ำได้โดยไม่สร้างผลซ้ำซ้อน
• โหมดทำงานลดระดับ: ระบุล่วงหน้าว่างานใดเดินต่อได้โดยไม่ต้องใช้โมเดลระดับแนวหน้า เช่น ใช้กฎพื้นฐาน คำตอบที่แคชไว้ เลื่อนการส่งมอบ หรือให้คนตรวจทาน
• การมอนิเตอร์และบันทึกเหตุที่เป็นอิสระ: ดูทั้งหน้าสถานะของผู้ให้บริการและการทดสอบจากระบบของตนเอง พร้อมเก็บบันทึกว่าผู้ให้บริการ โมเดล หรือจุดเชื่อมต่อใดล้มเหลว

ประเด็นสำคัญไม่ใช่ว่าเหตุล่มพร้อมกันทุกครั้งต้องมี “ต้นเหตุลับ” ร่วมกัน แต่ธุรกิจควรออกแบบและทดสอบแผนรับมือสำหรับความเป็นไปได้นั้น ก่อนเกิดเหตุครั้งถัดไป