Thinking Machines เปิดตัว Inkling? การประกาศนี้ได้รับการยืนยันอย่างเป็นทางการแล้วเมื่อ Thinking Machines Lab ได้แนะนำ Inkling ซึ่งเป็นโมเดลมัลติโมดอลแบบ open-weight ตัวแรกของบริษัท โดยออกแบบมาเพื่อแข่งขันกับ DeepSeek และระบบ AI ชั้นนำอื่นๆ แทนที่จะวางตำแหน่งโมเดลเป็น API เชิงพาณิชย์แบบปิด ทางบริษัทเน้นย้ำเรื่องการปรับแต่งสำหรับองค์กร การติดตั้งใช้งานแบบ open-weight และต้นทุนการดำเนินงานที่ต่ำลงสำหรับนักพัฒนา เนื่องจาก Inkling ถูกปล่อยออกมาภายใต้สัญญาอนุญาตแบบ Apache 2.0 นักพัฒนาในองค์กรจึงสามารถนำไปติดตั้ง แก้ไข และปรับจูน (fine-tune) ได้โดยไม่ต้องพึ่งพา API การอนุมาน (inference) แบบเฉพาะของเจ้าของแพลตฟอร์ม

เหตุผลที่ Thinking Machines เปิดตัว Inkling: ท้าทายการผูกขาดของโมเดลแบบปิด
สรุปสาระสำคัญ
- Thinking Machines Lab สตาร์ทอัพของ Mira Murati อดีต CTO ของ OpenAI ได้เปิดตัวโมเดล AI ภายในตัวแรกชื่อว่า Inkling โดยมาพร้อมกับสัญญาอนุญาตแบบ open-weight Apache 2.0
- ระบบนี้ใช้โครงสร้างแบบ Mixture-of-Experts (MoE) ที่มีพารามิเตอร์รวม 975 พันล้านพารามิเตอร์ (ใช้งานจริง 41 พันล้านต่อการประมวลผลหนึ่งงาน) ฝึกฝนด้วยข้อมูล 45 ล้านล้านโทเค็น ทั้งข้อความ รูปภาพ เสียง และวิดีโอ
- ต่างจากโมเดลปิดทั่วไป Inkling ถูกออกแบบมาเป็นจุดเริ่มต้นสำหรับองค์กรในการปรับแต่งด้วยตนเองผ่าน Tinker ซึ่งเป็นแพลตฟอร์มการปรับแต่งของบริษัท
การแบ่งขั้วระหว่างโมเดลอเนกประสงค์แบบรวมศูนย์กับระบบเฉพาะทางที่ปรับแต่งได้กำลังเข้าสู่ช่วงวิวัฒนาการครั้งสำคัญ ในช่วงหลายปีที่ผ่านมา องค์กรต่างๆ เริ่มเปรียบเทียบระหว่างการใช้ API เชิงพาณิชย์กับการติดตั้งโมเดล open-weight ที่โฮสต์เองมากขึ้น Inkling เข้ามาแข่งขันในตลาดนี้โดยนำเสนอโมเดล Apache 2.0 ที่ปรับให้เหมาะสมสำหรับการปรับแต่งภายในองค์กร แทนที่จะเน้นการอนุมานบนคลาวด์แบบอเนกประสงค์
การเปิดตัว Inkling สะท้อนให้เห็นถึงการเปลี่ยนแปลงในอุตสาหกรรมไปสู่โมเดล open-weight ที่โฮสต์เองและการปรับแต่ง AI ในระดับองค์กร เมื่อบริษัทนำความลับทางการค้า ซอร์สโค้ด และข้อมูลทางการเงินไปป้อนให้กับโมเดลเชิงพาณิชย์ ก็มีความเสี่ยงที่ความรู้นั้นจะถูกดูดซับเข้าไปในโมเดลเวอร์ชันสาธารณะในอนาคต สำหรับกลุ่มวิศวกรขนาดใหญ่ การที่ Thinking Machines เปิดตัว Inkling ถือเป็นโอกาสโดยตรงในการทวงคืนการควบคุมทรัพยากรซอฟต์แวร์หลัก ดังที่อธิบายไว้ใน ประกาศอย่างเป็นทางการของ Thinking Machines

