Ox Alpha โมเดล AI นิรนามตัวใหม่ ปรากฏตัวขึ้นบน OpenRouter แพลตฟอร์มรวมโมเดล AI เมื่อวันที่ 20 สิงหาคม 2026 ด้วยสเปกระดับท็อป ทั้ง Context Window ใหญ่ถึง 1 ล้าน Token (หน่วยนับปริมาณข้อความของ AI) รองรับข้อมูลนำเข้าทั้งภาพและวิดีโอ แถมยังเปิดให้ใช้งานฟรี ทว่าในช่องผู้พัฒนาหรือ Provider ที่ควรจะระบุชื่อแล็บ กลับลงไว้เพียงคำว่า Stealth

โมเดลลักษณะนี้ในวงการเรียกกันว่า Stealth Model หรือโมเดลที่ปล่อยออกมาทดสอบบนแพลตฟอร์มโดยไม่เปิดเผยชื่อผู้สร้าง ในปี 2026 มีโมเดลแนวนี้ปล่อยออกมาแล้วถึง 4 ตัว ได้แก่ Pony Alpha, Hunter Alpha, Elephant Alpha และ Owl Alpha ซึ่งทุกตัวล้วนมาในรูปแบบเดียวกันคือ ปล่อยออกมาแบบนิรนาม ให้นักพัฒนาช่วยกันแกะรอยว่ามาจากค่ายไหน ก่อนที่ค่ายผู้พัฒนาจะเปิดตัวอย่างเป็นทางการในอีกไม่กี่วันหรือไม่กี่สัปดาห์ถัดมา

ตอนนี้ Ox Alpha ก็กำลังอยู่ในวงจรนี้ แม้หลักฐานทางเทคนิคเกือบทั้งหมดจะชี้ไปที่แล็บเดียวกัน แต่ก็ยังไม่มีค่ายไหนออกมายืนยันอย่างเป็นทางการ คำตอบว่าใครสร้างอาจเฉลยก่อนสิ้นเดือนนี้ แต่สิ่งที่สำคัญและมีประโยชน์ยาวนานกว่าคำเฉลย คือ วิธีอ่านและประเมินโมเดลนิรนาม ว่าน่าเชื่อถือแค่ไหน ตั้งแต่วิธีดูคะแนน Benchmark ที่แชร์กันว่อนเน็ต ไปจนถึงการเช็กว่า Log ข้อมูลที่เราส่งเข้าไปจะไปตกอยู่ที่ใคร

Stealth Model ทำงานอย่างไร และค่าย AI ได้อะไรกลับไป

กลไกของ Stealth Model ตรงไปตรงมากว่าที่คิด แล็บผู้พัฒนาจะนำโมเดลไปฝากไว้กับโฮสต์บน OpenRouter โดยตั้งโค้ดเนมขึ้นมาแทนชื่อจริง ช่อง Provider บนหน้าเว็บจึงแสดงแค่คำว่า "Stealth" ขณะที่ OpenRouter ทำหน้าที่เป็นตัวกลางส่งต่อคำขอใช้งานเท่านั้น ไม่ได้เป็นเจ้าของหรือผู้พัฒนาโมเดลแต่อย่างใด

สิ่งที่แล็บได้กลับไปเต็มๆ คือ "ทราฟฟิกการใช้งานจริง" ช่วงพรีวิวจึงมักเปิดให้ใช้ฟรี เพราะโมเดลที่ทั้งเก่งและฟรีจะดึงดูดผู้ใช้เข้ามาทดสอบได้อย่างมหาศาลในเวลาอันรวดเร็ว เพียงไม่กี่วันแรกที่ Ox Alpha ปล่อยออกมา ผู้ใช้งานสองรายที่ส่งคำขอเข้ามามากที่สุด ยิงข้อมูลเข้าไปเกือบ 9,000 ล้าน Token ต่อราย ซึ่งเป็นชุดข้อมูลพฤติกรรมการใช้งานจริงและการทดสอบรับโหลดหนักระดับที่แล็บหาซื้อไม่ได้ แถมยังได้ข้อมูลเหล่านี้มาก่อนวันเปิดตัวจริงที่ต้องติดป้ายราคา

