On September 10, 2026, DeepSeek released DeepSeek-V4.1-Flash, the smallest member of its new architecture family. It is not a routine version iteration, but rather bundles a 552B total-parameter MoE with an entirely new Causal-Encoder-Decoder (CED) asymmetric architecture: only 8B activated on the input side and 16B on the output side. Combined with aggressive KV Cache compression, it reduces HBM requirements to 1/4 of the previous generation and SSD storage to 1/8, an overall reduction of roughly 437x compared with the original DeepSeek. With a 1M-token context, 384K-token maximum output, native multimodality, and three levels of thinking intensity, Flash's benchmark scores comprehensively surpass those of V4 Pro. This article unfolds in two parts: this part first dissects the architecture and the financials, while the next part covers engineering deployment and migration strategy. Understanding CED's asymmetric activation is the starting point for understanding all of Flash's cost advantages.
CED Asymmetric Architecture Overview: Why a 552B MoE Activates Only 8B on the Input Side and 16B on the Output Side
The design intuition behind Causal-Encoder-Decoder is this: split "understanding long input" and "writing long output" into two separate compute budgets. The input side faces a 1M-token context, and its task is essentially encoding—compressing the context into a representation that the decoder can repeatedly query; the output side faces 384K-token generation, where every new token must pass through full attention and FFN forward passes, making it the true amplifier of inference cost. Flash therefore makes an asymmetric split in MoE routing: only 8B activated on the input side and 16B on the output side.
This ratio is not arbitrary. The input side processes 1M tokens of prefill and encoding in one pass; if the activated parameters were stacked very high, prefill's compute peak and memory bandwidth would be instantly saturated. Yet the input side's encoding quality only needs to be "good enough for the decoder to query," and 8B of activation is sufficient to cover long documents, codebases, and multimodal visual features—content that needs to be understood but not reproduced verbatim. The output side is the opposite: every generated token is depended upon by subsequent tokens, so output quality is more sensitive to activation capacity, hence 16B. In one sentence: the input side buys "coverage," while the output side buys "generation quality."
The impact on inference cost is twofold. First, the prefill stage (the most expensive stage for long contexts) is billed at an 8B activation scale, so per-token activation compute is markedly lower than that of same-tier models of the same period; second, the decode stage is billed at a 16B activation scale, saving the input-side redundancy compared with a fully symmetric 16B input-output model. Combined with the KV Cache compression discussed later, Flash's cache-miss input pricing lands at 1 yuan per million tokens idle and 2 yuan per million tokens at peak, with output at 4 yuan idle and 8 yuan at peak—a 60% price reduction for cache hits versus V4 Flash, roughly 33.3% for misses, and roughly 11.1% for output. The pricing structure itself reflects the cost curve brought by asymmetric activation.
It must be emphasized that CED's "asymmetry" is not merely an asymmetry in the number of activated parameters, but an asymmetry in computation mode: the input side is encoder-like causal attention, while the output side is standard autoregressive decoding. The two segments share the same 552B MoE base, selecting different activation subsets by stage through routing and gating, rather than being two independent models. This is also why it can serve externally as a single model, exposing only one deepseek-flash model name.
Division of Responsibilities Between the Causal-Encoder and Decoder: How the Attention Path for a 1M Context Runs
On the attention path, the division of labor between the Causal Encoder and Decoder determines where the cache is written and where it is read. The input-side Causal Encoder performs one complete causal attention forward pass over 1M tokens, computing the K/V representations for each layer and writing them into the KV Cache; the output-side Decoder, during generation, reads these already-materialized K/V entries and only appends new K/V entries for the tokens it newly produces. In other words: cache writes happen in the encoding stage, while cache reads dominate the decoding stage. This split lets the heavy work on the input side be done only once, keeping every step on the decoding side as light as possible.
The key to this division supporting 1M tokens is that the chunking and sparsification of attention computation are completed on the Encoder side, so the Decoder side only faces a small working set of "existing compressed cache + new tokens." If all K/V for a 1M context were retained as-is, memory requirements would explode linearly with length; Flash's approach completes eviction and quantization before the Encoder writes to the cache, so that the entries entering the cache are compressed in both count and bit width. This is also the structural basis for the simultaneous, substantial drops in the two official metrics of HBM and SSD.
There is a counterintuitive point to understand in engineering: a 1M context does not mean a 1M attention matrix resident in memory. Flash uses chunked prefill to cut long input into multiple chunks, encoding chunk by chunk and writing cache chunk by chunk, so peak memory depends only on chunk size and the number of cache entries, not linearly on total length. This is the precondition for serving a 1M context even in batched scenarios. The following call example shows the basic form of ultra-long input:
from openai import OpenAI
client = OpenAI(
api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com"
)
# 1M-token-scale long document input: relies on Causal Encoder chunked prefill
# Thinking mode is enabled by default; here max is explicitly specified to observe long-context reasoning
resp = client.chat.completions.create(
model="deepseek-flash",
messages=[
{"role": "system", "content": "你是一名严谨的长文档分析助手。"},
{"role": "user", "content": long_document + "\n\n请给出结构化的风险清单。"}
],
extra_body={"thinking": {"type": "enabled", "intensity": "max"}}
)
print(resp.choices[0].message.content)
The KV Cache Compression Revolution: Deriving the Mechanisms Behind HBM Dropping to 1/4 and SSD to 1/8
The two official figures are central to understanding Flash's economics: HBM requirements drop to 1/4 of the previous generation, SSD storage to 1/8, and roughly 437x smaller than the original DeepSeek. Compression occurs at two levels: first, the cache structure itself is restructured, with the Encoder side writing compact K/V representations after eviction and quantization, systematically shrinking the product of layers × heads × bit width; second, at the scheduling level, cold cache is offloaded to SSD while hot cache stays in HBM, forming a tiered cache. The 1/4 corresponds to the capacity reduction at the HBM layer, and the 1/8 to the storage reduction at the SSD layer—the two are not two framings of the same number.
The 437x order of magnitude comes from taking the ratio of "the cache footprint of the original DeepSeek at the same context scale" to "Flash's compressed tiered cache footprint." It simultaneously stacks architectural generational gains, the reduction in cache entries brought by asymmetric activation, and quantization and eviction strategies. It is important to understand this: 437x is not brought by a single technology, but by the product of architecture + cache structure + tiered scheduling. Any claim attributing it to a single trick is inaccurate.
The direct implication for developers is that the value of cache hits is amplified. In official pricing, cache-hit input costs only 0.02 yuan idle and 0.04 yuan at peak per million tokens, while misses cost 1 yuan idle and 2 yuan at peak—the price gap between hits and misses reaches 50x. This means that in long-context, multi-turn conversation, and repeated system prompt scenarios, keeping the prefix stable and reusing the cache is a more effective way to save money than switching models. The table below compares different approaches in terms of cache and cost trade-offs:
| Approach | HBM Cache Footprint | SSD Tiering | Input Billing (Idle/Peak) | Applicable Scenarios |
|---|---|---|---|---|
| No cache, full recomputation each time | High (peak grows with length) | Not used | 1 yuan / 2 yuan | One-off short requests |
| Prefix cache hit | Low (reuses compact K/V) | Optional | 0.02 yuan / 0.04 yuan | Multi-turn conversations, fixed system prompts |
| Long documents + cold cache offloaded to SSD | Further reduced | Enabled | Hit price + cold start latency | 1M context batch processing |
The engineering pitfall is this: cache hits require the prefix to be byte-for-byte identical. Any attempt to insert timestamps or random IDs into the system prompt will drive the hit rate to zero and push the cost from 0.02 yuan back to 1 yuan. Keeping a stable prefix and placing variable content at the tail of the user message is basic discipline for long-context applications.
1M input and 384K maximum output: VRAM and throughput engineering constraints under long context
A 1M-token context and a 384K-token maximum output are two independent constraints and must not be conflated. 1M is the length the input-side Encoder must encode; 384K is the upper limit the Decoder can generate in a single pass. They impose different engineering requirements: the input side must solve peak management for chunked prefill and cache writes, while the output side must solve VRAM steady state and streaming return during long generation.
At the batching level, long context significantly reduces the effective batch size. Because each request's K/V cache occupies VRAM, once requests with 1M context run concurrently, HBM is quickly exhausted. The solution is chunked prefill: split the long input into fixed-size chunks and feed them into the Encoder one by one to control the single-pass peak VRAM; at the same time, exploit cache hits so that multiple requests sharing the same prefix reuse the already-encoded K/V. On the output side, streaming must be enabled; if a 384K-token output waits until full completion before returning, it is neither realistic nor conducive to the client consuming it as early as possible.
Another lesson in peak VRAM management is: do not stuff a full 1M input and also demand a 384K output in the same request. The cache footprint of input encoding and the cache footprint of output appending will stack, and near the limit this easily triggers eviction, which instead slows down decode. A reasonable approach is to split "heavy input understanding" and "heavy output generation" into two stages or two requests, stitching the intermediate results together with conversation prefix continuation. Below is a steady-state request example with tool calls and JSON output:
import json
from openai import OpenAI
client = OpenAI(
api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com"
)
# JSON Output + Tool Calls combination: structured output, easy for downstream parsing
resp = client.chat.completions.create(
model="deepseek-flash",
messages=[
{"role": "user", "content": "Read /data/metrics.csv and summarize the anomalous metrics."}
],
tools=[{
"type": "function",
"function": {
"name": "read_file",
"description": "Read a local file",
"parameters": {
"type": "object",
"properties": {"path": {"type": "string"}},
"required": ["path"]
}
}
}],
response_format={"type": "json_object"}
)
print(json.loads(resp.choices[0].message.content))
New pretraining method + larger-scale RL post-training: a training-side interpretation of comprehensively surpassing V4 Pro on benchmarks
The official statement is "adopts a new pretraining method + larger-scale RL post-training, comprehensively surpassing V4 Pro on benchmarks." From the training side, these two correspond to two different capability dimensions. The new pretraining method mainly improves representation quality and long-context extrapolation, which explains why Flash can still maintain reasoning stability under a 1M context; larger-scale RL post-training improves instruction following, tool use, and reasoning-chain quality, which explains the gains on agent- and safety-oriented benchmarks such as Terminal-Bench and CyberGym.
The two most noteworthy comparisons in the official benchmarks are: CyberGym 88.1 versus V4 Pro's 83.3, and Terminal-Bench 2.1 score 90.6 versus V4 Pro's 87.9. Both rely heavily on multi-step tool calls and long-horizon planning, exactly the areas that benefit from scaled-up RL post-training. The hardware-side metrics are also impressive: GPQA Diamond 90.9, Codeforces rating 3471, MathArena Apex 65.6, showing that reasoning and coding ability have not shrunk because of the small activated parameters—asymmetric activation saves inference compute, not the capability ceiling.
What requires restraint is that the official announcement only released these benchmark scores and a directional description of the training method, without disclosing the pretraining data volume, RL steps, or compute scale. No specific numbers can be guessed. What can be established in this paragraph is: Flash, with the family's smallest size and an activation scale of 8B on the input side / 16B on the output side, achieved results that comprehensively surpass V4 Pro, and the two training-side variables (new pretraining method, larger-scale RL) are the two attributable main lines.
Three levels of thinking-mode intensity: low / high / max and invocation strategy for the default thinking mode
Flash supports non-thinking mode and thinking mode, and thinking mode is enabled by default. Thinking intensity has three levels—low, high, and max—directly corresponding to the three-way trade-off among latency, cost, and accuracy. A practical judgment framework is: if it can be answered by rules or retrieval, use non-thinking; if it requires multi-step reasoning but the path is clear, use low; if it requires exploration, verification, and error correction, use high; for long-horizon agent tasks and high-difficulty math and code, use max.
In terms of cost, the higher the thinking intensity, the more thinking tokens the model produces, and the higher the output billing. Since output is priced at 4 yuan off-peak and 8 yuan at peak per million tokens, long thinking at the max level will noticeably inflate the bill. In terms of latency, the first-token latency and total duration at the max level are significantly higher than at low. Therefore, do not treat max as the default: the default thinking mode already has a reasonable balance when no intensity is specified, and it should be explicitly maxed out only when truly needed.
The engineering pitfall is: FIM is only supported in non-thinking mode. If your code completion pipeline relies on FIM, you must explicitly disable thinking mode, otherwise the request will fail or will not reach the FIM path. This is also why thinking-intensity configuration and functional capability are decoupled—they are not orthogonal. The example below shows an explicit configuration for non-thinking mode:
from openai import OpenAI
client = OpenAI(
api_key="your-deepseek-api-key",
base_url="https://api.deepseek.com"
)
# Non-thinking mode: the only legal combination for FIM code completion
resp = client.completions.create(
model="deepseek-flash",
prompt="def quicksort(arr):\n ",
extra_body={
"thinking": {"type": "disabled"},
"fim": True
}
)
print(resp.choices[0].text)
FIM is limited to non-thinking mode: interface boundaries and alternatives for code completion scenarios
Officially, FIM is clearly available only in non-thinking mode. The engineering implication of this boundary is: code completion is an independent, low-latency, no-chain-of-thought fast path, and it is a different form from agent-style code generation. In IDE completion scenarios, low latency matters more than long reasoning, so disabling thinking and using FIM is the correct choice; whereas for tasks like "rewrite the entire file according to requirements," you should use thinking mode + Tool Calls or conversation prefix continuation, rather than forcing FIM.
There are two configuration combinations to avoid: first, FIM + thinking mode enabled, which is directly illegal; second, FIM + conversation prefix continuation, whose semantics overlap and should not be mixed. The alternatives are: when you need context-aware completion, use non-thinking mode + a long prefix (stuff the file's preceding context into the prompt) so that cache hits on the prefix reduce input cost; when you need cross-file reasoning, switch to thinking mode and use the chat interface.
JSON Output, Tool Calls, and conversation prefix continuation: implementation points for structured output
Flash offers multiple capability combinations for structured output: JSON Output, Tool Calls, Responses API, Anthropic API, conversation prefix continuation, plus FIM, which is available only in non-thinking mode. Their applicable scenarios differ. JSON Output is suitable for extraction and classification with a fixed schema, parsed directly downstream; Tool Calls is suitable for agent workflows where the model must actively decide which external function to call; Responses API is suitable for applications that need server-side state maintenance and multi-step interaction; Anthropic API compatibility allows teams with existing Claude toolchains to migrate at low cost; conversation prefix continuation is suitable for having the model continue after a given prefix, used for controllable generation and stitching. There is one important constraint when using these in combination: JSON Output and Tool Calls can coexist, but thinking intensity and FIM are mutually exclusive. In addition, conversation prefix continuation changes the prefix structure of the cache key; if the prefix changes frequently, the cache hit rate will drop. As for the model name, the new model name is deepseek-flash, with a concurrency limit of 2500; the old names deepseek-v4-flash and deepseek-v4-flash-vision-exp have been taken offline, but compatibility routing is retained, so old code will not immediately error out, but you should switch to the new name as soon as possible. There is also a timing point that has a major impact on cost: starting at 12:00 Beijing time on 2026-09-14, all requests to deepseek-v4-pro will be routed to V4.1-Flash and billed at the Flash price. Pricing takes effect from 12:00 on 2026-09-10. Peak hours are Monday to Friday 9:00-12:00 and 14:00-18:00, and idle hours cost half of peak. Scheduling batch jobs into idle windows can directly cut costs in half. Native multimodal visual understanding supports three input methods: image links, base64, and the Files API, providing a unified entry point for document and screenshot understanding. In the next section, we will translate the above capabilities into concrete engineering plans for migration and tuning. Following the previous section's breakdown of the principles of the CED (Causal-Encoder-Decoder) asymmetric architecture and the quantitative analysis of KV Cache compression—the separation of responsibilities between 8B activation on the input side and 16B activation on the output side, as well as a storage structure reduced to 1/4 of the previous generation for HBM and 1/8 for SSD, roughly 437 times smaller than the first-generation DeepSeek—this section moves into the implementation layer, translating architectural advantages into executable engineering decisions. DeepSeek-V4.1-Flash natively supports multimodal visual understanding, providing three input paths: image links (URL), base64 inline, and the Files API. The three are not simply equivalent; under the CED architecture, the differences are amplified because visual tokens are first compressed into hidden states on the encoder side (8B activation) and then consumed by the decoder side. Which path you choose directly determines call chain length, cache hit rate, and bandwidth cost. Engineering recommendation: use the Files API for frequently reused images, base64 for one-off small images, and URL for static images already hosted on the public internet; be sure to ensure byte-level stability, otherwise the cache hit rate will drop to zero. After the 2026-09-10 release, the official API's formal model name is deepseek-flash; the old names deepseek-v4-flash and deepseek-v4-flash-vision-exp have been taken offline, but compatibility routing is retained. This means that existing production requests will not 404 because of the rename, but will instead be transparently forwarded to deepseek-flash. From an engineering perspective, this is both a benefit and a trap: the benefit is zero-modification migration; the trap is that compatibility routing does not guarantee fully identical parameter semantics, especially since some visual parameters corresponding to the old experimental vision name may be normalized.Native multimodal visual understanding: three input paths via image links, base64, and the Files API
Comparison Dimension Image Link base64 Inline Files API Request Size Extremely small About +33% Extremely small (reference id) External Dependency Strong (must be fetchable) None None Cache Reusability Low Medium (only hits if bytes are stable) High (stable id) Call Chain Complexity Medium Low Medium (one extra upload step) Applicable Scenarios CDN-hosted images Small images/one-off inference Reused images, batch tasks import base64
import requests
API_KEY = "your-deepseek-api-key"
BASE = "https://api.deepseek.com"
HEADERS = {"Authorization": f"Bearer {API_KEY}"}
# Path 1: Upload once via the Files API, then reuse with the file id
with open("diagram.png", "rb") as f:
upload = requests.post(
f"{BASE}/files",
headers=HEADERS,
files={"file": ("diagram.png", f, "image/png")},
data={"purpose": "vision"},
).json()
file_id = upload["id"]
# Path 2: base64 inline
with open("small.png", "rb") as f:
b64 = base64.b64encode(f.read()).decode()
payload = {
"model": "deepseek-flash",
"messages": [{
"role": "user",
"content": [
{"type": "image_url", "image_url": {"url": f"file://{file_id}"}},
{"type": "image_url", "image_url": {"url": f"data:image/png;base64,{b64}"}},
{"type": "text", "text": "Compare the differences between the two architecture diagrams and output JSON."},
],
}],
"response_format": {"type": "json_object"},
}
resp = requests.post(f"{BASE}/chat/completions", headers=HEADERS, json=payload)
print(resp.json()["choices"][0]["message"]["content"])
API migration in practice: the deepseek-flash model name, compatibility routing for old names, and the 2500 concurrency limit
deepseek-flash; old code can retain the old name in the short term, but it is recommended to complete the replacement and regression testing within one iteration cycle.import time
import t
2026-09-14 Routing Switch: Compatibility Handling for All deepseek-v4-pro Requests Redirected to V4.1-Flash
Starting at 2026-09-14 12:00 Beijing Time, all deepseek-v4-pro requests are fully routed to V4.1-Flash and billed at Flash pricing. This is an irreversible migration window, and production systems need to do three things in advance:
- Capability regression: Although official benchmarks show V4.1-Flash comprehensively surpassing V4 Pro (e.g., GPQA Diamond 90.9, CyberGym 88.1 vs. V4 Pro's 87.9 and 83.3), it is still recommended to run an A/B test on your own business dataset to confirm consistent output style, JSON structure, and tool-calling behavior.
- Cost expectation recalculation: After routing to Flash, billing follows Flash pricing—cache hits at 0.02/0.04 CNY, misses at 1/2 CNY, output at 4/8 CNY (idle/peak). If you previously budgeted at Pro pricing, you need to re-accrue and use the cost reduction headroom to adjust concurrency and caching strategies.
- Model name convergence: Explicitly replace
deepseek-v4-proin your code withdeepseek-flashto avoid long-term reliance on implicit routing and to facilitate parameter-level canary releases later.
For compatibility strategy, it is recommended to implement a model name mapping table at the gateway layer, normalizing old names uniformly to deepseek-flash, while logging the original model name for observability to help pinpoint differences before and after the switch.
Pricing Structure and Peak/Idle Periods: The Cost Optimization Math for Cache Hits, Misses, and Output
Pricing takes effect from 2026-09-10 12:00 Beijing Time. Peak periods are Monday to Friday 9:00-12:00 and 14:00-18:00; all other times are idle. Idle pricing is half of peak. Compared to V4 Flash: cache hits reduced by 60%, misses reduced by approximately 33.3%, output reduced by approximately 11.1%.
| Billing Item (CNY/million tokens) | Idle | Peak | vs. V4 Flash |
|---|---|---|---|
| Cache hit input | 0.02 | 0.04 | 60% reduction |
| Cache miss input | 1 | 2 | ~33.3% reduction |
| Output | 4 | 8 | ~11.1% reduction |
The core lever for cost optimization is cache hits: the price difference between hits and misses reaches 50x (idle 0.02 vs. 1). Solidify stable prefixes (system prompts, tool definitions, fixed documents) at the front of requests, and leverage conversation prefix continuation and prompt caching to push these tokens down to the 0.02 CNY tier. Second, move non-real-time tasks to idle windows to cut costs in half directly. On the output side, since the reduction is only 11.1%, controlling output length (e.g., limiting max tokens, using JSON Output to constrain structure) is more worthwhile than compressing input.
Official Benchmark Deep Dive: Capability Profile of GPQA Diamond 90.9, Codeforces 3471, Terminal-Bench 2.1 90.6
Official benchmarks provide a clear capability profile:
- GPQA Diamond 90.9: Graduate-level science Q&A, approaching top-tier performance, indicating that the CED decoder-side 16B activation is highly efficient on complex reasoning chains.
- Codeforces rating 3471: Competition-level programming at an extremely high level, combined with Tool Calls and FIM (non-thinking only), suitable for code completion and automated repair.
- MathArena Apex 65.6: High-difficulty math benchmark, demonstrating the gains of thinking mode on long-chain reasoning.
- Terminal-Bench 2.1 score 90.6: Outstanding terminal/command-line task agent capability, suitable as an agent execution layer.
- CyberGym 88.1: Cybersecurity scenario score, a notable improvement over V4 Pro's 83.3.
Compared to V4 Pro: official figures are GPQA Diamond 90.9 vs. 87.9, CyberGym 88.1 vs. 83.3, with all other items comprehensively surpassed. This means migrating from Pro to Flash is not a downgrade but an upgrade, at lower cost.
Open Source and Ecosystem Integration: Hugging Face Weights, Technical Report, and WorkBuddy, OpenCode Integrations
Officially, weights have been released on Hugging Face, accompanied by a technical report covering the CED asymmetric structure, KV Cache compression details, and training recipe. For in-house teams, this means quantization, distillation, and domain fine-tuning can be done in private environments. On the ecosystem side, official partners WorkBuddy (including CodeBuddy) and OpenCode have fully integrated, allowing developers to directly use V4.1-Flash's vision, tool-calling, and long-context capabilities in these tools, lowering the integration barrier.
- Weights: Directly obtainable from Hugging Face, with the technical report to understand CED implementation details.
- WorkBuddy / CodeBuddy: Plug-and-play integration for office and coding scenarios.
- OpenCode: Integration for open-source coding workflows, suitable for automated development processes.
- API side: JSON Output, Tool Calls, Responses API, Anthropic API, conversation prefix continuation, FIM (non-thinking only) are all available.
Engineering Pitfalls of CED Asymmetric Architecture: Troubleshooting Checklist for Cache Consistency, Multimodal Interleaving, and Long Output Truncation
The CED asymmetric design (8B activation for input, 16B activation for output) brings efficiency but also introduces several typical issues:
- Cache consistency pitfall: Any byte change in the prefix (timestamp, random id, image re-encoding) causes a cache miss, jumping cost from 0.02 to 1 CNY. Troubleshooting: move dynamic fields after the prefix, fix system prompts and tool definitions; for images, upload to Files API first to get a stable id.
- Multimodal interleaving pitfall: When visual tokens and text tokens interleave, unstable image order or placeholder method breaks the cache prefix. Troubleshooting: unify the position and order of images in the content array, maintain byte-level consistency of base64 or id.
- 384K long output truncation pitfall: Maximum output is 384K tokens; exceeding it gets truncated. Troubleshooting: set max_tokens limit and detect finish_reason; on truncation, use continuation (conversation prefix continuation) rather than retrying the full amount.
- Thinking mode switching pitfall: Default thinking mode; low/high/max three levels affect latency and cost. Troubleshooting: explicitly disable thinking for non-reasoning tasks; FIM is only available in non-thinking mode.
- Concurrency and rate limiting pitfall: Under the 2500 concurrency limit, burst traffic easily triggers 429. Troubleshooting: local semaphore + exponential backoff, distinguish burst from sustained load.
Summary and Best Practices
- Model name unification: New code should always use
deepseek-flash; old namesdeepseek-v4-flash/deepseek-v4-flash-vision-exprely on compatibility routing and should be replaced ASAP. - 9-14 migration window: From 2026-09-14 12:00 Beijing Time, v4-pro is fully routed to V4.1-Flash and billed at Flash pricing; do capability regression and cost recalculation in advance.
- Vision input selection: Frequently reused images go through Files API, one-off small images via base64, public static images via URL; ensure byte stability to hit cache.
- Cost optimization: Prioritize improving cache hits (0.02 CNY tier), move non-real-time tasks to idle windows, control output length; cache hit price difference reaches 50x.
- Concurrency design: Under the 2500 concurrency limit