GLM-5.1-HighSpeed ทดสอบจริง: 400 token/s ทั้งเร็วและฉลาด โมเดล AI จีนก้าวข้ามขีดจำกัดครั้งแรก

GLM-5.1-HighSpeed เปิดตัวอย่างเป็นทางการ ด้วยความเร็วเอาต์พุต 400 token ต่อวินาที ไม่เพียงแค่เร็ว แต่ยังมีประสิทธิภาพที่แข็งแกร่ง น่าทึ่งมาก ผมได้ทดสอบจริงทันที ด้านล่างนี้คือผลลัพธ์ที่แสดงให้เห็นโดยตรง

ผมได้กำหนดค่า GLM-5.1 และ GLM-5.1-HighSpeed ใน Claude Code ตามลำดับ เพื่อให้เห็นความแตกต่างของความเร็วระหว่างทั้งสองอย่างชัดเจน

GLM-5.1: หลังจากส่งคำสั่งสองคำสั่ง ใช้เวลาประมาณ 31 วินาทีตั้งแต่ส่งจนได้รับคำตอบ

GLM-5.1-HighSpeed: คำสั่งสองคำสั่งเดียวกัน ใช้เวลาเพียง 11 วินาทีหลังจากส่ง

Claude Opus 4.7: อาจได้รับผลกระทบจากปัจจัยเครือข่าย Opus 4.7 ใช้เวลาประมาณ 47 วินาที

ต่อไปมาทดสอบประสิทธิภาพจริงของ GLM-5.1-HighSpeed วิดีโอทั้งหมดเป็นความเร็วปกติ ไม่ได้เร่งความเร็ว ให้ GLM-5.1-HighSpeed สร้างหน้าเว็บ เสร็จภายใน 40 วินาที:

ทดสอบสร้างไฟล์ Word อีกครั้ง เสร็จใน 20 วินาที:

GLM-5.1 เวอร์ชันความเร็วสูง打破了ความเข้าใจทั่วไปในอุตสาหกรรม ก่อนหน้านี้วงการเชื่อกันโดยทั่วไปว่ามีเพียงโมเดลขนาดเล็กเท่านั้นที่สามารถทำการอนุมานความเร็วสูงได้ แต่โมเดลขนาดเล็กมักมาพร้อมกับปัญหาความฉลาดที่ลดลง

อย่างไรก็ตาม GLM-5.1 เวอร์ชันความเร็วสูงใช้ GLM-5.1 โมเดลธงของ智谱 เป็นครั้งแรกที่โมเดลใหญ่ในประเทศสามารถบรรลุทั้งความฉลาดระดับสูงสุดและความเร็วสูงสุดพร้อมกัน

ข้อเสียคือ หน้าต่างบริบทของ GLM-5.1-HighSpeed ยังคงอยู่ที่ 200K หวังว่าจะมีเวอร์ชัน 1M ในอนาคต

01 ผลลัพธ์เป็นอย่างไร?

ในด้านความฉลาดของโมเดล GLM-5.1 เวอร์ชันความเร็วสูงยังคงรักษาความสามารถของ GLM-5.1 ไว้อย่างสมบูรณ์

ผมทดสอบหลายกรณีเพื่อดูประสิทธิภาพจริงของ GLM-5.1 เวอร์ชันความเร็วสูง ก่อนอื่นสร้างพรอมต์เกม 3D ที่คล้ายกับ Minecraft: “ช่วยสร้างเกม 3D ที่คล้ายกับ Minecraft ให้ฉันหน่อย ฉันสามารถเล่นได้โดยตรงในหน้าเว็บ”

หลังจากสร้างโค้ดแล้วรันโดยตรง ไม่มีข้อผิดพลาดใดๆ หลังจากป้อนพรอมต์ข้างต้น ระบบใช้ฟังก์ชัน brainstorming ของ superpowers เพื่อระดมความคิด สนทนาหลายรอบกับ AI เพื่อจำกัดความต้องการ จากนั้นเขียนเอกสาร Spec และเอกสารแผน สุดท้ายแบ่งเป็น 10 งานย่อย ให้ SubAgent ดำเนินการทีละงาน จนเสร็จสมบูรณ์เป็นเวอร์ชัน MVP

