DeepSeek ชดเชยเหตุ API ขัดข้องอย่างไร? ทำความเข้าใจระบบ Token Credit

DeepSeek ชดเชยเหตุ API ขัดข้องหรือไม่? DeepSeek กลับมาเปิดให้บริการอินเทอร์เฟซเว็บแชทและบริการ API สำหรับนักพัฒนาอีกครั้งในวันที่ 15 ตุลาคม 2026 หลังจากเกิดเหตุขัดข้องทางบริการเป็นเวลา 4 ชั่วโมง 53 นาที พร้อมออกประกาศชดเชยด้วยโบนัสเครดิตที่มีมูลค่าเท่ากับการใช้งาน API ย้อนหลังเจ็ดวัน เหตุการณ์ดังกล่าวเริ่มต้นขึ้นเวลา 08:11 น. และได้รับการแก้ไขเมื่อเวลา 13:04 น. ตามเวลาปักกิ่ง (00:11 ถึง 05:04 UTC) ส่งผลกระทบต่อเอนด์พอยต์ที่ตรวจสอบได้ เช่น บริการแชท, DeepSeek V4 Pro API และ DeepSeek V4.1 Flash API แม้ว่าการจัดสรรเครดิตย้อนหลังนี้จะช่วยบรรเทาภาระค่าใช้จ่ายในรอบบิลถัดไปโดยตรง แต่ก็ไม่สามารถชดเชยคำขอแบบเรียลไทม์ที่ไม่ได้รับบริการหรือเวลาหยุดทำงานที่ผู้ใช้งานต้องเผชิญได้ สำหรับทีมวิศวกรรมซอฟต์แวร์ที่ดูแลภาระงานในระบบจริง ความผิดพลาดทางปฏิบัติการนี้ตอกย้ำถึงความจำเป็นในการก้าวข้ามการพึ่งพาผู้ให้บริการรายเดียว ไปสู่สถาปัตยกรรมระบบสำรองข้อมูลฝั่งแบ็กเอนด์ของแอปพลิเคชันที่มีโครงสร้างชัดเจน

ปัญหาเชิงปฏิบัติการและอุปสรรคด้านต้นทุน: DeepSeek ชดเชยเหตุ API ขัดข้องในทุกเอนด์พอยต์ที่ตรวจสอบ

สรุปสาระสำคัญ

• DeepSeek เกิดเหตุขัดข้องเป็นเวลา 4 ชั่วโมง 53 นาที ในวันที่ 15 ตุลาคม 2026 ส่งผลกระทบต่อบริการเว็บแชท, แอปพลิเคชันมือถือ และบริการ API สำหรับรุ่น V4 Pro และ V4.1 Flash ที่มีการตรวจสอบสถานะ
• แพลตฟอร์มประกาศมอบโบนัสเครดิตที่มีมูลค่าเท่ากับการบริโภคที่มีการเรียกเก็บเงินของบัญชีนักพัฒนาแต่ละรายตั้งแต่วันที่ 8 ตุลาคม ถึง 14 ตุลาคม 2026 โดยจะถูกนำไปเติมเข้ายอดคงเหลือในบัญชีโดยอัตโนมัติ
• โบนัสเครดิตจะถูกใช้งานก่อนยอดเงินสดในรอบบิล API ถัดไป ซึ่งช่วยบรรเทาค่าใช้จ่ายย้อนหลัง แทนที่จะเป็นการคืนเงินสดหรือรับประกันธุรกรรมที่ไม่สามารถให้บริการได้

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

อ้างอิงจากรายงานของ The Paper เกี่ยวกับการกู้คืนบริการของ DeepSeek ผู้ใช้เริ่มสังเกตเห็นประกาศ "เซิร์ฟเวอร์ไม่สามารถใช้งานได้ชั่วคราว" บนเว็บและอินเทอร์เฟซโปรแกรมในช่วงเวลาเร่งด่วนยามเช้าของเอเชีย ส่วนประกอบที่มีการตรวจสอบเริ่มรายงานว่าบริการลดประสิทธิภาพลงไม่นานหลังเวลา 08:00 น. ตามเวลาปักกิ่ง ส่งผลให้บริการ API หลักหยุดชะงักอย่างสมบูรณ์ก่อนที่ทีมวิศวกรรมจะแก้ไขเหตุการณ์ได้สำเร็จเมื่อเวลา 13:04 น. ตามเวลาปักกิ่ง

