用time.time()测单次predict()耗时最直接，需确保模型已训练完成、输入格式与线上一致、运行前gc.collect()，并优先使用time.perf_counter()获取更高精度。
用 time.time() 测单次预测耗时最直接
想看模型跑一次 predict() 要多久，time.time() 是最轻量、最不容易引入干扰的方式。别用 timeit 默认的多次循环——它会反复调用 fit() 或触发缓存机制，测出来的不是真实推理时间。
- 确保只测
predict()，模型必须已训练完成并保存为变量（如clf） - 输入数据要和线上一致：如果是批量预测，传入
numpy.ndarray或pandas.DataFrame，别用单个样本加.reshape(1, -1)模拟，开销差异明显 - 运行前加一句
import gc; gc.collect()，避免 Python 垃圾回收在计时窗口内触发，导致结果毛刺 - 示例：
import time<br>start = time.time()<br>y_pred = clf.predict(X_sample)<br>end = time.time()<br>print(f"单次推理耗时: {(end - start) * 1000:.2f} ms")
批量预测响应时间要看 P95/P99，不是平均值
线上服务的 SLA 通常按 P95 或 P99 响应时间定义，平均值会掩盖长尾延迟。比如 100 次预测里 95 次快于 10ms，但有 5 次卡在 200ms，平均才 20ms——实际用户体验是那 5% 的卡顿。
- 用
time.perf_counter()替代time.time()，精度更高，不受系统时钟调整影响 - 至少采集 100–1000 次，尤其对树模型（如
RandomForestClassifier）或大LinearSVC，首次预测常有 JIT 编译或内存预热开销，建议丢弃前 10 次 - 计算分位数用
numpy.quantile(times_ms, 0.95)，别手写排序取第 95 个 - 注意批量大小影响：
clf.predict(X_batch)中X_batch.shape[0]增大时，耗时未必线性增长——有些模型内部做了向量化优化，有些则因内存带宽瓶颈陡增
Scikit-learn 模型类型对推理速度影响极大
同样数据、同样硬件，LogisticRegression 和 GradientBoostingClassifier 的响应时间可能差 10–100 倍。不看模型类型就谈“响应时间”没意义。
-
LogisticRegression、LinearSVC、SGDClassifier：纯矩阵乘+激活函数，CPU 上通常 -
RandomForestClassifier：每棵树串行 traversal，树越多、深度越深，耗时越长；用n_jobs=-1只加速训练，推理默认单线程 -
NearestNeighbors：暴力搜索是 O(n)，algorithm='ball_tree'或'kd_tree'能降到 O(log n)，但建树本身有开销 - 所有模型启用
verbose=True不影响推理速度，但joblib.load()加载大模型时可能卡住几秒——这部分属于初始化，不应计入推理时间
绕不开的陷阱：transformer 预处理拖慢整体响应
真实 pipeline 里，predict() 前往往要过 StandardScaler、OneHotEncoder 或自定义清洗函数。这些步骤常比模型本身更慢，却容易被忽略。
立即学习“Python免费学习笔记（深入）”；
- 用
sklearn.pipeline.Pipeline封装时，pipeline.predict()包含全部步骤，必须整段计时 -
OneHotEncoder(handle_unknown='ignore')在遇到未见过的类别时会动态扩展输出维度，触发稀疏矩阵重建，耗时突增——务必用线上流量做 AB 测试 - 文本类 pipeline（如
TfidfVectorizer+LogisticRegression）中，vectorizer.transform()占总耗时 70%+，建议提前缓存 vocab 并用 Cython 加速 - 别在每次请求里重复调用
pd.get_dummies()——它不是 scikit-learn 组件，但常混进 pipeline，性能极差
真实服务压测时，Python GIL 和 NumPy 底层 BLAS 实现（OpenBLAS vs Intel MKL）会导致同一模型在不同环境偏差 2–3 倍。测之前先确认 np.show_config() 输出的 BLAS 是否启用多线程。
