DeepSeek V4.1 Flash 1017 vs. MiniMax M3.1 Flash Hands-On Test: Official Release Still Falls Short of a Comprehensive Win

Title

DeepSeek V4.1 Flash 1017 vs. MiniMax M3.1 Flash Hands-On Test: Official Release Still Falls Short of a Comprehensive Win

Meta Description

Based on hands-on testing by a Bilibili creator, a delivery comparison of DeepSeek^Ad V4.1 Flash 1017 and MiniMax M3.1 Flash official release on 100K-token long archives, code, and scheduling tasks: DeepSeek leads on core delivery, but both fall short on complex decision memos and strict delivery, and the official release fails to fully surpass the Preview.

Article Content

Sharing the same model name does not mean the same amount of thinking; sharing the same delivery item does not mean the same degree of completion. A recent hands-on test by a Bilibili creator placed DeepSeek V4.1 Flash (the October 17 update pointing to 1017) and MiniMax M3.1 Flash official release under the same "re-run old problems" framework, using real archives of over 100K tokens, official APIs, and the same AI Max hardware, comparing everything from basic functionality to complex decision memos item by item. The conclusion is not dramatic: the two are neck and neck on basic capabilities, but on strict deliveries like the "unattended four-stage project," all three models collectively submitted a blank sheet.

Test Method: Breaking Down "Same Name"

What is most noteworthy about this comparison is not the scores but the controlled variables. The creator explicitly distinguished three objects: DeepSeek's official default configuration (thinking cap of 4096 or 8192 tokens for short questions), the 1017 update of the DeepSeek Flash official release, and the MiniMax Flash Preview record saved on October 13. All requests went through the official API on the same AIMax, totaling 395 requests, with cloud hardware and quantization positions kept consistent.

An easily overlooked pitfall is the amount of thinking. The creator pointed out that DeepSeek's official default is actually the Hi tier, and the "actual work done" by the same-named model under different configurations is not the same. Therefore, although this round's main tests all ran at the Max tier, the results cannot be simply extrapolated to mean "the official release is definitely stronger." In addition, neither vendor has native timing; both Preview and Decode durations are marked as unknown, and the author refused to back-calculate speed from request duration—which is why the article remains restrained about "fast or slow."

Thinking tier (Hi/Max/Low): In reasoning models like DeepSeek, the thinking tier controls the upper limit of the token budget allowed for internal reasoning (such as chain-of-thought) before the model generates its final answer. The Hi tier typically corresponds to a shorter thinking cap (e.g., 4096 or 8192 tokens), suitable for simple questions to save cost; the Max tier opens up the budget, letting the model reason more fully on complex tasks; the Low tier further compresses thinking to pursue low latency. The same model name can perform significantly differently across tiers, so tests must clearly specify the tier configuration and cannot directly extrapolate results from one tier to another. This is also why the creator emphasized that "same name does not mean the same amount of thinking."

JSON code fence: A code fence is the syntax marker in Markdown used to wrap code blocks (three backticks). In strict interface scenarios that require the model to output pure JSON, if the model adds an extra code fence outside the JSON, the receiving party may error out when parsing because it cannot recognize the fence symbols. This is a typical "format compliance" issue rather than a content error, but in automated delivery pipelines it causes the entire request to fail. The creator repeatedly pointed out that the MiniMax official release tripped over code fences, precisely to emphasize the zero tolerance for format in strict interfaces.

Basic Functionality: Two Rounds Passed, the Gap Is in Waiting Rather Than Quality

The basic rule question requires filtering illegal data without modifying the input. All three models passed the nine-function checks in two rounds, with no gap in quality. The difference showed up in waiting amounts: DeepSeek official had a median of about one second, the official release about five seconds, and the Preview about 1.5 seconds.

On the basic code question, DeepSeek official waited a median of over four seconds, and the official release about 17 seconds; both had fluctuations in single rounds. The creator's judgment was direct—the official release added no additional correct items on this basic question. The short-news question only provided six questions and data for ten, twelve, and eighteen seconds, and the author specifically cautioned against expanding this into long-term strengths or weaknesses. All three models wrote complete answers in both rounds, and appropriate length and applicability boundaries also passed; the official release did not open a quality gap in short writing.

Delivery Execution: Format Issues Repeatedly Trip Up the Official Release

The inventory question requires both selecting the right product and reserving only once. DeepSeek completed both rounds; the MiniMax official release and Preview each passed one round. In the round the official release failed, the actual actions were correct, but it added a code fence outside the final JSON, which the strict interface could not accept—the creator noted that this kind of problem still exists in the old version.

The scheduling function question requires handling dependent resources and exceptions together. DeepSeek official and the old Preview each passed one round, while the official release exhausted over 8,000 output tokens in both rounds; DeepSeek's second round passed thirteen checks with 6,313 output tokens. The creator's conclusion: under this Max budget, the official release did not make up for the old version's shortcomings.

The "angle ledger" question deliberately makes tools fail temporarily and also adds untrusted commands into the logs. DeepSeek completed both rounds, and the two MiniMax versions each passed one round. The official release did not overstep authority and correctly found the cause, but again wrapped an extra layer of Markdown at the end—it knew to investigate the problem, yet still could not stably deliver the correct format.

Complex Decisions and Long Archives: The Real Dividing Line

The decision memo is the ugliest item in this test: none of the three models fully met the standard in either of the two rounds. DeepSeek failed to form a draft in both rounds; the official release wrote half a sentence in one round, and in the other round finished but treated a single VR test record as an applicable process, scoring 14; the old Preview scored 13 and 12, neither reaching the 16-point threshold.

