DeepInfer คืออะไร? เอนจินการอนุมานของ DeepSeek และส่วนประกอบที่ไม่ได้เปิดตัว

DeepInfer คือเฟรมเวิร์กสำหรับการอินเฟอเรนซ์ที่ DeepSeek เผยแพร่เมื่อวันที่ 16 ตุลาคม 2026 ภายใต้ Apache-2.0 และให้บริการโมเดลเพียงหนึ่งเดียวเท่านั้น คือ DeepSeek-V4.1-Flash โดยมี DeepSeek-V4.1-Flash-1017 เป็นเช็กพอยต์เริ่มต้น ขอบเขตแบบโมเดลเดียวนั้นเป็นสิ่งแรกที่ต้องเข้าใจ เพราะมันอธิบายเกือบทุกอย่างเกี่ยวกับรีโพซิทอรีนี้ นี่ไม่ใช่เฟรมเวิร์กการให้บริการทั่วไปที่บังเอิญมีคอนฟิกูเรชันของ DeepSeek อยู่ด้วย หากแต่เป็นเส้นทางโค้ดที่ DeepSeek ใช้ในระบบโปรดักชัน ซึ่งถูกตัดให้เหลือเฉพาะส่วนที่สามารถนำไปใช้ทั่วไปได้ และซื่อตรงเกี่ยวกับการตัดทอนนี้ รายการใน README เองที่ระบุว่าบริการอินเฟอเรนซ์ที่สมบูรณ์ต้องมีอะไรบ้าง และรีลีสนี้ไม่รวมอะไรบ้าง ได้ระบุถึงระบบแคช KV การแยกส่วน VE/Prefill/Decode และการกระจายโหลดข้ามรีพลิกาแบบ data-parallel สิ่งที่คุณได้คือเส้นทางการคำนวณ — เคอร์เนล การขนาน การถอดรหัสแบบคาดเดา การจัดตารางเวลา และเอาต์พุตแบบมีโครงสร้าง สิ่งที่คุณไม่ได้คือชั้นจัดเก็บและกำหนดเส้นทางที่ทำให้เส้นทางการคำนวณมีต้นทุนต่ำในการปฏิบัติงานในระดับสเกล DeepSeek ระบุเหตุผลว่า คอมโพเนนต์เหล่านี้ผูกติดแน่นกับโครงสร้างพื้นฐานภายใน ดังนั้นการออกแบบจึงถูกอธิบายไว้ในเอกสารที่เผยแพร่ ขณะที่โค้ดยังคงอยู่ภายในองค์กร

จริงๆ แล้วมีอะไรอยู่ในรีโพซิทอรี

รายการฟีเจอร์ที่เผยแพร่ออกมาอ่านแล้วเหมือนเป็นการพาไปสำรวจคอขวดต่างๆ ในการให้บริการโมเดล mixture-of-experts ขนาดใหญ่ มีไลบรารีเคอร์เนลที่ DeepSeek เปิดตัวมาก่อนหน้านี้ — FlashMLA สำหรับ attention, DeepGEMM สำหรับการคูณเมทริกซ์, DeepEP สำหรับการสื่อสารแบบ expert-parallel พร้อมด้วย TileKernels และ DeepSelect มีรูปแบบการทำงานแบบขนาน: attention ทำงานเป็น data parallelism พร้อม context parallelism ที่สมดุล ส่วนครึ่ง MoE ทำงานเป็น expert parallelism พร้อมตัวบาลานเซอร์โหลดแบบ expert-parallel มี DSpark ซึ่งเป็นสแตกการถอดรหัสแบบ speculative โดยความยาวการตรวจสอบถูกจัดตารางแทนที่จะคงที่ มี SWA bounded replay ซึ่งเป็นกลไกที่ป้องกันไม่ให้แคช sliding-window attention บังคับให้ต้องคำนวณใหม่ทั้งหมดทุกครั้งที่เกิด cache miss มีการจัดตารางแบตช์แบบอะซิงโครนัส การอนุมานแบบ batch-invariant พร้อมการสุ่มตัวอย่างที่กำหนดผลได้แน่นอน และเอาต์พุตแบบมีโครงสร้างที่ถูกจำกัดด้วย regex, JSON schema หรือ EBNF