ขณะเดียวกัน ฝั่งนักพัฒนาก็เริ่มแกะรอยกลับ โดยนักวิจัยอิสระจะส่งชุดทดสอบหลากหลายรูปแบบเข้าไปเพื่อหา "ลายนิ้วมือทางเทคนิค" ของโมเดล เช่น ระบบตัดคำ Tokenization วิธีคำนวณ Token ของวิดีโอ รูปแบบ Error Code ที่ระบบส่งกลับมา ไปจนถึงความถี่และสไตล์การใส่อีโมจิในคำตอบ ลายนิ้วมือทางเทคนิคเหล่านี้ปลอมแปลงได้ยากมาก เพราะแม้แล็บจะเปลี่ยนชื่อโมเดลได้ในพริบตา แต่โครงสร้างการตัดและแปลง Token ภายในไม่สามารถเปลี่ยนได้ง่ายๆ ถ้าไม่เทรนโมเดลใหม่ทั้งตัว

ที่ผ่านมา เส้นทางของโมเดลนิรนามล้วนจบลงในรูปแบบเดียวกัน:

จะเห็นว่าโมเดล 4 ตัวแรกล้วนมาจากแล็บ AI ฝั่งจีนทั้งหมด พอ Ox Alpha ปรากฏตัว หลายคนจึงพุ่งเป้าไปที่ค่ายจีนตั้งแต่วันแรก ไม่ใช่เพราะอคติ แต่เพราะสถิติที่ผ่านมาออกมาในรูปแบบนี้ชัดเจน

สเปกจริงของ Ox Alpha: ตัวเลขไหนคงที่ ตัวเลขไหนเปลี่ยนไปทุกวัน

เริ่มจากเรื่องชื่อเป็นอันดับแรก เพราะถ้าพิมพ์ผิดจะค้นหาไม่เจอแน่นอน Slug หรือชื่อโมเดลบนระบบคือ stealth/ox-alpha โดยสะกดว่า ox (ตัวอักษร O-X) ไม่ใช่ 0x (ศูนย์-เอ็กซ์) ถ้าเผลอพิมพ์เป็นเลขศูนย์ จะกลายเป็นคนละตัวทันที ทั้งในช่องค้นหาและในโค้ด API

สเปกหลักที่คงที่ ดูได้จากหน้าโมเดล Ox Alpha บน OpenRouter โดยตรง:

• Context Window: 1,048,576 Token (~1M Token)
• Max Output: ตอบกลับได้สูงสุด 131,072 Token ต่อหนึ่งคำขอ
• Modalities: รองรับข้อมูลนำเข้าทั้งข้อความ ภาพ และวิดีโอ (ส่วนคำตอบที่ส่งกลับเป็นข้อความล้วน)
• Features: รองรับคำสั่งเรียกใช้เครื่องมือภายนอกอย่าง Function Calling และ Tool Calling ตามมาตรฐานเดียวกับ OpenAI และสามารถสั่งเปิดขั้นตอนการคิดได้ผ่านพารามิเตอร์ reasoning
• ราคา: $0 ทั้งฝั่งส่งข้อมูลเข้าและรับคำตอบ (เปิดให้ใช้ฟรีในช่วงทดลอง)

Context 1 ล้าน Token มีประโยชน์อย่างไรในทางปฏิบัติ? ช่วยให้เราแนบโค้ดทั้งโปรเจกต์หรืออัปโหลดวิดีโอยาวๆ เข้าไปได้ในคำขอเดียว โดยไม่ต้องเสียเวลาหั่นเป็นก้อนย่อยๆ แล้วนำคำตอบมาปะติดปะต่อเอง

สิ่งที่ไม่ได้เพิ่มตาม Context 1 ล้าน Token คือความยาวของข้อความตอบกลับ เพราะต่อให้ป้อนข้อมูลเข้าไปมหาศาลแค่ไหน คำตอบสูงสุดก็ยังจำกัดไว้ที่ 131,072 Token และพารามิเตอร์ response_format สำหรับสั่งให้ตอบเป็น JSON ก็ไม่ได้บังคับตาม JSON Schema แบบเคร่งครัดหรือ Structured Outputs ดังนั้นถ้าระบบของเราต้องการโครงสร้าง JSON ที่แน่นอน 100% ทุกครั้ง จึงยังต้องเขียนโค้ดตรวจสอบความถูกต้องของผลลัพธ์เองอยู่ดี