สถาปัตยกรรมทางเทคนิค: Inkling เปรียบเทียบกับ DeepSeek อย่างไร
ในระดับโปรโตคอล สถาปัตยกรรม Transformer แบบหนาแน่น (Dense) มาตรฐานจะกระตุ้นชุดพารามิเตอร์ทั้งหมดสำหรับทุกโทเค็น ส่งผลให้มีต้นทุนการประมวลผลและความหน่วง (latency) สูง เพื่อแก้ปัญหาคอขวดด้านการประมวลผลนี้ โมเดลใหม่ที่เพิ่งเปิดตัวได้ใช้การออกแบบแบบ Mixture-of-Experts (MoE) คล้ายกับ DeepSeek-V3 ของจีน แต่ละเลเยอร์ของ MoE ประกอบด้วยผู้เชี่ยวชาญ (experts) 256 คนที่ถูกกำหนดเส้นทางและผู้เชี่ยวชาญที่ใช้ร่วมกัน 2 คน โดยมีเพียง 6 คน (ประมาณ 41 พันล้านพารามิเตอร์ที่ทำงานจริง) ที่ทำงานต่อหนึ่งโทเค็น สิ่งนี้ทำให้ระบบสามารถคงฐานความรู้ขนาด 975 พันล้านพารามิเตอร์ไว้ได้โดยที่ต้นทุนการอนุมานและความหน่วงยังต่ำ
สำหรับกลไกความสนใจ (Attention Mechanism) ระบบจะสลับเลเยอร์แบบ sliding-window และแบบ global ในอัตราส่วน 5:1 โดยใช้หัวอ่านคีย์-ค่า (KV) จำนวน 8 หัว ต่างจากสถาปัตยกรรมยอดนิยมอย่าง Llama และ DeepSeek ที่ใช้ Rotary Positional Embedding (RoPE) ระบบนี้เลือกใช้ relative positional embeddings ซึ่งแสดงประสิทธิภาพการคาดการณ์ที่เหนือกว่าในการประมวลผลข้อมูลยาวสูงสุด 1 ล้านโทเค็น และต่างจาก DeepSeek-V3 ตรงที่ Inkling ถูกปล่อยออกมาภายใต้สัญญาอนุญาต Apache 2.0 แทนที่จะเป็น MIT เพื่อเจาะตลาดองค์กรที่ต้องการโมเดล open-weight พร้อมเน้นเวิร์กโฟลว์การปรับแต่งผ่าน Tinker
[สถาปัตยกรรมโมเดลหนาแน่น (Dense Model) มาตรฐาน] Input Token ──> ทำงานทุกพารามิเตอร์ (975B) ──> ต้นทุนประมวลผลสูง & มีความหน่วง [สถาปัตยกรรมแบบ Mixture-of-Experts (MoE)] Input Token ──> Sigmoid-Based Router ──> ผู้เชี่ยวชาญที่ทำงานจริง (41B) ──> ประหยัดต้นทุน, อนุมานรวดเร็ว
สำหรับการติดตั้ง MoE ขนาดใหญ่หลายแห่ง เนื่องจากประสิทธิภาพการอนุมานขึ้นอยู่กับแบนด์วิดท์หน่วยความจำมากกว่าความเร็วในการคำนวณ จึงมีการปรับเปลี่ยนไปสู่การเพิ่มประสิทธิภาพการอนุมานที่เน้นหน่วยความจำ แม้ว่าโมเดลพื้นฐานจะถูกฝึกขึ้นใหม่ทั้งหมด แต่ในขั้นตอนการฝึกหลังการเรียนรู้ (post-training) ได้ใช้ข้อมูลสังเคราะห์ที่สร้างโดยโมเดล open-weights เดิมที่มีอยู่ รวมถึง Kimi K2.5 ของ Moonshot AI ผลการทดสอบประสิทธิภาพแสดงให้เห็นว่า Inkling มีประสิทธิภาพเทียบเท่ากับ NVIDIA Nemotron 3 Ultra โดยใช้จำนวนโทเค็นเพียงหนึ่งในสาม ความสามารถเชิงโครงสร้างที่ได้รับการยืนยันเมื่อ Thinking Machines เปิดตัว Inkling แสดงให้เห็นว่าสถาปัตยกรรม MoE แบบกำหนดเองช่วยลดค่าใช้จ่ายในการดำเนินงานโดยรวมได้อย่างไร ดังที่อธิบายไว้ใน รายงานแบบจำลองการโต้ตอบของ Thinking Machines.
Inkling vs. DeepSeek-V3 โดยสังเขป
เพื่อแสดงให้เห็นถึงความแตกต่างทางเทคนิคระหว่างสถาปัตยกรรม open-weights ชั้นนำเหล่านี้ ตารางเปรียบเทียบต่อไปนี้แสดงตัวเลือกการออกแบบพื้นฐาน:
| ตัวชี้วัดทางเทคนิค | โมเดล Inkling MoE | สถาปัตยกรรม DeepSeek-V3 |
|---|---|---|
| สัญญาอนุญาต | Apache 2.0 (อิสระ) | MIT (อิสระ) |
| ขนาดพารามิเตอร์รวม | 975 พันล้านพารามิเตอร์ | 671 พันล้านพารามิเตอร์ |
| พารามิเตอร์ที่ทำงานจริง | 41 พันล้านต่อหนึ่งโทเค็น | 37 พันล้านต่อหนึ่งโทเค็น |
| ขนาดหน้าต่างข้อมูล (Context Window) | สูงสุด 1 ล้านโทเค็น | สูงสุด 128 พันโทเค็น |
| การฝังตำแหน่ง (Positional Embedding) | Relative Positional Embeddings | Rotary Positional Embedding (RoPE) |