จุดเริ่มต้นถูกออกแบบให้เล็กโดยเจตนา หลังจากตั้งค่า DEEPINFER_ACCELERATOR เป็น nvidia หรือค่าที่เทียบเท่าสำหรับ Ascend แล้วรัน build.sh รีโพซิทอรีก็มี examples/offline_inference.py ซึ่งรัน checkpoint ค่าเริ่มต้นแบบครบวงจร DEEPINFER_HF_MODEL_DIR ใช้ชี้ไปยังไดเรกทอรีน้ำหนักอื่น เบนช์มาร์กที่เผยแพร่ถูกวัดบน GPU SM100 จำนวนสี่ตัวสำหรับ prefill และ GPU SM100 จำนวน 64 ตัวสำหรับ decode ซึ่งเป็นรูปแบบการติดตั้งใช้งานที่เอนจินนี้ถูกเขียนขึ้นมาเพื่อรองรับ ไม่ใช่เดโมขนาดแล็ปท็อป

README ยังระบุด้วยว่าโค้ดมาจากไหน ซึ่งเป็นสิ่งที่ควรรู้ก่อนอ่าน เอนจินนี้เดิมทีสร้างขึ้นโดยอิงกับ vLLM เป็นหลัก โดยได้แรงบันดาลใจในการออกแบบจาก SGLang และ TensorRT-LLM ที่มาดังกล่าวปรากฏให้เห็นในโครงสร้าง — scheduler, อินเทอร์เฟซ paged attention และเส้นทางการสุ่มตัวอย่างจะดูคุ้นเคยสำหรับใครก็ตามที่เคยอ่านโปรเจกต์เหล่านั้น — และอธิบายว่าทำไมรีลีสนี้จึงเป็นฟอร์กของสแตกสำหรับให้บริการ而非สถาปัตยกรรมที่เขียนขึ้นใหม่ตั้งแต่ต้น สิ่งที่ DeepSeek เพิ่มเข้ามาคือส่วนที่เฉพาะกับโมเดลของตัวเอง ได้แก่ การติดตั้งใช้งานแบบ disaggregated, wide expert parallelism พร้อมตัวบาลานเซอร์, การเล่นซ้ำแบบ sliding-window และ DSpark

สิ่งที่มันไม่มี และทำไมสิ่งนั้นจึงสำคัญกว่า

ชิ้นส่วนที่ขาดหายไปสามส่วนไม่ใช่การละเลยเล็กน้อย แต่ละส่วนเป็นระบบที่ต้องมีอยู่ก่อนที่เอนจินจะให้บริการทราฟฟิกโปรดักชัน และแต่ละส่วนก็มีต้นทุนสูงในรูปแบบที่แตกต่างกัน

• ระบบแคช KV การใช้คำนำหน้า (prefix) ซ้ำคือจุดที่ประหยัดต้นทุนได้มากที่สุดในงานประเภทแชต เพราะเมื่อเกิดแคชฮิต (cache hit) จะแทนที่การทำ prefill หากไม่มีที่เก็บแคช ทุกคำขอจะต้องคำนวณพรอมป์ของตนใหม่ เอกสารของ DeepSeek เองอธิบายถึงที่เก็บข้อมูลที่ใช้: คลัสเตอร์ 3FS โดยเฉพาะแทนหน่วยความจำของโฮสต์ภายในเครื่อง เพื่อให้เครื่อง prefill เครื่องใดก็ตามสามารถเข้าถึงคำนำหน้าใดก็ได้จากแคช และความจุแคชสามารถขยายได้อย่างอิสระจากกำลังประมวลผล

• การแยก VE/Prefill/Decode ออกจากกัน README ระบุว่าฟังก์ชันฝั่งเอนจินส่วนใหญ่มีอยู่แล้วในรีลีส; สิ่งที่ยังขาดคือการดีพลอย การแยก vision encoder, prefill และ decode ออกจากกันช่วยให้คุณกำหนดขนาดแต่ละสเตจให้สอดคล้องกับคอขวดของตัวเอง และควบคุม time-to-first-token แยกจาก time-between-tokens นั่นเป็นการตัดสินใจด้านโครงสร้างพื้นฐาน ไม่ใช่แค่แฟล็ก

• การกระจายโหลดข้ามรีพลิกาแบบ data-parallel DeepSeek ใช้ตัวบาลานซ์สี่ตัว — prefill, decode, vision encoder และ expert-parallel — และอธิบายทั้งสี่ตัวไว้ในเอกสาร ไม่มีตรรกะการจัดเส้นทางใดถูกส่งมอบออกไป หากไม่มีมัน ฝูงรีพลิกาจะดีได้เพียงเท่ากับเราเตอร์ที่คุณวางไว้ข้างหน้า และเราเตอร์แบบ round-robin อย่างง่ายจะทำลายอัตราการแคชฮิตที่ระบบจัดเก็บถูกสร้างขึ้นมาเพื่อปกป้อง

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

เกตฮาร์ดแวร์คือฟิลเตอร์ตัวจริง

