DeepSeek V4 Flash 这个版本最值得关注的不是名字而是标题里这组数字278 tok/sfull precisionno quantization。翻译过来就是模型权重不做量化按完整精度跑推理每秒能生成 278 个 token。对在本地或私有环境里部署大模型的人来说这组数字传递两个信号一是速度已经比较接近工程可用的门槛二是至少在这个测试场景里不需要为了跑得快牺牲权重精度。下面按实际落地顺序拆一遍先说怎么理解这个数字再说复现它需要什么环境、怎么做测速最后把常见报错和参数边界整理出来。如果你手上正好有 DeepSeek V4 Flash 的权重或者只是想知道全精度推理到底能跑多快这篇思路可以直接复用。1. 278 tok/s 这个数字先分清它到底可不可信任何速度数字脱离测试条件都没有意义。278 tok/s 看起来很快但你要先弄明白它是在什么条件下测出来的否则很容易拿别人的数据规划自己的业务最后上线时发现完全对不上。1.1 先澄清一个命名混用Flash 是模型名不是存储和插件搜索这个主题时你会看到大量无关内容NAND Flash、NOR Flash、Flash 下载失败、DLL 被取消、Flash ID 查颗粒、基于 MQTT 和 Flash 的智能家居监控平台。这些和 DeepSeek V4 Flash 完全是两回事。这里的 Flash 是模型家族里的一个版本命名。从命名习惯看Flash 后缀通常表示比同系列完整版更轻、更侧重推理速度和资源控制的版本。搜索资料时建议直接组合模型关键词比如DeepSeek V4 Flash full precision、DeepSeek V4 Flash tok/s、DeepSeek V4 Flash 量化对比否则很容易被存储芯片、固件烧录的内容淹没。还有一点要注意如果你看到类似error: flash download failed - target dll has been cancelled这种报错先确认一下是不是在用嵌入式烧录工具。那是芯片烧录、固件下载场景里的错误和模型推理没有关系别拿它往大模型上套。1.2 tok/s 有两种口径测速之前必须分开一次完整推理分两个阶段prefill 和 decode。prefill 负责处理输入文本把 prompt 转成 KV Cachedecode 负责逐个生成输出 token。标题里的 278 tok/s 到底算哪个阶段差别非常大。很多推理工具默认报告的 tok/s 是 decode 阶段的速度也就是生成阶段的速度。prefill 阶段因为要并行处理整段输入衡量方式不一样速度单位虽然也写 tokens/s但含义完全不同。如果你通过 API 只统计总耗时然后用输出 token 数除以总时长这个数字会同时混入 prefill 时间和网络开销不能代表模型真实的生成速度。所以复现前先明确口径你要的是单条请求的端到端速度还是纯解码吞吐还是并发下的整体吞吐。这决定了后面所有测试怎么做。1.3 全精度通常指 FP16/BF16不是非要 FP32full precision 在推理语境里一般指权重不量化也就是用 FP16 或 BF16 加载模型而不是转成 INT8、INT4 或 FP8。FP32 在训练里常见推理时显存占用大、收益小多数推理引擎默认也不会用纯 FP32 跑。标题特意写 no quantization想表达的核心是这个速度是在没有牺牲权重精度的前提下得到的。这一点有价值因为低比特量化虽然能提速、省显存但偶尔会在输出质量和稳定性上带来波动。全精度跑出一个不错的 tok/s说明优化空间可以放在引擎和硬件上而不是先靠砍精度换速度。2. 复现测试前先对齐硬件、模型格式和推理引擎标题没有给出参数量、上下文长度和测试显卡所以 278 tok/s 只能当作参考点。想在自己机器上复现或对比先把三个前置条件理清楚显存够不够、模型是什么格式、用哪个推理引擎。2.1 显存怎么算权重字节数加 KV Cache第一步不用急着下载模型先做估算。公式很简单BF16/FP16每个参数占 2 字节FP32每个参数占 4 字节INT8每个参数占 1 字节INT4每个参数约 0.5 字节举个例子假设一个模型是 32B 参数BF16 权重大约是 64GB再加上 KV Cache 和激活值单卡 80GB 会比较从容48GB 比较紧张24GB 基本很难跑全精度长上下文。这是数学账和具体厂商无关可以自己算。除了显存内存带宽更关键。decode 阶段是典型的带宽瓶颈模型权重在显存里被一遍遍读取每读一遍才能生成一个 token。高带宽显卡跑大模型特别快消费级显卡带宽低同样模型速度可能差好几倍。如果 278 tok/s 是在数据中心级显卡上测出来的那它更多反映的是硬件带宽而不是单纯模型能力。2.2 模型格式决定你能用哪些引擎模型文件格式主要分两类。safetensors 是 Transformers 生态的标准格式适合 vLLM、SGLang、Transformers 这些引擎。全精度跑法通常优先选 safetensors BF16因为 vLLM 这类引擎对高吞吐场景优化更好也自带 OpenAI 兼容接口。GGUF 是 llama.cpp 生态的格式适合 CPU、CPUGPU 混合、低显存环境。如果显存不够也可以把全精度权重转成 FP16 或 BF16 的 GGUF这仍然算没有量化权重的方案只是格式不同。拿到模型先看目录结构确认是 safetensors 还是 GGUF再决定走哪条路。这一步搞错后面所有命令都会跟着错。2.3 三类引擎按场景选别一套配置打天下我的建议是按目标分三类只想快速验证模型能不能跑、行为正不正常用 Transformers 写最小脚本最快缺点是速度慢。要测高吞吐、并发 API 服务用 vLLM自带 OpenAI 兼容接口方便后面接入其他工具。显存不够或想 CPU 跑用 llama.cpp 生态它能把模型分块放在内存和显存之间调度。下面给两个最小启动示例。注意这是示例参数具体要以你下载的模型和引擎版本为准。# vLLM 启动 OpenAI 兼容服务示例 python -m vllm.entrypoints.openai.api_server \ --model /data/models/deepseek-v4-flash \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9# llama.cpp 生态的基准测试工具示例 llama-bench -m /data/models/deepseek-v4-flash-fp16.gguf -p 128 -n 2563. 把测速流程拆成四步每一步都有判断标准测速最怕一上来就高并发、长文本、满参数。更稳妥的顺序是先跑通、再测准、最后压测。3.1 第一步单条请求先确认行为正常启动服务后先用一条短 prompt 调通接口。不要一上来就跑 100 并发也不要一上来就测 8K 上下文。先确认三件事模型能正常加载回答内容完整合理日志里没有报错。这一步最常见的问题是模型路径写错、目录里缺少权重文件、依赖版本不匹配。vLLM 和 Transformers 对依赖版本要求比较严格建议装在一个干净的虚拟环境里不要和别的项目混在一起。3.2 第二步用固定长度测解码速度测 tok/s 最怕变量太多。输入长度不同prefill 时间不同输出长度不同平均速度也会波动。建议固定一条短 prompt固定输出长度温度设低跑 3 到 5 次取中位数。用 curl 请求时响应里会返回usage.completion_tokens用它除以请求总耗时就是端到端 tok/s。curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: /data/models/deepseek-v4-flash, prompt: 用三句话解释什么是 KV Cache。, max_tokens: 256, temperature: 0 } -w \n请求耗时: %{time_total}s\n如果 vLLM 服务端日志里已经有吞吐统计优先参考服务端统计因为它剔除了大部分客户端网络开销。3.3 第三步加并发测真实吞吐单条速度高不代表吞吐高。真实业务往往是多用户并发或批量任务这时候真正要看的是每秒钟能处理多少请求、多少 token而不是单个请求多快。可以用并发工具发 10、20、50 路请求观察两个指标平均响应时间和整体吞吐。如果并发上去后单条速度暴跌说明已经到资源瓶颈如果整体吞吐还在涨说明还有余量。import requests import concurrent.futures import time url http://localhost:8000/v1/completions payload { model: /data/models/deepseek-v4-flash, prompt: 用三句话解释什么是 KV Cache。, max_tokens: 256, temperature: 0, } def call(_): t0 time.time() r requests.post(url, jsonpayload) data r.json() dt time.time() - t0 return dt, data.get(usage, {}).get(completion_tokens, 0) with concurrent.futures.ThreadPoolExecutor(max_workers10) as ex: results list(ex.map(call, range(10))) avg_latency sum(r[0] for r in results) / len(results) total_tokens sum(r[1] for r in results) print(平均耗时:, round(avg_latency, 3), s) print(总输出 token 数:, total_tokens) print(整体吞吐:, round(total_tokens / sum(r[0] for r in results), 2), tok/s)这个脚本只是示例直接跑可以用但要做成正式压测建议用专门的压测工具并把请求间隔、超时、失败重试都考虑进去。3.4 第四步判断数字可不可信我一般看三个点。第一多次测试波动大不大。如果前后差 30% 以上说明有别的进程抢资源或者显存不够导致换页这时先清理环境再测。第二日志里有没有 KV Cache 溢出、序列被截断、请求被降级。这些情况会拉低速度但表面上看模型还在正常返回。第三服务端吞吐和客户端算出来的数字是否接近。差太多就查网络延迟、JSON 序列化开销和流式接口的 chunk 大小。流式返回通常会比整段返回多一点开销但也能更快拿到首个 token。4. 影响 tok/s 的关键参数往往比想象中更容易忽略同样的模型、同样的显卡参数不同测出来的 tok/s 可能差几倍。下面几个参数是坑最多的位置。4.1 批量大小和并发单序列不代表整体能力batch size 越大显存占用越高但单位 token 的算力利用率也可能越高。vLLM 这类引擎支持 continuous batching会把多个请求拼在一起处理。如果你只测单条请求得到的是单序列速度如果并发请求多引擎会自动批处理整体吞吐会提升但每条请求的延迟可能变长。所以报告速度时一定要注明是单条还是并发否则非常容易误导人。4.2 上下文长度和 KV Cache长上下文是速度杀手KV Cache 会随序列长度线性增长序列越长显存越紧。显存不够时引擎可能被迫降低 batch或者把缓存换到内存速度立刻掉下来。实测时建议分开测短上下文 512 测一轮长上下文 4096 或 8192 测一轮。两个数字通常会差不少不要拿短上下文的数字去规划长上下文业务。比如你做代码仓库分析动辄几千行代码塞进去和闲聊场景的 tok/s 完全不在一个量级。4.3 硬件层面的四个隐藏变量硬件因素是最容易被忽略的。一是显存带宽。decode 速度上限由带宽决定显卡显存大小的参考价值反而没那么高。二是电源和散热。笔记本或小机箱在高负载时会降频速度波动很大连续测试时一定要留意温度。三是多卡通信。如果模型切分在多张卡上卡间通信会成为瓶颈单卡能跑多快不代表多卡就一定线性叠加。四是磁盘 I/O。冷启动加载模型时磁盘速度影响很大运行稳定后一般影响不大但如果在 Windows 上开了 Defender 实时扫描首次加载模型可能慢得离谱。下面这张表可以直接收藏配置时对着看参数或变量影响方向常见误区并发数 / batch size并发上去后整体吞吐可能提高单条延迟可能变高用单条速度推断并发能力max-model-len越长 KV Cache 越大显存越紧用短上下文数字规划长上下文业务dtypebf16/fp16/fp8/int8影响显存占用和速度全精度占用最大认为量化一定掉质量或量化一定更快温度等采样参数不影响理论吞吐但影响输出长度分布忽略输出长度差异直接比速度显存带宽决定 decode 阶段速度上限只看显存大小不看带宽电源/散热高负载降频会拉低峰值速度连续测试速度不稳时先查温度再查参数5. full precision 和量化别被一个标题带偏no quantization 听起来很理想但它不是一个必须坚持的教条。选择要不要量化取决于你的任务对质量敏感程度和硬件约束。5.1 全精度为什么值得关注全精度的核心优势是输出更接近原始权重。对多数通用对话、代码生成、推理任务BF16 和 INT8 的差异通常不明显但在数学计算、复杂代码、文本细节、多轮一致性这些场景里量化后偶尔会出现小差异。如果你在做模型评测、复现实验结果或者模型行为对精度敏感先用全精度跑一遍作为基线是最稳妥的。标题里的 278 tok/s 真正的价值就在这里它证明全精度也能达到可用速度不需要一上来就砍精度。5.2 量化的真实收益和代价量化的收益是确定的显存占用下降可以跑更大的上下文或者放进显存更小的机器部分硬件上因为内存带宽压力减少速度会更快。代价也很实际。首先是权重精度损失大多数任务感知不到但个别输入会暴露问题。其次是兼容性某些算子不支持 INT4某些引擎对量化格式支持不完整落地时反而更折腾。还有一个容易被忽略的点量化版本不一定总是更快如果 kernel 优化不到位可能和全精度速度差不多但显存确实省了。5.3 按任务类型选别一刀切我的建议是这样学习、评测、复现结果用全精度 BF16。生产 API 服务且显存充足优先全精度或 FP8前提是模型和引擎都支持。显存紧张、需要长上下文或 CPU 混合部署考虑 INT8 或 INT4但一定要先做一轮质量对比测试。低延迟场景不要只看单条速度先测并发吞吐如果量化后吞吐提升明显且质量可接受再换。还有一种折中方案同一套模型同时保留全精度和量化两个副本。日常请求走量化需要高质量输出的关键任务切到全精度服务。多占一点磁盘但灵活度最高。6. 实测中常见的报错和速度异常按顺序排查遇到问题不要急着改参数先按链路走一遍大多数问题出在环境和输入上而不是模型本身。6.1 启动阶段OOM、依赖冲突、路径错误OOM 是最常见的。CUDA out of memory出现在启动阶段通常是权重加上 KV Cache 超出了显存。处理顺序是先调小 max-model-len再降 gpu-memory-utilization再考虑换量化版本最后才考虑换卡。不要一开始就上多卡单卡跑不稳多卡只会更复杂。依赖问题也很常见。vLLM 和 Transformers 对 PyTorch、CUDA 版本有要求建议在干净的虚拟环境里安装安装前先确认显卡驱动和 CUDA 版本。还有一种情况是模型路径错误错误信息可能显示成某个文件找不到先确认模型目录里是不是有完整的权重文件和配置文件。6.2 运行阶段速度慢、显存暴涨、输出为空运行阶段的问题分成四类。第一种是速度远低于预期。先看有没有回退到 CPU有些引擎在检测到显存不足时会自动用 CPU 计算速度会掉到个位数 tok/s再看 dtype 是不是被默认成了 fp32然后用 nvidia-smi 确认显存利用率和是否有其他进程占用。第二种是显存持续暴涨。多半是上下文长度没有限制住或者并发数太高KV Cache 越积越多。把 max-model-len 和 maximum concurrency 都显式设一下。第三种是输出为空或乱码。先检查 tokenizer 版本和 prompt 格式再确认模型是否被截断加载最后看服务的日志里有没有解码错误。第四种是请求卡住不返回。先看服务端日志和超时配置再确认是不是长上下文导致 prefill 时间过长。输入越长首 token 等待越久这不算死机但要把客户端超时时间设合理。6.3 一套可复制的排查链路我自己的排查顺序固定成五步看现象是报错、卡住、无输出还是单纯速度慢。看输入prompt 长度、max_tokens、上下文长度是否符合预期。看环境用 nvidia-smi 看显存和利用率再查内存、磁盘和依赖版本。看参数并发、batch、dtype、max-model-len、gpu-memory-utilization。看引擎和格式模型格式和引擎是否匹配引擎版本是否支持当前模型结构。大部分问题在第二步和第三步就能定位。先看日志再改参数不要凭感觉反复试。7. 适合谁这样跑以及我更推荐的落地顺序278 tok/s 全精度无量化是一个理想参考但最终要不要照搬取决于你的场景。7.1 三类适合全精度本地跑的典型场景第一类是做模型评测和调优的人。为了复现实验、对比不同版本输出全精度是最干净的基线排除了量化带来的变量。第二类是对数据隐私有要求、需要私有化部署的团队。模型权重完全在自己机器上输入输出都不出内网这时候全精度能少一层质量不确定性。第三类是研究推理性能、做容量规划的工程师。比如你要评估一台服务器能支撑多少用户并发就需要用自己的模型、自己的卡、自己的典型输入长度做压测而不是直接套用网上的数字。7.2 从测试到生产最该先做好的三件事第一把输入输出格式和日志提前定义好。模型返回什么格式、错误怎么记录、请求超时多久这些在生产里比峰值 tok/s 更重要。第二把模型版本、dtype、上下文长度、并发参数固定下来写进启动脚本。不要手动改这几个参数否则每次启动的行为都不一样排错时非常痛苦。第三先单机单卡跑稳再考虑多卡、批量和接入外部工具。如果你是想接到 VS Code、Codex、Copilot 这类编码助手场景里用真正要关注的是 OpenAI 兼容接口能不能稳定对话、能不能正常流式返回、长代码文件会不会超上下文而不是 278 这个数字。我个人更建议把第一次接触这个模型的流程分成三个阶段先用 Transformers 验证行为再用 vLLM 测吞吐最后根据显存和任务决定要不要量化。标题里的 278 tok/s 是很好的参考但只有在你自己的机器、自己的输入长度、自己的并发模型下测出来的数字才是做容量规划的依据。先跑稳单条再谈并发先看质量再调参数。这样即使速度没有达到 278你也知道差距在哪里而不是被一个数字带着走。
DeepSeek V4 Flash 这个版本最值得关注的不是名字而是标题里这组数字278 tok/sfull precisionno quantization。翻译过来就是模型权重不做量化按完整精度跑推理每秒能生成 278 个 token。对在本地或私有环境里部署大模型的人来说这组数字传递两个信号一是速度已经比较接近工程可用的门槛二是至少在这个测试场景里不需要为了跑得快牺牲权重精度。下面按实际落地顺序拆一遍先说怎么理解这个数字再说复现它需要什么环境、怎么做测速最后把常见报错和参数边界整理出来。如果你手上正好有 DeepSeek V4 Flash 的权重或者只是想知道全精度推理到底能跑多快这篇思路可以直接复用。1. 278 tok/s 这个数字先分清它到底可不可信任何速度数字脱离测试条件都没有意义。278 tok/s 看起来很快但你要先弄明白它是在什么条件下测出来的否则很容易拿别人的数据规划自己的业务最后上线时发现完全对不上。1.1 先澄清一个命名混用Flash 是模型名不是存储和插件搜索这个主题时你会看到大量无关内容NAND Flash、NOR Flash、Flash 下载失败、DLL 被取消、Flash ID 查颗粒、基于 MQTT 和 Flash 的智能家居监控平台。这些和 DeepSeek V4 Flash 完全是两回事。这里的 Flash 是模型家族里的一个版本命名。从命名习惯看Flash 后缀通常表示比同系列完整版更轻、更侧重推理速度和资源控制的版本。搜索资料时建议直接组合模型关键词比如DeepSeek V4 Flash full precision、DeepSeek V4 Flash tok/s、DeepSeek V4 Flash 量化对比否则很容易被存储芯片、固件烧录的内容淹没。还有一点要注意如果你看到类似error: flash download failed - target dll has been cancelled这种报错先确认一下是不是在用嵌入式烧录工具。那是芯片烧录、固件下载场景里的错误和模型推理没有关系别拿它往大模型上套。1.2 tok/s 有两种口径测速之前必须分开一次完整推理分两个阶段prefill 和 decode。prefill 负责处理输入文本把 prompt 转成 KV Cachedecode 负责逐个生成输出 token。标题里的 278 tok/s 到底算哪个阶段差别非常大。很多推理工具默认报告的 tok/s 是 decode 阶段的速度也就是生成阶段的速度。prefill 阶段因为要并行处理整段输入衡量方式不一样速度单位虽然也写 tokens/s但含义完全不同。如果你通过 API 只统计总耗时然后用输出 token 数除以总时长这个数字会同时混入 prefill 时间和网络开销不能代表模型真实的生成速度。所以复现前先明确口径你要的是单条请求的端到端速度还是纯解码吞吐还是并发下的整体吞吐。这决定了后面所有测试怎么做。1.3 全精度通常指 FP16/BF16不是非要 FP32full precision 在推理语境里一般指权重不量化也就是用 FP16 或 BF16 加载模型而不是转成 INT8、INT4 或 FP8。FP32 在训练里常见推理时显存占用大、收益小多数推理引擎默认也不会用纯 FP32 跑。标题特意写 no quantization想表达的核心是这个速度是在没有牺牲权重精度的前提下得到的。这一点有价值因为低比特量化虽然能提速、省显存但偶尔会在输出质量和稳定性上带来波动。全精度跑出一个不错的 tok/s说明优化空间可以放在引擎和硬件上而不是先靠砍精度换速度。2. 复现测试前先对齐硬件、模型格式和推理引擎标题没有给出参数量、上下文长度和测试显卡所以 278 tok/s 只能当作参考点。想在自己机器上复现或对比先把三个前置条件理清楚显存够不够、模型是什么格式、用哪个推理引擎。2.1 显存怎么算权重字节数加 KV Cache第一步不用急着下载模型先做估算。公式很简单BF16/FP16每个参数占 2 字节FP32每个参数占 4 字节INT8每个参数占 1 字节INT4每个参数约 0.5 字节举个例子假设一个模型是 32B 参数BF16 权重大约是 64GB再加上 KV Cache 和激活值单卡 80GB 会比较从容48GB 比较紧张24GB 基本很难跑全精度长上下文。这是数学账和具体厂商无关可以自己算。除了显存内存带宽更关键。decode 阶段是典型的带宽瓶颈模型权重在显存里被一遍遍读取每读一遍才能生成一个 token。高带宽显卡跑大模型特别快消费级显卡带宽低同样模型速度可能差好几倍。如果 278 tok/s 是在数据中心级显卡上测出来的那它更多反映的是硬件带宽而不是单纯模型能力。2.2 模型格式决定你能用哪些引擎模型文件格式主要分两类。safetensors 是 Transformers 生态的标准格式适合 vLLM、SGLang、Transformers 这些引擎。全精度跑法通常优先选 safetensors BF16因为 vLLM 这类引擎对高吞吐场景优化更好也自带 OpenAI 兼容接口。GGUF 是 llama.cpp 生态的格式适合 CPU、CPUGPU 混合、低显存环境。如果显存不够也可以把全精度权重转成 FP16 或 BF16 的 GGUF这仍然算没有量化权重的方案只是格式不同。拿到模型先看目录结构确认是 safetensors 还是 GGUF再决定走哪条路。这一步搞错后面所有命令都会跟着错。2.3 三类引擎按场景选别一套配置打天下我的建议是按目标分三类只想快速验证模型能不能跑、行为正不正常用 Transformers 写最小脚本最快缺点是速度慢。要测高吞吐、并发 API 服务用 vLLM自带 OpenAI 兼容接口方便后面接入其他工具。显存不够或想 CPU 跑用 llama.cpp 生态它能把模型分块放在内存和显存之间调度。下面给两个最小启动示例。注意这是示例参数具体要以你下载的模型和引擎版本为准。# vLLM 启动 OpenAI 兼容服务示例 python -m vllm.entrypoints.openai.api_server \ --model /data/models/deepseek-v4-flash \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9# llama.cpp 生态的基准测试工具示例 llama-bench -m /data/models/deepseek-v4-flash-fp16.gguf -p 128 -n 2563. 把测速流程拆成四步每一步都有判断标准测速最怕一上来就高并发、长文本、满参数。更稳妥的顺序是先跑通、再测准、最后压测。3.1 第一步单条请求先确认行为正常启动服务后先用一条短 prompt 调通接口。不要一上来就跑 100 并发也不要一上来就测 8K 上下文。先确认三件事模型能正常加载回答内容完整合理日志里没有报错。这一步最常见的问题是模型路径写错、目录里缺少权重文件、依赖版本不匹配。vLLM 和 Transformers 对依赖版本要求比较严格建议装在一个干净的虚拟环境里不要和别的项目混在一起。3.2 第二步用固定长度测解码速度测 tok/s 最怕变量太多。输入长度不同prefill 时间不同输出长度不同平均速度也会波动。建议固定一条短 prompt固定输出长度温度设低跑 3 到 5 次取中位数。用 curl 请求时响应里会返回usage.completion_tokens用它除以请求总耗时就是端到端 tok/s。curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: /data/models/deepseek-v4-flash, prompt: 用三句话解释什么是 KV Cache。, max_tokens: 256, temperature: 0 } -w \n请求耗时: %{time_total}s\n如果 vLLM 服务端日志里已经有吞吐统计优先参考服务端统计因为它剔除了大部分客户端网络开销。3.3 第三步加并发测真实吞吐单条速度高不代表吞吐高。真实业务往往是多用户并发或批量任务这时候真正要看的是每秒钟能处理多少请求、多少 token而不是单个请求多快。可以用并发工具发 10、20、50 路请求观察两个指标平均响应时间和整体吞吐。如果并发上去后单条速度暴跌说明已经到资源瓶颈如果整体吞吐还在涨说明还有余量。import requests import concurrent.futures import time url http://localhost:8000/v1/completions payload { model: /data/models/deepseek-v4-flash, prompt: 用三句话解释什么是 KV Cache。, max_tokens: 256, temperature: 0, } def call(_): t0 time.time() r requests.post(url, jsonpayload) data r.json() dt time.time() - t0 return dt, data.get(usage, {}).get(completion_tokens, 0) with concurrent.futures.ThreadPoolExecutor(max_workers10) as ex: results list(ex.map(call, range(10))) avg_latency sum(r[0] for r in results) / len(results) total_tokens sum(r[1] for r in results) print(平均耗时:, round(avg_latency, 3), s) print(总输出 token 数:, total_tokens) print(整体吞吐:, round(total_tokens / sum(r[0] for r in results), 2), tok/s)这个脚本只是示例直接跑可以用但要做成正式压测建议用专门的压测工具并把请求间隔、超时、失败重试都考虑进去。3.4 第四步判断数字可不可信我一般看三个点。第一多次测试波动大不大。如果前后差 30% 以上说明有别的进程抢资源或者显存不够导致换页这时先清理环境再测。第二日志里有没有 KV Cache 溢出、序列被截断、请求被降级。这些情况会拉低速度但表面上看模型还在正常返回。第三服务端吞吐和客户端算出来的数字是否接近。差太多就查网络延迟、JSON 序列化开销和流式接口的 chunk 大小。流式返回通常会比整段返回多一点开销但也能更快拿到首个 token。4. 影响 tok/s 的关键参数往往比想象中更容易忽略同样的模型、同样的显卡参数不同测出来的 tok/s 可能差几倍。下面几个参数是坑最多的位置。4.1 批量大小和并发单序列不代表整体能力batch size 越大显存占用越高但单位 token 的算力利用率也可能越高。vLLM 这类引擎支持 continuous batching会把多个请求拼在一起处理。如果你只测单条请求得到的是单序列速度如果并发请求多引擎会自动批处理整体吞吐会提升但每条请求的延迟可能变长。所以报告速度时一定要注明是单条还是并发否则非常容易误导人。4.2 上下文长度和 KV Cache长上下文是速度杀手KV Cache 会随序列长度线性增长序列越长显存越紧。显存不够时引擎可能被迫降低 batch或者把缓存换到内存速度立刻掉下来。实测时建议分开测短上下文 512 测一轮长上下文 4096 或 8192 测一轮。两个数字通常会差不少不要拿短上下文的数字去规划长上下文业务。比如你做代码仓库分析动辄几千行代码塞进去和闲聊场景的 tok/s 完全不在一个量级。4.3 硬件层面的四个隐藏变量硬件因素是最容易被忽略的。一是显存带宽。decode 速度上限由带宽决定显卡显存大小的参考价值反而没那么高。二是电源和散热。笔记本或小机箱在高负载时会降频速度波动很大连续测试时一定要留意温度。三是多卡通信。如果模型切分在多张卡上卡间通信会成为瓶颈单卡能跑多快不代表多卡就一定线性叠加。四是磁盘 I/O。冷启动加载模型时磁盘速度影响很大运行稳定后一般影响不大但如果在 Windows 上开了 Defender 实时扫描首次加载模型可能慢得离谱。下面这张表可以直接收藏配置时对着看参数或变量影响方向常见误区并发数 / batch size并发上去后整体吞吐可能提高单条延迟可能变高用单条速度推断并发能力max-model-len越长 KV Cache 越大显存越紧用短上下文数字规划长上下文业务dtypebf16/fp16/fp8/int8影响显存占用和速度全精度占用最大认为量化一定掉质量或量化一定更快温度等采样参数不影响理论吞吐但影响输出长度分布忽略输出长度差异直接比速度显存带宽决定 decode 阶段速度上限只看显存大小不看带宽电源/散热高负载降频会拉低峰值速度连续测试速度不稳时先查温度再查参数5. full precision 和量化别被一个标题带偏no quantization 听起来很理想但它不是一个必须坚持的教条。选择要不要量化取决于你的任务对质量敏感程度和硬件约束。5.1 全精度为什么值得关注全精度的核心优势是输出更接近原始权重。对多数通用对话、代码生成、推理任务BF16 和 INT8 的差异通常不明显但在数学计算、复杂代码、文本细节、多轮一致性这些场景里量化后偶尔会出现小差异。如果你在做模型评测、复现实验结果或者模型行为对精度敏感先用全精度跑一遍作为基线是最稳妥的。标题里的 278 tok/s 真正的价值就在这里它证明全精度也能达到可用速度不需要一上来就砍精度。5.2 量化的真实收益和代价量化的收益是确定的显存占用下降可以跑更大的上下文或者放进显存更小的机器部分硬件上因为内存带宽压力减少速度会更快。代价也很实际。首先是权重精度损失大多数任务感知不到但个别输入会暴露问题。其次是兼容性某些算子不支持 INT4某些引擎对量化格式支持不完整落地时反而更折腾。还有一个容易被忽略的点量化版本不一定总是更快如果 kernel 优化不到位可能和全精度速度差不多但显存确实省了。5.3 按任务类型选别一刀切我的建议是这样学习、评测、复现结果用全精度 BF16。生产 API 服务且显存充足优先全精度或 FP8前提是模型和引擎都支持。显存紧张、需要长上下文或 CPU 混合部署考虑 INT8 或 INT4但一定要先做一轮质量对比测试。低延迟场景不要只看单条速度先测并发吞吐如果量化后吞吐提升明显且质量可接受再换。还有一种折中方案同一套模型同时保留全精度和量化两个副本。日常请求走量化需要高质量输出的关键任务切到全精度服务。多占一点磁盘但灵活度最高。6. 实测中常见的报错和速度异常按顺序排查遇到问题不要急着改参数先按链路走一遍大多数问题出在环境和输入上而不是模型本身。6.1 启动阶段OOM、依赖冲突、路径错误OOM 是最常见的。CUDA out of memory出现在启动阶段通常是权重加上 KV Cache 超出了显存。处理顺序是先调小 max-model-len再降 gpu-memory-utilization再考虑换量化版本最后才考虑换卡。不要一开始就上多卡单卡跑不稳多卡只会更复杂。依赖问题也很常见。vLLM 和 Transformers 对 PyTorch、CUDA 版本有要求建议在干净的虚拟环境里安装安装前先确认显卡驱动和 CUDA 版本。还有一种情况是模型路径错误错误信息可能显示成某个文件找不到先确认模型目录里是不是有完整的权重文件和配置文件。6.2 运行阶段速度慢、显存暴涨、输出为空运行阶段的问题分成四类。第一种是速度远低于预期。先看有没有回退到 CPU有些引擎在检测到显存不足时会自动用 CPU 计算速度会掉到个位数 tok/s再看 dtype 是不是被默认成了 fp32然后用 nvidia-smi 确认显存利用率和是否有其他进程占用。第二种是显存持续暴涨。多半是上下文长度没有限制住或者并发数太高KV Cache 越积越多。把 max-model-len 和 maximum concurrency 都显式设一下。第三种是输出为空或乱码。先检查 tokenizer 版本和 prompt 格式再确认模型是否被截断加载最后看服务的日志里有没有解码错误。第四种是请求卡住不返回。先看服务端日志和超时配置再确认是不是长上下文导致 prefill 时间过长。输入越长首 token 等待越久这不算死机但要把客户端超时时间设合理。6.3 一套可复制的排查链路我自己的排查顺序固定成五步看现象是报错、卡住、无输出还是单纯速度慢。看输入prompt 长度、max_tokens、上下文长度是否符合预期。看环境用 nvidia-smi 看显存和利用率再查内存、磁盘和依赖版本。看参数并发、batch、dtype、max-model-len、gpu-memory-utilization。看引擎和格式模型格式和引擎是否匹配引擎版本是否支持当前模型结构。大部分问题在第二步和第三步就能定位。先看日志再改参数不要凭感觉反复试。7. 适合谁这样跑以及我更推荐的落地顺序278 tok/s 全精度无量化是一个理想参考但最终要不要照搬取决于你的场景。7.1 三类适合全精度本地跑的典型场景第一类是做模型评测和调优的人。为了复现实验、对比不同版本输出全精度是最干净的基线排除了量化带来的变量。第二类是对数据隐私有要求、需要私有化部署的团队。模型权重完全在自己机器上输入输出都不出内网这时候全精度能少一层质量不确定性。第三类是研究推理性能、做容量规划的工程师。比如你要评估一台服务器能支撑多少用户并发就需要用自己的模型、自己的卡、自己的典型输入长度做压测而不是直接套用网上的数字。7.2 从测试到生产最该先做好的三件事第一把输入输出格式和日志提前定义好。模型返回什么格式、错误怎么记录、请求超时多久这些在生产里比峰值 tok/s 更重要。第二把模型版本、dtype、上下文长度、并发参数固定下来写进启动脚本。不要手动改这几个参数否则每次启动的行为都不一样排错时非常痛苦。第三先单机单卡跑稳再考虑多卡、批量和接入外部工具。如果你是想接到 VS Code、Codex、Copilot 这类编码助手场景里用真正要关注的是 OpenAI 兼容接口能不能稳定对话、能不能正常流式返回、长代码文件会不会超上下文而不是 278 这个数字。我个人更建议把第一次接触这个模型的流程分成三个阶段先用 Transformers 验证行为再用 vLLM 测吞吐最后根据显存和任务决定要不要量化。标题里的 278 tok/s 是很好的参考但只有在你自己的机器、自己的输入长度、自己的并发模型下测出来的数字才是做容量规划的依据。先跑稳单条再谈并发先看质量再调参数。这样即使速度没有达到 278你也知道差距在哪里而不是被一个数字带着走。