ส่วนตัวเลขอีกกลุ่มบนหน้าเดียวกันจะเปลี่ยนแปลงอยู่ตลอดเวลา ณ วันที่ 23 สิงหาคม หน้าเว็บแสดง Throughput อยู่ที่ 22 Token/วินาที ค่า Latency 6.09 วินาที และ Availability ของ Endpoint อยู่ที่ 87.6% ขณะที่คนที่เปิดดูก่อนหน้านั้นหนึ่งวันเห็นค่าอยู่ที่ 96.79% ส่วนค่า Uptime บนหน้าเดียวกันขึ้นว่า 99.99% สาเหตุที่ตัวเลขไม่เท่ากันเพราะทั้งสองค่าวัดคนละขอบเขต โดย Uptime นับช่วงเวลาที่มีโฮสต์พร้อมตอบคำขอ ส่วน Availability นับเฉพาะคำขอที่ส่งข้อมูลสำเร็จจริง

อีกจุดที่มักสร้างความสับสนคือวันที่ปล่อยโมเดล บนหน้าเว็บระบุ Release Date เป็นวันที่ 21 สิงหาคม 2026 แต่มีคนพบโมเดลนี้ตั้งแต่วันที่ 20 สิงหาคม ซึ่งไม่ใช่เรื่องผิดปกติ แค่วันที่บันทึก Deployment ในระบบกับวันที่เปิดให้คนทั่วไปเห็นไม่ตรงกัน ทั้งนี้ คาดว่าช่วงเปิดให้ใช้งานฟรีจะยาวราว 1 สัปดาห์ หรือจนถึงประมาณวันที่ 27 สิงหาคม 2026

80% บน DeepSWE แปลว่าอะไรกันแน่

ตัวเลขที่ทำให้ Ox Alpha กลายเป็นกระแสไวรัลชั่วข้ามคืน คือคะแนนความแม่นยำ 80% บน DeepSWE ซึ่งเป็นชุดทดสอบการแก้โจทย์เขียนโปรแกรมจริง 113 ข้อ ตัวเลขนี้เริ่มแชร์กันเมื่อวันที่ 21 สิงหาคม พร้อมตารางเปรียบเทียบว่าโมเดลเรือธงตัวอื่นๆ ภายใต้เงื่อนไขเดียวกันทำได้เพียง 52% ถึง 65% เท่านั้น

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

และเมื่อนักวิจัยคนเดิมนำโมเดลไปทดสอบกับชุดโจทย์เต็ม 113 ข้อ คะแนนเฉลี่ยจริงกลับลดลงมาอยู่ที่ราว 63% ซึ่งใกล้เคียงกับ GPT-5.6 Sol รุ่นระดับกลาง ตัวเลขนี้ลดลงจากพาดหัวข่าวเดิมเกือบ 20 คะแนน โดยผู้ทดสอบเองก็ระบุว่า ผลลัพธ์จากชุดทดสอบเต็ม 113 ข้อ สะท้อนประสิทธิภาพที่แท้จริงได้ดีกว่า

นอกจากนี้ อีกจุดที่คนมักเข้าใจผิดคือ ชื่อชุด Benchmark เพราะ DeepSWE ไม่ใช่ชุดทดสอบ SWE-bench Verified ที่โมเดลเรือธงใช้โชว์คะแนนระดับ 96% ทั้งสองชุดเป็นคนละข้อสอบและมีความยากต่างกัน จึงนำมาเทียบกันตรงๆ ไม่ได้ การเห็นตัวเลข 80% แล้วเข้าใจว่าเก่งเกือบเท่า 96% ของ SWE-bench จึงเป็นการเทียบผิดคู่มาตั้งแต่ต้น

เรื่องนี้ยิ่งเห็นภาพชัดขึ้นเมื่อดูอีก Benchmark บนลีดเดอร์บอร์ด Kingbench ที่มีคลิปบันทึกผลการทดสอบ พบว่า Ox Alpha ทำคะแนนได้ 87.5% ขณะที่ GLM-5.3 จากค่าย Zhipu ทำได้ 91.25% ทั้งที่ในชุดย่อยของ DeepSWE ก่อนหน้านี้ Ox Alpha เคยนำ GLM-5.3 อยู่ที่ 80% ต่อ 62% สรุปคือโมเดลคู่เดิม แต่พอเปลี่ยนชุดทดสอบ ผลลัพธ์กลับสลับข้างกันทันที