DeepInfer มุ่งเป้าไปที่ NVIDIA SM100 และ Huawei Ascend 950 โดยไม่มีเส้นทางสำหรับ Ampere และไม่มีเส้นทางสำหรับ Hopper ซึ่งตัด GPU ส่วนใหญ่ออกไปจากคลัสเตอร์ส่วนใหญ่ในปัจจุบัน ส่วนเครื่องมือที่เหลือของ toolchain ก็เจาะจงพอ ๆ กัน คือรองรับเฉพาะ Linux, GCC 13 หรือใหม่กว่า, Python 3.12, CUDA 13 สำหรับ NVIDIA หรือ CANN 9.2 สำหรับ Ascend และยังไม่มีการเปิดตัวใด ๆ เลย — ตอนที่อ่าน repository นี้เมื่อวันที่ 21 ตุลาคม 2026 มี release ที่เผยแพร่แล้วเป็นศูนย์ ดังนั้นจึงไม่มีอะไรให้ดาวน์โหลดและไม่มีอะไรให้ pin คุณต้องโคลนมันแล้ว build กับ toolchain ของคุณเอง

การผสมผสานเช่นนั้นเป็นเรื่องผิดปกติสำหรับการเปิดตัวโอเพนซอร์สที่ได้รับความสนใจมากขนาดนี้ และควรตีความว่าเป็นคำแถลงขอบเขตที่แม่นยำมากกว่าจะเป็นความพลั้งเผลอ เคอร์เนลในรีพอซิทอรีถูกเขียนขึ้นสำหรับชุดคำสั่งเฉพาะและโครงสร้างการเชื่อมต่อเฉพาะ ตัวเลขใน README มาจากฮาร์ดแวร์นั้น การพอร์ตเส้นทางการคำนวณลงไปหนึ่งรุ่นเป็นงานประเภทที่ชุมชนทำได้อย่างรวดเร็วและองค์กรด้านวิศวกรรมไม่สามารถให้คำมั่นได้ ภายในไม่กี่วันหลังการเปิดตัว การพอร์ตโดยบุคคลที่สามซึ่งมุ่งเป้าไปยังชิ้นส่วน NVIDIA รุ่นเก่าก็ปรากฏบน GitHub ซึ่งเป็นสัญญาณที่มีประโยชน์เกี่ยวกับความต้องการ และไม่ใช่สัญญาณใด ๆ เลยว่าตัวเลขปริมาณงานที่เผยแพร่จะยังคงอยู่หลังการพอร์ตหรือไม่

รูปแบบการติดตั้งใช้งานที่ DeepSeek ใช้งานจริง

เอกสารอธิบายสถาปัตยกรรมคือจุดที่สมมติฐานของรีโพซิทอรีปรากฏให้เห็นได้ชัด ระบบถูกแยกส่วนออกเป็น vision encoder, prefill และ decode พร้อมโหนดจัดเก็บข้อมูลเฉพาะทาง Prefill ใช้ expert parallelism ตั้งแต่ 2 ถึง 8 พร้อม data parallelism ที่จับคู่กัน โดยเลือกการกำหนดค่าที่เล็กที่สุดเท่าที่ HBM จะอนุญาต Decode ไปในทางตรงกันข้าม: expert parallelism และ data parallelism ตั้งแต่ 64 ถึง 128 ซึ่ง DeepSeek เรียกว่า Wide-EP โดยใช้การกำหนดค่าที่ใหญ่ที่สุดเท่าที่ GPUs ที่มีอยู่จะอนุญาต ไม่ได้ใช้ tensor parallelism และ context parallelism เลย Vision encoder ทำงานหนึ่ง GPU ต่อหนึ่งอินสแตนซ์ โดยแนะนำให้ใช้ GPUs ที่ราคาถูกกว่า เพราะ encoder ไม่ใช่ส่วนที่เงินลงทุนหลักไปอยู่

การติดตั้งใช้งานที่เล็กที่สุดที่สมเหตุสมผลนั้นได้มาจากตัวเลขเหล่านั้น GPU สำหรับ prefill หนึ่งตัวและ GPU สำหรับ decode หนึ่งตัวจะทำงาน และในทางปฏิบัติ อัตราส่วนระหว่างสองพูลนั้นอยู่ที่ประมาณหนึ่งต่อหนึ่ง แต่เนื่องจาก decode ต้องการ GPU 64 ตัวหรือมากกว่าเพื่อให้ได้ประโยชน์จาก expert-parallel หน่วยที่มีประสิทธิภาพเล็กที่สุดจึงเป็น GPU prefill 64 ตัวบวก GPU decode 64 ตัว นั่นคือตัวเลขที่ควรจดจำไว้เมื่ออ่านข้อกล่าวอ้างใด ๆ เกี่ยวกับประสิทธิภาพของ DeepInfer: ตัวเลขเหล่านี้อธิบายการติดตั้งใช้งานแบบ 128 GPU และครึ่งหนึ่งของมันคือหนึ่งสเตจ

