GPU 利用率 90%，用户还是喊卡？大模型推理指标的三重认知陷阱

“我们的模型在公开 Benchmark 上跑出了 200 TPS，为什么上线后用户反馈‘首字等 3 秒、生成像打字机’？”

这不是个例。在大模型推理从实验室走向生产环境的过程中，我们反复观察到一种割裂：监控面板上的指标一片繁荣，用户体验却千疮百孔。问题不在于加速器不够快，而在于我们用错了尺子。

传统 Web 服务的 QPS/延迟模型，在 Token 流式生成的世界里几乎完全失效。本文将拆解三个最致命的认知误区，并给你一个可以立即运行的诊断脚本——不再被白皮书峰值牵着鼻子走。

误区一：负载画像错配——你在测什么？

几乎所有推理框架或硬件白皮书都会亮出一个惊人的 TPS 数字。但当你把同样的模型部署到真实的 RAG 或 Agent 场景中，性能往往打 3-5 折。这是 Benchmark 假设与真实业务负载画像的结构性错配造成的：

评估供应商或选型时，不能只看官方 TPS。你需要要求提供与自身业务输入输出长度分布匹配的实测数据，或者用下文提供的校准脚本自行验证。基于峰值做的容量规划，上线后大概率面临 3 倍以上的资源缺口。

从系统侧看，这种错配的根源在于：加速器利用率是一个“欺骗性指标”——它无法区分算力是被用于有效 Decode、被 Prefill 抢占，还是消耗在 Padding 填充上。真正能反映推理健康度的监控指标，应该是“实际 Batch Size 均值/P99”和“Prefill/Decode 时间占比”。至于为什么利用率会骗人、以及这些替代指标如何指导优化，我们将在 “误区二：Prefill 与 Decode 是两种病” 一节中深入拆解。

认知校准器：你的业务场景到底能跑多少 TPS？

下面这个 Python 脚本是一个 “认知校准器”，基于昇腾 910B3 + Qwen3.5-27B FP16 的参数，用引入 Batch Size 感知的简化 Roofline 模型 + 经验衰减系数，帮你快速建立“业务参数 → 系统指标”的直觉。

大模型量化实战（上）：从显存焦虑到算法本质

想在本地跑个 70B 的大模型？FP16 精度下光权重就得吃掉 140G 显存，连加载都报错。这时候你肯定盯上了量化：换成 INT4，35G 显存搞定，一张 RTX 4090 就能起飞。

但真用起来，坑就来了：

• 明明体积缩小了 4 倍，生成速度怎么没快 4 倍？
• 评测分数看着没掉，怎么让它写个复杂代码就开始胡言乱语了？
• 网上满天飞的 GPTQ、AWQ、W8A8，到底该下哪个包？

很多人以为量化就是“把文件压缩一下”，其实根本不是。它更像是在给大桥换便宜的钢材 ——有些钢缆是主承重墙，换差了桥就塌了；有些只是栏杆，随便换。

而且别被 PPL（困惑度）这种评测指标骗了。很多时候分数没变，但模型的长尾知识召回下降、多步推理链断裂、格式化输出不稳定 ——这些才是量化最常见的“隐形退化”。这就是为什么不能闭着眼睛无脑转 INT4。

为了搞懂这些，我把大模型里需要量化的东西分成了三块，它们的脾气完全不一样：

这篇文章不打算给你背公式。我们直接从这几个实际问题出发，用大白话盘一盘主流算法到底是怎么解决这些“刺头”的，最后给你一张直接能用的选型决策表。

大模型量化实战（下）：从敲命令到验精度

上篇我们聊了量化的本质是“误差甩锅”，也给了选型决策表。但很多读者反馈：“知道该选 AWQ 了，可打开终端还是不知道敲什么。”“量化完怎么验证？PPL 跑完了然后呢？”

这篇就是来填坑的。我们将聚焦两件事：怎么用 ms-swift 一行命令完成量化，以及怎么科学验证量化模型没变傻。不再有“精密博弈”之类的废话，直接上命令、上脚本、上诊断思路。

