deepseek v3每秒生成多少字

你大概遇到过这种场景：同一句提示词，早上问 DeepSeek V3 感觉唰唰出字，晚上再问就一个字一个字往外蹦，于是开始怀疑「是不是官方变慢了」。其实每秒出多少字，跟模型本身关系没那么大，更多取决于你在哪调、发多长、并发几个人、输出是中文还是代码。这篇不给死数字，只给一套能自己量、能横向比、能定位瓶颈的做法。

你大概遇到过这种场景：同一句提示词，早上问 DeepSeek V3 感觉唰唰出字，晚上再问就一个字一个字往外蹦，于是开始怀疑是不是官方变慢了。先别急着下结论，每秒出多少字这件事，跟模型本身的关系没你想的那么大，更多取决于你在哪调、发多长、并发几个人、输出是中文还是代码。

下面不给死数字，只给一套能自己量、能横向比、能定位瓶颈的做法。你按这套跑完，再回头看别人报的速度，就知道该怎么读那个数了。

为什么没人能给你一个「每秒多少字」的定数

最根本的原因是单位对不上。输出速度的原始单位是 token/s，不是字/s。中文一个字常常对应一到多个 token，英文一个词也未必是一个 token，所以「每秒多少字」这个口径本身就带着换算误差。想先把概念对齐，可以到 /ai-dict/category/basics 把 token 的定义过一遍，后面所有换算都建立在这个理解上。

• 同一模型换一条调用路径，速度就变：官方直连、聚合平台、自建机房，排队策略和限流口径完全不同
• 输入的提示词越长，首字延迟越高，长对话一路累积，感知会越来越慢
• 是否开思考模式、输出是散文还是长代码，都会改变出字节奏，代码还常带缩进和符号
• 所以正确说法是「在某个渠道、某次请求下的实测值」，模型本身没有固定速度

影响出字快慢的六个变量，按影响从大到小排

这张表的使用顺序是从上往下：先确认渠道，再看输出类型，然后依次排查。多数人以为的模型变慢，最后都落在前两行。渠道对速度的影响通常比模型版本大得多。

自己测一遍：三步拿到可用数字

1. 固定变量同一条提示词、同样输出长度上限、同样是否流式，只改一个条件。否则测出来的差异说不清是谁造成的。
2. 量两个指标首字延迟和生成阶段的 token/s。前者体感最明显，后者才是真正的吐字速度。延迟基线可以到 /tools/speed-test 量一下。
3. 换算成「字」拿同一段中文分别数 token 和字数，得到一个属于自己的换算系数，再用它去换算。比直接信别人给的数字靠谱得多。

记录时带上时间点、渠道、并发数。攒三五次就能看出规律，也方便跟平台方对账。如果要横向比多家，先去 /inference 这类页面对齐吞吐口径，再回到 /tools/speed-test 用自己的网络实测一遍，两边对照着看。

什么情况下别纠结出字速度

• 任务是批处理、离线生成，慢一点不耽误交付，这时优先看输出质量和稳定性
• 你只是偶尔问几句，首字延迟比整体吐字速度更值得优化，减少输入长度比换渠道见效更快
• 本地部署且显存吃紧时，瓶颈通常在显存卸载与算力，不在模型选择，可对照 /models/deploy 的测算口径
• 实时对话、同声翻译、边写边看的场景，速度就是硬指标，值得为它单独挑渠道

反过来也要注意：如果你业务本身对延迟不敏感，为速度多花钱、多换渠道就是白折腾。先想清楚你的场景到底卡在哪一步，再决定要不要为速度投入。

拿数字对比时怎么不被带偏

别人报的速度要问清四件事：渠道、提示词、输出类型、是否流式。缺一条就没法跟你自己比。同一家平台不同时间段测出来的差异，往往比不同平台之间的差异还大，所以至少避开自己的业务高峰去测。

真要长期盯，就把测速做成固定脚本定期跑，而不是每次靠感觉判断。脚本里把渠道、提示词、输出类型写死，只留时间变量，跑一段时间就能看出趋势。要对比多家的可信度，可以顺手到 /rankings 和 /price-watch 看当时的公开数据，再结合自己的实测下判断。