การแยก prefill และ decode ไปยังศูนย์ข้อมูลต่าง ๆ เป็นเรื่องที่เป็นไปได้ในทางเทคนิค เพราะ DeepSeek-V4.1-Flash บีบอัด KV cache ของตนได้อย่างมาก และการติดตั้งใช้งานของ DeepSeek เองก็วางโหนด inference ไว้ในศูนย์ข้อมูลที่แตกต่างกันแต่ใกล้กัน งบประมาณคือ interconnect ประมาณ 400 Gbps ต่อ GPU แปดตัว และเอกสารเขียนอย่างตรงไปตรงมาเกี่ยวกับต้นทุนด้านความน่าเชื่อถือ — ไฟเบอร์ระหว่างอาคารนั้นตัดได้ง่าย

ทำไม decode ถึงกระจายออกกว้างขนาดนี้

การขนานผู้เชี่ยวชาญแบบกว้างเป็นทางเลือกที่มีผลกระทบมากที่สุดเพียงอย่างเดียวในการออกแบบ และเป็นเรื่องง่ายที่จะตีความผิดว่าเป็นกลเม็ดด้านการขยายขนาด ในเลเยอร์แบบ mixture-of-experts โทเค็นทุกโทเค็นจะแตะผู้เชี่ยวชาญเพียงจำนวนเล็กน้อย ดังนั้นต้นทุนของขั้นตอนการถอดรหัสจึงถูกครอบงำด้วยการย้ายน้ำหนักและแอ็กทิเวชันของผู้เชี่ยวชาญ มากกว่าความเข้มข้นของการคำนวณ การกระจายผู้เชี่ยวชาญไปยัง GPU 64 หรือ 128 ตัวช่วยลดปริมาณการรับส่งข้อมูลหน่วยความจำต่อขั้นตอนที่ GPU แต่ละตัวมีส่วนทำให้เกิดขึ้น ซึ่งจะเพิ่มจำนวนโทเค็นต่อวินาที หาก — และนี่คือเงื่อนไข — ภาระโหลดของผู้เชี่ยวชาญยังคงสม่ำเสมอ นั่นคือสิ่งที่ตัวปรับสมดุลโหลดแบบขนานผู้เชี่ยวชาญมีไว้สำหรับ

การตั้งค่าของ DeepSeek เจาะจงพอที่จะคัดลอกได้ สำหรับ prefill GPU แต่ละตัวจะเก็บ expert สำรองสี่ตัวเพิ่มจากตัวที่มันเป็นเจ้าของ สถิติจะถูกเก็บในช่วงหน้าต่าง 100 สเต็ป และจัดสรร expert ใหม่ทุก 1,000 สเต็ป โดยสลับน้ำหนักภายในกลุ่มผ่านหน่วยความจำร่วม NVLink ความไม่สมดุลที่วัดได้ — แรงก์ที่ช้าที่สุดหารด้วยค่าเฉลี่ย — ออกมาเป็น 1.074 สำหรับการกำหนดค่า EP4/DP4 และ 1.045 สำหรับ EP2/DP2 สำหรับ decode การตั้งค่าจะยืดออกไป: expert สำรองหนึ่งตัวต่อ GPU หน้าต่างสถิติ 1,000 สเต็ป จัดสรรใหม่ทุก 10,000 สเต็ป และมีความไม่สมดุลที่วัดได้ 1.090 ความแตกต่างระหว่างทั้งสองคือประเด็นสำคัญ prefill เจองานที่มาเป็นระลอกและมีความหลากหลาย จึงต้องปรับสมดุลอย่างรวดเร็ว ส่วน decode เจอสตรีมที่สม่ำเสมอและสามารถใช้หน้าต่างยาวได้ จึงปรับสมดุลไม่บ่อยและแทบไม่ต้องจ่ายอะไรเพื่อสิ่งนั้น

