LFM3-1.7B บน vLLM: ผ่านไปเก้าวัน การรองรับแบบเนทีฟยังคงเป็นเพียง PR ที่เปิดอยู่สองรายการ

ของ Liquid AI LFM3-1.7B เปิดตัวเมื่อวันที่ 27 ตุลาคม 2026 พร้อมการ์ดโมเดลที่ระบุคำสั่ง vllm serve "LiquidAI/LFM3-1.7B" ราวกับว่าเป็นคำสั่งธรรมดา ๆ เก้าวันต่อมา vLLM ต้นน้ำกลับไม่มีสถาปัตยกรรม Lfm3ForCausalLM สำหรับใช้รันโมเดลนี้ สิ่งที่มีอยู่แทนคือ feature request ที่เปิดขึ้นเมื่อวันที่ 30 ตุลาคม, pull request ฝั่ง kernel หนึ่งรายการที่ทุกอย่างอื่นพึ่งพาอยู่ และ PR โมเดลที่ยังเปิดอยู่หกรายการ — สองรายการในนั้นพัฒนาโมเดลข้อความ LFM3-1.7B เดียวกันในสองวิธีที่แตกต่างกัน และทั้งสองรายการยังไม่ถูก merge

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

บนการ์ดระบุว่า vLLM ตารางโมเดลที่รองรับระบุว่า LFM2

เอกสาร supported-models ของ vLLM เองระบุสถาปัตยกรรมของ Liquid AI ไว้สามรายการ ได้แก่ Lfm2ForCausalLM, Lfm2MoeForCausalLM และ Lfm2VlForConditionalGeneration โดยไม่มีรายการ LFM3 ส่วนการ์ด LFM3-1.7B ระบุว่าเช็กพอยต์นี้ "ใช้งานได้กับ vLLM, SGLang และบิลด์ llama.cpp ที่รองรับ LFM3" พร้อมทั้งให้คำสั่งสำหรับการให้บริการโดยไม่มีแฟล็กใด ๆ ต่อท้าย

ความสอดคล้องอยู่ในการกำหนดค่าของเช็กพอยต์เอง {{1}}LFM3-1.7B{{/1}} มี auto_map ที่ชี้ไปยัง modeling_lfm3.py ที่มาพร้อมกัน ดังนั้นโค้ดฝั่ง Hugging Face จึงมีอยู่และโคลนตัวเองเข้าไปในตัวโหลดที่อนุญาตให้ใช้โค้ดระยะไกล issue สำหรับติดตามการพอร์ตของ vLLM, {{2}}#64645{{/2}} — "{{3}}[ฟีเจอร์]: รองรับโมเดล LiquidAI LFM3{{/3}}" ซึ่งเปิดเมื่อวันที่ 30 ตุลาคมโดย abhijithneilabraham — ระบุตรง ๆ ถึงผลที่ตามมา: "{{4}}vLLM ไม่มี Lfm3ForCausalLM{{/4}}" ทางเลือกที่ระบุไว้คือทางออกสำรองที่คนส่วนใหญ่จะใช้ในที่สุดในเดือนนี้: "{{5}}รัน LFM3 ผ่านโค้ดระยะไกลของเช็กพอยต์ด้วยแบ็กเอนด์ Transformers ซึ่งต้องสละ paged attention และแคชสถานะ conv{{/5}}"

ข้อแลกเปลี่ยนนี้ควรพูดให้ตรง ๆ เพราะ "รันบน vLLM" กับ "รันบนแบ็กเอนด์ transformers ของ vLLM" เป็นผลิตภัณฑ์ที่แตกต่างกัน Paged attention คือกลไกที่ทำให้ vLLM จัดแบตช์คำขอที่มีความยาวแตกต่างกันมากได้โดยไม่สิ้นเปลืองหน่วยความจำ KV ส่วนแคชสถานะ conv คือแนวคิดเดียวกันที่นำไปใช้กับเลเยอร์ short-convolution ของสถาปัตยกรรมนี้ ถ้าเอาทั้งสองอย่างออกไป คุณจะได้เอนด์พอยต์ที่ทำงานได้ แต่ได้ละทิ้งเหตุผลสองประการที่ทำให้ vLLM มีอยู่ สำหรับโมเดล 1.7B ที่ให้บริการที่ระดับการทำงานพร้อมกันต่ำ นั่นอาจเป็นสิ่งที่ยอมรับได้สำหรับช่วงสุดสัปดาห์ แต่ไม่ใช่รูปแบบที่ยอมรับได้สำหรับโปรดักชัน