ช่องว่างระหว่าง "คะแนน Benchmark สวยหรู" กับ "การใช้งานจริง" ไม่ใช่เรื่องใหม่ในวงการ เหมือนกรณีของ GLM 5.2 ที่เคยทุบสถิติ Benchmark แต่สุดท้ายเขียนเกมที่เดินไม่ได้จริง ซึ่งเจอปัญหาจากการวัดผลลักษณะเดียวกัน

ถึงอย่างนั้น ตัวเลขเหล่านี้ยังมีข้อมูลเชิงพฤติกรรมที่น่าสนใจซ่อนอยู่ ตัวอย่างเช่น ในโจทย์ข้อยากของ DeepSWE ที่ GLM-5.3, GPT-5.6-sol และ Grok 4.6 ทำไม่ผ่านเลยทั้ง 4 ครั้ง Ox Alpha กลับแก้โจทย์ผ่านได้ตั้งแต่รอบแรก และในการทดสอบด้าน AI Agent ที่ต้องเรียกใช้ Tool ต่อเนื่องกัน 69 ครั้ง Ox Alpha พลาดไปเพียงครั้งเดียว โดยไม่มีอาการวนลูปแก้โค้ดซ้ำที่เดิม ข้อมูลพฤติกรรมจริงเหล่านี้มีประโยชน์ต่อการประเมินมากกว่าตัวเลขบนพาดหัวข่าว เพราะสะท้อนถึงการทำงานจริงของโมเดล

ข้อสังเกตสุดท้ายคือ ตัวเลขทั้งหมดในหัวข้อนี้มาจากการทดสอบของบุคคลภายนอกทั้งสิ้น ปัจจุบัน Ox Alpha ยังไม่มีผลคะแนนอย่างเป็นทางการบนลีดเดอร์บอร์ดมาตรฐานที่ตรวจสอบย้อนกลับได้เลยสักแห่ง

ลายนิ้วมือที่ชี้ไป Zhipu เรียงตามน้ำหนักหลักฐาน

หลักฐานทางเทคนิคที่แกะรอยกันออกมาได้ เกือบทั้งหมดชี้ตรงไปที่ Zhipu AI โดยแต่ละชิ้นมีน้ำหนักความน่าเชื่อถือไม่เท่ากัน การจัดลำดับน้ำหนักหลักฐานเหล่านี้จึงเป็นทักษะสำคัญที่นำไปใช้แกะรอยโมเดลนิรนามตัวถัดไปได้ทันที

1. หลักฐานที่มีน้ำหนักมากที่สุด: ระบบคำนวณ Token ของวิดีโออย่าง Video Tokenization จากการทดสอบป้อนไฟล์วิดีโอ 4 ชุด แล้ววัดจำนวน Token ที่โมเดลใช้งาน พบว่า Ox Alpha และ GLM-5V-Turbo ให้ผลลัพธ์ตรงกัน 100% ทั้งเรื่องการสุ่มเฟรมภาพที่ไม่ขึ้นกับเฟรมเรตเดิมของไฟล์ อัตราการกิน Token คงที่ที่ประมาณ 147 Token ต่อวินาทีของความยาววิดีโอ และสูตรการคำนวณ Token ตามความละเอียดของแต่ละเฟรม ขณะที่โมเดลคู่แข่งอย่าง MiMo v2.5, Qwen 3.8 Max และ GLM-4.6V ให้ตัวเลขที่ต่างออกไปอย่างชัดเจนบนชุดทดสอบเดียวกัน

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

2. หลักฐานน้ำหนักรองลงมา: ชุดตัดคำข้อความอย่าง Tokenizer จากการทดสอบด้วย 25 คำสั่ง Prompt พบว่าจำนวน Token ของ Ox Alpha ตรงกับ GLM-5.3 เป๊ะทุกข้อ ต่างกันเพียงมี Header Token บวกเพิ่มเข้ามา 75 Token เสมอ