ฝั่งการจัดเส้นทางก็มีลักษณะเดียวกัน คำขอ prefill จะถูกแบ่งกลุ่มตามความยาวบริบททั้งหมดออกเป็นสี่ระดับ คือต่ำกว่า 16K, 16 ถึง 64K, 64 ถึง 256K และ 256K ขึ้นไป และเอนจินจะถูกกำหนดให้กับแต่ละระดับตามสัดส่วนความต้องการใช้พลังประมวลผลของระดับนั้นในรอบก่อนหน้า ภายใน GPU ขนาดชังก์ของแต่ละขั้นตอน prefill ไม่ได้คงที่ โมเดลต้นทุนแบบกำลังสองที่ปรับให้เข้ากับข้อมูลจะทำนายว่าขั้นตอนหนึ่งจะใช้เวลานานเท่าใดเมื่อกำหนดจำนวนโทเค็นลำดับและคำนำหน้าที่คำนวณไว้แล้ว และตัวจัดตารางจะแก้ปัญหาเพื่อหาชังก์ที่ใหญ่ที่สุดซึ่งพอดีกับงบประมาณ 32,768 โทเค็นภายในเวลาที่เหลือ ตัวบาลานซ์ decode ปรับสมดุลสองมิติพร้อมกัน คือจำนวนคำขอและความยาว KV cache รวม โดยส่งคำขอสั้นไปยัง GPU ที่มีภาวะพร้อมกันต่ำและมีแคชยาว และส่งคำขอยาวไปยัง GPU ที่มีแคชเล็ก สรุปของ DeepSeek เองว่าทั้งหมดนี้ให้ผลตอบแทนเท่าใด: ประมาณ 80 เปอร์เซ็นต์ของ benchmark ออฟไลน์ที่ปรับสมดุลสมบูรณ์แบบ

แคช และคำถามเรื่องสามวัน

KV cache อยู่บนคลัสเตอร์ 3FS โดยเฉพาะ ไม่ได้อยู่ในหน่วยความจำโฮสต์ภายใน และการตัดสินใจนี้เป็นตัวกำหนดส่วนที่เหลือของการออกแบบระบบจัดเก็บ ข้อมูลถูกจัดเก็บด้วย erasure coding แบบ 10+2 ดังนั้นแต่ละกลุ่มการเข้ารหัสจะยังคงอยู่รอดได้แม้มีโหนดล้มเหลวพร้อมกันสองโหนด; การอ่านจะส่งคำขอไปยังทั้ง 11 โหนดในกลุ่ม และคำตอบใด ๆ 10 รายการก็เพียงพอต่อการถอดรหัส มีเวิร์กเกอร์เก็บขยะทำงานบนทุกโหนดจัดเก็บ และทำการ evict ตาม LRU เมื่อเกิน watermark เซิร์ฟเวอร์ที่แนะนำมีไดรฟ์โซลิดสเตต 20 ไดรฟ์ ขนาด 30.73 TB ต่อไดรฟ์ และรองรับการอ่านอย่างน้อย 40 GB/s และการเขียน 5 GB/s โดยมีขนาดความจุที่ออกแบบให้เก็บข้อมูลได้ประมาณ 24 ชั่วโมงต่อเซิร์ฟเวอร์ ในทางปฏิบัติ คลัสเตอร์ทำงานที่แคชเชิงตรรกะประมาณ 14.4 TB ต่อ GPU ที่ออนไลน์ โดยมีความจุทางกายภาพมากกว่านั้น

การคงอยู่ในแคชคือจุดที่การแลกเปลี่ยนเริ่มเห็นได้ชัด ไม่มีตรรกะการหมดอายุฝั่งแคช ส่วน TTL ถูกกำหนดฝั่งสตอเรจไว้ที่สามวันสำหรับทราฟฟิกของเอเจนต์ และเจ็ดวันสำหรับทราฟฟิกของแชตบอต บนคลัสเตอร์ที่เก็บสตอเรจโซลิดสเตตประมาณ 100 เพタไบต์ การแยกนี้มีอยู่เพราะทราฟฟิกของแชตบอตมีหางยาวของการฮิตหนักกว่ามาก แคชจำนวนเล็กน้อยถูกอ่านซ้ำหลายครั้ง ดังนั้นการสูญเสียแคชนั้นจึงส่งผลต่ออัตราการฮิตโดยรวมมากกว่าที่ปริมาณจะบ่งชี้ ต้นทุนที่วัดได้ของ DeepSeek จากการลดระยะเวลาการเก็บแคชของแชตบอตเหลือสามวันอยู่ที่ร้อยละ 0.5 ถึง 1 ของอัตราการฮิตแคช นั่นเป็นตัวเลขเล็กๆ ที่บังเอิญแทนปริมาณพรีฟิลจำนวนมากที่ต้องคำนวณใหม่

