
如果您曾经将长简报粘贴到DeepSeek中并看到“长度限制已达到,开始新的聊天”,那么您已经遇到了DeepSeek字符限制的实际边缘。坦白地说,DeepSeek根本不测量字符——它测量的是 令牌,您关心的每一个限制(提示词大小、对话长度、回复长度、文件上传)都是以令牌为单位执行的,而不是字符。这种区别很重要,因为一个英语单词大约是1.3个令牌,而一个中文字符大约是0.6个令牌。本指南为您提供了当前DeepSeek V4系列的精确数字,展示了如何将字符转换为令牌进行规划,并解释了当聊天遇到瓶颈时如何恢复。
简短回答:DeepSeek限制的是令牌,而不是字符

DeepSeek 没有设置“每条消息最大字符数”。相反,模型会进行计数 令牌 ——分词器从您的文本中产生的子词单元。相同的硬限制适用于您的输入、系统提示、任何上传的文件内容以及模型的回复组合。当运行总接近模型的上下文窗口时,您会看到截断、“长度限制已达到”横幅或400类API错误。
对于规划,请使用以下工作比例:
- 英语: 1个令牌 ≈ 4个字符 ≈ 0.75个单词。1,000个令牌的提示词大约是3,300-4,000个字符或600-900个单词。
- 中文、日语、韩语: 1 Chinese character ≈ 0.6 令牌. A 1,000-token prompt is roughly 1,650 Chinese characters.
- 代码: ~2–3 令牌 per character in dense languages; a useful shortcut is ~4 令牌 for a simple line, ~8–12 for a real-world line 带缩进、名称和注释。以这个速度,1M个令牌大约可以容纳80K-150K行代码,具体取决于风格和语言。
如果您需要确切的数字,请在将其粘贴到长时间运行的会话之前,通过 DeepSeek token counter 运行您的文本。
概览当前DeepSeek V4的限制
The current generation is DeepSeek V4于2026年4月24日发布,以两个MIT许可下的开放权重专家混合模型的形式发货。V4两个级别共享相同的上下文架构。
| 限制 | deepseek-v4-flash | deepseek-v4-pro |
|---|---|---|
| Total parameters | 284B(13B活跃) | 1.6T(49B活跃) |
| 上下文窗口(输入+输出) | 1,000,000 令牌 | 1,000,000 令牌 |
| Max output 令牌 | 384,000 | 384,000 |
| 推荐的thinking-max上下文 | ≥ 384K 令牌 | ≥ 384K 令牌 |
| 思维模式 | 非思维/高/最大 | 非思维/高/最大 |
| Weights license | MIT | MIT |
DeepSeek-V4-Pro拥有1.6T参数(49B激活)和DeepSeek-V4-Flash拥有284B参数(13B激活)——两者都支持一百万个token的上下文长度。上下文窗口为1,048,576个token,最大输出为384,000个token。对于Think Max推理模式,DeepSeek建议将上下文窗口设置为至少384K个token。
一个值得注意的微妙之处:1M个上下文是用于输入的。大多数答案都适合在2,000个输出token内。1M个上下文是用于输入,而不是输出。如果你期望生成50K个token的响应,你受到的限制是max_令牌,而不是上下文窗口。换句话说,一百万token的数字是余量,但384K的输出上限和你的 max_令牌 参数通常先咬一口。
API如何计算令牌
DeepSeek的聊天界面是对OpenAI兼容性的薄包装。 POST /chat/completions endpoint at https://api.deepseek.com。输入token和生成token的总长度受模型上下文长度的限制。你 messages 数组中的每个token——系统提示、先前助手操作回放、新用户消息以及模型的响应——都计入同一个窗口。
这里是使用OpenAI SDK的最小Python模式:
from openai import OpenAI
client = OpenAI(
base_url="https://api.deepseek.com",
api_key="YOUR_KEY",
)
resp = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[
{"role": "system", "content": "You are a concise assistant."},
{"role": "user", "content": "Summarise this contract in 5 bullets."},
],
max_令牌=2000,
temperature=1.3,
)
print(resp.usage.prompt_令牌, resp.usage.completion_令牌)
The usage 响应中的对象为你提供了权威的计数: prompt_令牌, completion_令牌,加上 prompt_cache_hit_令牌 and prompt_cache_miss_令牌 计费。这是唯一重要的计数——来自第三方库的tokenizer估计可能会相差几个百分点。
关于API界面相对于聊天机器人的两个要点:
- The API is statelessDeepSeek在其侧边不记住之前的转向;你必须每次请求时重新发送完整的对话历史。相比之下,网页聊天和移动应用会为你保存会话历史。
- DeepSeek还在相同的基URL上暴露了一个Anthropic兼容的界面,因此Anthropic SDK通过交换来工作。
base_urlandapi_key.
关于获取认证和有效请求的背景信息,请参阅 DeepSeek API getting started tutorial.
Legacy model IDs and the migration window
如果您的代码仍然使用 deepseek-chat or deepseek-reasoner,你有截止日期。模型名称deepseek-chat和deepseek-reasoner将在未来被弃用。为了兼容性,它们分别对应于deepseek-v4-flash的非思考模式和思考模式。遗留ID在[3]上被完全退役。 2026-07-24 at 15:59 UTC之后它们就会失败。
迁移只需一行代码更改。保持 base_url, just update model to deepseek-v4-flash or deepseek-v4-pro本指南中的令牌限制已经适用于你今天的流量,因为遗留ID路由到V4-Flash。
网络聊天和移动应用:用户实际遇到瓶颈的地方
On DeepSeek chat 在浏览器和移动端 DeepSeek app,你不会看到令牌计数。当对话超过系统的最大令牌或上下文容量时,会出现横幅:“长度限制达到,开始新的聊天”。
聊天机器人跟踪整个线程的累积令牌使用情况,而不是每条消息。这意味着:
- 单次粘贴大量内容可以在一次操作中填满窗口。
- 许多小的转向也可以填满它——每个之前的使用者/助手对都会保持在上下文中,直到你开始新的聊天。
- 上传的PDF文件、图片和文档将被提取为文本并添加到相同的预算中。
系统必须同时考虑您的输入和AI的响应。长度随时间默默累积,这就是为什么消息可能会突然出现。
为什么“字符”不是正确的思考单位
Users reach for “character limit” because that is the language Twitter and SMS taught us. Inside an LLM, the budget is 令牌, and tokenization depends on the script, the language, and how rare a word is. “Antidisestablishmentarianism” is one English word but several 令牌; “你好世界” is four Chinese characters and roughly two-and-a-bit 令牌. Reasoning in characters will mislead you. Reason in 令牌, and use a counter when the gap matters.
当你达到限制时会发生什么