เมื่อขยายการทดสอบเป็น 30 ชุดข้อความที่ครอบคลุมหลากหลายภาษา ระบบตัวเขียน อีโมจิ โค้ดโปรแกรม และคำสั่ง SQL ผลลัพธ์ก็ยังตรงกับ GLM-5.3 ครบทั้ง 30 ครั้ง นอกจากนี้ เครื่องมือตรวจสอบของชุมชนนักพัฒนาที่ทดสอบ 9 ด้าน พบว่าตรงกันถึง 6 ด้าน และเมื่อคำนวณค่า Token เฉลี่ยแบบ Normalized ก็ตรงกับโมเดลตระกูล GLM ครบทั้ง 4 ด้าน ขณะที่โมเดลต้องสงสัยนอกตระกูล GLM ที่ใกล้เคียงที่สุด ตรงกันเพียง 2 ใน 4 ด้านเท่านั้น

3. หลักฐานชิ้นที่สาม: พฤติกรรมการปฏิเสธไฟล์เสียงหรือ Audio Rejection Ox Alpha ไม่รองรับข้อมูลนำเข้าประเภทไฟล์เสียง และเมื่อส่งไฟล์เสียงเข้าไป ระบบจะส่งข้อความปฏิเสธในรูปแบบเดียวกับ GLM-5V หลักฐานข้อนี้ช่วยตัดตัวเลือกออกไปได้ทันที เพราะโมเดลอย่าง MiMo v2.5 รองรับเสียงได้ ทฤษฎีที่ว่า Ox Alpha มาจากค่าย Xiaomi จึงตกไป

4. หลักฐานชิ้นที่สี่: รูปแบบข้อผิดพลาดจากเซิร์ฟเวอร์หรือ API Error Response เมื่อนักวิจัยลองยิงคำขอที่ผิดรูปแบบเข้าไป ระบบได้ส่งรายงานข้อผิดพลาดอย่าง Java Stack Trace กลับมา ซึ่งปรากฏชื่อคลาส com.wd.paas.api.domain.v4.chat.ChatCompletionRequest ตรงกับโครงสร้าง Endpoint /api/paas/v4/chat/completions ในเอกสาร API ทางการของ Zhipu ยิ่งไปกว่านั้น เมื่อทดสอบส่ง Parameter ผิดรูปแบบไปยังโมเดล z-ai/glm-5.3, glm-5.2 และ glm-5v-turbo บน OpenRouter ระบบก็ส่ง Error Code หน้าตาเดียวกันออกมาเป๊ะ คือ: {"code":"1214","message":"Incorrect role information"}

อย่างไรก็ตาม หลักฐานเรื่อง Error มีจุดที่ต้องแยกให้ออก คือไม่ได้ระบุตัวตนของ "ไฟล์โมเดล" โดยตรง แต่ระบุตัวตนของ "ผู้ให้บริการโฮสต์" สังเกตได้จากโมเดล glm-5.2 ตัวเดียวกัน ถ้านำไปรันบนแพลตฟอร์มอื่นอย่าง DeepInfra จะส่ง Error หน้าตาต่างออกไป ลายเซ็นนี้จึงบอกได้เพียงว่าหลังบ้านของ Endpoint นี้เชื่อมต่อไปยังระบบของ Zhipu ซึ่งแม้จะช่วยสนับสนุนข้อสรุปเดิม แต่ในทางเทคนิคถือเป็นคนละเรื่องกับการยืนยันตัวตนของตัวโมเดล

5. หลักฐานที่มีน้ำหนักเบาที่สุด: สไตล์และพฤติกรรมการตอบ Ox Alpha มีอัตราการใส่อีโมจิเฉลี่ยประมาณ 1.3 ตัวต่อ 1,000 ตัวอักษร ซึ่งใกล้เคียงกับสไตล์ของตระกูล GLM และ Qwen ขณะที่ Claude, GPT-5.6 และ Grok แทบไม่ใช้อีโมจิเลยภายใต้เงื่อนไขเดียวกัน อย่างไรก็ดี หลักฐานด้านสไตล์ภาษาอาจเกิดจากความบังเอิญหรือการปรับแต่ง System Prompt เลียนแบบขึ้นมาได้ จึงเป็นได้แค่เบาะแสเสริม ไม่ใช่หลักฐานชี้ขาด