สลิดดิงวินโดว์แอตเทนชันมีแคชแยกต่างหากพร้อมกฎที่แตกต่างกัน แคช SWA ไม่เข้าไปในเพจบล็อก แต่ละซีเควนซ์ใช้หนึ่งสล็อตขนาดคงที่ในหน่วยความจำโฮสต์ และสำหรับ DeepSeek-V4.1-Flash เลเยอร์ที่จัดเก็บคือ 20 เลเยอร์แรก มีเพียงพื้นที่นั้นที่คงอยู่ — 20 เลเยอร์ คูณ 134 โทเค็น คูณ 528 ไบต์ ซึ่งเท่ากับ 1,415,040 ไบต์ต่อซีเควนซ์ในรูปแบบ MXFP8 ไม่มีข้อมูลใดถูกส่งไปยังคลัสเตอร์จัดเก็บข้อมูล ข้อมูลยังคงอยู่ในหน่วยความจำของเครื่องที่สร้างขึ้น โดยมีไดเรกทอรีในหน่วยความจำที่บันทึกว่าเครื่องใดเก็บอะไรไว้ และการเข้าถึงข้ามเครื่องจะดึงข้อมูลกลับมาผ่าน VLAN ความเร็ว 400 Gbps

สองกลไกที่ก่อให้เกิดตัวเลขพาดหัวข่าว

Bounded replay เป็นวิธีที่น่าสนใจกว่าในสองวิธีนี้ เพราะเปลี่ยนต้นทุนที่ไม่จำกัดให้กลายเป็นค่าคงที่ โดยปกติ การเกิด cache miss ของ sliding-window หมายถึงการคำนวณหน้าต่างใหม่ตั้งแต่ต้น และต้นทุนจะเพิ่มขึ้นตามความยาว context และจำนวน layer แต่ DeepSeek จะคำนวณใหม่เฉพาะ 128 token ล่าสุด และตัด attention window ให้เหลือเพียงส่วนนั้น ทำให้ได้ SWA cache แบบประมาณในต้นทุนคงที่ ในฝั่ง encoder สิ่งนี้ทำให้ความยาวของ prefix-cache ที่ hit เป็นอิสระจาก SWA cache อย่างสิ้นเชิง: หาก SWA cache หายไป จะมีการ replay 128 token สุดท้ายของ prefix ที่ hit ขณะที่ block cache ถูกนำกลับมาใช้โดยไม่ถูกแตะต้อง

ฝั่งเดโคเดอร์คือจุดที่ประหยัดได้มาก ในสถาปัตยกรรมนี้ แคชบล็อกของเลเยอร์เดโคเดอร์ถูกโปรเจกต์จาก hidden state ของเลเยอร์เอนโคเดอร์ตัวสุดท้าย ดังนั้นจึงต้องคำนวณเฉพาะแคช SWA ของเดโคเดอร์ในแต่ละเลเยอร์ — และการสร้างมันขึ้นมาใหม่ให้ตรงเป๊ะจะหมายถึงการผลัก 2,560 โทเคนสุดท้ายผ่าน 20 เลเยอร์เดโคเดอร์ในทุกครั้งที่ทำ prefill แต่การรีเพลย์ 128 โทเคนแทน และใช้ผลลัพธ์สำหรับ decode เท่านั้นโดยไม่ปล่อยให้เข้าสู่ prefix cache ช่วยลดการคำนวณ prefill ทั้งหมดลงเกือบครึ่ง การเปลี่ยนแปลงเพียงครั้งเดียวนั้นมีค่ามากกว่าการปรับแต่งเคอร์เนลส่วนใหญ่ และเป็นสิ่งที่ทีมที่เป็นเจ้าของสถาปัตยกรรมโมเดลเท่านั้นจึงจะทำได้

ผลงานของ DSpark เล็กกว่าและเป็นแบบทั่วไปมากกว่า โทเคนร่างมีความน่าจะเป็นการยอมรับที่แตกต่างกันไปตามคำขอและตำแหน่ง ดังนั้นการตรวจสอบร่างห้าตัวแบบคงที่ในแต่ละขั้นจึงสิ้นเปลืองการประมวลผลกับโทเคนที่จะถูกปฏิเสธ หัววัดความมั่นใจจะทำนายอัตราการยอมรับของโทเคนร่างแต่ละตัว และตัวจัดกำหนดการจะเรียงลำดับร่างตามผลตอบแทนคาดหวังและตรวจสอบเฉพาะคำนำหน้าที่เพิ่มทรูพุตได้สูงสุด ในการใช้งานจริง โมเดลร่างยังคงสร้างโทเคนห้าตัวต่อขั้น โดยจำนวนที่ตรวจสอบลดลงจาก 5.00 เหลือระหว่าง 3.2 ถึง 4.4 ซึ่งลดลงประมาณ 30 เปอร์เซ็นต์ ขณะที่ความยาวที่ยอมรับแทบไม่เปลี่ยน — 3.29 เทียบกับ 3.20 เมื่ออ่านจากข้อมูล benchmark EP64/DP64 แล้ว นั่นคิดเป็นทรูพุตเพิ่มขึ้น 4 ถึง 7 เปอร์เซ็นต์ที่ประมาณ 60 ซีเควนซ์พร้อมกันต่อแรงก์ ที่ 60 พอดี ทรูพุตต่อแรงก์เพิ่มจาก 13,730 เป็น 14,466 โทเคนต่อวินาที ต่ำกว่าประมาณ 16 ซีเควนซ์พร้อมกัน เทคนิคนี้จะขาดทุนสุทธิเล็กน้อย ซึ่งควรรู้ไว้ก่อนนำไปใช้กับการติดตั้งใช้งานที่มีทราฟฟิกต่ำ