三种故障模式,按照它们在实际中出现的频率排序:
- 在长答案的中间截断。 响应对象的
finish_reason返回值为"长度"如果finish_reason="长度",则消息内容可能会部分截断,这表示生成超过了max_令牌或对话超过了模型的上下文长度。通过增加输入长度来修复。max_令牌(V4上最多384,000)或分割任务。 - 提示被拒绝。 在生成开始之前,API返回400错误,因为输入本身已经超出了窗口大小。通过裁剪历史记录、总结或把大量参考材料移入检索索引来修复。
- “Length 限制 Reached” in the chatbot. 开始新的聊天。粘贴一个紧凑的总结,说明你之前停下的地方,而不是完整的记录。
保持低于限制的实用策略
1. 缓存静态前缀
当DeepSeek检测到请求之间存在重复的前缀时,上下文缓存是自动的。如果两个请求共享一个公共前缀(例如,系统提示或少量示例),DeepSeek将应用上下文缓存。那些重复的标记不会按全额计费。您将在使用对象中看到这一点,例如在prompt_cache_hit_令牌和prompt_cache_miss_令牌字段下。标记以64个标记的块进行缓存。将您的系统提示和少量示例移至 messages的开头,并在调用之间保持字节相同。缓存大大降低了成本;然而,它并不会扩展窗口。参见 DeepSeek context caching 具体规则的参考。
3. 使用检索处理大型语料库
对于长时间运行的线程,请模型生成到目前为止对话的200-400个标记摘要,然后以摘要作为系统提示重新开始。您在下一阶段的工作预算上做出了一些精度上的妥协。
4. 故意设置最大token数
一百万个Token足以容纳一个中等规模的代码库或一系列合约,但将所有内容输入会降低精度。使用嵌入来检索相关的片段;不是默认的。 DeepSeek RAG tutorial 介绍了一个工作流程。
思考模式会改变你的token计算
如果你要求一份50,000个token的报告,设置 max_令牌=60000,而不是默认的。如果你只需要一个简洁的答案,将其设置为1,500——这可以保护你免受无休止的JSON输出和模型填充到你没有阅读的内容中的影响。
工作示例:计算长文档工作流程的成本
V4支持在两个模型上设置三种推理努力级别:默认思考模式,以及 reasoning_effort="high" (pass extra_body={"thinking": {"type": "disabled"}} for non-thinking) with extra_body={"thinking": {"type": "enabled"}}, or reasoning_effort="max" 用于最深入的思考。当启用思考模式时,响应将返回 reasoning_content alongside the final content。这两个字段都计入你的输出计费。
两个运营后果:
- Token消耗更高。 推理跟踪可以在最终答案出现之前运行数千个Token。相应地预算输出。
- 请勿重放
reasoning_content. 当你继续一个多轮对话线程时,只发送助手的最终回复。contentback. Replaying reasoning text in the next prompt wastes 令牌 and confuses the model.
对于思考密集型的工作负载,至少分配384K个Token的上下文,否则推理链会静默截断。
如何与DeepSeek相比,其他提供商在上下文方面的比较
假设你每月对10,000份合同进行审查。 deepseek-v4-flash。每个调用都有一个4,000个Token的系统提示(首次请求后缓存),一个50,000个Token的合约(未缓存,每个调用不同),以及一个5,000个Token的结构化响应。V4-Flash费率:$0.0028缓存命中 / $0.14缓存未命中 / 每输出1M个Token $0.28。
Cached input: 4,000 × 10,000 = 40,000,000 令牌 × $0.0028/M = $1.12
Uncached input: 50,000 × 10,000 = 500,000,000 令牌 × $0.14/M = $70.00
Output: 5,000 × 10,000 = 50,000,000 令牌 × $0.28/M = $14.00
------
Total $85.12
在同一台机器上运行相同的任务。 deepseek-v4-pro 在促销价$0.435 / $0.87(至2026-05-31享受75%折扣;目录价$0.0145 / $1.74 / $3.48)每1M个Token,账单为$5.80 + $870.00 + $174.00 = $1,049.80——这是一个有用的提醒,当提示很长时,层级选择的影响远大于其他所有因素。 DeepSeek pricing calculator 为你处理算术运算。
文件、图像和音频
截至2026年4月,1M-token的上下文在市场上处于领先地位,但仅仅窗口大小并不能说明全部——深度检索准确性和输出限制都很重要。MRCR 8-needle的准确率在256K 令牌时保持在0.82以上,在1M 令牌时保持在0.59。实际上,这意味着V4在几十万个令牌内是可靠的,而在极端情况下会逐渐变弱。对于头对头上下文比较,请参阅 DeepSeek vs Claude and DeepSeek vs Gemini.
快速参考:规划你的提示

