DeepSeek V4.1 Flash Tool Calling cập bến vLLM: Những gì các thẻ có khoảng trắng đã phá hỏng

DeepSeek V4.1 Flash đã được cung cấp rộng rãi kể từ ngày 10 tháng 9 năm 2026, và trong mười hai ngày đầu tiên kể từ khi ra đời, mô hình này có một khoảng trống mà không ai viết về: nó có thể suy luận, có thể nhìn hình ảnh, có thể giữ một triệu token ngữ cảnh, nhưng lại không thể gọi công cụ một cách đáng tin cậy thông qua ngăn xếp phục vụ mở phổ biến nhất. Khoảng trống đó giờ đã được lấp đầy trong vLLM — không phải bằng một cờ cấu hình, mà bằng một bản viết lại trình phân tích cú pháp. Hai pull request thực hiện công việc này, và lý do chúng cần thiết mới là phần thú vị.

Bản ngắn gọn: DeepSeek V4.1 Flash phát ra các lệnh gọi công cụ của nó ở định dạng thẻ mà bộ nhận diện DeepSeek V4 hiện có không nhận ra, nên trên một bản triển khai vLLM nguyên bản, phần đánh dấu lệnh gọi công cụ đến dưới dạng văn bản thông thường thay vì đầu ra có cấu trúc. Không có gì báo lỗi. Mô hình trông như thể nó chỉ đơn giản là từ chối gọi hàm. Nếu bạn đã và đang thử nghiệm các vòng lặp agent với một DeepSeek V4.1 Flash tự lưu trữ và kết luận rằng mô hình này kém trong việc dùng công cụ, thì rất có thể đây chính là thứ bạn đang nhìn vào.

Thực sự thì điều gì đã thay đổi trong serving stack

Việc phân tích cú pháp lệnh gọi công cụ của vLLM cho các mô hình DeepSeek đã tồn tại ở hai nơi trong một thời gian: một frontend Python và một frontend Rust mới hơn, với công việc ở cấp ngữ pháp được giao cho dự án XGrammar. Việc đưa hỗ trợ V4.1 Flash sang đồng nghĩa với việc chuyển đổi C++ deepseek_xml bên trong XGrammar sang trình dựng Rust, sau đó nối mã hóa riêng của mô hình vào thư mục tokenizer của vLLM.

• Công việc frontend Rust là PR #56235, PR này chuyển đổi XGrammar C++ deepseek_xml sang trình dựng Rust. PR này đi kèm 18 bài kiểm thử mới dành riêng cho V4.1, và toàn bộ các bộ kiểm thử hiện có — 472 bài kiểm thử trong vllm-parser và 326 trong vllm-chat — vẫn xanh.

• Công việc frontend Python là PR #56408, hiện vẫn là bản nháp. Nó phụ thuộc vào việc thay đổi XGrammar ở thượng nguồn (mlc-ai/xgrammar#885) được đưa vào trước, và báo cáo 110 bài kiểm thử đạt khi áp dụng phần phụ thuộc đó.

• Mô-đun mã hóa mới là vllm/tokenizers/deepseek_v41_encoding.py — một tệp riêng biệt thay vì một nhánh bên trong mã hóa V4, điều này cho thấy ngữ pháp thẻ thực sự khác biệt chứ không chỉ đơn thuần là mở rộng.

• Việc gọi công cụ là tường minh: --tool-parser deepseek_v41. Không có cơ chế dự phòng tự động phát hiện nào âm thầm làm đúng việc cần làm.

Các thẻ được đặt cách nhau chính là toàn bộ câu chuyện.

Lý do một trình phân tích cú pháp mới tồn tại thay vì một biểu thức chính quy được mở rộng là khoảng trắng. DeepSeek V4.1 Flash ghi các thẻ công cụ DSML của nó với dấu cách giữa các token. Mẫu của bộ phát hiện V4 mong đợi dạng không có dấu cách, nên nó không khớp được, và một lần không khớp trong trình phân tích cú pháp lệnh gọi công cụ vốn im lặng theo thiết kế — văn bản được truyền qua như nội dung thay vì báo lỗi.