หากใช้ GLM-5.1 หรือ Opus 4.7 รุ่นก่อน กระบวนการนี้ใช้เวลาอย่างน้อย 1 ถึง 2 ชั่วโมง แต่ตอนนี้ใช้เวลาเพียง 11 นาทีเท่านั้น และคุณภาพการส่งมอบก็รับประกันได้

การถามและชี้แจงในการระดมความคิดล่วงหน้ามาเป็นชุด ความเร็วทำให้ผมตามไม่ทัน

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

การสร้างเว็บไซต์: เปรียบเทียบกับ GLM 5.1 ใช้พรอมต์เดียวกันและสภาพแวดล้อมเดียวกัน ต่างกันแค่โมเดล พรอมต์: “สร้างเว็บไซต์แนะนำตัวจากไฟล์แนะนำตัวบนเดสก์ท็อป ใช้สไตล์ Claude ใน Awesome Design ไม่ต้องระดมความคิด เริ่มเลย”

GLM-5.1:

GLM-5.1-HighSpeed:

จากความรู้สึกโดยตรง ผลลัพธ์ของ GLM-5.1-HighSpeed ดีกว่าเล็กน้อย และเร็วกว่า GLM-5.1 ถึง 5 ถึง 6 เท่า ผมให้ Claude Opus 4.7 ให้คะแนนผลลัพธ์ที่สร้างจากทั้งสอง สรุปได้ว่าผลลัพธ์การส่งมอบของ GLM-5.1-HighSpeed ดีกว่า

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

ส่งผลลัพธ์ให้ Claude Opus 4.7 ประเมินเช่นกัน

02 ทำไมถึงเร็วขนาดนี้?

GLM-5.1 เวอร์ชันความเร็วสูงพัฒนาร่วมกันโดยทีม GLM ของ智谱และทีม TileRT โดยปรับให้เหมาะสมพร้อมกันในสามระดับ:

• ระดับเอนจินอนุมาน: ปรับเส้นทางการอนุมานหลักใหม่ตามลักษณะสถาปัตยกรรมของ GLM-5.1 เพิ่มความสามารถในการประมวลผลต่อการ์ด
• ระดับระบบจัดตาราง: ปรับการประมวลผลแบบไดนามิก การรวมคำขอ และการจัดตาราง KV cache ให้เหมาะสม ลดความหน่วงท้ายอย่างมีนัยสำคัญในสถานการณ์ที่มีการทำงานพร้อมกันสูง
• ระดับโครงสร้างพื้นฐาน: ปรับการปรับใช้คลัสเตอร์อนุมาน ลิงก์เครือข่าย และการปรับสมดุลโหลดร่วมกัน เพื่อให้แน่ใจว่า 400 TPS ไม่ใช่ตัวเลขสูงสุด แต่เป็นระดับการผลิตที่เสถียร

แต่นวัตกรรมหลักที่สุดคือเอนจินอนุมาน TileRT เอง

ขีดจำกัดบนของความเร็วการอนุมานโมเดลถูกกำหนดโดยฮาร์ดแวร์ แต่ระบบจริงมักไม่ถึงขีดจำกัดนี้ ตัวอย่างเช่น เซิร์ฟเวอร์ 8 การ์ด H200 มีแบนด์วิดท์หน่วยความจำรวมประมาณ 38TB/s ในทางทฤษฎี ขีดจำกัดบนของความเร็ว decode ใกล้ 1000 token/s แต่บริการอนุมานจริงมักทำได้เพียงหลายสิบ token/s

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

วิธีการของ TileRT คือละทิ้งการจัดตารางแบบไดนามิกในเลเยอร์ Runtime โดยสิ้นเชิง จัดเรียงกราฟการคำนวณทั้งหมดแบบคงที่เป็น Persistent Engine Kernel ที่อยู่บน GPU ตลอดเวลาในระหว่างการคอมไพล์