ทำไมโมเดล 1.7B ถึงต้องทำงานกับเคอร์เนลเลย

LFM3-1.7B ไม่ใช่การปรับแต่งซ้ำแบบตรงไปตรงมาของตระกูล LFM2 ที่ vLLM ให้บริการอยู่แล้ว แต่เป็นไฮบริด 24 เลเยอร์ที่มีเลเยอร์สามประเภทแทนที่จะเป็นสองประเภท: เลเยอร์คอนโวลูชันสั้นแบบเกต 13 เลเยอร์, เลเยอร์แอตเทนชันแบบหน้าต่างเลื่อน 5 เลเยอร์ที่มีหน้าต่าง 256 โทเค็น และเลเยอร์แอตเทนชันเต็ม 6 เลเยอร์ คอนฟิกของเช็กพอยต์ระบุเรขาคณิตไว้อย่างชัดเจน — conv_L_cache: 7, sliding_window: 256, คำศัพท์ขนาด 128K — และรายการความแตกต่างของ issue ใน vLLM เองก็เพิ่ม QK RMSNorm, เกตเอาต์พุตแอตเทนชันแบบซิกมอยด์ต่อหัว, การนอร์มัลไลเซชันแบบแซนด์วิช และ RoPE บางส่วน (partial_rotary_factor: 0.5) บนเลเยอร์แอตเทนชันเต็ม ซึ่งจัดวางในรูปทรงหางศูนย์แบบเดียวกับที่ Gemma 4 ใช้

ตัวเลขที่ทำให้การพอร์ตแตกคือเลขเจ็ด short convolution ของ LFM2 มีความกว้างสามแทป ส่วน LFM3 ขยายให้เป็นเจ็ด เคอร์เนล causal_conv1d ของ Triton ใน vLLM จะคลายลูปความกว้างชุดหนึ่งแบบคงที่ และอย่างที่ issue สำหรับติดตามงานระบุไว้: "เคอร์เนล prefill ของ Triton causal_conv1d จะคลายลูปความกว้าง 2 ถึง 4 และเคอร์เนล decode จะคลายลูปความกว้าง 2 ถึง 6 ดังนั้นโมเดลความกว้าง 7 จึงไม่สามารถรันบน CUDA ได้ในปัจจุบัน"

ดังนั้น PR แรกในสแต็กจึงไม่ใช่โมเดลเลย #64647, "[Kernel] Support width-7 causal conv1d" ซึ่งเปิดเมื่อวันที่ 30 ตุลาคมโดย abhijithneilabraham แตะไฟล์สองไฟล์และมี 186 บรรทัดที่เพิ่มเข้ามา: PR นี้ขยายเคอร์เนล prefill จากความกว้าง 2–4 เป็น 2–7 และเคอร์เนล decode จาก 2–6 เป็น 2–7 และทำให้ wrapper ทั้งสองตัว raise ValueError สำหรับค่าใดๆ นอกช่วงนั้น คำอธิบายของ PR เองอธิบายว่าทำไมการปฏิเสธจึงสำคัญพอๆ กับการขยาย: ก่อนการเปลี่ยนแปลง "weight ที่กว้างกว่านั้นรันโดยไม่มีสาขาที่ตรงกันและคืนค่าที่ผิด" ความเสียหายเชิงตัวเลขแบบเงียบเป็นความล้มเหลวที่แย่กว่าการปฏิเสธ และเป็นสิ่งที่แสดงออกเฉพาะกับโมเดลที่คุณบังเอิญลองใช้เท่านั้น