ภายหลังการกู้คืนระบบ DeepSeek ได้เผยแพร่วิธีการกู้คืนบริการและประกาศการชดเชยอย่างเป็นทางการ แทนที่จะออกคูปองแบบเท่ากันทั้งหมด บริษัทได้กำหนดโครงสร้างการชดเชยตามกิจกรรมของบัญชีก่อนหน้า บัญชีนักพัฒนาที่มีสิทธิ์ได้รับโบนัสเครดิตตรงตามยอดเรียกเก็บเงินจริงตั้งแต่วันที่ 8 ตุลาคม ถึง 14 ตุลาคม 2026 ข้อกำหนดระบุว่าโบนัสเครดิตเหล่านี้จะถูกฝากเข้ายอดคงเหลือของผู้ใช้โดยตรง และจะถูกหักออกก่อนเงินสำรองในรอบการเรียกเก็บเงินในอนาคต

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

สาเหตุเชิงโครงสร้างและสายคำขอที่ไม่ใช่ภาพ: การประเมินการพึ่งพาจุดเดียว

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

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

แผนภาพด้านล่างแสดงตัวอย่างสถานการณ์ความล้มเหลวที่เปรียบเทียบระหว่างการตั้งค่าแบบผู้ให้บริการรายเดียวกับสถาปัตยกรรมอ้างอิงแบบหลายผู้ให้บริการระดับแอปพลิเคชัน:

[ Fragile Single-Provider Dependency ]
  Client Request ──> App Backend ──> DeepSeek API ──> (Incident: 5xx / Timeout) ──> Request Aborted

[ Decoupled Multi-Provider Routing (Illustrative) ]
  Client Request ──> App Backend ──> Smart Routing Layer
                                          │
                                          ├─ (Primary Route: Error / Timeout)
                                          │         │
                                          │         ▼
                                          └─ (Failover Attempt) ──> Secondary Provider ──> Conditional Response

บันทึกของแพลตฟอร์มบน หน้าสถานะของ DeepSeek บันทึกเหตุการณ์การดำเนินงานในอดีตในช่วงเวลาการตรวจสอบต่างๆ ซึ่งแสดงให้เห็นถึงประสิทธิภาพที่ลดลงเป็นครั้งคราวควบคู่ไปกับเหตุการณ์บริการหยุดชะงักครั้งใหญ่ แม้ว่าแดชบอร์ดสถานะสาธารณะจะแสดงตัวชี้วัดสุขภาพของส่วนประกอบแบบเรียลไทม์ แต่ก็ไม่ได้ทำหน้าที่เป็นการเปิดเผยสถาปัตยกรรมอย่างละเอียดหรือเป็นเกณฑ์มาตรฐานเวลาทำงานในอดีตในช่วงเวลาที่ไม่มีกำหนด

สำหรับองค์กรด้านวิศวกรรม การจัดการการพึ่งพา AI ภายนอกจำเป็นต้องปฏิบัติต่อเอนด์พอยต์ API ต้นทางเสมือนทรัพยากรเครือข่ายที่มีความผันผวน ระบบที่ออกแบบด้วยตัวตัดวงจร (Circuit Breakers), ขีดจำกัดการลองใหม่ที่มีขอบเขต และเส้นทางสำรองข้อมูล สามารถแยกข้อผิดพลาดต้นทางก่อนที่จะลุกลามไปยังผู้ใช้ปลายทางได้

การเปรียบเทียบโซลูชัน: ข้อแลกเปลี่ยนในการนำสถาปัตยกรรม AI แบบหลายผู้ให้บริการไปใช้งาน

การบรรเทาปัญหาความขัดข้องของ API โมเดล จำเป็นต้องมีความซ้ำซ้อนเชิงโครงสร้างภายในแบ็กเอนด์ของแอปพลิเคชัน เนื่องจาก DeepSeek มีอินเทอร์เฟซที่รองรับ OpenAI ซึ่งเข้าถึงได้ที่ https://api.deepseek.com นักพัฒนาจึงสามารถสร้างกลไกสำรองโดยใช้ไลบรารีไคลเอนต์มาตรฐานได้

อย่างไรก็ตาม การเปลี่ยนจากรูปแบบเชิงแนวคิดไปสู่การใช้งานที่เชื่อถือได้ จำเป็นต้องมีการจัดการกับข้อแลกเปลี่ยนทางวิศวกรรมเฉพาะด้าน:

• แอปพลิเคชันต้องตรวจสอบความถูกต้องของการกำหนดค่าสภาพแวดล้อมเมื่อเริ่มต้นระบบ เพื่อให้แน่ใจว่าข้อมูลประจำตัวและเอนด์พอยต์สำรองได้รับการแก้ไขอย่างสมบูรณ์ก่อนที่ความผิดพลาดในขณะรันไทม์จะเกิดขึ้น
• การหมดเวลาของคำขอหลักและสำรองจะต้องทำงานภายใต้งบประมาณการดำเนินการที่มีขอบเขต เพื่อป้องกันความล่าช้าที่ต่อเนื่องไปยังบริการที่เกี่ยวข้อง
• ควรปิดใช้งานวงจรการลองใหม่ระดับไคลเอนต์ภายในอินสแตนซ์ SDK เพื่อป้องกันการสะสมของความหน่วง โดยจัดการการตรวจจับความล้มเหลวและตรรกะการสำรองข้อมูลอย่างชัดเจน
• การจำแนกประเภทข้อผิดพลาดควรแยกข้อผิดพลาดในการจัดรูปแบบฝั่งไคลเอนต์ (เช่น 400 Bad Request หรือ 401 Unauthorized) ออกจากข้อผิดพลาดของโครงสร้างพื้นฐานชั่วคราว (เช่น การหมดเวลาการเชื่อมต่อ, ข้อผิดพลาด 5xx ของต้นทาง หรือขีดจำกัดอัตราการเรียกใช้ชั่วคราว)
• แอปพลิเคชันที่เรียกใช้งานเครื่องมือภายนอกหรือการดำเนินการที่ไม่สามารถทำซ้ำผลลัพธ์เดิมได้โดยไม่มีผลข้างเคียง (Non-idempotent) จะต้องป้องกันผลข้างเคียงที่ไม่ตั้งใจระหว่างความพยายามลองใหม่และการสำรองข้อมูล
• นักพัฒนาต้องตรวจสอบว่าโมเดลสำรองรักษาความเข้ากันได้ของโครงสร้างผลลัพธ์ การปฏิบัติตามคำสั่งของระบบ และขีดจำกัดหน้าต่างบริบทที่เพียงพอสำหรับภาระงานในการผลิต

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

import OpenAI from "openai";

type Msg = OpenAI.Chat.ChatCompletionMessageParam;

// Strict startup configuration validation ensuring values resolve to non-empty strings
function requireEnv(name: string): string {
  const value = process.env[name];
  if (!value || value.trim() === "") {
    throw new Error(`Missing required configuration: ${name}`);
  }
  return value;
}

const primaryApiKey = requireEnv("DEEPSEEK_API_KEY");
const fallbackApiKey = requireEnv("FALLBACK_API_KEY");
const fallbackBaseUrl = requireEnv("FALLBACK_BASE_URL");
const fallbackModelName = requireEnv("FALLBACK_MODEL");

// Set maxRetries to 0 to prevent SDK-level retry loops from compounding request latency
const primaryClient = new OpenAI({
  baseURL: "https://api.deepseek.com",
  apiKey: primaryApiKey,
  maxRetries: 0,
});

const fallbackClient = new OpenAI({
  baseURL: fallbackBaseUrl,
  apiKey: fallbackApiKey,
  maxRetries: 0,
});

function isTransientError(err: unknown): boolean {
  if (!(err instanceof OpenAI.APIError)) return false;
  const status = err.status;
  // Transient failure candidates: network/connection timeouts (status undefined), rate limits (429), or server errors (5xx)
  return status === undefined || status === 429 || status >= 500;
}

export async function chat(messages: Msg[], totalTimeoutMs: number = 25_000) {
  if (!Number.isFinite(totalTimeoutMs) || totalTimeoutMs <= 1_000) {
    throw new RangeError("totalTimeoutMs must be a finite number greater than 1000");
  }

  const startTime = Date.now();

  // Enforce bounded budget for primary attempt (e.g. up to 15 seconds)
  const primaryBudgetMs = Math.min(15_000, totalTimeoutMs);

  try {
    return await primaryClient.chat.completions.create(
      {
        model: "deepseek-flash",
        messages,
      },
      { timeout: primaryBudgetMs }
    );
  } catch (err) {
    if (!isTransientError(err)) throw err;

    const elapsedMs = Date.now() - startTime;
    const remainingBudgetMs = totalTimeoutMs - elapsedMs;

    // Abort if the remaining budget is insufficient for a network round trip
    if (remainingBudgetMs <= 1_000) {
      throw new Error("Request timeout budget exceeded prior to initiating fallback provider attempt.");
    }

    console.warn(`Primary endpoint failed (${elapsedMs}ms elapsed). Initiating secondary provider with remaining budget (${remainingBudgetMs}ms).`);

    return await fallbackClient.chat.completions.create(
      {
        model: fallbackModelName,
        messages,
      },
      { timeout: remainingBudgetMs }
    );
  }
}

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

ตารางด้านล่างเปรียบเทียบกลยุทธ์ทางสถาปัตยกรรมทั่วไปสำหรับการจัดการความพร้อมใช้งานของโมเดลต้นทาง:

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

รายการตรวจสอบทางวิศวกรรมและกำหนดการกำกับดูแล: การเพิ่มความแข็งแกร่งให้แอปพลิเคชันต่อเวลาหยุดทำงานของโมเดล

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

รายการตรวจสอบการใช้งานสำหรับนักพัฒนา

