Alibaba Model Studio เตรียมถอด DeepSeek รุ่นเก่า 10 ต.ค.—อย่าเปลี่ยนชื่อโมเดลแล้วหวังว่าผลจะเหมือนเดิม

Alibaba Cloud Model Studio ระบุว่าจะถอด deepseek-v3, deepseek-v3.1, deepseek-v3.2, deepseek-v3.2-exp, deepseek-r1, deepseek-r1-0528 และ distill บางรุ่นวันที่ 10 ตุลาคม 2026 พร้อมแนะนำ qwen3.7-plus, qwen3.7-max และ qwen3.6-flash แทนครับ เหลือไม่กี่วัน แต่ migration ที่ดีไม่ใช่แก้ model string แล้ว deploy เพราะ semantics, context, structured output, latency และราคาสามารถเปลี่ยนพร้อมกัน

ผมตรวจ ประกาศ lifecycle ของ Alibaba, รายการโมเดล Model Studio, เอกสารต้นทางของ DeepSeek API และ model cards ของ Qwen เพื่อแยกสิ่งที่ประกาศชัดจากสิ่งที่ทีมยังต้อง benchmark เอง

สรุป 30 วินาที

• วันตัดบริการที่เอกสาร Alibaba ระบุคือ 10 ตุลาคม 2026 สำหรับ model IDs หลายตัวบน Model Studio ไม่ได้แปลว่า DeepSeek upstream หยุดให้บริการทุกช่องทางในวันเดียวกัน
• Alibaba แนะนำ Qwen หลาย tier แต่ยังไม่มี mapping แบบ one-to-one ว่า workload ใดต้องย้ายไปรุ่นไหน ทีมต้องเลือกจาก quality, latency, context, region และราคา
• OpenAI-compatible endpoint ลดงานเปลี่ยน transport แต่ไม่รับประกัน tool schema, reasoning field, token counting, refusal, JSON validity หรือ prompt behavior เท่ากัน
• ต้องมี replay set ที่ไม่มีข้อมูลลับ วัด task success, factuality, structured-output pass rate, tool calls, latency percentile และ cost ต่อ successful task
• วาง canary/dual-run กับ fallback ก่อน deadline และ pin model ID ห้ามใช้ alias ที่เลื่อนไปเองระหว่างทดสอบ
• ตรวจ data residency, retention, quota และ rate limit ของ region จริง เพราะหน้าเอกสารระบุ endpoint/availability ต่างตามพื้นที่

ทำไมเกี่ยวกับคุณ

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

ทีม application ต้องสนใจ response schema และ error path ทีม ML/AI eval ต้องสนใจ regression ด้านคำตอบ ทีม platform ต้องสนใจ quota/region/observability และทีม finance ต้องวัดราคาใหม่แบบรวม retry ไม่ใช่ดูราคาต่อ token อย่างเดียว

ทำงานยังไง: มิเตอร์แท็กซี่เหมือนกัน แต่เส้นทางไม่เหมือน

API compatible เปรียบเหมือนรถสองคันใช้มิเตอร์หน้าตาคล้ายกัน เราส่งต้นทางปลายทางรูปแบบเดิมได้ แต่คนขับอาจเลือกเส้นทางต่าง ความเร็วต่าง และค่าทางด่วนต่าง โมเดลใหม่อาจ tokenize ภาษาไทยต่าง ใช้ reasoning token ต่าง หรือเข้มเรื่อง safety ต่าง จึงต้องวัดผลปลายทาง ไม่ใช่ตรวจว่า HTTP 200

เริ่มจาก inventory ทุก model ID รวม batch job, notebook, environment variable, gateway rule และ fallback ที่ซ่อนอยู่ จับคู่แต่ละ caller กับ owner/SLO แล้วสร้าง golden set จากงานจริงที่ redact แล้ว ครอบคลุม happy path, edge case, ภาษาไทย, long context, malformed input, tool failure และ refusal

สำหรับ structured output ให้ validate schema แบบ strict และบันทึกเหตุผลเมื่อ fail สำหรับ agent ให้จำลอง tool ที่ไม่มี side effect ตรวจจำนวน call, argument และ stop condition สำหรับ retrieval ให้ตรึง corpus กับ timestamp เพื่อไม่ให้ข้อมูลค้นหาที่เปลี่ยนมาปนกับผลโมเดล

เงินและผลกระทบ

ราคา token ต่ำกว่าอาจแพงกว่าหากคำตอบต้อง retry หรือ human correction มากขึ้น วัด cost per accepted task = input + cached input + reasoning/output + tool execution + retry + reviewer time แยก p50/p95 latency เพราะ tail ที่ยาวทำให้ timeout และ queue โตแม้ค่าเฉลี่ยดี

การ dual-run เพิ่มค่าใช้จ่ายชั่วคราว แต่ถูกกว่า outage วันตัดบริการ จำกัด sample ตาม risk: งานสร้างข้อความทั่วไปอาจ 5–10% ส่วน workflow ที่มี side effect ให้ shadow โดยไม่ execute tool จริงก่อน แล้ว canary tenant เล็กพร้อม kill switch

สิ่งที่ยังไม่ชัดและแหล่งข่าวพูดไม่ตรงกัน