มีข้อแม้หนึ่งข้อที่ควรระบุกำกับไปพร้อมกับ PR นั้น ผู้เขียนระบุตรงๆ ว่าตนไม่มีเครื่อง CUDA: เส้นทางอ้างอิงบน CPU ผ่านการทดสอบ 96 รายการ เคอร์เนล Triton ถูกตรวจสอบด้วยการวิเคราะห์เชิงสถิตบน AST ของเคอร์เนล และการตรวจสอบความถูกต้องบน GPU ถูกปล่อยให้เป็นหน้าที่ของ CI นั่นเป็นการเปิดเผยอย่างตรงไปตรงมามากกว่าที่จะเป็นข้อบกพร่อง แต่หมายความว่าการเปลี่ยนแปลงเพียงรายการเดียวที่ PR อื่นๆ ของ LFM3 ทุกอันต้องพึ่งพานั้น ยังไม่เคยถูกทดลองบนฮาร์ดแวร์ที่ผู้อ่านส่วนใหญ่จะรันมัน

การนำไปใช้สองแบบของโมเดลข้อความเดียวกัน

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

PR #64959, "[Model] Add LiquidAI LFM3 (Lfm3ForCausalLM)" ซึ่งเปิดเมื่อวันที่ 1 พฤศจิกายนโดย atmikshetty เป็นตัวเลือกที่อนุรักษ์นิยม: มีเจ็ดไฟล์ และตามคำอธิบายของตัวเองแล้ว มันนำ ShortConv ที่ความกว้าง 7, Lfm2MLP, ตัวแมปน้ำหนัก LFM2 และ proportional RoPE ที่มีอยู่มาใช้ซ้ำ โดยไม่เปลี่ยนแปลงองค์ประกอบหลักใด ๆ มันลงทะเบียนโมเดลใน registry เพิ่มโมเดลลงในชุดทดสอบโมเดลแบบไฮบริดและตารางโมเดลที่รองรับ และ—ซึ่งมีประโยชน์สำหรับใครก็ตามที่ทำให้มันทำงานได้—จัดทำเอกสารแฟล็กสำหรับการให้บริการที่มันตรวจสอบแล้ว ได้แก่ --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice ส่วนการตรวจสอบความถูกต้องรายงานว่ามีการทดสอบเคอร์เนล 324 รายการผ่านบน A100-SXM4-40GB ใน BF16 การทดสอบ registry และการเริ่มต้นผ่าน และการเปรียบเทียบ log-probability กับ reference แบบ remote-code ของ Hugging Face

PR #65826 "[Model] Add LFM3-Text" เปิดเมื่อวันที่ 5 พฤศจิกายนโดย paulpak58 — ซึ่งเป็น Liquid AI — เป็นเวอร์ชันของผู้จำหน่ายเอง: สิบไฟล์และ 829 บรรทัดที่เพิ่มเข้ามา รวมถึงคลาสคอนฟิกของตัวเองภายใต้ transformers_utils/configs/lfm3.py และโมดูลทดสอบของตัวเอง เปิดเป็น "[Model] Add LFM3" และเปลี่ยนชื่อในวันเดียวกันเมื่อตระกูลนี้ถูกแยกออกเป็น PR แบบซ้อนกันสี่รายการ: #65826 สำหรับข้อความ, #65827 สำหรับภาพและภาษา, #65828 สำหรับเสียง และ #65829 สำหรับ omni โดยแต่ละรายการสร้างต่อยอดจากรายการก่อนหน้า

สองสิ่งนี้ไม่ได้ขัดแย้งกันเท่าใดนัก แต่เป็นการดำเนินไปแบบคู่ขนาน และการอภิปรายทำให้เห็นตาข่ายการพึ่งพากันอย่างชัดเจน ใน PR ของเคอร์เนล paulpak58 เขียนเมื่อวันที่ 4 พฤศจิกายนว่า “เรามี PR ภายในของเราเองสำหรับโมเดล LFM3 แต่นี่เป็นส่วนเพิ่มเติมที่เรียบร้อยซึ่งเราให้การสนับสนุนได้” ใน PR ด้านข้อความของชุมชน abhijithneilabraham เสนอว่าการ merge อาจต้องรวมงาน transformers ของ Liquid ก่อน — “ฉันเชื่อว่าการ merge PR นี้ต้องมี PR transformers จาก @paulpak58” — ซึ่ง atmikshetty ตอบว่า Lfm3Config ยังไม่อยู่ในรีลีสของ transformers ดังนั้นสาขานี้ “โหลดคอนฟิกผ่าน trust_remote_code จากเช็กพอยต์ และการทำงานใช้โมเดล vLLM แบบเนทีฟ” นั่นคือด่านที่สองที่ผู้อ่านส่วนใหญ่จะไม่คิดถึง: แม้ PR ของ vLLM จะถูก merge แล้ว ก็ยังต้องมีคลาสคอนฟิกที่ถูกจัดส่งไปยังที่ใดที่หนึ่ง

ในฝั่ง transformers PR ที่เทียบเท่ากันคือ #50322 "[Model] LFM3 Family: LFM3-Text" ซึ่งเปิดเมื่อวันที่ 3 พฤศจิกายนและยังเปิดอยู่ โดยแยกออกมาจาก PR ของครอบครัวที่ใหญ่กว่า บันทึกของ PR นี้เกี่ยวกับ convolution ตรงกับ issue ของ vLLM: short conv เป็น "torch-only ใน LFM3 (เคอร์เนล causal_conv1d บน Hub รองรับความกว้าง 2-4 ส่วน LFM3 ใช้ 7)"

ฝั่ง vision-language ก็มีปัญหาซ้ำเช่นกัน นอกจาก {{1}}#65827 ของ Liquid{{/1}} แล้ว PR LFM3-VL แยกต่างหาก ({{2}}#65450{{/2}} เปิดเมื่อ {{3}}3 พฤศจิกายน{{/3}}) ยังเปิดอยู่และขึ้นอยู่กับ PR ข้อความของชุมชน ดังนั้น ณ วันนี้ จึงมี PR LFM3 ที่เปิดอยู่ 6 รายการในสองค่าย และยังไม่มีรายการใดที่ถูก merge

วันนี้มีอะไรที่ทำงานอยู่จริง ๆ

ตัดเรื่องการคาดเดาออกไป แล้วภาพที่เป็นจริงในวันที่ 5 พฤศจิกายนจะมีลักษณะเช่นนี้

• vLLM แบบเนทีฟ — ไม่สามารถทำได้กับบิลด์มาตรฐาน ไม่มี Lfm3ForCausalLM ใน registry ไม่มีแถว LFM3 ในตารางโมเดลที่รองรับ และ PR ที่จะเพิ่มเข้าไปนั้นยังไม่ได้รับการ merge

• vLLM, แบ็กเอนด์ transformers — วิธีแก้ปัญหาที่มีเอกสารระบุไว้ โดยใช้โค้ดระยะไกลที่มาพร้อมกับเช็กพอยต์และ trust_remote_code คุณจะสูญเสีย paged attention และแคชสถานะ conv; คุณยังคงมีเซิร์ฟเวอร์ที่เข้ากันได้กับ OpenAI

• SGLang — เส้นทางเซิร์ฟเวอร์ของผู้จำหน่ายเอง โพสต์เปิดตัวของ Liquid วัดตัวเลขทรูพุตบน NVIDIA B300 เครื่องเดียวใน BF16 ด้วย SGLang รวมถึง 3.6 พันล้านโทเค็นต่อวันที่คำขอพร้อมกัน 1,024 รายการ vLLM ปรากฏในโพสต์นั้นเพียงในฐานะรันไทม์ที่ใช้ให้บริการโมเดลคู่แข่งเท่านั้น

• llama.cpp — การ์ดระบุถึง "LFM3-compatible llama.cpp builds" ซึ่งเป็นตัวจำกัดคุณสมบัติจริง ไม่ใช่ข้อความสำเร็จรูป; ตัวเลขบนอุปกรณ์ของ Liquid คือ llama.cpp ที่ Q4_0 พร้อมบริบท 32K

• MLX — บันทึกประจำรุ่น 0.33.0 ของโปรเจกต์ vLLM-Metal ซึ่งแยกต่างหาก ระบุถึงเช็กพอยต์ MLX สำหรับข้อความ LFM3 โดยต้องเปิดใช้ผ่าน --trust-remote-code นี่เป็นโค้ดเบสที่แตกต่างจาก vLLM ต้นทาง และไม่ได้บ่งชี้ถึงการรองรับ CUDA

• โฮสต์ — API และ playground ของ Liquid เอง การ์ดนี้ไม่มีตารางราคา ดังนั้นต้นทุนต่อโทเค็นจึงไม่ใช่สิ่งที่คุณจะตั้งงบประมาณได้จากข้อมูลสาธารณะ

ตัวเลขสองตัวช่วยให้เห็นภาพกรณีการโฮสต์เองได้ชัดขึ้น น้ำหนักโมเดลเล็กพอจนหน่วยความจำไม่ใช่ข้อจำกัด — Liquid อ้างว่าประมาณ 1 GB ที่ 4-bit — และผู้จำหน่ายกล่าวว่าบริบทขนาด 128K โทเค็นต้องใช้ KV cache ประมาณ 1.6 GB ข้อจำกัดอยู่ที่สแตกการให้บริการ ไม่ใช่ GPU

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

ห่วงโซ่การพึ่งพานี้สะอาดผิดปกติ ซึ่งทำให้สิ่งที่ควรจับตามองมีความเฉพาะเจาะจงอย่างผิดปกติ ก่อนอื่น #64647 ต้องถูก merge ก่อน เพราะ PR ของ LFM3 ตัวอื่นทุกตัวมี commit นั้นอยู่ด้วย หรือไม่ก็ถูก stack อยู่บน commit นั้น จากนั้นหนึ่งใน PR ฝั่งข้อความสองตัวต้องผ่านการรีวิวให้ได้ ตัวที่เป็นของชุมชนมีบันทึกการตรวจสอบที่ครบถ้วนกว่า ส่วนตัวของ Liquid มีผู้เขียนที่ดูแลฝั่ง transformers อยู่ด้วย จากนั้น Lfm3Config ต้องได้ลงในรีลีสของ transformers ไม่เช่นนั้นทุกการดีพลอยจะยังต้องส่ง trust_remote_code ต่อไป เฉพาะหลังจากนั้น LFM3-VL-2B, LFM3-Audio-2B และ LFM3-Omni-2B จึงจะเป็นไปได้จริง และโมเดลเหล่านี้ยังอยู่หลัง PR อีกหลายตัวที่สมมติว่าโมเดลข้อความได้เข้ามาแล้ว

ไม่ควรตีความข้อความนี้ส่วนใดว่าเป็นการวิจารณ์ความเร็วในการดำเนินงาน เก้าวันนับจากการเปิดตัวจนถึงชุด PR ทั้งเคอร์เนลและโมเดลที่สมบูรณ์และผ่านการทดสอบถือว่าเร็ว และข้อเท็จจริงที่ทีมอิสระสองทีมสร้างอิมพลีเมนเทชันที่ใช้งานได้จริงภายในไม่ถึงหนึ่งสัปดาห์ สะท้อนว่า LFM3 อยู่ใกล้ LFM2 เพียงใดมากกว่าจะสะท้อนถึงความล่าช้าใด ๆ แต่การ์ดโมเดลคือคำกล่าวอ้างเรื่องความเข้ากันได้ และการตีความสถานะปัจจุบันของ LFM3-1.7B อย่างตรงไปตรงมาคือ “เข้ากันได้กับ vLLM ผ่านแบ็กเอนด์ transformers” ไม่ใช่ “รองรับโดย vLLM”

หากคุณต้องการโมเดลขนาดเล็กที่เรียกใช้เครื่องมือได้ในสัปดาห์นี้

LFM3-1.7B เป็นสิ่งที่ชวนให้อยากได้ ตัวเลขที่ผู้ขายรายงานนั้นแข็งแกร่งในจุดที่โมเดลขนาดเล็กมักล้มเหลวพอดี — 71.39 บน BFCL V4, 80.36 บน ToolSandbox, 96.66 บน IFEval, 43.40 บน SWE-bench Verified — เมื่อเทียบกับค่าเฉลี่ยรวม 49.37 ซึ่ง Liquid จัดให้อยู่เหนือ LFM2.5-2.6B ของตัวเองที่ 31.55 นี่คือการประเมินของผู้ขายเอง ดำเนินการโดยบริษัทที่สร้างโมเดลนี้ โดยไม่มีการทำซ้ำอย่างอิสระ และไม่พบรายการใน Artificial Analysis ณ วันนี้ โปรดถือการจัดอันดับเป็นสมมติฐาน และตัวเลขแต่ละค่าเป็นการกล่าวอ้าง ข้อควรระวังที่มาคู่กันมาจากแหล่งเดียวกัน: การ์ดโมเดลแนะนำไม่ให้ใช้กับการเขียนโค้ดแบบเอเจนต์และการให้เหตุผลหลายขั้นตอนที่ซับซ้อน และเกณฑ์มาตรฐานด้านความรู้ก็สอดคล้องกับคำแนะนำนั้น — 63.37 บน GPQA Diamond และ 65.56 บน RULER ที่ 128K ไม่ใช่ตัวเลขของโมเดลอเนกประสงค์