ภายในการ์ดเดียว การคำนวณ IO แบบอะซิงโครนัส และการสื่อสารถูกแยกเป็นงานย่อยระดับ Tile กระบวนการอนุมานทั้งหมดเริ่มต้นเพียงครั้งเดียว ผลลัพธ์กลางระหว่างโอเปอเรเตอร์ไม่ถูกเขียนกลับไปยัง Global Memory แต่ถูกส่งโดยตรงผ่าน Register, Shared Memory และ L2 Cache

ในสถานการณ์หลายการ์ด GPU ที่แตกต่างกันไม่ดำเนินการตรรกะแบบเดียวกัน แต่ถูกปรับให้เป็น worker ที่แตกต่างกันตามความหนาแน่นของการคำนวณและการพึ่งพาข้อมูล ตัวอย่าง GLM-5.1 GPU 0 ทำหน้าที่ Sparse Indexer โดยเฉพาะ GPU 1 ถึง 7 รับผิดชอบแกนหลักความสนใจ MLA การกระจาย การลด และการเพิ่มส่วนที่เหลือข้ามการ์ดถูกบีบอัดเป็นคำสั่งการสื่อสารเดียวกัน

ในที่สุด หน่วยจัดตารางของการอนุมานลดลงจาก operator/kernel เป็น tile

03 เป็นประโยชน์ต่อผลิตภัณฑ์ AI ที่ต้องการความเร็วตอบสนองสูง

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

• ที่อยู่โอเพนซอร์ส: https://github.com/Wechat-ggGitHub/Lumi

ตัวอย่างเช่น ผมพูดว่า: “เฉียนตั้วตั้ว ช่วยจัดระเบียบไฟล์บนเดสก์ท็อปให้ฉันหน่อย” งานนี้จริงๆ ใช้เวลาห้าถึงหกนาทีจึงจะเสร็จ วิดีโอด้านล่างถูกเร่งความเร็ว

คุณเห็นไหม เมื่องานเสร็จ การตอบกลับด้วยเสียงแจ้งผู้ใช้: “เจ้านาย ผมจัดระเบียบให้คุณแล้ว” แต่ถ้าหลังจาก 5 นาทีผู้ใช้ลืมเรื่องนี้ไปแล้ว การตอบกลับด้วยเสียงว่าเสร็จงานจะไม่ใช่ความประหลาดใจ แต่เป็นความตกใจ—จู่ๆ ก็มีเสียงพูดขึ้นมา ประสบการณ์ไม่ดีเลย

แต่ถ้าความเร็วการอนุมานของโมเดลเร็วมาก ห่วงโซ่การเรียก Agent มีประสิทธิภาพเพียงพอ และรวมกับการปรับแต่งรายละเอียดผลิตภัณฑ์บางอย่าง ประสบการณ์ผู้ใช้ในสถานการณ์นี้จะดีขึ้นอย่างมาก อย่างน้อยจากความรู้สึกจริงในการพัฒนา Lumi ด้วย Vibe Coding เมื่อเร็วๆ นี้ ความเร็วเป็นปัจจัยสำคัญที่ส่งผลต่อประสบการณ์ผู้ใช้ เชื่อว่าผลิตภัณฑ์ AI หลายอย่างที่ต้องการความหน่วงต่ำในอนาคตจะเลือก GLM-5.1-HighSpeed เป็นโมเดลพื้นฐาน

04 คลิกการ์ดด้านล่าง ติดตาม逛逛 GitHub

บัญชีสาธารณะ WeChat นี้เคยเผยแพร่โปรเจกต์โอเพนซอร์สที่น่าสนใจมากมาย หากคุณขี้เกียจเลื่อนดูบทความทีละบทความ เพียงติดตามบัญชีสาธารณะ WeChat: 逛逛 GitHub สนทนาที่后台ได้: