Cloudflare เปิดตัวเลขจริงของการรีดโมเดลเปิดลง GPU — FP8 KV cache ดัน Kimi K2.6 จาก 686K เป็น 1.37M token, INT4 ย่อ GLM 5.2 จาก 705GB เหลือ 421GB

ข่าวโมเดลเปิดตัวใหม่มาทุกสัปดาห์ แต่คำถามที่คนรันจริงเจอกลับเป็นคำถามเดิม — โมเดล MoE ขนาด 700GB ที่รับ context ระดับล้าน token จะยัดลง GPU ยังไงให้คุ้ม วันที่ 3 สิงหาคม 2026 ทีม Workers AI ของ Cloudflare (Alex Reneau, Kevin Flansburg และ Chi McIsaac) เขียนบล็อกตอบคำถามนี้ด้วยตัวเลขจริงจากโปรดักชัน ไม่ใช่สไลด์การตลาด

สิ่งที่ทำให้โพสต์นี้มีค่ากว่าโพสต์ “เราเร็วขึ้น X เท่า” ทั่วไปคือ เขาเปิดตารางทั้งฝั่งที่ได้และฝั่งที่เสีย — บอกตรง ๆ ว่าการควอนไทซ์ KV cache ทำให้ throughput ต่อ token ช้าลงเล็กน้อย และ INT4 ทำให้ prefill ช้าลงจริง แล้วอธิบายว่าทำไมถึงยังคุ้ม

สามชั้นที่ซ้อนบนสถาปัตยกรรมแยก prefill/decode

โมเดลที่พูดถึงคือ Kimi K2.6 ของ Moonshot และ GLM 5.2 ของ Z.ai — ทั้งคู่เป็น MoE ขนาดใหญ่ context ยาว ซึ่ง Cloudflare บอกตรง ๆ ว่า “ใช้งานดีมาก แต่เสิร์ฟให้มีประสิทธิภาพยากมากเพราะข้อจำกัดหน่วยความจำ”

ฐานที่มีอยู่แล้วคือการแยก prefill (ช่วงอ่าน prompt) กับ decode (ช่วงพ่น token) ออกเป็นคนละ pool ซึ่งเป็นกุญแจของทั้งโพสต์ เพราะทำให้แต่ละเทคนิคเลือกใช้เฉพาะฝั่งที่มันชนะได้ บนฐานนั้นเขาซ้อนสามอย่าง: ควอนไทซ์ KV cache, บีบน้ำหนักโมเดล และตรวจความถูกต้องของ cache ที่ถูกแชร์

ทั้งการทดลองและทราฟฟิกโปรดักชันรันบน SGLang โดย Cloudflare ระบุว่าเป็นเฟรมเวิร์กที่ให้ประสิทธิภาพดีที่สุดในตลาดตอนนี้ และทีมทำงานร่วมกับ SGLang เพื่อ upstream แพตช์กลับเข้าโอเพนซอร์ส — จุดนี้สำคัญสำหรับคนที่ self-host เพราะแปลว่าของบางส่วนไหลกลับมาถึงมือเรา

FP8 KV cache: ไม่ได้เร็วขึ้น แต่รับงานพร้อมกันได้มากขึ้น

KV cache คือที่เก็บ key/value ของทุก token ที่โมเดลอ่านไปแล้ว และสำหรับโมเดล context ยาว มันคือสิ่งที่กินหน่วยความจำ GPU เต็มก่อนน้ำหนักโมเดลด้วยซ้ำ ค่าเริ่มต้นเก็บที่ BF16 (16 บิต) Cloudflare เปลี่ยนไปเก็บที่ FP8 (e4m3) ซึ่งลดขนาดลงครึ่งหนึ่ง

ผลกับ Kimi K2.6 คือ context ที่ค้างในหน่วยความจำได้พร้อมกันขยับจาก ราว 686,000 token เป็นราว 1.37 ล้าน token

ตัวเลข decode บน H200 แบบ disaggregated เทียบ attention kernel ตรง ๆ:

requests พร้อมกัน	BF16 KV (tok/s)	FP8 KV (tok/s)
1	137	125
8	731	689
16	1,106	1,028
32	1,558	1,489
64	Out of memory	2,192

อ่านตารางนี้ให้ถูก: ทุกระดับ concurrency ที่ BF16 ยังรันได้ BF16 เร็วกว่า เพราะ FP8 kernel ต้องแปลงค่าตอนอ่าน สิ่งที่เปลี่ยนไม่ใช่ความเร็วต่อ token แต่คือ เพดาน — BF16 หมด cache ที่ 32 requests และรับ request ที่ 33 ไม่ได้เลย ส่วน FP8 ไปต่อถึง 64 แตะ 2,192 tok/s ซึ่งสูงกว่าจุดพีคของ BF16 ราว 41% และคิดเป็นต้นทุนต่อ token ที่ถูกลงราว 30%