Kiểu hỏng hóc đó đáng để ta suy ngẫm, vì nó là loại tốn kém nhất. Một parser ném lỗi thì chỉ cần một buổi chiều là sửa xong. Một parser trả về một chuỗi đúng định dạng nhưng chứa markup mà bên gọi chưa từng yêu cầu thì trông y như một vấn đề về chất lượng mô hình, và các đội ngũ phản ứng với nó đúng theo cách bạn sẽ phản ứng với một vấn đề chất lượng mô hình: họ thử những prompt khác nhau, họ thêm ví dụ, họ đổi mô hình. Mười hai ngày là đủ dài để rất nhiều chuyện trong số đó đã âm thầm diễn ra.

Điều đó cũng có nghĩa là bản sửa lỗi không phải là một nút tinh chỉnh. Bạn không thể dùng prompt để thoát khỏi một bộ phát hiện không khớp với định dạng đầu ra của mô hình, và bạn cũng không thể sửa nó trong ứng dụng khách bằng cách xử lý hậu kỳ, vì khi văn bản đến được ứng dụng khách của bạn thì cấu trúc đã biến mất. Nó phải xảy ra trong ngăn xếp phục vụ, chính xác là nơi nó hiện đang nằm.

Tại sao điều này lại quan trọng hơn đối với V4.1 Flash so với V4

Gọi công cụ không phải là một tính năng tiện ích đối với mô hình cụ thể này. DeepSeek V4.1 Flash là một mô hình mixture-of-experts với 552 tỷ tham số, trong đó 8 tỷ tham số hoạt động ở đầu vào và 16 tỷ hoạt động ở đầu ra, cửa sổ ngữ cảnh 1M token và đầu ra tối đa 384K token. Sự phân tách kích hoạt chính là điểm mấu chốt: mô hình được xây dựng để nhận một đầu vào lớn — một kho mã, một tập tài liệu, một dấu vết công cụ dài — và đưa ra một phản hồi có cấu trúc dài. Đó là hình dạng của một tác nhân, không phải hình dạng của một cuộc trò chuyện.

Phần còn lại của đặc tả ra mắt cũng chỉ về cùng một hướng. Trọng số theo giấy phép MIT, 890 byte KV cache mỗi token, 45 nghìn tỷ token tiền huấn luyện, thị giác nguyên bản. Con số KV cache mới là yếu tố quan trọng về mặt vận hành ở ngữ cảnh 1M: nó là thứ khiến một bản ghi agent dài có thể được giữ thường trú với chi phí hợp lý, và là lý do mô hình này khả thi trong vai trò worker giá rẻ trong một vòng lặp do một mô hình đắt hơn giám sát.

Điều đó khiến khoảng trống gọi công cụ kéo dài mười hai ngày trở thành một chi phí thực sự chứ không phải chỉ là một chú thích nhỏ. Một mô hình mà cơ sở kinh tế của nó dựa vào việc trở thành bộ thực thi khối lượng lớn trong một pipeline tác tử thì chẳng đáng giá bao nhiêu nếu pipeline không thể lấy ra được một lệnh gọi có cấu trúc từ nó.

Còn gì vẫn đang mở

Tình hình thực tế một cách trung thực, tính đến ngày 22 tháng 9 năm 2026:

• Đường dẫn frontend Rust (PR #56235) là đường dẫn có độ phủ kiểm thử đầy đủ trên cả các trường hợp V4.1 mới lẫn các bộ kiểm thử đã có từ trước. Nếu bạn đang dùng bản dựng vLLM có bao gồm nó, trình phân tích cú pháp đã sẵn có cho bạn ngay hôm nay.

• Đường dẫn frontend Python (PR #56408) là bản nháp và có một phụ thuộc bên ngoài. Nếu bạn đang bị ghim vào một bản dựng có trước thay đổi XGrammar, frontend Python sẽ chưa cung cấp cho bạn khả năng phân tích công cụ V4.1.

• Vì việc gọi là tường minh, một triển khai nâng cấp vLLM nhưng không thay đổi cờ khởi chạy của nó sẽ giữ nguyên hành vi cũ. Parser tồn tại và parser được sử dụng là hai chuyện khác nhau.

• Hiện chưa có bằng chứng công khai nào về một lần chạy đánh giá chuẩn gọi công cụ độc lập đối với V4.1 Flash khi bộ phân tích cú pháp mới đã được tích hợp. Điều chúng ta biết là phần kết nối kỹ thuật hoạt động và các bài kiểm tra đều đạt. Liệu chất lượng gọi công cụ của mô hình có tốt hay không là một câu hỏi riêng mà việc hợp nhất không trả lời.

Điểm cuối cùng đó là điều cần bám lấy. Việc sửa lỗi parser đưa mô hình từ "không thể được đánh giá" sang "có thể được đánh giá." Đó là điều kiện tiên quyết để đưa ra một phán quyết, chứ không phải là phán quyết.

Nếu bạn không muốn tự chạy ngăn xếp phục vụ

Có một con đường ngắn hơn. DeepSeek V4.1 Flash có sẵn thông qua endpoint của OrcaRouter dành riêng cho nó, nghĩa là hành vi gọi công cụ đến dưới dạng một lệnh gọi API thông thường thay vì một vấn đề build — không cần khớp phiên bản XGrammar, không phải chọn frontend, không cần nhớ cờ khởi chạy. Lý do điều đó đặc biệt quan trọng ở đây là bản sửa lỗi đã được đưa vào hai nơi với độ trưởng thành khác nhau, và một endpoint được host sẽ khiến quyết định đó trở nên không còn cần thiết.

Cùng một khóa cũng tiếp cận được phần còn lại của các mô hình mà bạn sẽ đem ra so sánh, và đây chính là đặc tính hữu ích khi câu hỏi không phải là "trình phân tích cú pháp này có đúng không" mà là "mô hình này có đủ tốt cho vòng lặp của tôi không." Bạn có thể đặt DeepSeek V4.1 Flash phía sau một quy tắc định tuyến với vai trò trình thực thi giá rẻ và chuyển dự phòng sang một mô hình mạnh hơn khi cuộc gọi thất bại, mà không cần hợp đồng thứ hai hay SDK thứ hai. Việc thử một mô hình chỉ mới có hỗ trợ gọi công cụ được hai tuần chính là tình huống mà cơ chế chuyển dự phòng tự động sinh ra để xử lý.

Xem gì tiếp theo

Ba điều sẽ biến đây từ một câu chuyện kỹ thuật thành một phán quyết:

• PR #56408 sắp được đưa ra khỏi trạng thái bản nháp, điều này sẽ biến lộ trình frontend Python thành hiện thực và chấm dứt tình trạng hỗ trợ hai tầng.

• Một đánh giá độc lập về agent hoặc gọi công cụ được chạy trên V4.1 Flash với một stack phục vụ cố định. Mô hình đã ra mắt được mười hai ngày, còn parser có thể dùng được trong ít hơn khoảng thời gian đó, nên bất kỳ điểm số gọi công cụ nào bạn thấy được trích dẫn cho nó vào lúc này đều đáng để hỏi lại — thiết lập quan trọng không kém gì mô hình.

• Liệu các serving stack khác có noi theo hay không. vLLM là bên có các PR công khai; vấn đề thẻ có khoảng trắng không đặc thù riêng cho vLLM, nên bất kỳ stack nào đã áp dụng bộ phát hiện V4 mà không tái suy ra nó từ đầu ra V4.1 đều đang có cùng lỗi âm thầm đó nằm trong mình.

Cho đến khi điều đầu tiên trong số đó thành hiện thực, bản tóm tắt chính xác vẫn hẹp và đáng được nói thẳng: DeepSeek V4.1 Flash là một mô hình GA với trọng số MIT, ngữ cảnh 1M và trần đầu ra 384K, và tính năng gọi công cụ của nó giờ đã hoạt động trên đường Rust trong vLLM với một cờ parser tường minh. Đó là một bước tiến thực sự và vẫn chưa phải là một kết quả.