Project - hx_llm

目标

用固定模型、硬件和请求分布，比较不同推理路线在质量不回退前提下的 TTFT、TPOT、吞吐、峰值显存和 p99；所有结论必须能由脚本和配置复现。

本项目采用的推理路线

当前决策

决策 依据 状态
选择推理引擎 待补充基准和约束 待验证

先把工作负载写成实验变量

“比较引擎”不是一个可复现的实验。首个基准应冻结模型权重和 tokenizer 版本、量化格式、GPU 型号/数量、驱动和 runtime 版本，并把请求分成至少三种：短 prompt/短输出、长 prompt/短输出、短 prompt/长输出。每种分布再设置低并发、稳定并发和突发流量；否则一个偏 prefill 的负载可能被误当成所有业务的结论。

1
2
3
4
5
6
workload distribution
→ prefill/decode ratio
→ KV residency and batch shape
→ scheduler decisions
→ kernel / parallel / quantization behavior
→ TTFT, TPOT, throughput, p99, cost

采样参数、停止条件和最大上下文也必须固定。质量验收至少保存一组确定性 prompt 的输出、拒答/工具调用行为和长上下文样例；性能更快但输出截断或引用变差，不算可接受的优化。

基准矩阵与记录格式

变量 最小取值 记录原因
输入/输出 token 512/128、4k/128、512/2k 区分 prefill 与 decode
并发 1、目标稳态、突发峰值 观察 batching、队列和 KV 压力
引擎配置 batch 上限、KV 预算、量化、TP 解释差异来自哪里
运行阶段 cold、warm、稳定窗口 避免把加载/warmup 当吞吐
结果 TTFT、TPOT、tokens/s、P50/P99、OOM 同时覆盖体验和容量

每次运行保存配置文件、服务日志、版本 hash、warmup 次数、失败请求和显存峰值。性能表应保留原始请求级数据，而不是只提交均值；p99 被少量长请求支配时，均值会隐藏真正的回归。

决策规则

先用单机单卡建立正确性基线，再增加并发和多卡。若 TTFT 是瓶颈，优先看 prefill kernel、chunked prefill 和请求队列；若 TPOT 是瓶颈，沿 Decode 检查权重/KV 带宽、GQA、量化和 speculative decoding；若 P99 变差，先看 admission、continuous batching 和长请求是否挤占短请求。只有瓶颈稳定后，才把引擎更换纳入 A/B。

“选择 vLLM”目前只是候选实现，不是结论。应以质量不过线、OOM/错误率不过线、p99 和单位 token 成本满足目标为约束；若某优化只提升平均吞吐却使突发 p99 或 cold-start 超标，记录为不适合该负载，而不是简单标记为更快。

性能因果链

1
2
3
4
5
请求分布/上下文长度
→ prefill 与 decode 比例
→ KV 容量、batch 与调度
→ kernel/量化/并行
→ TTFT、TPOT、吞吐、p99 与成本

因此 benchmark 至少固定：模型与量化、prompt/output 长度分布、并发、采样、硬件/驱动、warmup 和测量窗口。报告同时保留失败率、OOM、质量样例和版本 hash，避免只挑 tokens/s。

下一步

  • 写清目标模型、硬件和负载特征

  • 定义首个可复现基准

  • 把结果连接回对应概念笔记

  • 将每个瓶颈映射回 LLM Inference Optimization Map

当前未决实验

  1. 在固定模型和 4k/128 负载下，比较单卡 vLLM 的 batch/KV 配置，确定 TTFT 与 TPOT 的拐点。
  2. 在同一请求分布下比较 BF16 与目标量化，检查速度收益是否伴随质量、OOM 或冷启动变化。
  3. 对一条长 prompt 请求和多条短请求混合压测，确认 scheduler 是否造成短请求的 p99 回归。

每完成一个实验，更新“依据”和版本，而不是直接把临时跑分写成架构决策。相关失败现象回填到 AI System Performance Bottlenecks；若实验无法在当前硬件上区分假设，转入 Open Questions。