เพราะ prefill ติด compute ไม่ใช่หน่วยความจำ Cloudflare จึงเก็บ cache ฝั่ง prefill ไว้เป็น BF16 ตามเดิม

ด้านความแม่นยำเขาเปิดตาราง: GSM8K 94.24 → 94.09, ARC-Easy 89.06 → 89.14, ARC-Challenge 66.72 → 67.49, MMLU 89.11 → 89.04, MMLU-Pro 80.29 → 79.29, เบนช์มาร์กภายในชื่อ mcxams ได้ 61/63 เท่ากันทั้งคู่ และ tool-call validity 92.2% → 92.6% — ตัวหลังนี่คือตัวที่คนสร้าง agent ควรดูที่สุด เพราะ quantization ที่ทำให้ JSON tool call พังคือฝันร้ายที่เบนช์มาร์กความรู้ทั่วไปจับไม่ได้

INT4 กับน้ำหนัก GLM 5.2: เช็คพอยต์หาย 284GB

ฝั่งน้ำหนักโมเดล Cloudflare บีบ GLM 5.2 จาก FP8 ลงเป็น INT4 ผลคือเช็คพอยต์ลดจาก 705GB เหลือ 421GB (~40%) และหน่วยความจำต่อ GPU บน deployment แบบ 8-way tensor parallel ลดจากราว 88GB เหลือราว 52GB — ที่ว่างที่เหลือแปลงเป็น KV cache ได้อีกราว 1.18 ล้าน token บนฮาร์ดแวร์ชุดเดิม

decode เร็วขึ้นชัดเจน เพราะการพ่นแต่ละ token คือการสตรีมน้ำหนักออกจากหน่วยความจำ GPU ย้ายข้อมูลน้อยลงก็เร็วขึ้น:

requests พร้อมกัน	GLM FP8 (tok/s)	GLM INT4 (tok/s)	ต่าง
1	60	92	+55%
8	425	513	+21%
16	683	825	+21%
32	994	1,267	+27%
64	1,672	1,933	+16%

สังเกตว่ากำไรสูงสุดอยู่ที่ concurrency ต่ำ — คือเคสที่ latency ต่อ request สำคัญที่สุด ซึ่งตรงกับงาน agent แบบโต้ตอบ

แต่ prefill ช้าลงจริง: INT4 ต้องคลายน้ำหนักกลับออกมาก่อนคูณ ทำให้ GLM ทำ prefill ได้ราว 8,660 tok/s เทียบกับ 10,160 tok/s ตอนเป็น FP8 คำตอบของ Cloudflare คือใช้สถาปัตยกรรมแยก pool ให้เป็นประโยชน์ — รัน INT4 ที่ decode และ FP8 ที่ prefill ไม่ต้องเลือกอย่างใดอย่างหนึ่ง ความแม่นยำเขาระบุว่าไม่ห่างจาก FP8 เกิน 0.8 จุดในทุกเบนช์มาร์ก

ชั้นที่สาม: ป้องกัน KV cache ที่ถูกแชร์

สองเทคนิคแรกมีผลข้างเคียงเดียวกัน — ทำให้ request จำนวนมากขึ้นมากมาแชร์หน่วยความจำ GPU ตัวเดียวกัน กลไกที่ทำให้เร็ว (paged attention, continuous batching, cache reuse) ล้วนพึ่งการทำบัญชี page ให้ถูกเป๊ะ และ Cloudflare เขียนประโยคที่ตรงประเด็นมาก: ที่ปริมาณ request ระดับของเขา ความผิดพลาดระดับหนึ่งในพันล้านจะโผล่ให้เห็นเป็นประจำ

วิธีแก้คือให้ทุก physical cache page มี tag ที่เปลี่ยนทุกครั้งที่ page ถูกจัดสรรใหม่ เซิร์ฟเวอร์บันทึกว่าแต่ละ request คาดว่าจะใช้ page/tag ไหน แล้วตรวจก่อนอ่าน ถ้าไม่ตรง — ยกเลิก request นั้นทิ้ง แทนที่จะปล่อยให้คืนข้อมูลจาก page ของคนอื่น

ต้นทุนที่วัดได้บนโมเดลโปรดักชันขนาดกลาง (2 prefill 2 decode, input 8,192 token, output 1,000 token) อยู่ที่ throughput ลดลง 0.38–0.79% และ p95 latency เพิ่ม 0.42–0.80% — ต่ำกว่า 1% ทั้งคู่ เคล็ดคือรัน validation เป็น batch check แยก ไม่ fuse เข้าไปใน attention kernel ซึ่งจะทำให้เกิด race ระหว่าง thread group บน GPU ฟีเจอร์นี้เปิดปิดได้ราย deployment และ path ปกติใช้ tracker แบบ no-op ที่ไม่มี overhead วัดได้

