两个团队都能报告 DeepSeek V4.1 Flash 每秒数百个 token，但衡量的仍可能是不同事物。一个可能指单个请求的解码速度；另一个可能指数十个并发请求的聚合输出。要改进 DeepSeek V4.1 Flash 推理吞吐量优化，首先选择你的服务所需指标，然后基于你自己的请求组合进行基准测试，一次只更改一个服务变量，并同时验证延迟、质量和成本。该模型系列现在包含 10 月 17 日的 Flash-1017 更新，因此在比较结果前记录准确检查点。公开报告展示了有用的优化路径，但都不能替代在你自己硬件上进行的匹配测试。
关键要点
- 聚合输出 tokens/s 衡量跨请求的容量；每请求解码速度衡量单个用户体验。
- 在调优前复现你的提示长度、输出限制、并发、热状态和延迟目标。
- V4.1 Flash 的压缩 KV 缓存和有界重放可降低内存压力，但不保证固定的端到端加速。
- 仅在模型、硬件、工作负载和测量条件匹配时比较 vLLM 和 SGLang。
对 DeepSeek V4.1 Flash 而言，吞吐量意味着什么？
吞吐量是一个速率，但分子和测试边界很重要。对于推理服务，至少记录五项测量：
| 指标 | 它告诉你什么 | 典型用途 |
|---|---|---|
| 聚合输出 tokens/s | 由所有活动请求每秒产生的输出 token | 容量规划和集群效率 |
| 每请求解码 tokens/s | 单个请求体验到的生成速度 | 生成期间的交互响应速度 |
| 预填充 tokens/s | 每秒处理的输入 token | 长提示和检索密集型工作负载 |
| 首个 token 时间 (TTFT) | 从请求到达至首个输出 token 的时间 | 感知到的启动延迟 |
| 端到端延迟，p50/p95 | 流量分布中的总请求时长 | 服务级别目标和尾部行为 |
服务器可以通过批处理更多序列来提高聚合吞吐量，同时让每个用户在 token 之间等待更久。反过来，针对低并发调优的设置可能提供快速的单个响应，却让加速器利用不足。两种结果都不是普遍更好。正确的目标是吞吐量-延迟曲线上的一个点，满足你产品的服务目标。
这两个速率统计的是不同输出流。这是概念图，并非实测的 DeepSeek V4.1 Flash 性能。
明确吞吐量是否包括预填充、解码或两者。说明是否除以 GPU 数量。报告成功的输出 token，而不是请求的最大 token，并披露取消或错误。没有这些细节，tokens/s 数字无法告诉运维人员它是否能预测其应用表现。
构建可复现的 DeepSeek V4.1 Flash 基线
有用的基线要足够接近生产流量，以暴露其瓶颈。单个短提示无法很好地代表反复发送大量对话历史的智能体，而固定 1,024 token 输出会漏掉提前停止或变化很大的工作负载。
固定工作负载和测量窗口
根据观察到的流量创建请求分桶。对于每个桶，保留近似输入长度、预期输出长度、到达模式和任何共享前缀。如果工具或推理轮次构成真实请求路径的一部分，则将其包含在内。在多次运行之间保持提示、采样设置、停止条件和输出上限固定。
同时运行低并发情况和你的服务在峰值时预期的并发。然后加入中间并发级别，以揭示吞吐量在哪里停止上升或延迟在哪里越过其限制。在预热后使用稳定的测量窗口，重复每个点，并报告中位数加范围。短时突发可能测量的是启动行为，而不是稳定的服务容量。
将冷启动测量与热服务分开。根据技术栈不同，冷运行包括模型加载、图捕获或缓存填充；热运行描述已准备好服务的系统。对于前缀缓存工作负载，分别测量缓存命中和缓存未命中流量。除非组合比例与生产匹配，否则不要将它们合并为一个平均值。
保留基准测试记录
为每次运行保存一行，包含以下字段：检查点或模型修订版；运行时和提交；GPU 型号和数量；互连；精度和量化；张量、专家或流水线并行布局；输入和输出 token 分布；并发和请求到达模式；热或冷状态；运行时长；成功率；聚合吞吐量；每请求解码速度；TTFT；以及 p50/p95 端到端延迟。
该记录比排行榜数字更有用，因为它使下一次实验可复现。在调优前将其冻结。如果工作负载或检查点变化，请启动新基线，而不要将差异归因于某个服务标志。
诊断预填充、解码、KV 缓存或调度
使用症状来选择下一次测量，而不是猜测修复方法。TTFT 高但解码速度可接受，指向输入处理、排队、缓存未命中或启动开销。低并发下解码缓慢，表明应检查内核、内存带宽、并行通信和模型执行路径。随着并发上升，聚合吞吐量趋于平台期，可能表明内存压力、调度器限制、通信开销或计算路径饱和。长上下文性能下降则需要测量缓存驻留、预填充工作和主机到设备传输。
| 观察结果 | 首先检查 |
|---|---|
| TTFT 随提示长度增长 | 预填充速率、队列时间、前缀缓存命中率、图或编译预热 |
| 即使在并发 1 时解码速度也很低 | 运行时模型路径、内核支持、精度、GPU 利用率、通信开销 |
| 聚合 tokens/s 随并发上升而趋于平台期 | KV 缓存容量、调度器批处理、内存带宽、并行拓扑 |
| p95 延迟急剧上升，而聚合输出改善 | 批大小、排队策略、请求长度组合、服务目标 |
| 长提示驱逐有用的活动请求 | KV 缓存驻留、缓存分配、上下文分布、主机内存流量 |
V4.1 Flash 具有旨在缓解其中一些压力的架构特性。模型报告描述了 CSA2，具有跨层缓存复用和 FP4 全局 KV 缓存，报告称全局 KV 占用为每 token 890 字节，约为 V4-Flash 对应占用的四分之一。SWA 有界重放解决了另一种存储权衡：部署不必持久化所有滑动窗口注意力状态，而是可以通过重放最近窗口来重建缺失状态。DeepSeek 报告称，对于此设计，持久化 KV 缓存接近 V4-Flash 占用的八分之一，并伴有少量额外的预填充重计算。这些是架构和部署结果，不是八倍吞吐量承诺。（DeepSeek 技术报告，2026 年 9 月）
源图描述的是缓存容量，而非每个部署的端到端吞吐量倍数。
当诊断不明确时，对一次代表性运行进行性能分析，并检查队列时间、GPU 利用率、内存使用和分阶段计时。更改一个变量，重新运行相同工作负载，并检查输出正确性或任务质量。这可以防止表面上的加速掩盖服务或答案的回归。
针对同一目标调优 vLLM 或 SGLang
选择其当前模型路径支持你打算部署的检查点和硬件的运行时。验证确切的发布版本、内核、图行为和并行布局。模型被列为受支持，并不意味着每种量化或拓扑都得到同等优化。
vLLM：验证特定发布版本的模型路径
vLLM 团队 10 月的报告描述了其 AgentX 基准测试上的进展：与第零天基线相比，低延迟结果提升约 1.9 倍，在 150 TPS 约束下吞吐量提升约 5.3 倍。该工作包括带 CUDA 图的 SWA 有界重放，以及模型专用内核集成。将这些值视为该技术栈在该基准测试下随时间发生实质性变化的证据，而不是可套用到另一个集群的倍数。（vLLM 工程报告，2026 年 10 月）
对于你的运行，首先建立受支持的发布版本和已知良好配置。然后分别测量图捕获或重放行为、批处理和并行。保留用于选择更高吞吐量点的延迟约束。如果图捕获改变启动或内存需求，请将这些成本纳入部署决策。
SGLang：匹配其并发特征
SGLang 团队的报告给出了一个异常清晰的例子，说明为什么测试上下文很重要。在 8 块 H200 GPU 上，其未使用投机解码的优化运行，在并发为 1 时，每用户从大约 76 tokens/s 提升到 168 tokens/s；在并发为 64 时，每 GPU 输出从约 96 tokens/s 提升到 221 tokens/s。它使用固定的 8,192 token 输入和 1,024 token 输出。其另外的 4×GB300 结果使用了不同的提示长度、并行设置和 DSpark 投机解码。因此，该报告支持你根据自己的流量评估 SGLang 的优化，而不是将其直接与 vLLM AgentX 数字排名。（LMSYS/SGLang 优化报告，2026 年 9 月）
来源报告使用了不同的工作负载和硬件；其数字不应被解读为直接对比图。
从一个运行时开始，并优化其受支持路径。只有在你能保持检查点、GPU 分配、提示和输出分布、并发、预热和服务目标恒定时，才构建第二个运行时比较。这种比较会消耗工程时间，因此首先确认当前技术栈确实是限制因素。
在不破坏 SLO 的情况下优化并发和长上下文
逐步增加并发，并在每一步捕获聚合输出、每请求解码速度、TTFT、p95 延迟、内存使用和失败情况。只有当最高吞吐量点的延迟和错误率仍满足你的服务目标时，才保留它。如果请求在生成前排队，更大的批处理可能提高设备利用率，同时让产品感觉更慢。
对于长上下文流量，测量活动上下文分布和缓存命中率。声明的最大上下文窗口并不意味着每个请求都能以该长度并发得到服务。KV 缓存与权重、激活、图池和运行时缓冲区争夺内存。为可变请求长度留出余量，并在现实流量下测量驱逐或抢占。
更长的上下文或更多并发请求可能增加 KV 缓存需求。内存块为示意，并非按比例绘制。
将量化、KV 缓存精度、张量并行、专家并行以及预填充/解码分离视为独立实验。它们可能改变内存使用、通信、内核选择、输出质量和延迟。最佳布局取决于 GPU 类型和互连；增加更多 GPU 可能提高通信成本或让部分资源闲置。更改精度或模型执行后，验证确切的输出质量和故障模式。
实用顺序很简单：复现基线，找出未达到目标的指标，形成一个瓶颈假设，更改一个设置，然后重复。如果该设置改善了一个指标却损害了另一个指标，请明确决定这种权衡是否适合产品。这使优化成为受控决策，而不是一堆标志。
验证投机解码和每一项声称的加速
当草稿 token 被高效接受且运行时良好实现验证时，投机解码可以减少串行目标模型工作。其收益取决于草稿路径、接受行为、批形状、硬件以及提示/输出组合。它可能有助于解码受限流量，而当预填充、排队或通信占主导时价值很小。
在启用和禁用投机的情况下运行 A/B 测试。保持模型检查点、提示集、token 上限、到达模式、并发、预热和测量窗口固定。如果可用，记录每个验证步骤接受的 token，同时记录聚合吞吐量、每请求速度、TTFT、p95 延迟、GPU 使用、失败和任务质量。已发布基准中的模拟接受长度是测试条件，而不是可假定用于你的提示的值。
声称的加速只有在通过三项检查时才有用：相同的服务目标、可接受的答案质量，以及公平的成本比较。发布任何数字时都报告完整上下文。避免将不同的 GPU 数量、提示长度、输出长度、精度模式、模型修订版或指标当作受控实验来比较。
自托管，还是使用托管式 DeepSeek V4.1 Flash API？
当流量足够稳定以保持 GPU 有用、团队能够运营推理基础设施，并且对硬件或执行的控制足以证明运营工作合理时，自托管才有意义。包括加速器、容量余量、电力、网络、存储、维护和工程时间的全部成本。仅凭高峰值 tokens/s 结果，并不能确立每个成功任务的成本更低。
当团队需要快速验证产品需求、避免运行服务集群，或将 API 基线与自己的部署进行比较时，托管 API 很有用。Atlas Cloud 在模型 ID deepseek-ai/deepseek-v4.1-flash 下列出了 DeepSeek V4.1 Flash，并提供 OpenAI 兼容 API。DeepSeek V4.1 Flash 模型页面 目前显示每百万输入 token $0.30、每百万输出 token $1.20、每百万缓存读取 token $0.03，截至 2026 年 10 月未显示折扣。在估算支出前，请查看当前定价列表。托管端点并不能免除测量自身请求延迟或流量经济性的需要。
该列表标明了一个托管 API 选项；它不是服务基准测试。
为了做出公平的部署决策，请对自托管服务和托管端点重放相同的业务请求。比较每个已完成任务的成本、延迟分布、可靠性以及维护每种选项所需的人员时间。如果你的主要目标是 DeepSeek V4.1 Flash 推理吞吐量优化，请为两条路径保持相同的工作负载和成功标准。
常见问题
吞吐量与每用户每秒 token 数有什么区别？
聚合吞吐量统计活动请求的输出。每用户 tokens/s 衡量单个请求的解码速率。批处理可以提高前者，同时降低后者，因此对于交互式服务应同时报告两者。
增加并发总能提高吞吐量吗？
不能。聚合输出可能上升，直到计算或内存饱和，然后趋于平缓。此后排队和尾部延迟可能持续恶化。当服务目标不满足时，停止增加并发。
vLLM 和 SGLang 的基准数字可以直接比较吗？
只有当模型修订版、硬件、提示和输出长度、并发、热状态、测量边界和延迟约束匹配时才可以。已发布报告使用不同设置，因此它们展示的是优化路径，而不是直接的运行时胜者。
什么时候应使用托管 API 而不是自托管？
当集成速度和减少基础设施工作比拥有服务技术栈更重要时，使用托管 API。当利用率、运营专业知识、控制以及经过衡量的总成本案例证明运行 GPU 合理时，选择自托管。