สร้าง vs. ซื้อ: กลยุทธ์การติดตั้งใช้งาน Open-Weight
ในขณะที่ต้นทุนการดำเนินงานในการรักษา API AI อเนกประสงค์สูงขึ้น การเปิดตัว Inkling ยังกระตุ้นให้ทีมวิศวกรทบทวนกลยุทธ์โครงสร้างพื้นฐานระยะยาว การทบทวนการพึ่งพาระบบเผยให้เห็นความจริงทางการเงินที่สำคัญ: การเช่าโมเดลเฉพาะของเจ้าของแพลตฟอร์มอาจนำไปสู่กับดักการจ่ายเงินซ้ำซ้อน Satya Nadella เพิ่งโต้แย้งว่าองค์กรที่ใช้ AI เฉพาะของเจ้าของแพลตฟอร์มมีค่าใช้จ่ายสองต่อ: ครั้งแรกคือค่าสมัครสมาชิกโดยตรง และอีกครั้งคือการมอบความรู้ทางธุรกิจที่เป็นกรรมสิทธิ์ซึ่งฝังอยู่ในคำสั่ง (prompts) ซึ่งมีการอภิปรายใน บทความที่ปรึกษาด้านเทคนิคของ Nadella.
ต้นทุนการอนุมานที่ต่ำลงยังเปลี่ยนวิธีที่องค์กรประเมินการใช้จ่ายด้านโครงสร้างพื้นฐาน ในมุมมองของ FinOps การประเมินว่าจะสร้างไปป์ไลน์ในพื้นที่เองหรือสมัครสมาชิกคลาวด์แบบปิดต้องการการประเมินประสิทธิภาพการประมวลผลอย่างเข้มงวด เมื่อ Thinking Machines เปิดตัว Inkling นักพัฒนาสามารถสร้างความสมดุลระหว่างงบประมาณโทเค็นและโปรไฟล์ประสิทธิภาพได้ง่ายขึ้น เนื่องจากน้ำหนักโมเดลเปิดเผยต่อสาธารณะ องค์กรจึงสามารถปรับแต่งไปป์ไลน์การติดตั้งและนำไปใช้งานในเชิงพาณิชย์ได้โดยไม่ต้องติดล็อกกับแพลตฟอร์มเฉพาะ กระบวนการปรับแต่งนี้ได้รับการสนับสนุนอย่างเต็มที่โดยแพลตฟอร์ม Tinker ของ Thinking Machines Lab ซึ่งองค์กรสามารถอัปโหลดน้ำหนักโมเดลส่วนตัวและฝึกฝนเฉพาะโดเมนได้
สถานการณ์การติดตั้งและตัวเลือกแพลตฟอร์ม
เพื่อช่วยให้สถาปนิกโครงสร้างพื้นฐานประเมินการกำหนดค่าโฮสติ้งของตนภายใต้รูปแบบเศรษฐกิจที่เปลี่ยนไปนี้ ตารางเมทริกซ์การติดตั้งต่อไปนี้จะแสดงข้อได้เปรียบและข้อเสียมาตรฐาน:
| สถานการณ์การติดตั้ง | ต้นทุนการอนุมาน | การรองรับการปรับแต่ง | อธิปไตยของข้อมูล |
|---|---|---|---|
| API แบบปิดที่โฮสต์บนคลาวด์ | สูง (คิดราคาตามโทเค็น) | ไม่มี (ค่าเริ่มต้นของระบบ) | ต่ำ (การจัดการข้อมูลภายนอก) |
| Inkling ที่โฮสต์เอง | ปานกลาง (ค่าโครงสร้างพื้นฐานเซิร์ฟเวอร์) | ปานกลาง (อัปเดตเองในเครื่อง) | สูง (โฮสต์ในพื้นที่ก่อน) |
| Inkling ที่ปรับจูนบน Tinker | ต่ำ (รันไทม์ที่ปรับให้เหมาะกับงาน) | สูง (ปรับจูนด้วยโปรแกรม) | สูง (การแยกส่วนบน Private Cloud) |
คุณค่าของแนวทางการปรับแต่งแบบ open-weights นี้แสดงให้เห็นโดยโครงการร่วมระหว่าง Thinking Machines และ Bridgewater Associates กองทุนเฮดจ์ฟันด์ที่ใหญ่ที่สุดในโลก ด้วยการใช้โมเดลพื้นฐานแบบเปิดและฝึกฝนเพิ่มเติมด้วยความเชี่ยวชาญทางการเงินที่เป็นกรรมสิทธิ์ของ Bridgewater นักวิจัยได้สร้างระบบที่ได้คะแนน 84.7% ในการทดสอบการใช้เหตุผลทางการเงิน โมเดลที่ปรับแต่งนี้มีประสิทธิภาพเหนือกว่าทางเลือกเชิงพาณิชย์ชั้นนำในขณะที่มีต้นทุนการทำงานเพียง 1 ใน 14 ของระบบเดิม ตัวชี้วัดประสิทธิภาพเหล่านี้สนับสนุนวัตถุประสงค์ด้าน FinOps โดยตรง ช่วยให้นักพัฒนาปรับสมดุลระหว่างงบประมาณและประสิทธิภาพ ดังที่ระบุไว้ใน การศึกษาการใช้เหตุผลทางการเงินของ Bridgewater.

