在追求吞吐量之前先定义有用的结果
在交互场景中，测量首个 token 的等待时间和完整响应的等待时间。对于离线语料库，测量获得全部预期输出所需的时间。两种情况下都要设定验收规则：已知答案的准确率、排序质量或字段抽取是否经过验证。一个语法上有效的 JSON 仍可能包含错误的答案。
在工具允许的情况下，把排队等待、处理和你的客户端观察到的完整往返分开。引擎内部的测量与应用程序的测量边界不同。vLLM 的指标文档特别区分了等待、首个 token 和总时长：无论选用哪种引擎，在你的记录中都保留这一区分。
技术来源： vLLM — 请求与延迟指标
把你的请求转化为选型标准
准备带有稳定标识符的短输入、常规输入和长输入。保留模型、tokenizer、对话模板和生成参数。统计实际传输的 token 数，包括历史和应用程序追加的文档。分别记录请求的 batch、发送的并发数和实际同时处理的请求数：这些数字不一定相同。
| 需固定的输入 | 测量与单位 | 对选型的影响 |
|---|---|---|
| 完整 prompt 和输出上限 | 每个请求的输入和输出 token 数 | 检查长案例和达到上限被截断的响应 |
| 并发请求数与到达速率 | 活跃、排队中和已完成的请求数 | 确定在要求时延下的可持续负载 |
| 精度、量化和缓存 | 每张 GPU 的内存峰值，以字节或 Gio 计 | 排除在预期负载下超出内存的设置 |
| 质量规则与参考基准 | 接受的输出 / 期望的输出；业务指标 | 只比较符合同一标准的变体 |
| 计时范围 | 首个 token、完整回答还是语料：以秒计 | 比较起止边界相同的时长 |
| 直到文件取回为止的日程 | 总时间窗口，以小时或天计 | 然后再选择 3 天、7 天或 30 天的套餐 |
在上下文与并发条件下测量内存
对于逐 token 生成的自回归模型，KV 缓存会保存注意力状态。其大小取决于模型和保留的 token。动态缓存在生成过程中可能增长；静态缓存则预留一个最大容量。某些滑动窗口层会限制这种增长。因此，请用实际采用的策略测试预期的序列长度和并发量。
权重量化与缓存量化是两个不同的选择。例如，bitsandbytes 会把某些线性层替换为量化版本；这并不能描述你这次运行中的所有内存分配。更改精度后，请重新检查内存和质量，而不要假设整个峰值会按相同比例下降。
在 PyTorch 中，请分别记录已分配张量的峰值和分配器预留内存的峰值。不要把它们相加。注明所测量的 GPU 和单位：1 GiB 等于 2³⁰ 字节。这些计数器不一定代表设备的全部占用。内存专题会详细说明它们的局限。
技术来源： Hugging Face Transformers 5.17 — KV 缓存策略 · Hugging Face Transformers 5.17 — bitsandbytes 量化 · PyTorch 2.14 — CUDA 内存管理与计数器
一次可测量的 300 份文档试验
可用你获得授权的语料完成的示例：从 300 份文档中提取日期、金额和类别。请复核期望值，明确缺失字段的处理方式，并在试验前设定接受阈值。文档数量描述的是方案本身；不对任何时间、得分或吞吐量作假定。
- 固定这 300 个标识符、模型版本、提示词、token 上限和解析规则。在总结中让长文档保持可识别。
- 先以一次一个请求的方式运行基准。把加载、预热和测量分开；按文档保留预测结果和错误。
- 然后只增加一个参数：批量处理用 batch，请求引擎用并发量。保持相同的输入和质量标准。
- 每一轮都记录时长、内存峰值、无重复找回的标识符数量和被接受的输出。重复测量，并保留原始数值及其离散程度。
- 如果某个变体失败，请记录原因：内存、截断、格式或质量。减少 batch 或重试是需要记录的决定，而不是应当抹去的失败。
技术来源： IteraGPU — 同等质量对比的详细方案
在恰当的范围内使用 IteraGPU Lab v1 资源
该 notebook 及其配套脚本提供了一个权重计算和在小型合成网络上进行的测量。其测量代码已在本地一台 RTX 5070 上以 PyTorch 2.11.0 运行，采用一个小型 float32 配置。这次试验验证的是该运行场景；它既不测量 LLM，也不测量 KV 缓存，也不测量目录中的 GPU 在你请求下的表现。
用该 notebook 理解这些计数器，然后用它所在的环境测量你的真实负载。质量方案和原始表格用于准备对比。分发的 notebook 的输出和 CSV 的结果行仍为空白；该流程不会安装任何模型或驱动。运行前请阅读 README 中的前置条件。
- IteraGPU Lab v1 内存 notebook
用于理解内存测量的计算过程和小型合成网络。
- 待补充的质量方案
固定输入、输出接受标准和试验对比。
- 空白原始表格
每轮实际运行一行，包含参数、测量值和结论。
- IteraGPU Lab v1 的前置条件与局限
已完成本地试验的说明和确切范围。
从测量结果过渡到报价
您的选择清单应汇总兼容的环境、单卡显存、上下文、并发、达到的质量和实测时长。先比较满足这些条件的配置，再按完整周期——准备、处理、评估、恢复和导出——比较 3 天、7 天和 30 天套餐。基准测试档案的计算器使用完整套餐和经过实际验证的有效语料。
请将这份清单和代码版本保存在您的笔记中。软件和处理方式由您选择；IteraGPU 不会检查您的文件、提示词或计算内容。下单时选择的环境表达的是您对准备工作的需求：它并不构成您的模型已经安装或测试过的证明。
实际问题
24 GB 对我的推理模型够用吗？
仅凭 24 GB 这一容量无法回答，还需要了解模型和负载。请综合检查权重、运行时分配、上下文和并发请求。配置必须在要求的质量下完成长用例；仅凭文件大小或对权重的估算无法证明这一点。
对于离线语料，应比较哪个吞吐量指标？
首先比较完成并评估同一语料所需的时长。如果您要公布吞吐量，请给出被接受的可用输出数量、计时方式和错误情况。只有每秒 token 数、没有回答长度和质量控制，不足以区分两种配置的优劣。
显存溢出是否就必须更换 GPU？
显存溢出首先需要找出引发它的设置和输入。您可以在保持项目目标的前提下调整 batch、并发、长度或精度。任何改变所处理文档或预期回答的缩减都需要重新进行质量验证；如果必须保留这些约束，则可能需要更多显存。
提供的 notebook 能验证我的推理应用吗？
提供的 notebook 不能验证您的应用：它只测量一个小型合成网络并解释显存计数器。文档中所述的本地试验仅针对该场景。在得出任何容量或性能结论之前，您的应用必须使用自己的模型、输入、环境和验收标准进行评估。