On September 10, 2026, DeepSeek released the smallest member of its new architecture family—DeepSeek-V4.1-Flash. This is not a routine version iteration, but an architecture-level redesign: a 552B total-parameter MoE, an entirely new Causal-Encoder-Decoder (CED) asymmetric architecture, only 8B activated on the input side versus 16B on the output side, combined with native multimodal visual understanding, a 1M context window, and a 384K maximum output—turning a "small-size" member into a flagship-class capability that comprehensively surpasses V4 Pro. This article focuses on putting multimodal visual understanding into production: from how an image is fed into the model, to multi-image planning for long documents, to multi-turn reasoning in visual Agents, and further to thinking-intensity tiers and token budget control. You will get code you can run directly, a parameter selection table ready for production environments, and those engineering details that you only learn by stepping on the pitfalls yourself. This article is published in two parts; this is Part 1/2, which first thoroughly explains the architecture, KV Cache, context, and visual input channel, and gets the first visual understanding request running.
Breaking down the CED asymmetric architecture: why a 552B MoE activates only 8B on the input side and 16B on the output side
To understand the design of V4.1-Flash, you first need to understand the division-of-labor philosophy behind the name Causal-Encoder-Decoder (CED). A traditional Transformer uses "unified attention": whether you are reading in a piece of context or generating the next token, you use the same set of parameters and the same causal mask. CED, by contrast, models "reading" and "writing" as two fundamentally different kinds of tasks.
The task of the encoding side (Encoder, input side) is to understand the input: encode text tokens, image patches, and interleaved text-image sequences into semantic representations. Understanding is a process that is "parallel, bidirectional, and repeatedly revisitable"—when you see the 100th token, it is entirely natural to look back and revise your understanding of the 3rd token. Therefore, the encoding path of CED adopts non-causal (bidirectional) attention, allowing information to flow freely within the input sequence. The cost is that this part does not need autoregressive sampling, so computation can be completed with an extremely low activation volume. V4.1-Flash activates only 8B parameters here.
The task of the decoding side (Decoder, output side) is generation: the answer after image understanding, the tool-call parameters for an Agent, the body text of a long-document summary. Generation is a process that is "serial, causal, and incrementally accumulated"; each step must make decisions based on the entire history, and quality directly determines the final output, so it requires higher parameter capacity and stronger reasoning ability. V4.1-Flash activates 16B parameters on the output side, exactly twice that of the input side.
This 1:2 asymmetric activation is not a number pulled out of thin air, but a calculation based on real workloads: in multimodal scenarios, a 1024×1024 image may produce thousands of visual tokens after visual encoding, and the number of input tokens in a single request is often several times to dozens of times the output. If the input side also activated 16B, the vast majority of compute would be wasted on "content that has already been understood." Compressing the input side to 8B and tilting capacity toward the output side is equivalent to letting "cheap reading" handle massive context while letting "expensive writing" concentrate its firepower on generating high-quality results.
There are three direct impacts on engineering practice:
- The cost of visual input is structurally lowered. For input-dominated tasks such as multi-image long documents, the marginal compute cost per token is significantly lower than for output-dominated tasks, which makes "splitting an entire PDF into images and throwing them in" economically viable for the first time.
- The output side remains the main budget item. 16B activation means generating long text and long-chain Agent trajectories is still expensive, so truncation strategies and max_tokens planning are more important than ever.
- The 552B total MoE parameters guarantee knowledge capacity; a small activation volume does not mean weak capability. Sparse activation lets the model mobilize only the experts relevant to the current token during inference, which is also the fundamental reason it can provide Pro-level capability at the Flash price point.
It must be emphasized that 552B refers to total parameters, while 8B/16B are activated parameters; the relationship between the two is like "warehouse size" versus "amount taken out in a single retrieval." This is also why the official team can release the weights on Hugging Face (deepseek-ai/DeepSeek-V4.1-Flash)—the total parameter scale determines the VRAM threshold, the activation scale determines the form of demand on compute clusters, and together they determine whether it is suitable for local deployment.
From V4 Pro to V4.1-Flash: capability leaps brought by new pretraining methods + larger-scale RL post-training
Common sense would suggest that the "small-size member" of a family should be the lower bound of capability. But the official benchmarks for V4.1-Flash are counterintuitive: it comprehensively surpasses the previous-generation flagship V4 Pro across multiple dimensions. The reason is that two technical routes advanced simultaneously—new pretraining methods and larger-scale RL post-training.
Let's look at the hard metrics first. Among the officially published numbers:
- GPQA Diamond 90.9—PhD-level science Q&A, approaching the saturation range of this benchmark;
- Codeforces rating 3471—competitive programming, in the range of top contestants;
- MathArena Apex 65.6—high-difficulty mathematical reasoning;
- Terminal-Bench 2.1 score 90.6, versus 87.9 for V4 Pro;
- CyberGym 88.1, versus 83.3 for V4 Pro.
Two points in this set of numbers are worth the attention of engineers. First, the rise in "hard reasoning" metrics such as GPQA Diamond and Codeforces shows that the improvement is not piled up through data memorization, but is progress in reasoning ability itself, and this kind of ability transfers directly to multimodal visual reasoning tasks—for example, inferring values from charts or interpreting engineering drawings. Second, the two Agent/security benchmarks Terminal-Bench 2.1 and CyberGym improved by 2.7 and 4.8 points respectively, showing that long-chain Agent execution capability has been significantly strengthened, which is exactly the underlying quality most needed in visual Agent scenarios.
The official release post also includes four other Agent benchmarks: Terminal-Bench 3.0 score 30.0, DeepSWE v1.1 score 74.2, CyberGym 88.1, Automation-Bench 54.8. Among them, Terminal-Bench 3.0 and DeepSWE are both strongly procedural tasks—the model must continuously operate the environment over multiple steps and revise its plan based on feedback. Combining this kind of capability with visual input yields the closed loop of "take a look at the screenshot → decide the next operation → execute → look at the new screenshot," which is exactly the visual Agent form to be built in the latter half of this article.
There is also an easily overlooked fact: starting from 12:00 Beijing time on 2026-09-14, all requests to deepseek-v4-pro are routed to V4.1-Flash and billed at the Flash price, until V4.1-Pro goes live. This means that if you are currently running V4 Pro in production, you have already been upgraded to V4.1-Flash without realizing it, and the bill is cheaper. This is the best window for regression testing—using real traffic to verify whether the claim that "the small-size member comprehensively surpasses the previous-generation flagship" holds on your own business distribution.
The conclusion is straightforward: stop using "parameter size" to predict model capability. V4.1-Flash is the product of new pretraining methods and large-scale RL post-training; its capability ceiling is determined by data and training methods, not by the number of activated parameters.
The KV Cache compression quartet: how 890 bytes/token, HBM reduced to 1/4, and SSD reduced to 1/8 are achieved
For those working on long-context and multimodal inference, KV Cache is what truly determines "whether it can go live," not benchmark scores. The official data for V4.1-Flash in this area is very aggressive:
- KV size per token is about 890 bytes, versus about 3514 bytes for V4 Flash;
- HBM demand is reduced to 1/4 of the previous generation;
- SSD storage demand is reduced to 1/8;
- Compared with the first-generation DeepSeek, the KV Cache is reduced by about 437 times overall.
Let's first calculate what this number means. Taking a 1M context as an example, V4 Flash's 3514 bytes per token means a single sequence's KV is on the order of about 3.5GB; V4.1-Flash's 890 bytes compresses it to the order of about 0.89GB. For an API service with 2500 concurrent requests, this directly determines how many long-context sessions the same HBM can carry.
The "quartet" can be understood as the combined effect of compression across four dimensions:
- Asymmetric design at the architecture layer. The encoding side and decoding side of CED take on different responsibilities, and the KV storage structure can be optimized separately along each path, without having to pay the cost of a full cache for a single unified attention scheme.
- Sparsification and low-rankification of the attention structure. In long-context scenarios, not all historical tokens need to be retained at full precision; low-rank projection and selective retention reduce the effective cache dimension of each layer and each head.
- Quantization and mixed-precision storage. Storing KV at lower bit widths, combined with precision protection for critical layers, is the key to bringing bytes/token down from the thousands to the hundreds.
- Tiered caching and SSD offloading. HBM holds hot data and SSD holds cold data; the reduction of SSD demand to 1/8 shows that the on-disk footprint per token has been squeezed even harder, which is crucial to the economics of ultra-long sessions.
In engineering terms, the most important implication is that the cost structure of long context has been rewritten. In the past, the problem with 1M context was "you can enable it but you can't afford it"—KV memory gets maxed out, and OOM hits as soon as concurrency rises. Now, with HBM demand at 1/4 and SSD at 1/8, it means you can run the same concurrency on fewer machines, or run longer sessions on the same machines. Combined with the pricing where cache-hit input is only 0.02 yuan per million tokens when idle (0.04 yuan at peak), placing stable, unchanging long documents in the prefix to hit the cache is the most cost-effective approach for long-document visual understanding.
Also keep in mind a hidden cost of KV Cache: it grows linearly with session length. Even though 890 bytes/token is already very small, a multi-turn visual Agent session lasting 10 hours will still accumulate a considerable cache. In engineering practice, you should proactively split sessions, stripping completed subtasks out of the active context and keeping only summaries.
1M context + 384K max output: window planning strategies for long-document visual understanding and long-chain Agents
V4.1-Flash provides a 1M token context and a 384K token max output. These two numbers must be understood together, because they correspond to two completely different types of tasks.
The 1M context solves "seeing everything." In multi-image long-document scenarios, a several-hundred-page technical manual, a financial report with charts, or an entire set of UI design drafts can all be fed in as a whole without pre-splitting. This eliminates the most common source of precision loss in the past—losing cross-page and cross-image associative information due to splitting. All three channels—image links, base64, and the Files API—can use this 1M window; the only difference is the transmission method.
The 384K max output solves "writing it all out." The multi-turn planning of a visual Agent generates a large amount of intermediate text: chains of thought, tool-call parameters, observation results fed back in, and plan revisions. If the output limit were only 8K, a complex task would be truncated after just a few turns. 384K allows a single call to carry an ultra-long Agent trajectory, or to output the structured parsing result of an entire book in one go (for example, converting a 200-page scan into structured JSON).
But "a large window" does not mean "use it however you like." Here are three actionable window planning strategies:
- Fix the prefix. Place materials that do not change with the conversation (long documents, reference image sets, system prompts) at the very front of the message sequence, keep the prefix stable, and maximize the cache hit rate. In the official pricing, cache-miss input is 1 yuan per million tokens when idle, while a hit is only 0.02 yuan—a 50x difference. Prefix design directly determines the order of magnitude of cost.
- Tiered truncation. Do not crudely truncate by character count; truncate by semantic unit: first keep the system instructions and task definition (which must not be truncated), then keep the most recent N turns of complete dialogue, compress the middle history into a summary, and only then consider discarding old images. Once an image is discarded, its contextual associations cannot be recovered, so it has the lowest priority.
- Declare the output budget explicitly. In Agent scenarios, tier max_tokens by task type: give a small value for a single-step tool call (e.g., 2K), a large value for the final summary (e.g., 64K), and only go into the hundreds of thousands for full-document structured output. If you do not declare an output budget, the model may write far more thinking text than expected in order to "think it through."
Visual Agents in particular should note: each turn of screenshot input occupies the input window, and after multiple turns the input side grows extremely fast. It is recommended that after every N turns, replace historical screenshots with textual description summaries to give the window back. This both controls cost and prevents the model from losing the main thread amid too much visual detail.
Three channels for native multimodal visual understanding: selection and trade-offs among image links, base64, and the Files API
V4.1-Flash natively supports multimodal visual understanding, and officially provides three image input channels: image link (URL), base64 inline, and Files API. The three are equivalent in capability, but differ enormously in latency, bandwidth, caching, and reusability. The table below is the core reference for engineering selection:
| Channel | Latency characteristics | Bandwidth/size | Cache hit | Reusability | Typical scenario |
|---|---|---|---|---|---|
| Image link URL | Requires server-side fetching, affected by the origin site, first-packet latency is uncertain | Request body is extremely small | If the URL is stable and the content unchanged, the prefix can hit stably | High; the same URL can be reused across requests | Images already on a CDN/object storage, gateway batch processing |
| base64 inline | No extra network round trip, fastest | Request body inflates by about 33%, constrained by the single-request size limit | Hits only when the content is identical each time; repeated calls are costly | Low; must be retransmitted with each request | Quick validation of a single image, small images, temporary images |
| Files API | Upload once, subsequent references go through the server, stable and low latency | Upload bandwidth is paid once | The file ID is stable, which favors prefix caching | Highest; upload once and reference many times across many turns | Multi-turn visual Agents, long-document image sets referenced repeatedly |
The selection recommendations can be directly reduced to three rules:
- Single question-and-answer, image very small (tens of KB) → base64. Saves one network round trip, and the code is simplest.
- Image already publicly accessible, and the same image will be referenced by multiple requests → URL. Smallest request body, lowest bandwidth cost.
- Multi-turn visual Agent, needing to repeatedly reference the same batch of images → Files API. This is the only channel that can treat images as "stable prefix assets" across multi-turn dialogue; combined with the cache-hit price of 0.02 yuan per million tokens, long-session costs can be driven extremely low.
Two real pitfalls. First, base64 looks convenient for small images, but repeatedly sending it across multiple turns causes input tokens to be billed repeatedly, and the inflated request body may hit the gateway's size limit, resulting in a 413 once the image gets large. Second, the stability of the URL channel depends on the origin site; if the image comes from a signed URL that expires, the cache prefix will be broken, and a fetch failure may even cause the entire request to fail. In production, use long-lived object storage addresses, or implement a caching proxy at the fetch layer. In addition, regardless of which channel is used, image resolution directly affects the number of visual tokens, and thus the input cost and window occupancy; high-precision OCR and overall scene understanding have different resolution requirements, so downsample according to the task.
Three thinking-mode levels low/high/max: trade-offs among thinking intensity, cost, and latency for visual tasks
V4.1-Flash supports non-thinking mode and thinking mode, with thinking mode being the default, and offers three thinking-intensity levels: low / high / max. This is the switch most easily abused in visual tasks—many people leave it on max by default, and both cost and latency spiral out of control.
The essence of the difference among the three levels is the depth of the model's internal reasoning before giving the final answer. The higher the level, the longer the reasoning chain, the more self-checking of intermediate hypotheses, and the more likely it is to overturn a first draft and start over; the lower the level, the more it tends toward intuitive, quick answers. For visual tasks, you can choose the level according to the three-layer difficulty of "vision—language—reasoning":
- low: OCR, image description, simple classification. For such tasks, the answer is almost entirely determined by the visual input and requires no multi-step reasoning. Using the low level yields the greatest gains in latency and cost, with almost no loss in quality.
- high: chart Q&A, schematic diagrams requiring reading values, image-text consistency verification. The task requires "read the image first, then calculate, then verify," which is a medium depth of reasoning. high is the best balance point for this tier, and is also the default recommendation for multimodal business.
- max: complex visual reasoning. For example, multi-image cross-page comparison, multi-constraint judgment on engineering drawings, planning the next step in a visual Agent by synthesizing screenshots and historical actions, and visual tasks that need to be coupled with code/mathematical reasoning. The thinking text at the max level will
A practical tip is tiered downgrading: use high for an Agent's routine steps, and only escalate to max for a retry when a particular step repeatedly fails or requires global replanning. This preserves the success rate of difficult steps without paying the max cost for every step. Also keep in mind one limitation the official docs make explicit: FIM (Fill-in-the-Middle) is only available in non-thinking mode. If your business uses prefix continuation or FIM for code completion, you need to keep a separate pipeline for non-thinking mode.
Key parameters at a glance: API model name deepseek-flash, concurrency 2500, and legacy-name compatibility routing
Before you start, align your parameters first, otherwise the model name is where you're most likely to trip up. The currently valid parameters are as follows:
- API model name: deepseek-flash. This is the only recommended stable identifier.
- Concurrency limit: 2500. This is a fairly high concurrency quota, but note that it constrains the number of simultaneous requests; long sessions don't get cheaper just because concurrency is high.
- Legacy-name compatibility routing: deepseek-v4-flash and deepseek-v4-flash-vision-exp have been retired, but the official side retains temporary compatibility routes that point these two legacy names to V4.1-Flash. This gives you a buffer period for a smooth migration, but it should not be treated as a long-term solution—please unify the model name to deepseek-flash in your configuration center as soon as possible.
- Traffic for deepseek-v4-pro has been routed to V4.1-Flash and billed at Flash pricing since 2026-09-14 12:00, until V4.1-Pro launches. Reconciliation and capacity planning need to take this change into account.
- Supported interface surface: JSON Output, Tool Calls, Responses API, Anthropic API, conversation prefix continuation, and FIM, which is only available in non-thinking mode.
On concurrency design, the 2500 limit combined with a KV size of 890 bytes/token means a single node can safely carry far more long sessions than the previous generation; but on the request side you still need to handle queuing and prioritization yourself: put low-value batch image parsing into idle periods (peak hours are Monday to Friday 9:00–12:00 and 14:00–18:00, with idle pricing at half of peak), and reserve high-priority quota for critical interaction paths. On pricing, cache-hit idle input is only 0.02 yuan per million tokens, while cache-miss idle input is 1 yuan and idle output is 4 yuan; compared with V4 Flash, cache hits are 60% cheaper, misses are about 33.3% cheaper, and output is about 11.1% cheaper. Prefixing reusable content and tiering thinking intensity on demand—these two moves essentially determine the billing trajectory of the vast majority of businesses.
Minimal working code: sending an image into deepseek-flash with the Responses API
Below are three runnable code snippets. The first is a minimal working example: sending a local image into deepseek-flash via the base64 channel, and specifying the thinking intensity.
import base64
import json
from openai import OpenAI
client = OpenAI(
api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com",
)
# 1) Read a local image and convert it to base64 (data URL form)
def image_to_data_url(path: str) -> str:
with open(path, "rb") as f:
raw = f.read()
b64 = base64.b64encode(raw).decode("utf-8")
return f"data:image/png;base64,{b64}"
resp = client.chat.completions.create(
model="deepseek-flash",
messages=[
{
"role": "user",
"content": [
{"type": "text", "text": "Please describe the main content of this image and list the key text in it."},
{
"type": "image_url",
"image_url": {"url": image_to_data_url("demo.png")},
},
],
}
],
# Thinking mode (enabled by default) and thinking intensity: low / high / max
extra_body={
"thinking": {"type": "enabled", "budget": "high"}
},
max_tokens=2048,
)
print(resp.choices[0].message.content)
The second snippet uses the Responses API through the image-link channel, suitable for scenarios where the image is already on object storage or a CDN; the request body is minimal, and the prefix is most likely to hit the cache stably.
import json
from openai import OpenAI
client = OpenAI(
api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com",
)
resp = client.responses.create(
model="deepseek-flash",
input=[
{
"role": "user",
"content": [
{"type": "input_text", "text": "What trend does this chart illustrate? Please give the readings and calculate the year-over-year change."},
{
"type": "input_image",
"image_url": "https://cdn.example.com/report/q3-revenue.png",
},
],
}
],
# Thinking intensity: chart reading + calculation is medium reasoning, choose high
extra_body={"thinking": {"type": "enabled", "budget": "high"}},
max_output_tokens=8192,
)
print(resp.output_text)
The third snippet demonstrates the skeleton of a multi-turn visual Agent: upload an image once with the Files API, get the file ID, and reference it repeatedly across turns, turning the image into a stable cache-prefix asset; at the same time, downgrade low-difficulty steps to low and upgrade difficult steps to max.
import json
from openai import OpenAI
client = OpenAI(
api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com",
)
# 1) Upload an image to get a file ID that can be referenced repeatedly
with open("screenshot.png", "rb") as f:
upload = client.files.create(file=f, purpose="vision")
file_id = upload.id
print("file_id =", file_id)
# 2) Multi-turn visual Agent: the same image + a summary of historical actions
messages = [
{"role": "system", "content": "You are a visual Agent that plans the next operation based on the screenshot."},
{
"role": "user",
"content": [
{"type": "text", "text": "This is the current interface screenshot; please give the next operation."},
{"type": "image", "file_id": file_id},
],
},
]
for step in range(3):
budget = "low" if step < 2 else "max" # low for routine steps, max for difficult replanning
resp = client.chat.compl
Once you have run through these three code snippets, you have already covered the three channels of visual input and the basic control of thinking intensity. The next section will dive into the complete loop of a visual Agent: how to orchestrate multi-round screenshots and tool calls, how to budget-plan long documents with multiple images, how to achieve a 50x cost difference through prefix design for cache hits, and real-world rate limiting and degradation under 2500 concurrency.
In the previous section, we already opened up the three channels of image input (URL, base64, Files API) and dissected the engineering logic behind the CED asymmetric architecture and the 1M tokens context. This section pulls the camera back: from simple "look at an image and answer" to "turn images into downstream-consumable structures, embed visual capabilities into the Agent toolchain, and push costs into a controllable range," ultimately forming a production-grade solution that can be deployed.
Structured Visual Extraction: Combining JSON Output and Tool Calls for Image Information Extraction
The first hurdle for multimodal deployment is not "can it understand" but "once it understands, can it be stably consumed by programs." Visual information is inherently unstructured, while downstream business needs fields, enums, amounts, and dates. DeepSeek-V4.1-Flash natively supports JSON Output and Tool Calls. Combining these two is the correct approach for visual extraction: JSON Output constrains the output form, letting the model generate field by field within schema boundaries; Tool Calls connect external capabilities, handing off fields that cannot be read accurately (currency conversion, product database matching, invoice verification).
In engineering, a "two-stage" orchestration is recommended: the first stage uses JSON Output to perform pure visual field extraction on the image, without introducing any external dependencies, ensuring reproducibility; the second stage uses the first stage's results as tool call parameters to trigger validation and completion. This way, even if an external tool times out, you still have a complete set of raw extraction results for retries and auditing. The code below demonstrates converting an invoice image into a strict schema structure and triggering tool verification when field confidence is insufficient.
from openai import OpenAI
import json
client = OpenAI(
api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com"
)
EXTRACT_SCHEMA = {
"type": "object",
"properties": {
"invoice_no": {"type": "string"},
"date": {"type": "string"},
"total_amount": {"type": "number"},
"currency": {"type": "string"},
"line_items": {
"type": "array",
"items": {
"type": "object",
"properties": {
"name": {"type": "string"},
"qty": {"type": "number"},
"price": {"type": "number"}
},
"required": ["name", "qty", "price"]
}
}
},
"required": ["invoice_no", "date", "total_amount", "currency"]
}
tools = [{
"type": "function",
"function": {
"name": "verify_invoice",
"description": "Call the invoice verification platform to verify invoice authenticity and amount",
"parameters": {
"type": "object",
"properties": {
"invoice_no": {"type": "string"},
"total_amount": {"type": "number"}
},
"required": ["invoice_no", "total_amount"]
}
}
}]
resp = client.chat.completions.create(
model="deepseek-flash",
messages=[{
"role": "user",
"content": [
{"type": "image_url",
"image_url": {"url": "https://example.com/invoice.png"}},
{"type": "text",
"text": "Please strictly extract invoice fields according to the schema. If key fields cannot be confirmed, call the verify_invoice tool for verification."}
]
}],
response_format={"type": "json_object"},
tools=tools,
tool_choice="auto"
)
print(resp.choices[0].message)
A few details in practice are worth emphasizing: first, the narrower the schema, the more stable it is; avoid open-ended objects and tighten as much as possible with enums and required; second, for key fields such as amounts and dates, it is recommended to have the model also output a confidence field, and when it falls below a threshold, hand it over to a tool for re-verification rather than blindly trusting it; third, in thinking mode the model reasons first and then outputs, which easily mixes the chain of thought into the main text. When doing extraction, it is recommended to switch to non-thinking mode to obtain cleaner structured results. When there are many fields and messy images, splitting a large schema into multiple small extractions and then merging them is often more stable than one large extraction.
FIM and Conversation Prefix Continuation: Visual Completion and Controllable Generation Boundaries in Non-Thinking Mode
There are two types of "controlled generation" demands in visual scenarios: one is completion—given an image and half a piece of text, let the model continue; the other is format constraint—force the model to start output from a predetermined prefix to prevent drift. V4.1-Flash provides two means: conversation prefix continuation and FIM (Fill-In-the-Middle). There is a limitation that must be kept in mind: FIM only supports non-thinking mode. This is because thinking mode first generates a reasoning trajectory and then produces the answer, while FIM requires the model to continue strictly from the middle gap; the two are mutually exclusive in generation semantics.
Conversation prefix continuation is essentially pre-setting a beginning for the assistant role, and the model can only write forward. In visual scenarios, this is very suitable for format control: for example, if you require the model to output a Markdown table, you can pre-set the header and the model automatically fills the rows; for example, if you require fixed JSON output, you can pre-set {"result": " to let the model continue from inside the quotes. FIM, on the other hand, is more suitable for code and document completion: if a screenshot contains a table structure diagram and you want to complete annotations or CREATE TABLE statements, give the model the before/after ends and it fills in the middle. The boundary between the two is clear—prefix continuation constrains the "starting point," while FIM constrains the "gap." In engineering, if a task involves images and requires strict formatting, prefer prefix continuation + non-thinking mode; if it involves code completion and has a clear contextual gap, use FIM; once thinking mode is turned on, you must give up FIM.
Anthropic API Compatible Access: A Migration Checklist for Moving an Existing Visual Agent to V4.1-Flash
Many teams' visual Agents are built around Anthropic-style interfaces, and V4.1-Flash provides Anthropic API compatibility, so migration costs are greatly reduced. But compatibility does not mean zero changes. The table below lists required changes and recommended changes.
| Change Item | Anthropic-style Usage | Usage/Notes for Migrating to V4.1-Flash |
|---|---|---|
| Model name | claude-* series | Uniformly change to deepseek-flash; the old names deepseek-v4-flash / deepseek-v4-flash-vision-exp have been taken offline, with only a temporary compatibility route retained, so be sure to switch as soon as possible |
| Image input | source
| Supports three channels: image links, base64, and the Files API. For long conversations, images are recommended to go through the Files API for reuse |
| Thinking mode | thinking budget | Maps to thinking effort low/high/max in three tiers; thinking is on by default, and extraction tasks can switch to non-thinking |
| Tool calling | tool_use / tool_result | Maps to Tool Calls; note the concurrency limit of 2500, so high-concurrency scenarios need queuing |
| Context | 200K class | V4.1-Flash context is 1M tokens and max output is 384K tokens, enough to carry a full image album or a long stream of screenshots |
| Pricing expectation | Billed per Anthropic | Billed at Flash rates, and starting 2026-09-14 12:00, all deepseek-v4-pro requests are routed to V4.1-Flash and billed at Flash rates until V4.1-Pro launches |
The easiest pitfall during migration is assumptions about image format and dimensions. Anthropic imposes per-side resolution and size limits on images, so after migration you need to re-validate according to V4.1-Flash's input method; at the same time, thinking mode being on by default will make prompts that originally "answered directly" verbose, so it is recommended to explicitly declare in the system whether to think, and to run a regression test on tool orchestration. Overall, interface-layer compatibility lets you get requests running first, then align semantics item by item, and the migration window can be compressed to a few days.
Visual Agent in practice: reverse-engineering design tradeoffs from Terminal-Bench 3.0 30.0, DeepSWE v1.1 74.2, and Automation-Bench 54.8
The official release post gives four Agent benchmarks: Terminal-Bench 3.0 score 30.0, DeepSWE v1.1 score 74.2, CyberGym 88.1, and Automation-Bench 54.8. This set of numbers is extremely valuable for designing visual Agents: Terminal-Bench 3.0 is only 30.0, showing that long-horizon terminal operation chains remain a weak spot, and Agents easily drift off target after dozens of steps; DeepSWE v1.1 reaches 74.2, showing that code-level tasks are relatively mature; Automation-Bench 54.8 sits in the middle, meaning everyday automation still has a lot of room for improvement; CyberGym 88.1 shows outstanding performance on security-related tasks.
From this, reverse-engineer the design tradeoffs: for terminal-type visual Agents, do not pursue "one-shot completion"; instead, split tasks into short chains + high-frequency verification, having the model re-decide based on the latest screenshot at every step to avoid long-term reliance on historical actions; screenshot feedback should use differential compression, sending only changed regions, leaving the 1M context for scenarios that truly need full information; failure retries should distinguish "retryable" (timeout, tool error) from "non-retryable" (permission denied, target does not exist), using exponential backoff for the former and escalating directly to a human for the latter. On code-type tasks you can be more aggressive, letting the Agent autonomously complete longer tool chains; on long terminal tasks you should introduce an external state machine as a fallback, with the model only responsible for visual judgment at key nodes. Below is the skeleton of an Agent loop with screenshot feedback and retries.
import time, base64
from openai import OpenAI
client = OpenAI(api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com")
def call_model(history, image_b64, thinking="low"):
return client.chat.completions.create(
model="deepseek-flash",
messages=history + [{
"role": "user",
"content": [
{"type": "image_url",
"image_url": {"url": f"data:image/png;base64,{image_b64}"}},
{"type": "text", "text": "Decide the next action based on the current screenshot, and output a JSON action."}
]
}],
response_format={"type": "json_object"},
extra_body={"thinking": {"effort": thinking}}
)
def run_visual_agent(env, max_steps=15):
history = []
for step in range(max_steps):
shot = env.screenshot()
b64 = base64.b64encode(shot).decode()
for attempt in range(3):
try:
resp = call_model(history, b64)
action = resp.choices[0].message.content
break
except Exception as e:
if attempt == 2:
raise
time.sleep(2 ** attempt) # exponential backoff
history.append({"role": "assistant", "content": action})
if env.done(action):
break
return history
Note that thinking effort low is used here: a visual Agent must make quick decisions at every step, and high/max will significantly slow down the loop; only when encountering ambiguous frames should you temporarily raise the tier. Screenshot base64 will quickly consume context; although 1M is large, it is still recommended to keep only the most recent several frames plus a compressed summary.
Benchmark comparison: interpreting the gap between Terminal-Bench 2.1 90.6 and CyberGym 88.1 relative to V4 Pro
In the official benchmarks, V4.1-Flash scores 90.6 on Terminal-Bench 2.1 and 88.1 on CyberGym, while V4 Pro corresponds to 87.9 on Terminal-Bench 2.1 and 83.3 on CyberGym. This means the smallest member of the family leads by 2.7 and 4.8 points respectively on two hard metrics. Note the version difference: Terminal-Bench 3.0 in the Agent post is a harder new version, scoring 30.0, and cannot be directly compared with 2.1's 90.6—seeing "30 points" should not make you mistakenly think capability has regressed; it is due to increased task difficulty.
There are three key points when reproducing benchmarks: first, version alignment, be sure to confirm whether you are running 2.1 or 3.0, because using the wrong version will completely reverse the conclusion; second, sampling and retry strategy, official scores usually have a fixed number of retries, and if your self-test uses a different number of retries, the fluctuation may exceed 3 points; third, randomness, thinking effort, temperature, and whether thinking is enabled all affect results, so it is recommended to fix parameters and run multiple times to take the average. From a bigger picture, V4.1-Flash adopts a new pretraining method + larger-scale RL post-training, and the official claim is that it comprehensively surpasses V4 Pro on benchmarks; this comparison set of Terminal-Bench 2.1 and CyberGym is exactly supporting evidence. For engineering teams, the conclusion is: do not lower expectations just because it is the "smallest size"; on many hard benchmarks it is instead the strongest choice in the current family.
Engineering pitfalls and solutions: image size, cache hits, and cost control under peak pricing
The bulk of a visual application's bill is often not output, but tokenization of input images plus premium pricing during peak hours. First, lay out the pricing clearly (per million tokens, effective Beijing time 2026-09-10 12:00; peak is Monday to Friday 9:00-12:00 and 14:00-18:00, and idle is half of peak):
| Billing Item | Off-Peak Price (CNY per million tokens) | Peak Price (CNY per million tokens) |
|---|---|---|
| Cache hit input | 0.02 | 0.04 |
| Cache miss input | 1 | 2 |
| Output | 4 | 8 |
Compared with V4 Flash, cache hit prices dropped 60%, cache miss dropped about 33.3%, and output dropped about 11.1%. But a low price does not mean a low bill—the key is the hit rate. The input price gap between cache hits and misses is as high as 50x (0.02 vs 1 yuan at idle), so placing stable system prompts, tool definitions, and reusable image prefixes at the front of the cache is the top priority for cost reduction. On the image side, long sessions should preferentially use the Files API to reference the same image, avoiding re-uploading base64 each time—the same image repeatedly counted as cache-miss input will quickly accumulate costs.
Another set of facts related to KV Cache is worth noting: V4.1-Flash's KV Cache size per token is about 890 bytes, while V4 Flash is about 3514 bytes; HBM demand drops to 1/4 of the previous generation, and SSD storage drops to 1/8, roughly 437x smaller than the first-generation DeepSeek. This means that for self-hosted deployment, VRAM and storage pressure are greatly relieved, and the marginal cost of long context drops significantly. Practical advice: schedule batch tasks during idle periods to cut costs in half directly; limit output to the necessary length and use JSON where possible to reduce invalid tokens; for high-frequency repeated extraction tasks, deduplicate images before feeding them into the model; monitor cache hit rate, and if it is lower than expected, check whether the prefix is being interrupted by dynamic content.
Deployment and Ecosystem Adoption: Hugging Face Weights, Supercomputing Internet One-Click API, WorkBuddy and OpenCode Integration
V4.1-Flash was released and open-sourced on 2026-09-10, with weights released on Hugging Face under the repository deepseek-ai/DeepSeek-V4.1-Flash, accompanied by a technical report, and can be downloaded directly for secondary development and local deployment. For teams without GPU clusters, the National Supercomputing Internet launched the DeepSeek V4.1 Flash model API service and weight files on 2026-09-11. Developers can both call the API with one click and download the weights for local deployment—this is a "zero-infrastructure" starting path.
On the ecosystem side, official partners WorkBuddy (including CodeBuddy) and OpenCode have fully integrated, allowing V4.1-Flash to be selected directly within these tools; the official team says it will work closely with the open-source community to advance inference support for V4.1-Flash and explore more deployment options. Large-scale deployments targeting 2000 GPU + storage clusters can be discussed with the official team. One reminder: the old model names deepseek-v4-flash and deepseek-v4-flash-vision-exp have been discontinued, with only a temporary compatibility route pointing to V4.1-Flash retained. For long-term use, please unify on deepseek-flash. The consumer-facing product has also consolidated the original three conversation entries—"fast response / professional consultation / image recognition"—into a single interactive interface, indicating that multimodality is no longer a separate entry point but a default capability.
Summary and Best Practices
Compress the entire article into an actionable checklist:
- Model unification: Always use deepseek-flash, with base_url https://api.deepseek.com; immediately stop using deepseek-v4-flash and deepseek-v4-flash-vision-exp.
- Extraction tasks: Constrain the schema with JSON Output; the narrower the fields, the more stable it is; add confidence to key fields, and use Tool Calls for re-verification when below the threshold.
- Controlled generation: For format control, use dialogue prefix continuation; for code/text completion, use FIM, and FIM is limited to non-thinking mode.
- Mode selection: Default to thinking, with low/high/max intensity as needed; use low or non-thinking for extraction and high-frequency Agent loops, and upgrade only for complex reasoning.
- Context management: 1M context and 384K max output are upper limits, not goals; compress screenshots with differencing, and reuse images in long sessions via the Files API.
- Agent design: Refer to Terminal-Bench 3.0 30.0, DeepSWE v1.1 74.2, and Automation-Bench 54.8; for long terminal tasks, use short chains + high-frequency verification + external state machine fallback.
- Evaluation comparison: Terminal-Bench 2.1 90.6 and CyberGym 88.1 versus V4 Pro's 87.9 and 83.3; note version differences and retry strategies, and average multiple runs with fixed parameters.
- Cost control: Cache hit input is 0.02 yuan at idle / 0.04 yuan at peak, cache miss is 1 / 2 yuan, and output is 4 / 8 yuan; put stable prefixes first to improve hit rate, schedule batch processing during idle periods, and use JSON output to control length.
- Deployment paths: For self-hosting, download the deepseek-ai/DeepSeek-V4.1-Flash weights; for zero infrastructure, use the National Supercomputing Internet (launched 2026-09-11) one-click API; on the tool side, use WorkBuddy / OpenCode; for large-scale clusters (2000 GPU + storage), contact the official team for discussion.
- Concurrency and migration: The concurrency limit is 2500, so queuing is required; Anthropic-style interfaces can be migrated compatibly, with the main changes being the model name, image input parameters, and thinking mode mapping.
At this point, the complete loop from image input to visual Agent has been thoroughly explained. V4.1-Flash achieves highly competitive hard benchmarks within the family and extremely low inference cost at the smallest size. What remains is to implement the checklist above item by item in your production system.