แล้วทำไมถึงตัดแล็บยักษ์ใหญ่อื่นๆ ออกจากรายชื่อผู้ต้องสงสัย?

• Xiaomi (MiMo): สถาปัตยกรรมการแปลงวิดีโอไม่ตรงกัน และ MiMo v2.5 รองรับเสียง แต่ Ox Alpha ปฏิเสธเสียง
• DeepSeek: ไม่เคยมีโมเดลสายวิดีโอมาก่อน และ Tokenizer เป็นคนละตัว
• Alibaba (Qwen): ทั้ง Tokenizer และโครงสร้างประมวลผลวิดีโอไม่ตรงกับตระกูล Qwen
• xAI (Grok): สไตล์การตอบและคุณสมบัติทางเทคนิคไม่ตรงกัน
• OpenAI & Anthropic: ขัดแย้งกับหลักฐานทั้งหมด ตั้งแต่ Tokenizer, สไตล์คำตอบ ไปจนถึงโมดูลแปลงวิดีโอ

ทั้งนี้ มีข้อสันนิษฐานทางเลือกว่า Ox Alpha อาจเป็นโมเดล MAI 2 ของ Microsoft ที่ยังไม่เปิดตัว ด้วยเหตุผลว่า Tokenizer คล้ายกับ cl100k_base ของ OpenAI ซึ่งแล็บจีนไม่น่าเลือกใช้ ทว่าทฤษฎีนี้มีที่มาจากแหล่งเดียว เกิดขึ้นภายหลัง และไม่ได้อธิบายหลักฐานสำคัญชิ้นอื่นๆ เลย ทั้งเรื่องการประมวลผลวิดีโอ Java Stack Trace หรือการปฏิเสธไฟล์เสียง จึงเป็นสมมติฐานที่มีน้ำหนักน้อยกว่ามาก

จังหวะเวลาในการปล่อยโมเดลก็สอดคล้องกันพอดี: Zhipu เพิ่งเปิดตัว GLM-5.3 รุ่นที่รองรับเฉพาะข้อความเมื่อวันที่ 14 สิงหาคม พร้อมระบุว่าจะปล่อย Model Weights ให้ดาวน์โหลดหลังตรวจสอบความปลอดภัยเสร็จในอีกประมาณ 2 สัปดาห์ จากนั้นเพียง 6 วันถัดมา Ox Alpha ก็ปรากฏตัวขึ้นพร้อมฟีเจอร์ประมวลผลวิดีโอที่ GLM-5.3 เวอร์ชันสาธารณะยังไม่มี

สิ่งที่ยังต้องรอคำตอบที่ชัดเจน คือ Ox Alpha เป็นเวอร์ชันประมวลผลเร็วของ GLM-5.3 หรือเป็นโมเดล Multimodal เจเนอเรชันถัดไปในสายการพัฒนาเดียวกัน ซึ่งจุดนี้ยังเป็นเพียงการคาดการณ์

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

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

ใช้งานฟรีจริง แต่ Log ข้อมูลไม่ได้หายไปไหน

นโยบายความเป็นส่วนตัวและข้อตกลงเรื่องข้อมูลของ Ox Alpha ประกอบด้วย 3 ระดับ ซึ่งแต่ละระดับมีข้อกำหนดที่ต้องแยกให้ออก:

1. ระดับแบนเนอร์บนหน้าโมเดลของ OpenRouter: ระบุว่าผู้ให้บริการจะบันทึก Prompt และคำตอบของโมเดลตัวนี้ไว้ แต่จะไม่นำไปใช้เทรนโมเดลต่อ
2. ระดับข้อตกลงโปรแกรม Stealth Program Terms: เป็นเอกสารข้อตกลงส่วนกลางของโครงการ Stealth ทั้งหมด ซึ่งระบุว่าผู้ให้บริการมีสิทธิ์จัดเก็บเนื้อหาของผู้ใช้ เพื่อนำไปประเมิน ปรับปรุง และใช้เทรนโมเดลภายในโปรแกรมได้
3. ระดับแอปเขียนโค้ดอย่าง OpenCode: แอปเขียนโค้ดที่เชื่อมต่อกับ Ox Alpha ชี้แจงว่าฝั่งตัวแอปไม่ได้เก็บข้อมูลของผู้ใช้เลย

