การเรียกใช้เครื่องมือของ DeepSeek V4.1 Flash มาถึง vLLM แล้ว: แท็กที่มีช่องว่างทำให้อะไรพัง

DeepSeek V4.1 Flashเปิดให้ใช้งานทั่วไปตั้งแต่ 10 กันยายน 2026 และในช่วงสิบสองวันแรกของชีวิต โมเดลนี้มีช่องโหว่ที่ไม่มีใครเขียนถึง: มันสามารถให้เหตุผลได้ มันมองเห็นภาพได้ มันเก็บบริบทได้ถึงหนึ่งล้านโทเคน และมันไม่สามารถเรียกใช้เครื่องมือได้อย่างเชื่อถือได้ผ่านสแต็กการให้บริการแบบเปิดที่ใช้กันอย่างแพร่หลายที่สุด ช่องโหว่นั้นปิดลงแล้วใน vLLM — ไม่ใช่ด้วยแฟล็กการตั้งค่า แต่ด้วยการเขียน parser ใหม่ พูลรีเควสต์สองรายการรับงานนี้ไว้ และเหตุผลที่จำเป็นต้องมีมันคือส่วนที่น่าสนใจ

เวอร์ชันสั้น: DeepSeek V4.1 Flash ส่งการเรียกเครื่องมือในรูปแบบแท็กที่ตัวตรวจจับ DeepSeek V4 ที่มีอยู่ไม่รู้จัก ดังนั้นบนการติดตั้ง vLLM แบบมาตรฐาน มาร์กอัปการเรียกเครื่องมือจึงมาเป็นข้อความธรรมดาแทนที่จะเป็นเอาต์พุตแบบมีโครงสร้าง ไม่มีข้อผิดพลาดใด ๆ โมเดลดูเหมือนเพียงแค่ปฏิเสธที่จะเรียกฟังก์ชัน หากคุณกำลังทดสอบลูปเอเจนต์กับ DeepSeek V4.1 Flash ที่โฮสต์เอง แล้วสรุปว่าโมเดลใช้เครื่องมือได้แย่ นี่คือสิ่งที่คุณกำลังดูอยู่เป็นไปได้สูง

จริง ๆ แล้วมีอะไรเปลี่ยนแปลงไปในสแต็กการให้บริการ

การแยกวิเคราะห์การเรียกใช้เครื่องมือของ vLLM สำหรับโมเดล DeepSeek ได้อยู่ในสองที่มาระยะหนึ่งแล้ว: ฟรอนต์เอนด์ Python และฟรอนต์เอนด์ Rust ที่ใหม่กว่า โดยงานระดับไวยากรณ์นั้นมอบหมายให้กับโครงการ XGrammar การนำการสนับสนุน V4.1 Flash มาใช้หมายถึงการพอร์ต C++ deepseek_xml การแปลงภายใน XGrammar ไปยังตัวสร้าง Rust จากนั้นจึงเชื่อมต่อการเข้ารหัสของโมเดลเองเข้ากับไดเรกทอรี tokenizer ของ vLLM

• งาน Rust frontend คือ PR #56235 ซึ่งพอร์ตการแปลง XGrammar C++ deepseek_xml ไปยัง Rust builder โดยมีเทสต์ใหม่ 18 รายการสำหรับ V4.1 โดยเฉพาะ และชุดทดสอบที่มีอยู่เดิมทั้งหมด — 472 เทสต์ใน vllm-parser และ 326 ใน vllm-chat — ยังคงผ่านทั้งหมด

• งานฝั่ง frontend ของ Python คือ PR #56408 ซึ่งยังเป็นฉบับร่างอยู่ โดยต้องรอให้การเปลี่ยนแปลงใน XGrammar ต้นทาง (mlc-ai/xgrammar#885) ถูกนำเข้า/merge ก่อน และรายงานว่ามีการทดสอบผ่าน 110 รายการเมื่อนำ dependency นั้นไปใช้

• โมดูลการเข้ารหัสใหม่คือ vllm/tokenizers/deepseek_v41_encoding.py — เป็นไฟล์แยกต่างหาก ไม่ใช่สาขาย่อยภายใน V4 encoding ซึ่งบอกคุณว่าไวยากรณ์ของแท็กแตกต่างกันอย่างแท้จริง ไม่ใช่เพียงแค่การขยายเพิ่ม

• การเรียกใช้เป็นแบบระบุชัดเจน: --tool-parser deepseek_v41 ไม่มีกลไกสำรองแบบตรวจจับอัตโนมัติที่แอบทำสิ่งที่ถูกต้องให้เอง