ประกาศ Alibaba บอก model IDs และตัวเลือกแนะนำ แต่ไม่ได้ให้ equivalence matrix ของ prompt/benchmark ทุก workload และไม่ได้รับรองว่ารุ่นแนะนำใช้ parameter เดิมทั้งหมด หน้า DeepSeek upstream อธิบาย API ของบริการ DeepSeek เอง จึงใช้เทียบ semantics ได้แต่ไม่ใช่หลักฐานว่า Alibaba จะเก็บรุ่นเหล่านั้นต่อ

Qwen model cards อธิบาย capability ของโมเดล แต่ deployment บน Model Studio อาจมี serving configuration, context limit, safety layer และราคาเฉพาะ region ต่างจาก weights ที่รันเอง ต้องยึด console/docs ของ region ตอน rollout และเก็บ snapshot ของเงื่อนไขที่ใช้ตัดสินใจ

ยังไม่ชัดจากหน้าประกาศว่าหลัง deadline request ทุกแบบจะ error, reroute หรือมี grace period จึงห้ามออกแบบบนสมมติฐานว่ามีเวลาผ่อนผัน ถาม support สำหรับบัญชีสำคัญได้ แต่แผน production ควรพร้อมก่อนวันที่ระบุ

ควรทำอะไร

วันนี้ให้ freeze prompt/schema ปัจจุบัน, export baseline และเลือก candidate 2 รุ่นตาม workload พรุ่งนี้รัน offline replay แล้วแก้ incompatibility ที่ application layer จากนั้นเปิด shadow/canary พร้อม dashboard เปรียบเทียบ success, latency, cost และ refusal ก่อนขยาย traffic

ตั้ง alert เมื่อมี model ID เก่าใน logs/config และทำ deployment gate ปฏิเสธมันหลัง migration เก็บ rollback ไป candidate ที่ผ่านอีกตัว ไม่ใช่ย้อนกลับรุ่นที่จะถูกถอด ปิด dual-run เมื่อ evidence พอและลบ credential/config เก่าที่ไม่ใช้เพื่อไม่ให้เกิด zombie path

ทำ migration rehearsal แบบจับเวลาหนึ่งรอบก่อนวันจริงครับ เริ่มจากสร้าง traffic manifest ว่า request ชนิดใดวิ่งผ่าน gateway ไหน ใช้ region ใด และใครเป็นคนอนุมัติ จากนั้นบังคับ candidate ให้รับงานใน staging โดยปิด fallback รุ่นเก่า ถ้า staging ผ่านแต่ production canary ล้ม ทีมจะเห็นว่า failure อยู่ที่ quota, network, credential หรือ serving configuration ไม่ใช่เหมารวมว่า “โมเดลตอบไม่ดี”

เกณฑ์รับควรผูกกับงาน ไม่ใช่คะแนน benchmark ก้อนเดียว งานสรุปภาษาไทยดู factual coverage กับ citation งานจัดหมวดดู confusion matrix งานสร้าง JSON ดู schema-valid rate งาน agent ดู tool choice, argument, จำนวนรอบ และ side effect ที่ถูกปฏิเสธ บันทึกตัวอย่างแพ้ของแต่ละ candidate เพื่อให้ reviewer เห็น trade-off จริง หากรุ่นหนึ่งถูกกว่าแต่พลาดเคสกฎหมายหรือการเงินบ่อยกว่า ก็ไม่ใช่ตัวแทนที่เหมาะกับทุก route

วันที่สลับ traffic ให้มีคนรับผิดชอบ dashboard และ rollback โดยตรง ตั้ง freeze กับ prompt และ orchestration ที่ไม่เกี่ยวข้องเพื่อลดตัวแปร เปิด 5% แล้วรอ observation window ที่ครอบทั้งงานสั้น งานยาว และ batch ก่อนขยับเป็น 25%, 50% และ 100% แต่ละขั้นต้องตรวจ error rate, p95 latency, token usage, refusal, schema failure และ reviewer override หากเกิน budget ข้อใดให้ย้อน candidate สำรองที่ผ่านแล้ว ไม่ย้อน model ID ที่กำลังถูกถอด

หลังครบ 100% อย่าเพิ่งประกาศจบ ค้น repository, secret manager metadata, scheduler, dashboard และ saved notebook อีกรอบเพื่อหา model ID เก่า แล้วเฝ้า log อย่างน้อยหนึ่งรอบธุรกิจเต็ม เพราะ batch รายสัปดาห์อาจยังไม่ตื่นในช่วง canary สุดท้ายจึงปิด quota/credential เก่าและแนบหลักฐาน migration เข้ากับ runbook รอบถัดไป

Recap

• inventory model ID ทุกจุด รวม batch/fallback/notebook
• สร้าง golden set และวัด task success ไม่ใช่ HTTP 200
• ตรวจ schema, tools, safety, token counting, region และ quota
• ทำ shadow/canary พร้อม kill switch ก่อน 10 ตุลาคม
• วัด cost ต่อ successful task รวม retry และ reviewer time
• ลบ model ID เก่าและมี config gate กันกลับมา

เส้นตายนี้ควรถูกมองเป็น migration event ครับ ไม่ใช่การ rename หากทีมพิสูจน์ output contract และ operational boundary ก่อนสลับ traffic วันตัดบริการจะเป็นเพียงการปิดรางเก่า ไม่ใช่วันที่ต้องลุ้นว่ารางใหม่ต่อครบหรือยัง