The basic reconciliation first fixes amounts and illegal input. DeepSeek passed 13 items in one round, missed the rejection of an unknown Policy, and did not have time to wrap up; the other round was truncated. The official release failed to complete the implementation in both rounds; the old Preview passed all functions in both rounds, with only one round wrapping up in time. After adding date deadlines, refund status, and item-by-item diagnosis while preserving old rules, DeepSeek passed 25 items in one round and completed stage regression; the valid round of the official release was truncated while still thinking, and each side had another round blocked by invalid tool history, which cannot be used to judge capability.

The release stage injects a disk-full failure once. DeepSeek and the official release each completed recovery in one round and passed 35 function checks, but both stopped at the tool result lacking stage closure; one round of the Preview even completed the wrap-up. The creator's reminder is crucial: being able to publish the correct file still does not equal the entire stage's delivery deadline. Finally, when incorporating late refunds, delivering files, and explaining, all three models had one round where the published file was correct: DeepSeek hit the reply limit without writing an explanation, the official release was truncated while thinking about the wrap-up, and although the Preview wrote an explanation in one round, it reversed the direction of the amount impact, scoring 15 and missing the threshold.

Stage closure: In a four-stage project or tool-calling flow, stage closure means that after the model completes all subtasks of the current stage, it outputs a clear end signal (such as a summary, status marker, or delivered file list) so the system can determine that the stage can move to the next step. Lacking stage closure means that even if files have been correctly generated, the entire flow may still be considered incomplete. The creator repeatedly mentioned "stopping at the tool result lacking stage closure," i.e., the model can perform actions but does not form a closed loop, which is a fatal flaw in unattended automated delivery.

Strict score and editorial score: The strict score refers to a scoring method that requires all check items (including format, fields, evidence citations, etc.) to be satisfied simultaneously in order to pass; any single item failing means overall failure. The editorial score is closer to human review, awarding points based on dimensions such as content correctness and logical completeness, and allowing partial deductions. The creator used the two scores to distinguish "whether the content is right" from "whether the delivery is usable." For example, the MiniMax official release calculated the amounts correctly in the long archive but failed the strict score because literal formats such as evidence prefixes did not meet the standard.

Long Archives and Speed: Who Delivers Content More Reliably

On the entire strict delivery, all three models scored 0 to 2, and the final files were 1 to 2 correct. Looking only at the round where the file was correct, DeepSeek took about 151 seconds, the official release 469 seconds, and the Preview 239 seconds—but these were times when the single-word explanation had not yet been delivered and the error was edited early to end. The creator explicitly said this does not count as a speed advantage.

Calculating the amounts and refund routing for four orders from an archive of over 100K: DeepSeek fully calculated correctly and cited evidence in one round, and did not deliver in the other; the MiniMax official release was correct on the core in both rounds, yet failed the strict score in both, with the problem in literal formats such as evidence prefixes and version labels—it cannot be said that they got the amounts wrong. When writing the same long archive into a handover draft, DeepSeek delivered both the correct column amount evidence and the unexecuted status in one round, scoring 19 editorially, except that the policy field was written as a document ID and the original check still failed; the other round was truncated. The MiniMax official release failed to form a complete draft in both rounds. On this question, DeepSeek's content delivery was better.

On speed, for simple filtering lowered from Max to Low, DeepSeek did not save time; MiniMax's median went from 5.2 seconds to 2.1 seconds in these two rounds, and both were correct in both rounds at Low. The creator emphasized that tier benefits are not fixed, and you cannot assume Low is better just because you see it. In an added low-tier sample for tuning reads, both ends passed the three function checks; DeepSeek output 4,836 tokens and MiniMax 1,487, with waits of about 23 and 20 seconds—the official release delivered the same functionality with less generation, but one instance each cannot replace two rounds. In another Low-tier run on an archive of over 100K, DeepSeek passed the original 17 items in 13.6 seconds, while MiniMax took 28.4 seconds and got the four decisions and evidence right but added a DOC prefix, failing the strict check.

Overall Judgment: Core Delivery Ahead, Strict Delivery Collectively Absent

This round's overall priority is DeepSeek V4.1 Flash 1017, with common core delivery at 11 to 16, and the official release at 8 to 16. It also delivered a long-archive memo with qualified content; MiniMax's amount verification in both long-archive rounds was correct and its Low scheduling also passed, but the main test did not prove it comprehensively beats the Preview. On complex decision memos and the unattended four-stage project, none of the three met the standard.

This is a restrained, almost harsh hands-on test: only two rounds of samples, and the author repeatedly cautioned against expanding or extrapolating. The only transferable conclusion is this—on the "last mile" of strict interfaces and stage closure, the official release did not make up for the old version's shortcomings just because the version number was updated. When selecting models, it is worth putting these boundary scenarios into your own acceptance checklist.

One-line Summary

Bilibili creator tests DeepSeek V4.1 Flash and MiniMax M3.1 Flash: DeepSeek leads on core delivery, but all three collectively fall short on strict delivery.

Paragraph Summary

The creator used real archives of over 100K tokens, official APIs, and the same hardware to compare the DeepSeek V4.1 Flash 1017 update and the MiniMax M3.1 Flash official release by "re-running old problems." All three passed the nine basic function checks in two rounds, with the gap mainly in waiting time; however, on delivery execution questions such as inventory, scheduling, and angle ledgers, the MiniMax official release repeatedly failed strict interfaces due to literal formats such as code fences and DOC prefixes. On complex decision memos and the unattended four-stage project, none of the three models fully met the standard in both rounds. Overall, DeepSeek leads the MiniMax official release 11 to 16 on common core delivery versus 8 to 16, but the "last mile" of strict delivery remains a shared weakness.