项目地址本文配套的完整交付手册《大模型私有化交付操作手册》已开源涵盖 8 章正文 3 篇附录 3 张交付模板覆盖 vLLM / SGLang / TGI / TensorRT-LLM / lmdeploy / ollama 等主流推理引擎。项目地址https://gitee.com/wang-guangshuooo/llm-private-deploy-handbookTL;DR太长不看版显存估算必须包含KV Cache否则并发能力错 8 倍。TTFT统一口径从发送请求算推理模型单独统计思考段。容量规划看饱和点与尾延迟不能只看吞吐均值。先说结论私有化交付大模型翻车最多的不是装不上而是算错了。装不上会报错你能立刻发现。而算错了不报错——它安静地给你一个错误的数字然后你在方案里写下这个数字客户按它配了机器验收那天才发现不对。下面三个陷阱是我认为代价最高的三个共同特点是代码不会报错错误要到很晚才暴露。陷阱症状代价一显存估算只算权重忽略 KV Cache容量高估数倍买错卡 / 并发只有预估的 1/5二TTFT 口径不统一同一个词两个人量出差十倍验收现场扯皮三只看吞吐均值漏掉饱和点与尾延迟容量规划拍脑袋陷阱一显存估算只算权重KV Cache 被漏掉这是交付翻车的第一大原因。很多人算显存是这么算的72B FP16 → 72.7 × 2 145.4 GB → 8 张 80G 卡够收工。问题在于显存是三项之和不是一项总显存需求 权重显存 KV Cache 显存 激活/框架开销权重只是装得下的门槛KV Cache 才是决定能服务多少并发的那一项。而并发能力才是客户真正要买的东西。1.1 权重显存一行乘法但别用约数权重显存 参数量 × 每参数字节数精度每参数字节说明FP16 / BF162.0推理默认FP81.0需 H100/L40S 等支持INT8 (W8A8)1.0 少量 scale精度损失小INT4 (AWQ/GPTQ)≈0.55含 scale/zero point实际约 0.5~0.6常用结果速查GB模型FP16INT8INT47B7.6B15.27.64.214B14.7B29.414.78.132B32.5B65.032.517.972B72.7B145.472.740.0注意用真实参数量7.6B / 72.7B不要用7B / 72B这种约数。以模型目录下 config.json 的字段为准或者直接量 safetensors 文件总大小。1.2 KV Cache最容易被漏掉的一项单 token KV 字节 2 × 层数 × KV 头数 × head_dim × 字节数2 Key 和 Value 各一份各模型单 token KV 占用FP16模型层数KV 头数head_dim单 token8K 上下文Qwen2.5-7B28412856 KiB448 MiBQwen2.5-14B488128192 KiB1.5 GiBQwen2.5-32B648128256 KiB2.0 GiBQwen2.5-72B808128320 KiB2.5 GiB这里就是那个坑GQA 的 8:1 分组。Qwen2.5-72B 有 64 个注意力头但只有 8 个 KV 头分组查询注意力8:1。如果你按 64 个头去算 KV2 × 80 层 × 64 头 × 128 × 2 字节 2.5 MiB / token ← 错是实际值的 8 倍2 × 80 层 × 8 头 × 128 × 2 字节 320 KiB / token ← 对一个字段看错单 token KV 就错 8 倍最终并发能力估算也跟着错 8 倍——往哪个方向错取决于你是保守还是激进但两种都是错的。✅ 算之前先打开 config.json确认 num_key_value_heads。这个字段名和 num_attention_heads 长得很像但它们不是一回事。1.3 三个完整算例把并发算出来算例 1Qwen2.5-7B FP16单卡 A100 40G8K 上下文项计算结果权重7.6B × 215.2 GB可用显存40 GB × 0.90gpu_memory_utilization36.0 GB减激活/框架取 1.5 GB34.5 GBKV Cache 池36.0 − 15.2 − 1.519.3 GB单序列 8K 占用56 KiB × 8192448 MiB可支持并发19.3 × 1024 / 448≈ 44 路算例 2Qwen2.5-72B FP168 × A100 80G32K 上下文项计算结果权重72.7B × 2145.4 GB可用显存640 GB × 0.90576 GB减激活/框架/通信4 GB × 832 GBKV Cache 池576 − 145.4 − 32398.6 GB单序列 32K 占用320 KiB × 3276810 GiB可支持并发398.6 / 10≈ 39 路8 张 80G 卡只能同时服务约 39 路 32K 上下文请求。这个数字往往低于客户的预期——很多方案只报能跑起来但并发能力被 KV Cache 死死限制住。算例 3Qwen2.5-72B AWQ INT48 × A100 40G8K 上下文项计算结果权重72.7B × 0.5540.0 GB可用显存320 GB × 0.90288 GB减激活/框架3 GB × 824 GBKV Cache 池288 − 40 − 24224 GB单序列 8K 占用320 KiB × 81922.5 GiB可支持并发224 / 2.5≈ 89 路量化把并发从约 39 路32K提到约 89 路8K代价是权重从 145 GB 降到 40 GB并接受量化精度损失。这就是精度 vs 容量的量化决策依据。1.4 估完之后一定要反向校验方案定稿后实际跑起来用命令核对# vLLM 启动日志里会打印 # GPU KV cache size: XXX tokens # Maximum concurrency for XXX tokens per request: Y.Yx 实时观察显存 nvidia-smi --query-gpuindex,memory.used,memory.total,utilization.gpu --formatcsv -l 5 通过 Prometheus 看 KV Cache 使用率 curl -s localhost:8000/metrics | grep gpu_cache_usage_perc一条实用判据正常负载下 gpu_cache_usage_perc 应在 20% ~ 70% 之间。长期 90% → 并发接近上限请求开始排队TTFT 会陡增长期 10% → 显存浪费可以调大 --max-num-seqs 或减少卡数陷阱二TTFT 这个词两个人能量出十倍差TTFTTime To First Token首包延迟是交付现场唯一有意义的体感指标——用户不关心整个回答花了几秒他只在意多久开始出字。但这个词谁都在用定义却不一样。同一个服务、同一次压测两个人给出的 TTFT 可以差十倍。交付现场 90% 的性能争议本质是双方对 TTFT 的定义不一样。有三个口径陷阱陷阱 2.1从哪一刻开始算口径含义什么时候用从发送请求算含 HTTP 建连 TLS 握手 排队 预填充✅ 推荐最接近用户真实感受从收到 HTTP 200 算不含建连含排队 预填充排除网络噪声对比引擎性能从预填充开始算只含预填充计算纯引擎能力对比不是用户体验交付压测用第一种但必须在报告里写明是哪种并注明客户端与服务端同机 / 同机房否则网络 RTT 会被算进去。顺便说用流式请求时常见的写法是resp client.chat.completions.create(..., streamTrue) ttft time.perf_counter() - start # 错这是 HTTP 200 的时刻 for chunk in resp: # 真正的首 token 在这里才到 ...HTTP 200 返回的时候模型一个字都还没出。陷阱 2.2排队时间算不算必须算。用户按下回车就开始等了服务在排队这段时间他是真实感受到了的。这正是并发一高 TTFT 就爆炸的原因——不是模型变慢了而是请求在队列里等。这恰恰是压测最重要的发现之一把它排除掉等于把最关键的结论藏起来。陷阱 2.3推理模型的思考段算不算最隐蔽像 DeepSeek-R1、QwQ 这类推理模型会先输出一大段思考内容。在 OpenAI 兼容的 SSE 流式接口里这段内容往往走不同的字段如 delta.reasoning_content而不是 delta.content。实测逐帧解析的结果帧 1 ~ 帧 128 : delta 里只有 reasoning_content思考段 帧 129 : 第一个 delta.content 出现 ← 真正的 TTFT 应该在这里 帧 129 ~ 帧 211 : 正常输出内容把第一个任意分片当 TTFT → 首帧在第 1 帧就来了TTFT 被严重低估把 reasoning 也算作输出 token → TPOT 被摊薄虚低取 content → TTFT 里包含了几十秒思考数字大得没法跟普通模型对比三条路都不对因为这个指标对推理模型本身就不成立。✅ 正确做法TTFT 定义为第一个 content 字段出现的时刻思考段单独统计为思考耗时或一并计入端到端但明确标注报告里必须写清目标模型是推理模型还是普通模型做配置对比时不要混用推理模型和普通模型指标不可比。结论推理模型不适合作为 TTFT 口径对比的基准模型。做压测前先解析一次 SSE 帧结构确认字段名。陷阱三只看吞吐均值不看饱和点和尾延迟压测做完报一个吞吐 XXX tok/s这几乎等于没报。因为单看吞吐你无法回答客户唯一关心的问题我能服务多少人3.1 先看一组真机数据真机实测三条曲线。环境标注很重要RTX 4060 Laptop 8.0 GiB Windows 11 ollama qwen2.5:7b Q4_K_M 并发 1/2/4/8/16/32 每请求 256 tokens 预热 2 次 温度 0 流式 63 个请求、0 失败、总耗时 222.9 s。并发吞吐 (tok/s)加速比TTFT 均值 (ms)TTFT P99 (ms)TPOT (ms)端到端 P99 (ms)126.91.00×168.81168.8121.642159.52227.31.02×1335.322436.1723.934607.57430.41.13×3636.496869.4723.448871.39830.81.14×7804.7815156.9222.9617178.871630.01.11×15979.1230537.7921.5632414.353229.31.09×30839.1060821.1421.6962798.84显存峰值 5.6 GiB / 8.0 GiB70.3%平均 GPU 利用率 71.9%63 请求 0 失败。从这组数据可以读出三个关键信息第一饱和点出现在并发 2 附近。并发从 1 提到 2吞吐从 26.9 微升到 27.3 tok/s加速比只有 1.02×之后并发 4/8/16/32 一路走平甚至回落到并发 32 时吞吐降到 29.3加速比只剩 1.09×。也就是说这张 8G 显存的笔记本卡在并发 2 时吞吐就已经到顶继续加并发不仅没有收益还会因为排队和调度开销让整体吞吐下滑。饱和点就是 2。第二尾延迟在并发 2 之后开始失控。TTFT 均值从并发 1 的 168.81 ms 一路涨到并发 32 的 30839.10 ms涨了约 182 倍TTFT P99 在并发 2 时已经到 2436.17 ms并发 8 时冲到 15156.92 ms并发 32 时更是到 60821.14 ms。TPOT 全程稳定在 21.56~23.93 ms 之间基本不动说明单 token 生成速度并没有变慢——瓶颈不在算力而在调度。尾延迟的恶化远早于吞吐见顶这才是容量规划真正要盯的指标。第三据此确定最大并发数。如果只看吞吐并发 2 之后基本没有收益结合尾延迟并发 2 时 TTFT P99 已经超过 2.4 秒并发 4 时超过 6.8 秒体感明显变差。所以这张卡的实际可用并发建议取 2最多不超过 4——在 2 并发下吞吐仍有 27.3 tok/s接近峰值而 TTFT P99 还能压在 2.5 秒以内。容量规划的正确姿势是先找吞吐饱和点再往前退一档到尾延迟还能接受的位置那个并发值才是能写进方案的数字。由于 TPOT 全程恒定加算力换更好的卡无用要换调度更好的引擎或加副本才能提升并发能力。参考资料以下 5 条官方文档与本文三个陷阱直接相关建议在方案定稿前通读一遍vLLM 官方文档KV Cache 与 gpu_memory_utilizationAutomatic Prefix Caching - vLLM。为什么值得看本文 1.3 节所有算例里的 gpu_memory_utilization 和 KV Cache 池估算都能在这里找到官方口径避免凭经验拍脑袋。HuggingFace 关于 GQA分组查询注意力的技术博客https://huggingface.co/blog/gqa。为什么值得看GQA 的 8:1 分组是 1.2 节最容易算错 8 倍的地方这篇博客把 KV 头与注意力头的关系讲清楚了能帮你少踩一个字段看错的坑。OpenAI 关于流式响应与 SSE 字段定义的 API 文档https://platform.openai.com/docs/api-reference/chat。为什么值得看陷阱 2.1 和 2.3 都依赖对 SSE 流式帧结构的准确理解这份文档是 OpenAI 兼容接口字段定义的权威来源。DeepSeek-R1 技术报告中关于 reasoning_content 输出的说明https://github.com/deepseek-ai/DeepSeek-R1。为什么值得看陷阱 2.3 里推理模型思考段与 content 字段的区分在 DeepSeek-R1 官方仓库里有最直接的说明是压测前解析 SSE 帧结构的必读材料。ollama 官方性能调优指南https://github.com/ollama/ollama/blob/main/docs/faq.md。为什么值得看本文 3.1 节真机压测用的是 ollama qwen2.5:7b这份 FAQ 覆盖了并发、上下文长度和 KV Cache 相关的常见调优问题能帮你复现并验证压测结论。