ข้อความทั้ง 3 ส่วนนี้ไม่ได้ขัดแย้งกันโดยตรง เพราะกำลังพูดถึงข้อมูลในคนละช่วงของ Data Pipeline โดยแบนเนอร์ระบุนโยบายเฉพาะโมเดลตัวนี้ เอกสารกลางครอบคลุมภาพรวมของโครงการ Stealth ทั้งหมด ส่วนฝั่งไคลเอนต์รับประกันเฉพาะตอนที่ข้อมูลอยู่ในแอปของตนเอง ไม่ได้รวมถึงเซิร์ฟเวอร์ปลายทางที่รันโมเดล

ดังนั้นเวลาอ่านนโยบายความเป็นส่วนตัวของ AI เราจึงต้องตั้งคำถาม 2 ข้อควบคู่กันเสมอ: ใครเป็นคนประกาศ? และ คำรับรองนั้นครอบคลุมช่วงที่ข้อมูลอยู่กับใคร?

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

ตัวเลข 100 ล้านล้าน Token ต่อวัน คือคำเคลมเรื่องขีดความสามารถของระบบเซิร์ฟเวอร์

อีกหนึ่งตัวเลขที่แชร์ต่อกันแพร่หลายไม่แพ้ 80% คือคำเคลมว่าระบบรองรับได้ถึง 100 ล้านล้าน Token ต่อวัน ฟังเผินๆ อาจนึกว่าเป็นตัวเลขวัดความเก่งของโมเดล แต่ในความเป็นจริงคือคนละเรื่องกัน

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

ถึงอย่างนั้น ยังมีเบาะแสทางเทคนิคที่ช่วยอธิบายเรื่องนี้ได้บางส่วน โดยความเร็วในการสร้างข้อความ (Decoding Speed) ของ Ox Alpha ใกล้เคียงกับ GLM-5V-Turbo ต่างกันเพียงประมาณ 6% และโมเดลตระกูล GLM-5 ใช้สถาปัตยกรรม Mixture of Experts หรือ MoE ซึ่งมีพารามิเตอร์รวมราว 744,000 ล้านพารามิเตอร์ แต่ในการประมวลผลคำตอบแต่ละครั้ง จะเปิดทำงานจริงเพียงราว 40,000 ล้านพารามิเตอร์ (Active Parameters) เท่านั้น

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

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

วิธีเชื่อมต่อ stealth/ox-alpha เข้ากับระบบ และควรวางไว้ตรงไหนเพื่อไม่ให้ระบบพัง

ในแง่เทคนิค การเชื่อมต่อนั้นทำได้ง่ายมาก เพราะ API ของ OpenRouter เข้ากันได้กับมาตรฐานของ OpenAI เพียงเปลี่ยน Base URL และระบุชื่อโมเดลเป็น stealth/ox-alpha ก็เรียกใช้งานได้ทันที:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "stealth/ox-alpha", "messages": [{"role": "user", "content": "..."}]}'

ส่วน Header เสริมอย่าง HTTP-Referer และ X-Title จะใส่หรือไม่ใส่ก็ได้ โดยมีผลเฉพาะการจัดอันดับแอปบนลีดเดอร์บอร์ดของ OpenRouter เท่านั้น และไม่มีผลต่อการตอบของโมเดล สำหรับผู้ที่ไม่เคยตั้งค่ามาก่อน ดูแนวทางการเชื่อมต่อเพิ่มเติมได้จาก วิธีตั้งค่าพา Claude Code ไปวิ่งผ่าน OpenRouter ซึ่งใช้ตัวแปร Environment Variable รูปแบบเดียวกัน

สิ่งที่ต้องให้ความสำคัญมากกว่าการต่อ API คือ การวางตำแหน่งโมเดลใน Pipeline โดยโครงสร้างที่ปลอดภัยและคุ้มค่าที่สุดในตอนนี้ คือการจัดวางเป็น โมเดลชั้นแรกควบคู่ระบบสำรอง (Fallback Guard):