在消费者DeepSeek应用中,您可以上传文档、图像和PDF文件;系统会从每个文件中提取文本并用作输入。提取的文本计入相同的上下文窗口——包含图表的30页PDF可能包含约15,000-25,000个提取的文本令牌。当您上传一个长问题时,请考虑这一点。有关逐步文件工作流程,请参阅 DeepSeek功能 reference.
DeepSeek中的最大字符限制是多少?
- 简短问题,无历史记录: 适用于任何模型、任何级别——限制不适用。
- Long document review (≤ 200K 令牌): V4-Flash,非思考模式。预算4-8K输出。
- Repository-scale code analysis (200K–800K 令牌): V4-Pro,思考高度。分阶段提示;不要一次性全部输入。
- 对小输入进行复杂推理: V4-Pro,最大思考模式。分配384K上下文。
- 多轮代理循环: 缓存系统提示;在每个里程碑处总结旧回合。
查看每个模型能做什么的更全面情况,请浏览 DeepSeek beginner guides hub.
DeepSeek AI Guide is an independent resource and is not affiliated with DeepSeek or its parent company. Model IDs, pricing and API behaviour change; check the official DeepSeek documentation and pricing page before committing to a production decision.
为什么DeepSeek会说“长度限制已达到,开始新的聊天”?
DeepSeek不强制字符限制,而是强制令牌限制。当前DeepSeek V4系列支持1,000,000个令牌的上下文窗口,在V4-Flash和V4-Pro上最多可输出384,000个令牌。作为一个粗略的参考,1M 令牌大约相当于750,000个英语单词或1.65M个中文字符。使用 DeepSeek token counter 在粘贴长简报之前进行精确计数。
DeepSeek API是否有每日消息上限?
这条消息意味着您的消息总数加上模型的回复已达到该线程的上下文窗口。聊天机器人跟踪每个回合的累积使用情况,包括上传的文件。修复方法是开始一个新的聊天,并粘贴先前对话的简要总结而不是完整记录。 DeepSeek troubleshooting 涵盖其他常见错误信息。
DeepSeek中一个英文单词是多少个token?
一个英语单词平均有1.3个令牌,一个令牌大约有4个字符。一封典型的600字电子邮件大约有800个令牌;一份10页的文档大约有4,000-6,000个令牌。代码的token化密度更高——每行现实世界的代码预计有8-12个令牌。在发送请求之前对令牌进行计数和预算的更深入参考,请参阅 DeepSeek API best practices guide.
我能否将输出token限制增加到384,000以上?
截至2026年4月,DeepSeek并未公开文档说明API的每日消息上限。在负载较重时,它采用动态并发节流,表现为HTTP 429响应。应以指数退避和抖动的方式处理这些响应,而不是将其视为硬性配额。关于速率限制行为和重试的具体细节,请参阅 DeepSeek API rate limits reference.
Can I increase the output token limit beyond 384,000?
No. 384,000 令牌 is the hard maximum for output on both deepseek-v4-flash and deepseek-v4-proIf you encounter a 429 response, it indicates that the API has reached its concurrency limit. In this case, you should implement a retry mechanism with exponential backoff and jitter. The retry interval should be at least 60 seconds, and the maximum number of retries should be limited to 5. If you continue to experience issues, please contact DeepSeek support for assistance. DeepSeek API streaming 指南显示了该模式。
Sources & Methodology
Primary sources
- OfficialDeepSeek API documentationEndpoints, request/response shape, model IDsLast checked: April 30, 2026
- PricingDeepSeek API定价页面每百万令牌费率,计费单位,缓存命中定价Last checked: April 30, 2026
Methodology
Information in this article was checked against the official DeepSeek documentation, the article's cited primary sources, and the deepseekai.guide pricing dataset on the date shown above. Where third-party numbers are quoted, the originating source is linked inline so the reader can verify and re-check.
Data confidence
引用带主要来源链接的事实为高;上下文叙述为中等。
Editorial note
AI tooling moves quickly. If you spot an outdated number or a broken link, the contact link in the footer is the fastest way to flag it for the editorial team.