前言
从部署大模型时，你真正需要关心的指标可以总结为一句话：头字够不够快（TTFT），字出来不够连贯（TPOT/ITL），并发多了吞吐掉不掉（系统吞吐），显存能不能装下且留有余量（VRAM + KV缓存），每一百万代币的实际成本是多少（每M代币成本）。
这里适合哪些人读：
- 搞懂不同参数量对显存与带宽的真实要求，避免买错配置
- 针对RAG、长文档、Agent等业务场景打造装备模型与量化版
- 查高并发吞吐极限、出字卡顿与长排下游严重掉速
- 定位TTFT高峰、P99回转、显存超配与假死OOM
- 核算每百万Token真实TCO，评估自建与商业API的划算临界点
阅读指南：
- 如果您正确准备选购硬件或增加成本：第四节（显存计算）、第六节（成本核算）与第八节（硬件选型对照）
- 如果您正在调节优性能或排查吞吐极限：第二/三节（延迟与吞吐）、第七节（进阶优化）与第九节（真机实测避坑）
- 如果您正在为特定业务（RAG / Agent / 对话）做技术选型，搭建测试工具链与体系监控：第十节（常用实测与监控工具）
- 如果您的模型服务即将上线生产：第五节（服务质量与亮点）
一、先看实际案例
我们以7月底新出的
Ling-3.0-Flash
例如，这是一个MoE 架构模型 。和Qwen 3.8 27b 类似稠密模型不同的是，MoE 模型的一个典型特点是，模型参数和激活参数不一致，总参数 124B，每个令牌激活约 5.1B，定位为高层、面向生产级 Agent 的快速执行层，价格相当于 Qwen 3.8 27b 的一个零头。
实际部署中，同一个模型换个负载或上下文长度，吐吞与延迟可能延长数倍。本节以一台真实服务器的完整测量为例，把各项指标落地为具体数字。
测试环境与被测对象
- 硬件平台 ：NVIDIA DGX Spark（GB10 Grace-Blackwell）， 121 GB统一内存（CPU/GPU占用内存空间，无额外系统内存缓冲）
- 被测模型：Ling-3.0-flash-INT4（124B MoE / 5.1B激活，KDA+MLA混合注意力）
- 推理引擎 ：vLLM（开启 CUDA Graphs 与 MTP 投机解码）， --max-model-len 16384
- 统计口径 ：统一按API返回的 usage.completion_tokens计数
| 核心指标 | 实测表现 | 说明与排坑 |
|---|---|---|
| 单请求 TTFT | 215 ms | 短 Prompt 真实计算与传输延迟 |
| 高并发 TTFT | 20.7 s （20 请求并发） | 绝大部分时间在队列中等待调度，非模型计算慢 |
| 单流 Decode 速度 | 39.4 tok/s | 稳定出字速度 |
| 高并发聚合吞吐 | 242.1 tok/s | 16 并发饱和运行时的系统产出 |
| 显存与冷启动 | 权重常驻 71.7 GiB，总占用 103/121 GB | 冷启动约 8 分钟（引擎初始化 49.8 s） |
初次看到TTFT、单流解码速度、高并发聚合吞吐、显存与冷启动这些术语，想必大家都会和我一样云里雾里。好消息是，看完这篇文章，你将能够建立起一个端侧模型部署的全面认识。
二、延迟类指标（用户获取最直接）
1.预填充时间（预填充时间）
大模型推理分为两个阶段：
- Prefill（预填充） ：一次性处理你输入的整段提示词（提示），做注意力计算的前向扫描跑。这一阶段是 计算密集的------GPU的算力满
- Decode（解码） ：逐个字/token生成回复。这一阶段是 访存密集的------GPU在等显存里的数据搬过来，算力通常只用到一部分部分
预填充时间就是模型读取完整段提示到开始波形第一个字在系统内部所花的时间。它直接影响TTFT的大小，所以常被一起翻转，但两者定义不同（见下）。
2. TTFT（Time to First Token，首字延迟）
定义 ：从请求发送到服务端，到收到 第一个输出令牌的时间。
这是交互式对话场景中最关键的延迟指标，直接问回答完问题后要多久才能看到第一个字出来。一个70B模型在单卡H100上，短提示的TTFT一般在几十秒到两秒；长提示（几万字）会显着上升。
注意 TTFT = 预填充时间 + 排队等待时间。如果系统很忙、你的请求要排队，TTFT 里很大一部分其实是排队，而不是模型计算慢。
3. TPOT / ITL（逐令牌间隔，即延迟延迟）
连续两个词之后，字是一个接一个蹦出来的，这个蹦字速度有两个常用统计口径：
| 术语 | 英文 | 含义 |
|---|---|---|
| ITL | Inter-Token Latency | 每个 token 之间的时间间隔（逐 token 取样后统计，可分 P50/P95/P99） |
| TPOT | Time Per Output Token | 整段回复中，从第一个 token 到最后一个 token 的总时长 ÷ 输出 token 数（平均值） |
后面的文档和基准测试（如MLPerf Inference、vLLM/SGLang社区）主要用TTFT + TPOT 。它们是重复出字速度，不描述头字，也不介意输入多长。在单卡H100上跑INT4量化70B模型的常见区间是50～120个令牌/秒（即每个令牌约8～20毫秒），具体随一个长度而变。
重要规律：加速阶段受显存带宽限制，出字速度会随着上下文变长而下降（因为KV缓存越来越大，每次都要搬更多的数据）。这是部署必须知道的长带宽自现象。
这个下降比大多数人预期的要早、还要陡。第九节有一条实测曲线：同一台机器同一个模型，提示从300代币涨到15K，解码从39.0掉到18.2 tok/s------在16K窗口内部就已经腰斩，到49K 7.1，慢5.6倍。
4.延迟与分延迟（P95 / P99）
- 延迟延迟（End-to-End Latency） ：从发送请求到收到全部回复的时间，相当于 TTFT + 生成总时长，对文件汇总、代码生成此类任务更重要
- P95 / P99 延迟 ：不是只看随手！偶会忽视尾部异常。P95=慢的那5%请求的最差延迟，P99=慢的1%。生产环境看性能， 一定不是P95/P99均值。如果P99远着而P50，说明系统偶发连（GC、队列监听、OOM重试），这比随更值得重视
三、吞吐类指标（系统能承载多少活）
- 每秒令牌数（TPS，每秒令牌数）
最常见也是最容易被忽视的指标。必须分清三个不同的口径：
| 口径 | 说明 |
|---|---|
| 整体 TPS | 系统每秒钟生成的总 token 数（输入+输出合并或只看输出，要看报告怎么定义） |
| Prefill throughput | 预填充阶段的吞吐，对读长文档类任务重要 |
| Decode throughput | 解码阶段的吞吐，对对话类任务重要；常与单卡最大 TPS 挂钩 |
单卡 H100 上，70B INT4 模型的解码吞吐上限大概在100+ tokens/s ；7B 小模型在消费级 4090 上可以达到200 tokens/s 以上（因为小模型计算中部高，更算吃力带宽）。
2.每秒请求数（QPS，每秒请求数）
QPS 和 TPS 的依赖关系并发度：10路对话 × 每路 50 tok/s = 系统 500 tok/s。
3.连续批处理（Continuous Batching / Chunked Prefill）的效果
早期推理框架用静态批处理：必须等请求全部生成完成才下一个，GPU在等人想问题时空转，吞吐掉得厉害。现代框架（vLLM的连续批处理、SGLang、TGI）在token间隙就插入新请求，让GPU不空转。
评估本次优化是否有效的关键指标是：等显存下，并发数提升时系统吞吐是否能线性增长。没有连续批处理的系统，并发一高TPS就断崖下降；有的话可以顶住几十上百并发。
但断崖有多种，画的曲线一模一样：一种是连续批处理没生效，另一种只是**--max-num-seqs** 之类的并发槽位上限卡住了队列。第九节2把同一台机器的拐角并消耗在一起------同一个8个三角，一条104.9 tok/s且TTFT涨24倍，另一条167.9 tok/s，差别只在一个参数上看到。断崖先去查槽位，再去怀疑框架。
4. 系统吞吐 vs 单机吞吐
多卡部署时除线性扩展效率 ：N 张卡 ≈ N 倍吞吐？实际常因通信开销打 7～9 折。最小标准是效率比 = 实测多卡吞吐 ÷ （单吞卡吐 × 卡数）。低于 0.7 说明人力策略或互联（NVLink/PCIe）达到了瓶颈。
四、资源类指标（你的机器吃得消吗）
- VRAM显着占用（能够安装下是第一道设施）
总显存=权重参数占的显存+KV缓存占的显存+运行时碎片开销。
- 权重占用的粗略算法：参数量（十亿）×精度字节数。BF16/FP16每个参数2字节，INT4约0.7字节（含少量元数据按0.75计算）
- 常见区间参考：
| 模型 | FP16/BF16 | FP8 | INT4 AWQ/GPTQ |
|---|---|---|---|
| 7B | ~ 14 GB | ~ 7--8 GB | ~ 5--6 GB |
| 30B | ~ 60 GB | ~ 32 GB | ~ 18--20 GB |
| 70B | ~ 140 GB（+碎片≈150+ GB） | ~ 72 GB（+碎片≈90 GB） | ~ 40--45 GB |
| 7B ( 128K 上下文 KV cache 单独算） | --- | --- | 见下方 KV cache 速查 |
经验法则 ：算完理论值后乘以1.2的安全系数要求KV缓存和碎片空间。70B INT4单卡装得下，但方差稍高可能会导致KV缓存不足OOM，这就是为什么能安装，但运行过程中会挂的原因。
2. KV Cache计算公式（上下越长越吃显存）
KV缓存是把注意力计算结果存储起来，避免重复计算------上下窗口增大、占比例，占的显着存越多。通用公式：
plaintext
plaintext
KV cache 字节数 ≈ 2 × L(层数) × K_v_head_数量 × Head_Dim × 序列长度(S) × 批次(B) × 精度字节数其中2 代表Key和Value两份服务器。以Llama-3-70B为例（80层、GQA、8个KV头、head_dim=128、BF16即2字节）：
- 每个代币约 2 × 80 × 8 × 128 × 2 = 327,680 B ≈ 0.31 MB/代币
- 4096长度→约 1.3GB ；128K长度→约 40GB
这意味着：长上下文（≥32K）+多并发时，KV缓存本身可能超过权重，成为显存的第一个瓶颈。这也是为什么部署将长上下文的KV缓存做量化（KV量化）或卸载到CPU上。
反方向的错误同样常见，而且更结构：按最大上下文 × 最大并发把 KV 池开满，实际只用了百分之几 。第九节 3 是一个超配 24 倍的实测（池子 1,098,590 个 token，实际在用约 46,000，GPU KV 缓存使用 4.2%）；把这个参数调下来之后，腾出的内存换了更高的聚合吞吐。<strong> --gpu-memory-utilization 在配方里通常是为了安装得下而配置的，而不是为了得跑又好又稳定而配置，抄写配方的这个时候点意义。
3. GPU利用率与显存带宽利用率
- GPU利用率（%） ：计算单元（SM）被占用的比例。延迟阶段即使利用率只有30%也可能是正常的（因为卡在显存带宽上）------ 不能单靠利用率高低下结论
- 显存带宽利用率 ：LLM 解码通常是访存密集，这才是出字数度的真实瓶颈。对比硬件时稀疏 带宽（GB/s）：H100 SXM 约 3 TB/s、H200 约 4.8 TB/s、A100 约 2 TB/s、RTX 4090 约 1 TB/s。带宽差几倍，模型的出字速度同样差几倍
- 准确性与确定损失
- FP16/BF16：无损、质量，最佳但显存翻倍，解码偏访存瓶颈
- INT8：显存减半，大多数场景质量几乎保持不变
- INT4（AWQ/GPTQ）：显着存在值为1/4，对话类任务通常肉眼难以辨别差异，但在复杂推理/长链思考任务上可能有1～5个质量提升
失真指标：用权威题库（MMLU、GSM8K、HumanEval、MAUSt等）要跑量化对比分数，量化越激进分数掉得越多。选INT4前一定要实测自己业务相关题型的跌落。
五、服务质量与可靠性指标（生产环境才真正重要）
- P95/P99延迟与队列等待时间（Queue Wait Time）
即使单纯计算延迟很快，也排除队列时间------请求进不去正在跑的任务，要在队列里等多久。这是多用户共卡时的核心矛盾：单路快，人多都慢。
监控面板建议：TTFT-P50/P95、TPOT-P50/P95、排队时间-P50/P95，分别看。 - 错误率与 OOM 频率
- OOM（Out of Memory）重试会偶发请求延迟爆炸，是 P99 萌的常见原因
- 指标： 错误率（含超时、OOM、格式解析失败）、重试次数、解析错误率
- <strong> /health </strong> 返回 200 不代表引擎在出字。 大部分推理框架的健康检查探查是API服务器，而真正干活它背后的引擎进程------是两者分开可以死。三个探针要探 一次真实生成（发一个1 token的请求看有没有回来），不能只探端口或探进程
- 但活条件不能用请求超时。 一个会排队的系统里，满负载时请求本来就该等------用超时判活，等于让流量去判高峰重启你的服务。判活看的应该是引擎还在继续（比如引擎日志里的 平均生成吞吐量是否连续多个采样周期为0），不是单个请求快不快
3.可用性（Availability / Uptime）
- 服务正常对外可用时间的比例（99.9% ≈ 每月小于44分钟不可用）
- 配合健康检查（健康检查）和缓慢重启，避免因一次OOM把整个进程搞死
4.超时配置与流式（Streaming）体验
推荐开启流式输出：字了就边写边返回给用户，用户不用等整段生成完成，加载延迟接近TTFT。同时要设置合理的请求超时，防止单个超长请求卡死连接。
六、成本类指标（钱花得值不值）
- 每个代币的成本（每个代币的成本）
最观察的对比口径：
| 方式 | 参考成本（输出 token） |
|---|---|
| 云服务 API | 中小模型约 0.10～1/百万，旗舰模型 15～75/百万 |
| 自建 H100 实例 | 约 0.10～0.5/百万 （取决于硬件折旧+电费+利用率） |
注意API价格输入输出不一样，对比时要统一口径。自配置通常在当月调用量达到目前亿代币级别时才回本，取决于您的硬件购买成本和电费。
2. 每美元代币数（每美元份额代币数）&每千瓦时代币数
- 对于横向对比不同硬件的效率，尤其是买哪一块卡、还是直接租云
- 自建时还要把 电力消耗算进去（一张H100 SXM功耗700W，4090约450W），代币/kWh高的方案长期更省钱
- 硬件折旧与TCO（总拥有成本）
自部署的成本=硬件采购分摊（3～4年折旧）+电费+机房/网络+运维人力。短期高频调用且团队已有闲置GPU时自建划算；低频或活跃大的场景，租云更灵活。
七、进阶优化技术的独有指标
这些是你调优时的手感表，打开优化就要关注这些数据：
1.推测解码（投机采样/草稿验证）
使用小草稿模型先猜测一串token，再由大模型进行一次验证。
关键指标：
- 加速比（Speedup）：实测吞吐 ÷ 基线吞吐，常见1.5～3倍（解码阈值、中低梯度时最明显）
- 接受率（Accept Rate）：草稿模型被大模型接受的代币参与，加速决定效果；草稿模型越接近目标模型，接受率越高
- 代价：需要额外部署一个小模型（多份权重显存），且对 高并发、预填充主导的场景帮助有限
- 测量陷阱（这条比前面的负载更容易踩） ：打开投机采样后，按SSE块数计算tok/s会 系统性低估 ------被接受的草稿令牌和验证它的令牌挤在同一个块里。第5里这个错误把实际的41 tok/s报成20.5，而20.5几乎相当于关掉投机采样的参考值，看起来完全可信。正确做法： stream_options: {"include_usage": true} ，读 usage.completion_tokens
- Prefix Caching（外部缓存 / Prompt Caching）
把提示中公共的前几个令牌已算好KV缓存存储起来复用（比如同一个系统提示词、同一个长文档）。
关键指标：
- 命中率（Hit Rate） ：命中时该部分 Prefill 被跳过。真实业务（Agent 场景、RAG 固定文档）接近 50%～70%
- 延迟降低幅度 ：命中时该请求的Prefill可降到1/x，整体TTFT可下降 40%～90%；但全不命中时反而略增头部
- 注意缓存有生命周期管理，命中率太低说明你的场景重复度低，这个优化不划算
3.量化质量退化（Quantization Quality Degradation）
如前所述，用 MMLU/GSM8K/HumanEval 等分数 INT8/INT4 带来的质量损失，确保在极范围内。
4. 多卡扩展效率（Parallelism Scaling Efficiency）
- 单卡放不下时使用 DP（数据绒件复制）/TP（张量绒件切分权重）/PP（初始化绒件）
- 指标：三个 线性扩展效率比；多卡时要看通信重点（NVLink 机箱负载 PCIe），70B 以上模型基本需要多卡
- 长上下文专项指标
长上下部署额外关注：KV缓存参与（占总显存的%） 、长文解码降速比例（2K vs 32K时TPS掉多少）、以及是否启用了KV缓存量化/卸载、FlashAttention、PagedAttention等显存优化技术。
八、真实硬件参考值与选型对照
| 显卡 | 显存 | 带宽 | 适用部署层级 |
|---|---|---|---|
| RTX 3090/4090 | 24 GB | ~ 1 TB/s | 7B 模型 INT4/FP8，个人/小团队 |
| RTX 6000 Ada / A6000 | 48 GB | ~ 900 GB/s | 30B 模型 INT4，小批量 |
| A100 80 GB | 80 GB | ~ 2 TB/s | 70B INT4 单卡，中小企业 |
| H100 SXM 80G | 80 GB | 3 TB/s + 900 GB/s NVLink | 70B FP8/BF16 或 INT4 高并发，生产主力 |
| H200 | 141 GB | 4.8 TB/s | 70B BF16 单卡 / 大上下文 / 高并发 |
| H20（出口特供） | 96 GB | 低算力、带宽一般 | 70B INT4 单卡，预算受限场景 |
自部署的启动经验：
- 7B以内：一张24G消费卡即可，优先看TPOT和QPS
- 70B级别：需要H100/A100 80G或双卡A800/H20；INT4能省显存但做质量验证
- 长文档/企业RAG：重点关注KV缓存全局、前缀缓存命中率、长上下文降速
- 多用户在线服务：重点关注连续批处理、P95/P99、队列时间和OOM
九、实测样本：Ling-3.0-Flash真机测量
前面的章节给出了配置各项指标的定义与参考区间。但实际中，同一个模型换负载或带宽长度，吞吐与延迟可能的扩展倍数。本节以第一节中一台真实服务器的完整测量为例，把各项指标落地为具体数字。
测试环境与被测对象
- 硬件平台 ：NVIDIA DGX Spark（GB10 Grace-Blackwell）， 121 GB统一内存（CPU/GPU占用内存空间，无额外系统内存缓冲）
- 被测模型：Ling-3.0-flash-INT4（124B MoE / 5.1B激活，KDA+MLA混合注意力）
- 推理引擎 ：vLLM（开启 CUDA Graphs 与 MTP 投机解码）， --max-model-len 16384
- 统计口径 ：统一按API返回的 usage.completion_tokens计数
- 延迟与吞吐：区分计算时间与延迟时间
| 核心指标 | 实测表现 | 说明与排坑 |
|---|---|---|
| 单请求 TTFT | 215 ms | 短 Prompt 真实计算与传输延迟 |
| 高并发 TTFT | 20.7 s （20 请求并发） | 绝大部分时间在队列中等待调度，非模型计算慢 |
| 单流 Decode 速度 | 39.4 tok/s | 稳定出字速度 |
| 高并发聚合吞吐 | 242.1 tok/s | 16 并发饱和运行时的系统产出 |
| 显存与冷启动 | 权重常驻 71.7 GiB，总占用 103/121 GB | 冷启动约 8 分钟（引擎初始化 49.8 s） |
核心结论：监控报警TTFT高峰时，先看系统队列和队列队列，不要盲目归于模型计算力不足。
2. 丰富扩展：识别假性吞吐断崖
| 并发数 | 限制槽位 'seqs4' 聚合吞吐 | 放开槽位 'seqs16' 聚合吞吐 |
|---|---|---|
| 1 | 37.1 tok/s | 36.3 tok/s |
| 4 | 106.6 tok/s | 92.3 tok/s |
| 8 | 104.9 tok/s （TTFT 暴增至 5.2s） | 167.9 tok/s |
| 16 | --- | 242.1 tok/s |
- 假性断崖 ：在 seqs 4配置下，8个并发时吞吐不再增长且延迟暴增，开始是连续批处理失效，实分组服务端参数限制了并发位
- 扩展成本 ：从 1 倍扩散至 16 倍速度，总吞吐提升 6.7倍（36.3 → 242.1 tok/s），但单请求出字从 36.3 15.1 tok/s。单机部署需在单流体验与系统吞吐间权衡
- KV Cache显存陷阱：过犹不及的超配
按照常规经验将**--gpu-memory-utilization** 设为0.80 时，分配了21 GiB的KV Cache池（约110万Token）。但在实际运行4路复杂请求时，仅使用了约4.6万Token（利用率仅4.2%，显存超配24倍）。
| 配置参数 | 单流速度 | 16 路聚合吞吐 | 剩余可用显存 | KV 池大小 |
|---|---|---|---|---|
| utilization 0.80 / seqs 16 | 28.7 tok/s | 226.8 tok/s | 18 GB | 20.8 GiB |
| utilization 0.70 / seqs 16 | 36.3 tok/s | 242.1 tok/s | 30 GB | 9.67 GiB |
核心结论 ：盲目把KV池开满会挤占系统运行速度缓冲。若监控中 GPU KV缓存使用率长期处于一个活跃状态，主动调节低利用率参数，可释放多达12GB显存，且吞吐与单流反而更优。
4. 长上下文降速曲线：Prefill 与 Decode 走势完全相反
在大海捞针（Needle In A Haystack）长文本实测中（生成128代币）：
| Prompt 长度 | Prefill 速度 | TTFT | Decode 速度 |
|---|---|---|---|
| 269 token | 838 tok/s | 0.32 s | 39.0 tok/s |
| 2,971 token | 2,441 tok/s | 1.22 s | 32.4 tok/s |
| 10,815 token | 2,693 tok/s | 4.02 s | 20.5 tok/s （接近腰斩） |
| 14,738 token | 2,671 tok/s | 5.52 s | 18.2 tok/s |
| 49,000 token | 2,429 tok/s | --- | 7.1 tok/s （慢 5.6 倍） |
- Prefill 保持恒定：从 3K 到 49K Token，Prefill 速度稳定在 2,400+ tok/s（混合线性注意力架构优势明显）
- 解码持续衰减 ：随着上下文速度拉长，每一步抓取KV Cache的访存头部剧增， 在11K附近即已腰斩
- 避坑要点：比赛长文本性能时，必须将测点放在上下文窗口中段（如8K~16K），切忌只测首尾端点，也不意味着Prefill不掉速误当成Decode不掉速
5.投机采样：识别客户端统计陷阱
- 加速上限设定于接受长度 ：实测MTP接受率为 65.4% ，平均单次验证吐出 1.65个Token，加速收益上限约为1.6倍
- 统计陷阱 ：开启投机采样后，多个被接受的Token会合并在同一个SSE Chunk中返回。若在客户端简单按Chunk数量计算速度，会测出 20.5 tok/s 的假数据（误以为投机采样失效）；正确的做法是读取响应中的 usage.completion_tokens ，实际速度为 41 tok/s
6.质量分数：解读盲区的指标
- 链截断思维陷阱 ：在IFEval气压中，开启思考模式后得分从0.789骤降至0.207。排查发现是由于 max_tokens 设置为2048，导致链思维未完成即被强制不足截断。 上限输出配置在质量测试中梯度分数低，不是直接报错
- 工具调用（Function Calling）看分层表现 ：BFCL-v3综合得分0.744，但拆解后：单轮调用为 0.887 （足以支撑生产），而多轮自主循环 RB0.438。在构建Agent系统时，应由外层流编排驱动，而不工作完全依赖模型的长自主链规划
十、常用实测与监控工具
| 应用场景 | 最优先指标 | 次要关注 | 可适当妥协 |
|---|---|---|---|
| 聊天机器人 / 智能客服 | TTFT 、TPOT（单流出字速度） | 系统并发 QPS、P95 延迟 | Prefill 极限吞吐 |
| 长文档分析 / 知识库问答 | Prefill 吞吐 、端到端处理耗时 | 系统总吞吐 | 首字 TTFT 绝对值 |
| Agent / 自动化工具 | 工具调用分层准确率 、TTFT、P95 | 格式遵循稳定性 | 极端并发吞吐 |
| 离线数据批量处理 | 系统总吞吐（tok/s） 、单 Token 成本 | 任务整体完成时间 | 交互响应延迟 |
| 超长上下文 RAG | KV Cache 容量 、Prefix Cache 命中率 | 长上下文 Decode 衰减率 | 首字延迟 |
工具推荐：
本文的与参考值部分整理自开源推理社区（vLLM/SGLang/TGI）指标定义、MLPerf Inference 基准体系，以及当前主流硬件规格。第九节及自检定义清单中标记"样本"的全部数字，来自 2026-08-17 至 08-18 在 DGX Spark 上对 Ling-3.0-flash-INT4具体数值会随模型版本、量化方案、框架参数和环境变化，实测相同。
- 推理引擎内置工具
- vllm benchserve/ SGLang压测套件：快速测试TTFT、TPOT、系统吞吐与投机采样接受率
- 专业性能压力测量工具
- NVIDIA GenAI-Perf：标准化模型压测工具，输出符合MLPerf规范的TTFT/TPOT分补与每百万代币成本统计
- 质量与精度得分框架
- EvalScope / lm-evaluation-harness：用于量化稳定性、参数调优稳定性的基准回归（底座 IFEval、HumanEval、GSM8K 等）
- 硬件与运行时间监控
- Prometheus + Grafana ：触发推理框架的暴露 /指标端点，持续监控P95/P99延迟、排队时间与显存使用率
- nvidia-smi / gpustat ：实时观察GPU算力利用率、显存分配与功耗
相关链接： - 实测模型：
https://huggingface.co/inclusionAI/Ling-3.0-flash - DGX Spark参考配方：
https://github.com/sudoingX/dgx-spark-ling - lm-evaluation-harness：
https://github.com/eleutherai/lm-evaluation-harness - vllm：
https://github.com/vllm-project/vllm