1. ส่งงานให้ Ox Alpha ประมวลผลก่อน ในฐานะโมเดลฟรีที่ประสิทธิภาพสูง
2. มี Guardrail หรือ Evaluation คั่นกลางเพื่อตรวจผลลัพธ์ เช่น กำหนดให้ Test Suite ผ่านทั้งหมด ให้ Lint ไม่ฟ้อง Error หรือให้ Code Diff ไม่เกินขนาดที่กำหนด
3. ถ้าผลลัพธ์ไม่ผ่านเกณฑ์ ค่อยส่งต่องานไปยังโมเดลหลักแบบเสียเงิน

สิ่งที่ไม่ควรทำอย่างยิ่ง คือการตั้ง Ox Alpha เป็น Default Model แบบยิงตรงเข้าระบบจริงโดยไม่มีระบบตรวจสอบผลลัพธ์ โดยเฉพาะกับงานรวมโค้ดอัตโนมัติ (Automated Merge) งานตรวจสอบความปลอดภัย Security Review หรือกระบวนการที่แตะต้องข้อมูลที่กฎหมายคุ้มครอง และถ้าต้องการเตรียมโมเดลสำรองที่พฤติกรรมใกล้เคียงกันที่สุด GLM-5.3 ก็เป็นตัวเลือกที่พร้อมใช้งานได้ทันที

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

เช็คลิสต์สำหรับวิเคราะห์โมเดลนิรนามตัวถัดไป

ถ้าแนวทางการปล่อยโมเดลแบบ Stealth ยังคงดำเนินต่อไป อีกไม่นานก็จะมีโค้ดเนมใหม่ๆ โผล่ขึ้นมาอีก เราสามารถนำคำถาม 7 ข้อนี้ไปใช้ประเมินได้ทันที:

• ความครอบคลุมของผลทดสอบ: คะแนนที่แชร์กันมาจากผู้ทดสอบกี่คน ทดสอบกี่ข้อ และคิดเป็นกี่เปอร์เซ็นต์ของชุดทดสอบเต็ม?
• ความถูกต้องของ Benchmark: ชุดทดสอบที่ใช้อ้างอิง เป็นข้อสอบมาตรฐานเดียวกับที่โมเดลอื่นใช้วัดผลจริงหรือไม่ หรือแค่ชื่อคล้ายกัน?
• การทดสอบเปรียบเทียบข้ามชุด: มีผลการทดสอบจาก Benchmark อื่นที่ให้ผลลัพธ์สวนทางกันหรือไม่?
• หลักฐานมาจากส่วนไหนของระบบ: ลายนิ้วมือที่พบฝังอยู่ในสถาปัตยกรรมโมเดล เช่น Tokenizer หรือ Vision Layer หรือเป็นแค่สไตล์การตอบที่เลียนแบบกันได้?
• ต้นทางของร่องรอย: ลายนิ้วมือนั้นชี้ไปที่ค่ายผู้พัฒนาโมเดลโดยตรง หรือชี้ไปที่ฝั่งผู้ให้บริการโฮสต์เซิร์ฟเวอร์?
• ขอบเขตนโยบาย Log: ใครเป็นผู้ให้คำรับรองเรื่องความเป็นส่วนตัว และคำรับรองนั้นครอบคลุมถึงเซิร์ฟเวอร์ปลายทางหรือเฉพาะตัวแอป?
• แผนรับมือกรณีโมเดลปิดตัว: ถ้าพรุ่งนี้โมเดลนี้ปิดตัวลงหรือเริ่มคิดเงิน ระบบที่เราวางไว้จะกระทบตรงไหนบ้าง และมีแผนสำรอง (Fallback) หรือยัง?

ในอีกไม่กี่วันข้างหน้า ค่ายผู้พัฒนาน่าจะเปิดตัว Ox Alpha อย่างเป็นทางการ และกระแสข่าวของโมเดลนี้ก็จะค่อยๆ ซาลงไป แต่หลังจากนั้น โมเดลนิรนามตัวที่ 6 ตัวที่ 7 และตัวต่อๆ ไปก็จะปรากฏขึ้นมาใหม่อีกเรื่อยๆ คนที่รู้วิธีอ่านและแกะรอยหลักฐานทางเทคนิคอย่างเป็นระบบ จะคว้าความได้เปรียบได้ตั้งแต่วันแรกที่โมเดลปล่อยออกมา โดยไม่ต้องรอให้ถึงวันที่ค่ายผู้พัฒนาเฉลยตัวตน

ที่มา: เอกสารทางการของ Ox Alpha