Speaker A
Hi, welcome to another video. Before starting the video, I also want to tell you that there are new updates to Deep Seek's harness as well, which I'll be covering on my other channel, AIC King.
Deepseek V4.1 Flash launch review with architecture overview, performance benchmarks, and coding task tests showing major improvements and new features.
Key Takeaways
- Deepseek V4.1 Flash delivers significant performance and efficiency improvements with a new architecture.
- Thinking mode and max effort settings greatly enhance model output quality and reasoning.
- Native visual understanding is introduced but not benchmarked in this video.
- The model shows strong practical coding capabilities with meaningful improvements in tested tasks.
- Some minor bugs and edge cases remain, highlighting areas for further refinement.
What the video covers
- Deepseek V4.1 Flash officially launched with new architecture, native visual understanding, and lower API costs.
- Model uses a 552 billion parameter mixture of experts backbone plus 196 billion parameters in engram memory modules but activates only 8-16 billion parameters during processing.
- New causal encoder-decoder design reduces decoder computation for input tokens, lowering GPU memory and storage usage significantly.
- Native visual understanding enables image and text input with text output, though this video focuses on coding from text prompts.
- KingBench 3 testing showed an 81.25% score with thinking enabled at max effort, a large improvement from initial runs.
- Multiple coding tasks were tested including elevator simulation, 3D contact lens case, folding table, panda SVG, bow and arrow game, and a math permutation problem.
- Most tasks showed clear improvements in functionality, visual quality, and code correctness compared to previous versions.
- Some bugs and edge cases remain, such as a reset issue in the elevator simulation and a missing save score button in the archery game.
- The model demonstrates substantial reasoning capabilities, error correction, and iterative problem solving in math tasks.
- Pricing for API usage is detailed with low input costs and higher output costs, supporting cost-effective deployment.
Chapters
- 00:00Introduction and Deepseek Updates
- 00:58Model Architecture Overview
- 01:46Efficiency and Visual Understanding Features
- 02:40Performance Testing and Thinking Mode Impact
- 03:33Elevator Simulation Task Review
- 04:30Contact Lens Case Task Review
- 05:18Folding Table Task Review
- 06:12Bow and Arrow Game Task Review
- 07:06Math Problem Task Review
- 07:58Additional Project Details and Pricing
Full Transcript — Download SRT & Markdown
Speaker A
So, make sure you subscribe to me there as I have been pretty active there and I post cool stuff there as well. So, Deepseek V41 Flash is now officially launched. And after testing it with the correct thinking settings, I think this
Speaker A
model is amazingly good. It reached 81.25% on my KingBench 3 tests and the open code record suggests around 221 generated tokens per second, including reasoning. The release brings a new architecture, native visual understanding, and lower API prices.
Speaker A
There's also a technical report explaining how Deepseek is making this model more efficient. So let's look at what's actually new. Then I'll show you the generations and the code behind my scores. Deepseek calls flash the smallest model in its new architecture
Speaker A
family. But the report describes a 552 billion parameter mixture of experts backbone plus another 196 billion parameters in its engram memory modules.
Speaker A
This is still a huge model. The interesting part is how much of it gets activated. It uses about 8 billion active parameters while processing input and 16 billion while generating output.
Speaker A
The new causal encoder decoder design lets most input tokens skip the full decoder computation. That matters for coding agents because they spend a lot of time reading files, tool results, and conversation history. Deepseek also reports roughly a quarter of the
Speaker A
previous generation's GPU memory usage for the global attention cache and an eighth of the storage for the persistent cache under the same workloads. Those savings apply to the cached context.
Speaker A
They help explain the lower serving costs without implying the entire model has become that much smaller. Native visual understanding means you can send images along with text and receive text responses. My tests here focus on coding from text prompts. So, the vision
Speaker A
capability is part of the launch rather than something I've benchmarked in this video. The published results are promising, too. Deepseek reports 74.2 on DeepSWE version 1.1 compared with 62.7 for V4 Pro. These are their results at maximum effort. Other models still lead
Speaker A
on some harder benchmarks, and the report shows that the agent software around the model changes the score. So, I wanted to see what it could do in open code. Now, I need to correct my first impression. Thinking had been disabled
Speaker A
in my original open code model entry. I initially suspected a regression, but after enabling thinking and setting the effort to max, the score went from 53.75 to 81.25%.
Speaker A
The saved sessions contain substantial reasoning output, and the generations look dramatically better. These runs used the temporary API model just before today's launch. I haven't rerun the suite against the new production model name. They're my hands-on preview results alongside the official release
Speaker A
information, and I don't have evidence that DeepS secretly served a weaker variant in the first run. Kingbench 3 has eight tasks worth 10 points each.
Speaker A
These are my practical ratings. I also opened the generated interfaces and reviewed their code, preserving the original outputs. So, let's get right into it. Now, the first task is the elevator simulation. There should be three elevators, each carrying one
Speaker A
person. People wait on different floors, get on an available elevator, and travel to their assigned destinations. Hovering over, someone should show where they want to go. Look at the new result. The building is organized. All three shafts are visible, and passengers line up at
Speaker A
their floors. You can follow people boarding and see the waiting, rioting, and arrived counters update. In the browser check, two batches of 24 people were spawned. Both batches added the correct number. All 48 passengers arrived, and no cabin carried more than
Speaker A
one person at a time. The counters stayed consistent throughout that run as well. Previously, cabins disappeared offscreen and people were drawn in the wrong places. The new code also cleans up completed passenger elements, which helps with repeated use. There is still
Speaker A
a reset edge case if you clear the simulation while a staggered spawn is underway. Some pending passengers can appear afterward, but the main simulation now does the job. This moves from 3 to 8 out of 10. The second task
Speaker A
is the contact lens case. I wanted a 3D object with pronounced L and R markings and caps that open when clicked. This version is much more convincing. We have a clean white case, these mint colored caps, and large readable letters. The
Speaker A
lids open independently, and the open both button does what it says. You can close them again and rotate the object to inspect it. The previous version had broken letters and a solid looking surface under the caps. Here, the
Speaker A
geometry is organized around the hinges, so the motion makes sense. The compartments still look quite shallow, and the default camera can crop the lids when they're fully open, so it could use more refinement, but this is a much
Speaker A
better interpretation of the prompt. 7 out of 10, up from five. Now, the folding table. This was one of the most obvious failures in the first run because the tabletop was floating and the legs were underground. This time,
Speaker A
the unfolded table stands on four visible legs. The wood-like surface looks good. The slider responds smoothly, and the folding parts stay together as an assembly. Just look at the difference between the two outputs.
Speaker A
The code attaches the legs to the appropriate moving parts, addressing the central problem from before. It still loses points at the fully folded position. The leg bars intersect the stacked tabletop slabs, so the mechanism isn't physically clean all the way
Speaker A
through. I gave this 6 out of 10. It's an improvement, but it's also a useful example of where the model still needs checking. The fourth task is the panda eating a burger SVG. This one has a cleaner composition, a more expressive
Speaker A
face, and a burger with recognizable layers. The paws and little crumbs add some character. It's a compact, self-contained illustration, and it renders correctly. The remaining issue is the action. It still reads more like a panda holding a burger than taking a
Speaker A
bite. So, I like the illustration more, but it doesn't completely capture the prompt. 6 out of 10 here compared with five before. Now, the bow and arrow game is visually one of the strongest improvements. We have a sunset scene,
Speaker A
mountains in the background, an archer, four targets, and a clear timer. Dragging to aim and release feels much more like an actual archery game. The core shooting loop works. In the browser check, all four targets were hit with
Speaker A
four arrows, and the targets fell over as they were hit. The in-game timer showed 6.10 seconds for that four-shot round. That is a gameplay reading, separate from the time the model took to generate the game. It's an eight on my
Speaker A
scorecard, up from five. But the code review caught a bug that I need to disclose. After the last target, the game tries to use a save score button reference that hasn't been added to its element map. That throws an error and
Speaker A
stops the results screen from opening. So, the score couldn't be saved in that check. The shooting, atmosphere, and hit feedback are good. The completion flow needs that repair, which is why checking beyond the first screen matters. The sixth task is the math problem about
Speaker A
counting permutations of ordered pairs with restricted moves. The expected answer is 20,460. This time the saved session has the final answer clearly and it is correct.
Speaker A
There is also a solver that can be run again. I reran it and it produced 20,460 while matching brute force counts on the smaller cases it checked. The model found a mistake in its initial transition logic, corrected it, and
Speaker A
checked the revised algorithm against small brute force examples before giving the final number. That's useful problems so
Speaker A
The seventh task is the local Panda fine-tuning workflow. I asked it to create a data set, fine-tune a Gemma 2B model, and build a local web interface that generates a Panda fact when refreshed. This is a strong result. The
Speaker A
project contains a completed 700 iteration Laura training run, saved adapters, and a working local application. The data set contains 151 authored facts compared with 127 in the earlier version. The serving approach is simpler, too. It loads the model and
Speaker A
adapters directly through MLX using the tokenizer's chat template, removing an extra export and handwritten template layer from the previous attempt. And the interface looks good. It has a simple Panda illustration, a readable fact card, a new fact button, and layouts
Speaker A
that work on a phone as well. Refreshing the page, and pressing the button both produced responses during the review.
Speaker A
Five sample generations were clean single sentences without the stray markup we saw before. The two direct local requests took about half a second each. That is the locally fine-tuned Gemma model answering separate from Deepseek's API generation speed. I gave
Speaker A
the task 10 out of 10, up from six. There are still data quality limitations to be clear about. All the validation answers already appear in training. The test file copies training rows and some authored facts are inaccurate. A refresh
Speaker A
also repeated a fact during the review. So completing the workflow doesn't establish that every generated Panda claim is reliable, but getting the training and the local application working like this is impressive.
Speaker A
Finally, the wristwatch. This is probably the best visual demonstration of why I changed my mind. The first generation had a gold surface covering the dial. Now we have a detailed watch face, visible hour markers, a metal bracelet, readable day and date windows,
Speaker A
moving hands, and a second time zone sub dial. The overall presentation is much more polished. The interactions work too. You can select two time zones, swap them, toggle the day and date display and switch between sweeping and ticking
Speaker A
seconds. The control checks also pass the things that matter underneath the design. The hands align correctly at midnight. Mumbai's halfhour offset works. New York's daylight saving transition works and the second zone can roll over to the next day correctly. The
Speaker A
code also reuses its time formatterers, avoiding the old version's repeated construction every frame. The visual structure and clock logic finally work together. I really like this one. It goes from 4 to 10 out of 10, which is the largest improvement in the retest.
Speaker A
Now, let's look at the final chart. Eight for the elevator, seven for the contact lens case, six for the table, six for the SVG, eight for archery, and 10 each for the math, fine-tuning workflow, and wristwatch. That adds up
Speaker A
to 65 out of 80 or 81.25%. The thinking disabled run was 43 out of 80. So, we gained 22 raw points or 27.5 percentage points after correcting the setup and running the tasks again. The new score is also above my earlier V4
Speaker A
flash result of 72.5% and the V4 Pro entry at 76.25%. It ties Gemini 3.8 flash on this leaderboard and sits just above Opus 4.8 at 80%. It doesn't lead the whole chart, but this is a very competitive result. Now, about
Speaker A
the speed. I checked the open code log and it saved session records for this new test folder. There are 64 completed model responses with usable token counts and timing records. Background calls used for things like session titles are
Speaker A
excluded along with one unfinished wristwatch response. Across those completed responses, there are 364,574 generated tokens. Roughly 294,000 are reasoning tokens and about 70,000 are other output including code tool call arguments and answers. So most of the generated tokens in this run went into
Speaker A
thinking using each logged request start through its final generation event including the initial weight. The weighted estimate is about 221 tokens per second. A narrower estimate starting at open codes recorded streaming step event is about 235 tokens per second.
Speaker A
Both numbers include reason. These are estimates reconstructed from Open Codes timestamps. They exclude the later time spent executing tools, and they aren't exact measurements of the server's internal decoding speed. I summed the individual response durations, so running several tasks at once doesn't
Speaker A
artificially inflate the per response rate. I think that's impressive. It spent tens of thousands of tokens reasoning on several tasks while maintaining a high generation rate. The full task times give you another perspective. The elevator task took about 4 minutes and 20 seconds. The SVG
Speaker A
task took around 11 seconds. The local fine-tuning workflow took roughly 11 minutes and 38 seconds, including the work of setting things up, training, and checking the app. So, maximum thinking can mean a longer wait for a finished artifact. In this retest, that extra
Speaker A
work accompanied a large improvement in the results, which is a trade-off I'm happy with. Now, the API pricing is live. Off peak rates are 15 cents per million uncashed input tokens and 60 cents per million output tokens. Peak
Speaker A
rates are 30 cents for input and $120 for output. Cashed input costs just 3/10en of a cent per million tokens off peak doubling during peak hours. I'll link the current pricing schedule below.
Speaker A
To use the released model, select DeepSseek-lseek API address. Deepseek lists open code among the supported tools. Check that thinking is enabled and the effort is set to max. If you want the configuration used for this retest, the old V4 flash models have been retired
Speaker A
with their API names temporarily routing to V4.1 Flash. V4 Pro requests will start routing to V4.1 Flash at flash prices on September 14th at 4 a.m. UTC until V4.1 Pro launches. That date matters if you're relying on the Pro
Speaker A
model name. Reasoning uses billable output tokens, too. So maximum effort still has a cost, but this pricing, the observed speed, and an 81.25% result make V4.1 Flash a compelling coding option. Deepseek has also shared its technical report and model
Speaker A
repository and says it's working with the open- source community on inference support and deployment options. My verdict has changed substantially with thinking enabled at Max. This model produced some amazingly good results in my tests, especially the wristwatch and
Speaker A
the local model workflow. The elevator is also a clear demonstration that the improvement goes beyond nicer styling.
Speaker A
There are still bugs to catch and the lower scores on the table and SVG show that it isn't equally strong at every task, but I would absolutely give this model another look for coding. The configuration mistake led to an unfair
Speaker A
first impression, and this retest gives us a much better picture. Overall, it's pretty cool. Anyway, let me know your thoughts in the comments. If you like this video, consider donating through the super thanks option or becoming a member by clicking the join button.
Speaker A
Also, give this video a thumbs up and subscribe to my channel. I'll see you in the next one. Until then, bye.
Topics:Deepseek V4.1Deepseek FlashAI model architectureKingBench 3coding AInative visual understandingmixture of expertsAI reasoningAPI pricingAICodeKing