รายการตรวจสอบการบูรณาการ: วิธีที่ทีมวิศวกรเตรียมพร้อมสำหรับการเปลี่ยนผ่านแพลตฟอร์ม
เพื่อรักษาความปลอดภัยไปป์ไลน์ข้อมูลและสร้างความเป็นอิสระทางเทคนิคในขณะที่โมเดล open-weights กลายเป็นมาตรฐานอุตสาหกรรม ทีมวิศวกรรมและทีมผลิตภัณฑ์ต้องกำหนดแผนการย้ายระบบที่ชัดเจน
รายการตรวจสอบการนำไปใช้งานสำหรับนักพัฒนา
- ประเมินไปป์ไลน์การอนุมาน: ตั้งค่าเกณฑ์มาตรฐานการควอนไทซ์ (quantization) โดยใช้เฟรมเวิร์กอย่าง SGLang, vLLM หรือ llama.cpp เพื่อเพิ่มประสิทธิภาพหน่วยความจำ
- ตรวจสอบการใช้งาน GPU: วิเคราะห์เส้นทางของผู้เชี่ยวชาญเพื่อให้แน่ใจว่าลดข้อจำกัดด้านแบนด์วิดท์หน่วยความจำในระหว่างการอนุมานพร้อมกัน
- ตรวจสอบเวิร์กโฟลว์การปรับจูน: กำหนดค่าเทมเพลตการปรับแต่งโมเดลบนแพลตฟอร์มเช่น Tinker เพื่อทำให้เกณฑ์การประเมินเป็นอัตโนมัติ
รายการตรวจสอบกลยุทธ์ผลิตภัณฑ์และการเติบโต
- ยืนยันพารามิเตอร์ใบอนุญาตโมเดล: ตรวจสอบข้อกำหนด Apache 2.0 เพื่อให้แน่ใจว่าปฏิบัติตามกฎสำหรับการแจกจ่ายซ้ำเชิงพาณิชย์ในภายหลัง
- จัดตั้งระบบติดตาม FinOps: เปรียบเทียบต้นทุนการโฮสต์เซิร์ฟเวอร์ระยะยาวกับค่าใช้จ่ายในการสมัครสมาชิก API แบบคิดราคาตามการใช้งาน เพื่อเพิ่มประสิทธิภาพไปป์ไลน์การคำนวณ
- แยกที่เก็บข้อมูลที่เป็นกรรมสิทธิ์: สร้างกล่องทราย (data sandboxes) ที่เข้มงวดเพื่อให้แน่ใจว่าความรู้ที่ละเอียดอ่อนของบริษัทจะไม่ถูกดึงเข้าสู่โมเดลสาธารณะภายนอก
การกำหนดแนวทางที่ชัดเจนเหล่านี้ช่วยให้ทีมพัฒนาสามารถเปลี่ยนผ่านแอปพลิเคชันไปสู่สถาปัตยกรรมที่ปลอดภัยและเป็นไปตามมาตรฐานมากขึ้น ในขณะที่ยังคงความต่อเนื่องในการดำเนินงาน
คำถามที่พบบ่อย (FAQ)
เหตุใดการใช้โมเดลเชิงพาณิชย์แบบปิดถึงทำให้บริษัทต้อง "จ่ายสองต่อ"?
ข้อได้เปรียบทางเทคนิคของสถาปัตยกรรม Mixture-of-Experts ของ Inkling คืออะไร?
Inkling ปลอดภัยสำหรับการใช้งานในองค์กรโดยไม่มีการควบคุมจากส่วนกลางหรือไม่?
Inkling เป็นโอเพนซอร์สหรือไม่?
ประเด็นสำคัญสำหรับทีมวิศวกร
Inkling แสดงให้เห็นว่า AI ระดับองค์กรกำลังก้าวไปสู่การติดตั้งใช้งานแบบ open-weight ที่ปรับแต่งได้ แทนที่จะเข้ามาแทนที่แพลตฟอร์ม AI แบบปิดโดยสิ้นเชิง Inkling ได้ขยายขอบเขตของกลยุทธ์การติดตั้งใช้งานที่ทีมวิศวกรระดับองค์กรสามารถเลือกใช้ได้
องค์กรที่เลือกใช้โมเดล open-weight จะให้ความสำคัญกับการติดตั้งใช้งานภายใน ธรรมาภิบาลของโมเดล การอนุมานที่มีประสิทธิภาพ และความคุ้มค่าในการดำเนินงานระยะยาว มากกว่าการพึ่งพา API เชิงพาณิชย์ ดังนั้น ทีมงานจึงควรให้ความสำคัญกับโครงสร้างพื้นฐานที่รองรับการปรับจูนที่มีประสิทธิภาพ การปรับการอนุมานให้เหมาะสม และธรรมาภิบาลของระบบ
Share this article