ตัวเลข 155 ล้านล้านหมายความว่าอย่างไร

ตัวเลขที่ถูกอ้างอิงมากที่สุดซึ่งแนบมากับการเปิดตัวนี้ คือคลัสเตอร์เดียวที่ให้บริการ 155 ล้านล้านโทเคนต่อวัน ด้วยรายได้รวม 38 ดอลลาร์สหรัฐต่อ GPU-ชั่วโมง ณ ราคาแบบช่วงเวลาความต้องการต่ำ ทั้งสองส่วนเป็นข้อมูลที่ผู้ขายรายงานเอง และไม่มีส่วนใดเป็น benchmark ที่คุณทำซ้ำได้ ซึ่งไม่ได้ทำให้สิ่งเหล่านั้นไม่น่าสนใจ — ตัวเลขรายได้ต่อ GPU-ชั่วโมงเป็นการกล่าวอ้างคนละประเภทกับตัวเลข throughput อย่างแท้จริง เพราะมันรวมอัตราการใช้งาน ราคา และอัตราการเข้าใช้แคช (cache hit rate) ไว้ในบรรทัดเดียว อีกทั้งยังเป็นตัวเลขที่มีแนวโน้มถูกอ้างอิงโดยไม่มีเงื่อนไขกำกับมากที่สุด ดังนั้นเงื่อนไขกำกับเหล่านี้จึงควรค่าแก่การบันทึกไว้: คลัสเตอร์เดียว, ราคาแบบช่วงเวลาความต้องการต่ำ, รายได้ไม่ใช่ต้นทุน และเป็นผลรวมครอบคลุมทั้ง prefill, decode และ vision encoder

การเปิดเผยสองเรื่องที่เล็กกว่ามีประโยชน์โดยตรงมากกว่า เคอร์เนลถอดรหัส FlashMLA ในรีโพซิทอรีสาธารณะขาดการปรับแต่งแอสเซมบลีที่ปรับมือหนึ่งจุดซึ่งเวอร์ชันภายในมีอยู่ ทำให้เมื่อแยกดูแล้วช้ากว่า 5 ถึง 10 เปอร์เซ็นต์ DeepSeek ระบุว่าประสิทธิภาพแบบ end-to-end ต่างกันไม่เกิน 5 เปอร์เซ็นต์ และโมเดล draft ภายในสำหรับ speculative decoding นั้นใหม่กว่าโมเดลที่เผยแพร่ โดยอธิบายว่าความแตกต่างด้านประสิทธิภาพมีเล็กน้อย ข้อความทั้งสองนี้กำหนดความคาดหวังว่าบุคคลภายนอกจะเข้าถึงประสิทธิภาพที่เผยแพร่ได้มากเพียงใดโดยการคัดลอกโค้ด และคำตอบคือ: ได้เกือบทั้งหมด โดยมีเงื่อนไขว่าฮาร์ดแวร์ต้องตรงกัน

รีโพซิทอรีในสภาพที่เป็นอยู่ในปัจจุบัน

ภาพแคปเจอร์ด้านบนถูกบันทึกเมื่อวันที่ 21 ตุลาคม 2026 และแสดงให้เห็นว่าหน้านั้นอ่านได้ว่า 16.3k ดาว GitHub API ซึ่งสอบถามในวันเดียวกันส่งคืนค่า 16,590 ดาว, 1,649 ฟอร์ก และ 176 ปัญหาที่เปิดอยู่ โดยปิดใช้งาน issues และเปลี่ยนเส้นทางการสนทนาไปยัง GitHub Discussions แทน จำนวนดาวยังคงเพิ่มขึ้นเรื่อย ๆ ตั้งแต่นั้นมา ดังนั้นให้อ่านตัวเลขทุกตัวที่นี่เป็นตราประทับเวลา มากกว่าจะเป็นคุณสมบัติของโค้ด ทราฟฟิกขนาดนั้นภายในไม่ถึงหนึ่งสัปดาห์บอกถึงความสนใจในสแต็กการให้บริการของ DeepSeek มากกว่าความพร้อมของโค้ด และจำนวนรีลีสที่เป็นศูนย์บอกส่วนที่เหลือ