ขั้นถัดไปที่เขาประกาศคือขยาย FP8 KV cache ให้ทั่ว fleet, ตรวจสอบน้ำหนัก NVFP4 บน Blackwell และผลักดันให้เปิด integrity check ไว้ตลอดเวลาได้

ข้อควรระวังก่อนเอาตัวเลขไปใช้

ตัวเลขชุดนี้เป็นของ Cloudflare วัดเอง ไม่มีบุคคลที่สามยืนยัน และมีสามจุดที่ควรอ่านอย่างระวัง: หนึ่ง “ต้นทุนต่อ token ถูกลง 30%” คือต้นทุนฝั่ง Cloudflare ไม่ใช่ราคาที่ลูกค้าจ่าย — โพสต์ไม่ได้ประกาศลดราคา Workers AI แต่อย่างใด สอง เบนช์มาร์กความแม่นยำเป็นชุดที่เขาเลือกเอง รวม mcxams ที่เป็นของภายในและไม่มีใครตรวจสอบได้ สาม ตัวเลข overhead ของ integrity check วัดบน “โมเดลโปรดักชันขนาดกลาง” ที่ไม่ระบุชื่อ ไม่ใช่บน Kimi หรือ GLM ที่เป็นพระเอกของโพสต์

มุมมอง AI Curator

โพสต์นี้มีค่าที่สุดไม่ใช่ในฐานะข่าวโปรดักต์ของ Cloudflare แต่ในฐานะ คู่มือตัดสินใจสำหรับคนที่ self-host โมเดลเปิด — และนั่นคือคนกลุ่มใหญ่ในไทยที่ต้องรันโมเดลในประเทศเพราะข้อกำหนดเรื่องข้อมูล

บทเรียนที่ถอดมาใช้ได้ทันทีคือ การแยก prefill กับ decode เปลี่ยน “การประนีประนอม” ให้กลายเป็น “การเลือก” ทีมที่รัน vLLM หรือ SGLang แบบ pool เดียวจะต้องเลือกระหว่าง INT4 ที่ decode ไว prefill ช้า กับ FP8 ที่กลับกัน แต่พอแยก pool แล้วเอาสองอย่างที่ดีที่สุดมาประกบกันได้เลย นี่คือเหตุผลทางสถาปัตยกรรมที่จับต้องได้ ไม่ใช่แค่ buzzword

บทเรียนที่สองสำคัญกว่าและมักถูกมองข้าม: ตัวชี้วัดที่ควรดูตอนควอนไทซ์ ไม่ใช่ MMLU ทีมส่วนใหญ่พอควอนไทซ์เสร็จก็รัน MMLU เทียบแล้วเห็นว่าห่างไม่ถึงจุดก็สบายใจ แต่ถ้าคุณกำลังสร้าง agent สิ่งที่พังก่อนคือ tool call — JSON เพี้ยน argument หาย schema ไม่ตรง ซึ่ง MMLU จับไม่ได้เลย การที่ Cloudflare ใส่ tool-call validity ไว้ในตารางคือสัญญาณว่าทีมที่รัน agent จริงเรียนรู้เรื่องนี้แล้ว ถ้าคุณกำลังจะควอนไทซ์โมเดลไปรัน agent ให้เพิ่มเมตริกนี้เข้า eval ก่อนอย่างอื่น

สุดท้าย จุดที่ผมคิดว่าน่าสนใจที่สุดคือ KV cache integrity check ซึ่งเป็นปัญหาที่แทบไม่มีใครพูดถึง เมื่อการรีดประสิทธิภาพหมายถึงการเอา request ของคนแปลกหน้าหลายร้อยรายมาแชร์หน่วยความจำก้อนเดียวกัน bug บัญชี page หนึ่งตัวไม่ได้แปลว่า “ตอบผิด” แต่แปลว่า ผู้ใช้คนหนึ่งอาจได้เห็นบทสนทนาของอีกคน สำหรับผู้ให้บริการ AI ในไทยที่กำลังทำ multi-tenant inference ให้ลูกค้าองค์กร — โดยเฉพาะแบงก์กับโรงพยาบาลที่กำลังจะเข้าเงื่อนไข PDPA เต็มรูปแบบ — นี่คือความเสี่ยงระดับที่ต้องตอบให้ได้ในเอกสาร ไม่ใช่เรื่องที่ไว้ค่อยทำ และการที่ Cloudflare พิสูจน์ว่ามันมีต้นทุนต่ำกว่า 1% แปลว่า ข้ออ้างว่า “ทำแล้วช้า” ใช้ไม่ได้อีกต่อไป

แหล่งข่าว

• Smaller, faster, safer: running Kimi and GLM at scale — The Cloudflare Blog (3 ส.ค. 2026)
• SGLang — เฟรมเวิร์ก inference โอเพนซอร์สที่ Cloudflare ใช้
• moonshotai/Kimi-K2.6 บน Hugging Face
• Z.ai GLM บน Hugging Face