• กระทบยอดเครดิตบัญชี: เข้าสู่คอนโซลแพลตฟอร์ม DeepSeek เพื่อยืนยันว่าโบนัสเครดิตสำหรับหน้าต่างการเรียกเก็บเงินวันที่ 8–14 ตุลาคม ได้ถูกนำไปใช้กับยอดคงเหลือในบัญชีของคุณแล้ว
• ปรับเทียบการตรวจสอบการใช้จ่ายอัตโนมัติ: เนื่องจากการใช้งานครั้งต่อๆ ไปจะหักจากโบนัสเครดิตก่อนเงินสำรอง จึงควรปรับเทียบการแจ้งเตือนการเรียกเก็บเงินเพื่อตรวจสอบการใช้โทเค็นรวม แทนที่จะดูเฉพาะผลต่างของยอดเงินสดอย่างเดียว
• ตรวจสอบบันทึกข้อผิดพลาดจากเหตุการณ์: ค้นหาบันทึกคำขอของแบ็กเอนด์แอปพลิเคชันระหว่างเวลา 00:11 ถึง 05:04 UTC ของวันที่ 15 ตุลาคม 2026 โดยรวบรวมคำขอที่ถูกยกเลิกทั้งหมด การกระจายตัวของรหัสสถานะ และเวิร์กโฟลว์ของไคลเอนต์ที่ได้รับผลกระทบ
• กำหนดเวลาที่เข้มงวดและการลองใหม่ที่มีขอบเขต: กำหนดงบประมาณการหมดเวลาคำขอที่ชัดเจน (เช่น 15–20วินาที) และปิดใช้งานการลองใหม่ของ SDK ที่ไม่มีขอบเขต โดยศึกษาแนวทางการกำหนดค่าใน เอกสารการกำหนดค่า OpenAI Node SDK
• ตรวจสอบความเข้ากันได้ของสคีมาและเอาต์พุต: รันการทดสอบการผสานรวมอัตโนมัติกับโมเดลสำรอง เพื่อให้แน่ใจว่าเอาต์พุตที่มีโครงสร้าง การตรวจสอบความถูกต้องของ JSON และพารามิเตอร์การเรียกใช้เครื่องมือทำงานได้อย่างน่าเชื่อถือในผู้ให้บริการสำรอง

รายการตรวจสอบผลิตภัณฑ์และการกำกับดูแล

• สร้างการลดระดับ UI อย่างราบรื่น: ออกแบบอินเทอร์เฟซสำหรับผู้ใช้ที่แสดงสถานะสำรองข้อมูลที่เป็นประโยชน์หรือการตอบกลับที่แคชไว้ในช่วงที่โมเดลต้นทางขัดข้อง แทนที่จะแสดงหน้าต่างข้อผิดพลาดที่ไม่ได้จัดการ
• ประเมินข้อกำหนด SLA ของผู้ขายหลายราย: ตรวจสอบข้อตกลงระดับการบริการของผู้ขายและเงื่อนไขการชดเชย เพื่อให้แน่ใจว่าข้อตกลงทางการค้าสอดคล้องกับข้อกำหนดความต่อเนื่องทางธุรกิจภายในองค์กร
• ตรวจสอบความสามารถในการทำซ้ำอย่างปลอดภัย (Idempotency) ของผลข้างเคียง: ตรวจสอบว่าเวิร์กโฟลว์ของเอเจนต์อัตโนมัติหรือฟังก์ชันการเรียกใช้เครื่องมือมีการบังคับใช้คีย์ความสามารถในการทำซ้ำ เพื่อป้องกันการทำธุรกรรมภายนอกซ้ำซ้อนเมื่อคำขอเกิดการสลับไปใช้ระบบสำรอง

ผลกระทบในทางปฏิบัติและมุมมองในอนาคต

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

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

ข้อมูลอ้างอิง

• สถานะแพลตฟอร์ม DeepSeek ประวัติเหตุการณ์ DeepSeek และบันทึกการตรวจสอบส่วนประกอบ

• The Paper DeepSeek ประกาศการจัดสรรโบนัสเครดิตการใช้จ่ายเจ็ดวันเต็มหลังเหตุการณ์บริการขัดข้อง

• TechNode DeepSeek ดำเนินการแก้ไขหลังจากเหตุขัดข้องบางส่วนส่งผลกระทบต่อบริการแชทและ API

• South China Morning Post DeepSeek เสนอคืนเงินให้ผู้ใช้หลังจากประสบเหตุขัดข้องครั้งใหญ่อีกครั้ง

• แพลตฟอร์มเปิด DeepSeek เอกสารประกอบ API และแนวทางกำหนดราคาของ DeepSeek

• ที่เก็บข้อมูล OpenAI Node SDK เอกสารการกำหนดค่าไคลเอนต์ การลองใหม่ และเวลาหมดเวลา