แท็กที่มีการเว้นวรรคคือเรื่องราวทั้งหมด

เหตุผลที่ตัวแยกวิเคราะห์ใหม่มีอยู่แทนที่จะเป็นนิพจน์ปกติที่ขยายให้กว้างขึ้นคือเรื่องช่องว่าง DeepSeek V4.1 Flash เขียนแท็กเครื่องมือ DSML โดยมีช่องว่างระหว่างโทเค็น แพตเทิร์นของตัวตรวจจับ V4 คาดหวังรูปแบบที่ไม่มีช่องว่าง จึงจับคู่ไม่สำเร็จ และการจับคู่ที่ล้มเหลวในตัวแยกวิเคราะห์การเรียกเครื่องมือนั้นเงียบโดยการออกแบบ — ข้อความจะถูกส่งผ่านเป็นเนื้อหาแทนที่จะโยนข้อผิดพลาด

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

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

ทำไมเรื่องนี้จึงสำคัญสำหรับ V4.1 Flash มากกว่าที่เคยเป็นสำหรับ V4

การเรียกใช้เครื่องมือไม่ใช่แค่ของที่ “มีก็ดี” สำหรับโมเดลนี้โดยเฉพาะ DeepSeek V4.1 Flash เป็นโมเดลแบบ mixture-of-experts ขนาด 552 พันล้านพารามิเตอร์ โดยมี 8 พันล้านพารามิเตอร์ที่แอ็กทีฟตอนอินพุต และ 16 พันล้านพารามิเตอร์ที่แอ็กทีฟตอนเอาต์พุต มีหน้าต่างบริบทขนาด 1 ล้านโทเคน และเอาต์พุตสูงสุด 384K โทเคน การแบ่งว่าพารามิเตอร์ส่วนใดแอ็กทีฟนี่แหละคือเบาะแส: โมเดลถูกสร้างมาให้รับอินพุตขนาดใหญ่ — รีพозитори ชุดเอกสาร ร่องรอยการเรียกใช้เครื่องมือที่ยาว — แล้วส่งเอาต์พุตแบบมีโครงสร้างที่ยาวออกมา นั่นคือรูปร่างแบบเอเจนต์ ไม่ใช่รูปร่างแบบแชต

สเปกการเปิดตัวที่เหลือชี้ไปในทิศทางเดียวกัน เวตที่ใช้สัญญาอนุญาต MIT, KV cache 890 ไบต์ต่อโทเคน, 45 ล้านล้านโทเคนสำหรับการพรีเทรน, วิสชันแบบเนทีฟ ตัวเลข KV cache คือสิ่งที่สำคัญในเชิงปฏิบัติการที่บริบท 1M: มันคือสิ่งที่ทำให้บันทึกบทสนทนาของเอเจนต์ที่ยาวสามารถเก็บไว้ในหน่วยความจำได้อย่างคุ้มค่า และเป็นเหตุผลว่าทำไมโมเดลนี้จึงดูสมเหตุสมผลในฐานะผู้ทำงานราคาถูกในลูปที่โมเดลที่แพงกว่าคอยกำกับดูแล

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

อะไรยังเปิดอยู่

สถานการณ์ตามจริง ณ วันที่ 22 กันยายน 2026:

• เส้นทาง Rust frontend (PR #56235) เป็นเส้นทางที่มีความครอบคลุมการทดสอบอย่างเต็มรูปแบบทั้งในกรณีทดสอบ V4.1 ใหม่และชุดทดสอบที่มีอยู่เดิม หากคุณใช้บิลด์ vLLM ที่รวมสิ่งนี้ไว้ parser ก็พร้อมใช้งานสำหรับคุณตั้งแต่วันนี้

• เส้นทางฟรอนต์เอนด์ Python (PR #56408) เป็นฉบับร่างและมีการพึ่งพาภายนอก หากคุณถูกปักหมุดไว้กับบิลด์ที่เก่ากว่าการเปลี่ยนแปลง XGrammar ฟรอนต์เอนด์ Python จะยังไม่ให้การแยกวิเคราะห์เครื่องมือ V4.1 แก่คุณในตอนนี้

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

• ยังไม่มีหลักฐานสาธารณะใด ๆ เกี่ยวกับการทดสอบประสิทธิภาพการเรียกใช้เครื่องมือแบบอิสระที่รันกับ V4.1 Flash โดยมีตัวแยกวิเคราะห์ตัวใหม่ติดตั้งอยู่ สิ่งที่เราทราบคือระบบพื้นฐานทำงานได้และการทดสอบผ่าน ไม่ว่าคุณภาพการเรียกใช้เครื่องมือของโมเดลจะดีหรือไม่นั้นเป็นคำถามแยกต่างหากที่การ merge ไม่ได้ตอบ

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

หากคุณไม่ต้องการรันสแตกการให้บริการด้วยตัวเอง

มีเส้นทางที่สั้นกว่า DeepSeek V4.1 Flash พร้อมใช้งานผ่าน endpoint ของ OrcaRouter สำหรับมัน ซึ่งหมายความว่าพฤติกรรมการเรียกใช้เครื่องมือมาถึงในรูปแบบการเรียก API ปกติ แทนที่จะเป็นปัญหาด้านบิลด์ — ไม่ต้องจับคู่เวอร์ชัน XGrammar ไม่ต้องเลือกฟรอนต์เอนด์ ไม่ต้องจำแฟล็กการเปิดใช้งาน เหตุผลที่เรื่องนี้สำคัญโดยเฉพาะตรงนี้ก็คือ การแก้ไขนั้นลงเอยในสองที่ซึ่งมีความสมบูรณ์ต่างกัน และ endpoint แบบโฮสต์ทำให้การตัดสินใจนั้นยุบเหลือศูนย์

คีย์เดียวกันยังเข้าถึงโมเดลอื่น ๆ ที่เหลือที่คุณจะนำมาเปรียบเทียบด้วย ซึ่งเป็นคุณสมบัติที่มีประโยชน์เมื่อคำถามไม่ใช่ "พาร์เซอร์นี้ถูกต้องหรือไม่" แต่เป็น "โมเดลนี้ดีพอสำหรับลูปของฉันหรือไม่" คุณสามารถวาง DeepSeek V4.1 Flash ไว้หลังกฎการจัดเส้นทางในฐานะตัวดำเนินการราคาถูก และสลับไปยังโมเดลที่แข็งแกร่งกว่าเมื่อการเรียกนั้นล้มเหลว โดยไม่ต้องมีสัญญาที่สองหรือ SDK ที่สอง การลองใช้โมเดลที่เพิ่งรองรับการเรียกเครื่องมือมาได้เพียงสองสัปดาห์ก็คือสถานการณ์ที่การสลับสำรองอัตโนมัติถูกสร้างขึ้นมาเพื่อรองรับพอดี

สิ่งที่ควรดูต่อไป

สามสิ่งจะเปลี่ยนเรื่องนี้จากเรื่องระบบท่อให้กลายเป็นคำตัดสิน:

• PR #56408 กำลังออกจากสถานะฉบับร่าง ซึ่งจะทำให้เส้นทางฟรอนต์เอนด์ Python เป็นจริง และยุติสถานการณ์การสนับสนุนแบบสองระดับ

• การประเมินแบบเอเจนต์อิสระหรือการประเมินการเรียกใช้เครื่องมือ (tool-calling) ที่รันกับ V4.1 Flash บนสแต็กการให้บริการแบบคงที่ โมเดลนี้เปิดตัวมาได้สิบสองวันแล้ว และตัวพาร์เซอร์ก็ใช้งานได้จริงมาน้อยกว่านั้น ดังนั้นคะแนน tool-calling ใด ๆ ที่คุณเห็นถูกอ้างอิงสำหรับมันในตอนนี้จึงเป็นสิ่งที่ควรสอบถามให้ชัด — การตั้งค่ามีความสำคัญพอ ๆ กับตัวโมเดล

• ว่าสแตกการให้บริการอื่น ๆ จะทำตามหรือไม่ vLLM เป็นตัวที่มี PR สาธารณะ ปัญหาแท็กที่มีการเว้นวรรคไม่ได้จำเพาะกับ vLLM ดังนั้นสแตกใดก็ตามที่นำตัวตรวจจับ V4 ไปใช้โดยไม่ได้อนุมานใหม่จากเอาต์พุต V4.1 ย่อมมีความล้มเหลวแบบเงียบ ๆ แบบเดียวกันแฝงอยู่ในนั้น

จนกว่าสิ่งแรกในนั้นจะเกิดขึ้นจริง บทสรุปที่แม่นยำก็ยังแคบและควรพูดให้ตรงไปตรงมา: DeepSeek V4.1 Flash เป็นโมเดล GA ที่มีน้ำหนักแบบ MIT, คอนเท็กซ์ 1M และเพดานเอาต์พุต 384K และการเรียกใช้เครื่องมือของมันตอนนี้ทำงานบนเส้นทาง Rust ใน vLLM ด้วยแฟล็ก parser ที่ระบุชัดเจน นั่นเป็นก้าวจริง และยังไม่ใช่ผลลัพธ์