你可能遇到过这种情况：同一个 DeepSeek 模型，自己的机器上跑出来慢得离谱，换成在线接口又快得不一样，问别人给的数字又对不上。这篇不给你一个「标准答案速度」，而是把影响 tokens/s 的变量拆开：量化档位、显存与卸载、并发与批处理、输入输出长度比例、推理框架。看完你能自己测出一份靠谱的基线数字，并且知道它什么时候不适用。
先说结论：tokens/s 没有标准答案，你抄来的任何数字都必须连同测试条件一起看。同一个 DeepSeek 模型，换一张卡、换一个量化档位、换一个推理框架，结果可能差好几倍；在线接口和你本地跑，更是两个不可直接对比的口径。别人说快，你要先问一句「在什么条件下快」。
这篇不给你一个可背下来的速度值，而是把变量拆开：怎么量、被什么拖慢、不同规格和部署方式的差距从哪来、怎么做出能拿给别人看的对比表，以及什么情况下这个数字其实不重要。看完你能自己测出一份靠谱基线，并且知道它什么时候不成立。
先说清楚 tokens/s 到底怎么量，别拿错的数字比
很多人测速只记一个「快」字，但 tokens/s 至少有三个口径：首 token 延迟（TTFT）、单请求生成速度、整体吞吐。三者经常互相矛盾——首 token 快的不一定生成快，单请求快的并发一拉就崩。客服说的「快」、评测里写的「快」、你自己感觉的「快」，很可能不是同一件事，先对齐口径再比。
| 口径 | 衡量什么 | 典型适用场景 |
|---|---|---|
| TTFT 首 token 延迟 | 用户发出请求到看到第一个字的时间 | 对话补全、实时交互 |
| 单请求生成速度 | 一个请求从首 token 到结束的平均 tokens/s | 单次长文生成、代码补全 |
| 整体吞吐 | 所有并发请求合计的 tokens/s | 离线批处理、批量翻译、数据标注 |
- 固定变量再比：同一提示词、同一输出长度、同一并发数、同一量化档位，缺一项差异就有一部分来自你的测试设置
- 先量基线：到 /tools/speed-test 量出你当前环境的延迟基线，当作后续所有对比的对照组
- 短回答速度普遍偏高：只跑十几 token 的问答，样本太小，测出来的数字没有代表性，至少让输出跑到几百 token
- 别用「感觉快」下结论：手感和数字经常对不上，手边放个秒表或脚本比嘴靠谱
拖慢 DeepSeek 的几件事，按排查顺序排一遍
速度掉下来，先别急着换框架或者换卡，按下面的顺序排查，多数问题在前两步就能定位。真正难搞的往往不是模型本身，而是显存、并发和框架配置这些外围变量。
- 第一步：看显存打开监控看显存占用是不是贴着上限。一旦触发 CPU offload 或分层卸载，速度会掉一个数量级，这是最常见的「突然变慢」原因。
- 第二步：确认真的走了 GPU本地环境最容易踩的坑是框架悄悄退回 CPU 跑。看日志里有没有加载 CUDA 设备，用一张小卡跑一遍对比时间，差几十倍就是没上 GPU。
- 第三步：看量化档位量化档位选得太激进，速度和质量不一定同向变化。档位怎么取舍、显存怎么折算，去 /models/deploy 看部署测算口径。
- 第四步：看并发策略并发拉高之后单请求速度下降、总吞吐上升，这是正常现象，不是故障。一张卡能扛多少并发要按显存算，参考 /compute/sizing。
- 第五步：换框架验证同一个模型换推理框架和批处理策略，结果可能完全不同。怀疑框架有瓶颈，就换一个跑同样的负载对比。
排查顺序别乱：先排除显存和 GPU 这类硬问题，再调框架和批处理参数。反过来做，你把框架参数调穿了也可能根本没碰到真正的原因。
不同规格、不同部署方式下速度差在哪
参数量越大、注意力开销越高，单请求速度通常越慢，但这是趋势不是定律——实际差距更多取决于你的卡和量化档位。只看参数量判断速度，很容易被误导。
- 总参数 vs 激活参数
- MoE 类结构里这两个不是一回事，报速度前先确认你查的是哪个口径，否则对比全是错位
- 在线接口 vs 本地部署
- 对方有批处理、有更快的卡、也可能有排队限流，速度不可直接对比，只能同口径下比
- 量化档位
- 影响显存占用和计算量，进而影响速度，不同档位之间的数字不能拿来互相替代
想知道各家当前实测数字，去 /models 和 /benchmarks 看记录，去 /usage 看真实用量口径。别人截图里的旧数字不要直接抄，模型版本、部署环境、并发条件任何一项变了，数字就不成立。模型版本对照看 /official-api/providers/deepseek。
做一份能拿给别人看的对比表
如果你要把速度结论发给同事、写进选型报告，光说「快」没用。下面这张表缺任何一列，结论都会被质疑。列全了，别人才能判断这个数字对他适不适用。
| 必填字段 | 怎么写 | 为什么必须写 |
|---|---|---|
| 硬件 | 卡型号与数量、显存大小 | 硬件变了速度就变，没写等于没说 |
| 量化档位 | 具体档位或精度口径 | 不同档位速度不可比 |
| 输入/输出长度 | 提示词和生成各多少 token | 长输出和短问答速度差别明显 |
| 并发数 | 单请求还是多请求并发 | 并发会改变单请求速度 |
| TTFT 与生成速度 | 两个口径分开记 | 合在一起容易误导 |
| 测试条件备注 | 什么情况下这个数字不成立 | 防止别人误用 |
- 每组配置跑三轮取中位数，砍掉第一次的冷启动结果，避免被首次加载拖低
- 输入长度和输出长度都记录下来，长上下文和高输出量会明显拖慢速度
- 在表下方写清楚「什么情况下这个数字不成立」，比如换成长输出、换成高并发就另测
- 跨平台对比前先确认版本和量化是否一致，否则测的是两个不同的东西
什么时候不用纠结 tokens/s
不是所有场景都该盯着生成速度。分不清主次，容易为了一个不重要的指标折腾半天，最后发现瓶颈根本不在这。
- 对话补全类任务以首 token 延迟和交互体验为主，只盯生成速度意义有限，先把 TTFT 压下来
- 离线批处理看的是总吞吐和单位成本，不是单请求速度，应该算总账，去 /tools/model-cost-calculator 折算
- 如果瓶颈在你自己的排队、网络或响应解析上，先修链路再谈模型速度，否则优化模型也白搭
- 只做一次少量调用、对等待不敏感的场景，没必要为省几秒去做深度调优
常见问题
为什么我自己测的 DeepSeek 速度比别人说的慢很多？
大概率不是模型问题，而是变量不同：量化档位、显存是否够、有没有 CPU 卸载、并发数、输出长度都会影响结果。先把显存占用和是否走 GPU 确认一遍，再固定同一组参数重测，对比才有意义。
tokens/s 高就说明这个部署方式更好吗？
不一定。单请求速度高可能牺牲了并发吞吐，也可能换来了更低的量化精度。要看你跑的是交互场景还是批处理场景，前者看延迟，后者看单位时间总产出和成本，两者最优配置常常不一样。
在线接口和我本地跑的结果能直接比吗？
不建议直接比。在线侧有批处理、集群和限流策略，本地侧受你单卡显存和框架限制，两者的 tokens/s 口径并不对等。要对比就固定同一提示词和输出长度，并且把排队和网络时间单独拆出来看。