หากคุณกำลังคิดจะรันมันด้วยตัวเอง

สรุปตามตรงคือ DeepInfer คุ้มค่าที่จะอ่านอย่างละเอียด แต่ใช้งานจริงได้ยาก คำถามสี่ข้อจะบอกคุณว่ามันเหมาะกับคุณหรือไม่

• คุณมี SM100 หรือ Ascend 950 หรือไม่? สิ่งอื่นทั้งหมดในชุดเครื่องมือจะตามมาจากข้อนี้เพียงข้อเดียว หากไม่มีตัวเร่งที่ถูกต้อง ตัวเลขที่เผยแพร่ก็ไม่สามารถนำมาใช้ได้ และพอร์ตจากชุมชนยังไม่ผ่านการตรวจสอบในระดับการผลิต

• คุณสามารถรันดีโค้ด GPU 64 ตัวในโดเมนการสื่อสารเดียวได้หรือไม่? Wide expert parallelism ไม่ใช่การปรับแต่งที่ข้ามได้ มันคือการกำหนดค่าที่เส้นทางการดีโค้ดถูกออกแบบมาโดยรอบ ใต้สเกลนั้นคุณกำลังรันระบบที่แตกต่างออกไปแต่ใช้ชื่อเดียวกัน

• คุณมี prefix cache อยู่แล้วหรือไม่? หากไม่มี คุณกำลังเปรียบเทียบ compute path ของ DeepInfer กับสแต็กคู่แข่งที่มาพร้อมกับสิ่งนั้น และการเปรียบเทียบจะดูแย่กว่าที่การออกแบบควรจะเป็น

• คุณมีกำลังพอจะเขียนเลเยอร์การจัดเส้นทางเองไหม? การแบ่ง bucketing ช่วง prefill การบาลานซ์ช่วง decode และการกำหนดผู้เชี่ยวชาญใหม่ถูกอธิบายไว้ละเอียดพอที่จะนำไปสร้างใหม่ได้ และการสร้างใหม่เหล่านั้นต้องใช้เวลาหลายสัปดาห์ซึ่งรีโพซิทอรีไม่ได้ทำให้คุณ

หากคุณไม่อยากเป็นเจ้าของรายการใด ๆ ข้างต้น

สำหรับทีมส่วนใหญ่ คำถามในทางปฏิบัติไม่ใช่ว่าจะติดตั้งใช้งาน DeepSeek-V4.1-Flash อย่างไร แต่คือจะเรียกใช้มันจากที่ไหน โมเดลนี้พร้อมใช้งานผ่าน API ที่เข้ากันได้ โดยไม่ต้องสร้างคลัสเตอร์ GPU 128 ตัวหรือเขียนโหลดบาลานเซอร์ขึ้นมาใหม่ และนี่คือโมเดลเดียวกันกับที่สถาปัตยกรรมของมันถูกอธิบายไว้ในบทความนี้ — การจัดการคอนเท็กซ์แบบเดียวกัน พฤติกรรมเอาต์พุตแบบมีโครงสร้างแบบเดียวกัน โดยไม่ต้องทำงานแยกส่วน (disaggregation)

การเปรียบเทียบที่ควรทำไม่ใช่ว่าเอนจินใดเร็วกว่าในเชิงนามธรรม เพราะตัวเลขที่เผยแพร่นั้นเป็นการวัดที่ผู้ขายรายงานบนฮาร์ดแวร์ที่ผู้อ่านส่วนใหญ่ไม่มี แต่คือว่าภาระงานเป็นแบบที่ TTL แคช 3 วันและพูลถอดรหัส 64 GPU เปลี่ยนราคา หรือเป็นแบบที่การส่งคำขอทุก ๆ ไม่กี่วินาทีผ่าน API ถูกกว่าการดำเนินการใด ๆ ที่อธิบายไว้ข้างต้นอย่างง่าย ๆ สำหรับกรณีที่สอง — ซึ่งเป็นกรณีส่วนใหญ่ — ปริมาณ DeepInfer ที่ควรใช้คือไม่ใช้เลย และปริมาณที่ควรอ่านคือทั้งหมด เริ่มจาก หน้าโมเดล DeepSeek V4.1 Flash หากคุณต้องการเอนด์พอยต์; เริ่มจาก README ของรีโพซิทอรีหากคุณต้องการรู้ว่าเอนด์พอยต์กำลังทำอะไรอยู่