ดังนั้นการตัดสินใจจึงไม่ใช่เรื่องของโมเดลจริง ๆ แต่อยู่ที่ว่าคุณสามารถสร้างบนเส้นทางการให้บริการที่ตอนนี้ยังเป็น pull request ที่เปิดอยู่ได้หรือไม่ หากคุณรัน SGLang หรือ llama.cpp ได้ คุณก็ใช้ LFM3-1.7B ได้ตั้งแต่วันนี้ และคำถามเรื่อง vLLM ก็เป็นเพียงเรื่องทางทฤษฎี หากสแตกของคุณใช้ vLLM ตามนโยบาย คุณกำลังเลือกระหว่าง paged attention ที่หายไปของแบ็กเอนด์ transformers กับการรอ

ยังมีทางเลือกที่สามที่ควรค่าแก่การเอ่ยถึงสำหรับเวิร์กโหลดที่รอไม่ได้: ให้เปลี่ยนไปเรียกใช้อย่างอื่น OrcaRouter ไม่มี LFM3-1.7B ให้บริการ — การตรวจสอบแค็ตตาล็อกของเราวันนี้คืนค่า model id มากกว่า 200 รายการ และไม่มีรายการใดเป็นของ Liquid's — ดังนั้นนี่จึงไม่ใช่การเสนอให้เรียกใช้ผ่านเรา มันเป็นประเด็นที่ง่ายกว่าคือ PR ของเคอร์เนลที่ยังไม่ถูก merge เป็นจุดล้มเหลวจุดเดียวที่แย่สำหรับเส้นทางโปรดักชัน การมี API เดียวและ automatic failover อยู่หน้าโมเดลที่โฮสต์ไว้ทำให้คุณแลกกับการเปลี่ยนคอนฟิกเพียงครั้งเดียว และช่วยให้คุณสลับมาใช้ LFM3-1.7B ได้ในวันที่ native support ของมันถูก merge แทนที่จะเป็นวันที่คุณลงเดิมพันกับมันจนจบ หากคุณกำลังปรับแต่งโมเดลแทนที่จะเพียงเรียกใช้งานมัน ของเราเอง LFM3-1.7B-abliterated รุ่นที่เปิดตัวคือการทำ ablation ตามทิศทาง refusal ของ checkpoint เดียวกัน และสืบทอดสถานการณ์การให้บริการนี้มาโดยตรง

เวอร์ชันสั้น

LFM3-1.7B เปิดตัวแล้ว มีขนาดเล็ก และเหมาะอย่างยิ่งกับงานเรียกใช้เครื่องมือแบบเทิร์นเดียวที่มันถูกฝึกมา vLLM support ของมันกำลังถูกเขียนอยู่ตอนนี้ โดยสองทีม บนพื้นฐานของส่วนขยายเคอร์เนลที่ยังไม่เคยถูกเรียกใช้บน CUDA โดยคนที่เขียนมันขึ้นมา จับตา #64647 ก่อน — เมื่อ convolution ความกว้าง 7 ถูก merge เข้าแล้ว ส่วนที่เหลือของสแต็กจะเดินหน้าเร็ว และ "works with vLLM" บนการ์ดโมเดลจะเลิกเป็นข้อความเกี่ยวกับ remote code และเริ่มเป็นข้อความเกี่ยวกับ paged attention และ batching จนกว่าจะถึงตอนนั้น ใครก็ตามที่อ้างถึง "day-one vLLM support" สำหรับโมเดลนี้ กำลังอ้างถึงสิ่งที่รีโพซิทอรีนี้ยังไม่มี