💡 本篇定位
这是上篇的“实操续集”。如果你还没读过上篇，建议先花 5 分钟了解“误差甩锅”和选型逻辑，否则本篇的命令会显得孤立。

1. 量化实操：ms-swift 能做什么、不能做什么

ms-swift 是国内最友好的量化工具，但它不是万能的。先明确边界，再谈命令：

💡 关键提醒
上篇提到的 SmoothQuant 和 GGUF，在 ms-swift 中无法一键完成。如果你需要这两种方案，请跳转到对应工具链。本篇聚焦 ms-swift 真实支持的四种量化方法及 Ollama 导出。

最小可运行命令（复制即用）

SciPy 与 SymPy：数值算结果，符号推公式，各管各的

做科学计算的时候，你经常会遇到两种需求：

• 算一个具体的数：比如 ∫₀¹ sin(x) dx = 0.4596...
• 推一个数学公式：比如 ∫ x·sin(x) dx = -x·cos(x) + sin(x)

前者是数值计算（SciPy 的活），后者是符号运算（SymPy 的活）。数值给结果，符号给表达式。 两套工具，解决两类问题。

数值积分：函数没原函数，或者数据来自实验

很多工程问题需要算积分，但被积函数可能没有初等原函数，或者数据是测量来的（离散点，没有表达式）。这时候用数值积分。

一维定积分：quad（最常用）

from scipy.integrate import quad
import numpy as np

# 算 ∫₀¹ sin(x) dx
result, error = quad(np.sin, 0, 1)
print(f"{result:.10f}")   # 0.4596976941

quad 返回两个值：积分结果和误差估计。误差估计别看小，它告诉你结果可不可信。 如果误差比结果还大，说明积分没收敛。

带参数的积分：

def integrand(x, a, b):
    return np.exp(-a * x) * np.sin(b * x)

result, error = quad(integrand, 0, np.inf, args=(2.0, 3.0))

二重积分：dblquad（注意积分顺序）

from scipy.integrate import dblquad

# 算半球体积：∫∫ √(1-x²-y²) dy dx
def f(x, y):
    return np.sqrt(max(0, 1 - x**2 - y**2))

volume, error = dblquad(
    f,
    -1, 1,
    lambda x: -np.sqrt(1-x**2),
    lambda x: np.sqrt(1-x**2)
)
print(f"{volume:.6f}")   # 2.094395（= 2π/3）

SciPy 数值优化：从最小二乘到非线性求解，遇到什么问题该用什么

写代码做数据处理，很多问题最终都能归结成一个核心需求：找到一组最优的参数。

• 拟合一条曲线 → 找参数使误差最小
• 控制一个系统 → 找参数使性能最好
• 解一个方程组 → 找一组值使所有等式成立

SciPy 的 optimize 模块就是干这个的。但问题是：算法太多了——leastsq、curve_fit、fmin、fmin_bfgs、fsolve……新手看了直接懵。

---

最小二乘拟合：数据点 + 模型 = 找参数

90% 的优化需求都能归到这一类：你有数据点，你有一个带参数的模型，你想让模型尽可能贴合数据。

标准写法（老派）：

from scipy.optimize import leastsq
import numpy as np

x = np.array([1, 2, 3, 4, 5])
y = 2.5 * x + 1.3 + np.random.randn(5) * 0.5

def residuals(p, x, y):
    k, b = p
    return y - (k * x + b)

p0 = [1.0, 0.0]
result = leastsq(residuals, p0, args=(x, y))
k, b = result[0]
print(f"k={k:.3f}, b={b:.3f}")

更友好的写法（推荐）：

from scipy.optimize import curve_fit

def model(x, k, b):
    return k * x + b

popt, pcov = curve_fit(model, x, y, p0=[1.0, 0.0])
k, b = popt

curve_fit 比 leastsq 好用得多——不用自己写残差函数，不用操心 args 传参方式，直接定义模型函数就行。新代码优先用 curve_fit。

拟合正弦波（复杂模型示例）：