算法市场模型性能优化六大技巧：从延迟画像到自动回滚

我们部门在搭建企业算法市场那段时间，最头疼的还真不是模型效果不达标，而是"模型明明本地跑得好好的，一上市场就卡成狗"。业务方陆续来投诉：有的说接口超时，有的说结果出来了但等了半天，还有的说同一个模型昨天还快今天突然慢得离谱。那时候我才真正意识到一件事：算法市场里的模型性能优化，和单点模型优化根本不是一回事。

这里说的"算法市场"，是指企业内部的模型能力交易与复用平台——模型经过注册、版本管理、服务等级划分、鉴权、计量计费之后，开放给不同业务方调用。它的价值在于避免重复造轮子，比如A团队训练好的文本分类模型，B团队可以直接调用，不用再找人训练一个。但正因为它是"市场"，调用方多种多样、流量模式复杂、SLA需求各不相同，性能优化的目标也因此完全变了：不再是"把某一个模型调快"，而是"让整个平台的吞吐、稳定性、成本都处在可控状态"。

这篇文章分享的6个技巧，都是我们在算法市场建设中真正落地、并且事后证明有效的做法。它们既有模型层面的优化，也有服务架构和平台机制层面的设计。如果你是做AI平台、算法中台或者模型服务化的同学，这里的思路和踩坑经验可以直接参考。

1. 算法市场里的性能优化，和单点模型优化根本不是一回事

先说一个大家最容易踩的直觉误区：总觉得性能优化就是"把模型推理速度提上去"。但在算法市场这个场景里，真正吃掉延迟的往往不是模型本身。

我举一个实际数据。我们有一个OCR模型，单次推理P50是35毫秒，看起来很快对吧？挂到算法市场上之后，端到端P50变成了180毫秒。那多出来的145毫秒去哪了？拆开来看：网关鉴权10毫秒，配额校验8毫秒，路由寻址12毫秒，日志上报15毫秒，序列化反序列化30毫秒，剩下约70毫秒花在了排队等待和网络开销上。模型本身的推理时间，在这条链路里只占不到20%。

所以算法市场的性能优化，第一步永远不是调模型，而是先把整条链路拆开，看清楚时间到底花在哪儿。这是整个优化工作的基础，我下面所有技巧都建立在这个认知之上。

1.1 性能瓶颈的分布：平台链路才是大头

算法市场的一个请求从业务方发出，大致要经历这样的过程：网关鉴权、配额校验、模型路由寻址、实例调度、推理执行、结果回传、日志与计量计费。单看每一层似乎都没什么，但叠加起来的开销非常可观。

而且链路越长，抖动源越多。网络拥塞、中间件GC、连接池耗尽、鉴权服务变慢，任何一个环节抖动，都会直接反映在端到端延迟上。更麻烦的是，这些问题往往只影响一小部分请求——也就是长尾部分——但它们对业务方的体感影响最大。

我在设计平台时做了一个要求：每一个环节必须单独埋点上报耗时，并且延迟数据要按模型维度、调用方维度、版本维度聚合。这样一次线上性能问题出现时，我们能快速回答"延迟到底涨在哪一层"。没有这个基础，后面谈优化都是盲人摸象。

1.2 优化目标从"快"变成"稳、狠、准"

单模型优化，指标就是"延迟多低、吞吐多高"。算法市场还要多加两个维度：稳定性和成本效率。

稳定性指的是P99延迟不毛刺。业务方会把模型能力当基础设施来用，对波动的容忍度非常低。比如交易链路里的风险识别模型，P99超过300毫秒，意味着每1000个请求里有10个要等很久，这个等待会直接转化为用户流失和业务损失。

成本效率指的是"每一块钱的算力投入，能支撑起多少有效调用"。算法市场如果成本失控，平台就很难持续运营下去。所以我的核心指导思想是：不追求"最快"，而是在可接受的SLA内，用最低的成本承载最大的流量。

这几个维度结合起来，后面6个技巧的方向就清晰了。我把它们概括成一张总览表：

2. 技巧一：延迟画像——把性能基线建立在分位数而不是平均值上

第一个技巧看起来最简单，但恰恰是最容易被忽视的：先做延迟画像，并且把性能基线建立在分位数上。

2.1 为什么平均值会骗人

我们项目里有个很典型的例子。某个文本分类模型上线前压测，平均延迟45毫秒，大家觉得很好，直接发布到了算法市场。结果第二天，一个核心业务方投诉说接口"时快时慢"。查了详细日志才发现：P50只有40毫秒，P99却高达320毫秒。也就是说，绝大多数请求很快，但有1%的请求要慢七八倍。这1%占比不大，但对于调用量大的业务方来说，每分钟都会遇到几次超时重试，体验自然非常差。

平均值会骗人的原因在于，延迟分布通常是长尾的。网络抖动、GC暂停、GPU抢占、排队，都会把一部分请求推到很长的延迟区间里。只看平均值，等于把那一两百个长尾请求的耗时"摊平"到了所有请求上，问题就被藏起来了。

正确的做法是统计P50、P90、P99、P99.9这几个分位数，同时关注"毛刺率"——也就是P99和P50的差距。差距越大，说明服务越不稳定。这个道理做服务端的人应该都不陌生，但在模型上线流程里，它经常被忘得一干二净。

2.2 延迟画像的标准操作流程

不是简单地在压测工具里加几个百分位统计就完事了。我建议把延迟画像做成一个标准流程，放在模型上架之前：

1. 基准集构建：从真实业务流量中抽取有代表性的样本集，至少覆盖不同的输入大小、文本长度、图片分辨率。不要只用几个固定样例"点一下"看延迟，那完全没意义。
2. 压测场景设计：至少分三档——单用户串行调用、中并发（比如50并发）、高并发（比如200并发以上），分别记录每一档的P50/P90/P99。
3. 链路拆解：在网关、路由、推理服务、日志上报这几层都埋点单独记录耗时，确保能定位到"延迟到底在哪一层涨上去的"。

我们最初压测用的是wrk，后来换成了基于Locust自建的压力脚本，因为要模拟真实的鉴权头、参数分布和调用节奏。wrk虽然性能好，但场景定制能力太弱。另外，压测时一定要排除冷启动影响，先预热几分钟再开始记录数据，否则首个请求的冷启动延迟会严重污染P99。

2.3 算法市场里的特殊应用：给模型打"性能体检报告"

延迟画像在算法市场里有个单模型场景没有的应用：把压测结果作为模型元数据登记到市场上，调用方在选择模型时就能看到"这个模型P99是多少、适合什么业务等级"。我们内部把这称为模型的性能体检报告。

这个做法非常实用。不同模型之间的性能差异可以很大——一个大语言模型和一个轻量分类模型，延迟差一个数量级是正常的。如果市场不把性能画像显式暴露出来，调用方只能"盲选"，上线之后才发现延迟不符合要求，又回到平台侧排查，来回浪费时间。

所以我们每个模型上架时，除了精度指标，还必须附一份性能体检报告，包含：不同并发档位下的P50/P95/P99、压测时的GPU型号和显存占用、batch_size配置建议。调用方选模型的时候，可以直接根据这份报告判断是否适合自己的场景。

提示：性能画像不是一劳永逸的。模型代码更新、框架版本升级、输入分布变化，都会改变性能表现。建议每次发新版本都重新跑一遍画像，并且尽量保证压测环境与线上环境一致。

3. 技巧二：模型压缩与"分档发布"，让同一模型匹配不同SLA

第二个技巧涉及模型本身。不能一个版本打天下，要通过压缩、蒸馏等手段产出多个"性能档位"，分别发布到算法市场，对应不同的SLA和价格。

3.1 算法市场特有的矛盾：精度、延迟、价格三角博弈

单模型时代，你只需要自己权衡"精度和速度"。算法市场不一样——同一个模型，不同调用方的诉求可能完全相反。

有的调用方要极致精度，比如离线批量处理，跑几个小时都没关系；有的调用方要极致速度，比如实时拦截场景，宁可精度降一点也要快。如果市场只发布一个版本，要么实时业务方嫌慢，要么离线业务方嫌精度不够。

解法是做分档。我们的实践是每个模型产品做三个档位：

• 旗舰版（高精度版）：不量化，甚至可以用更大的输入尺寸或更多采样步数。适合离线批量处理、对效果要求苛刻的场景。
• 标准版：做INT8量化或轻量蒸馏，精度损失控制在可接受范围内（通常一个百分点以内），服务大多数线上实时场景。
• 轻量版（Lite）：深度剪枝加蒸馏，速度最快，适合移动端、边缘端、低算力场景。

在算法市场里，这三档是独立注册、独立计费的。调用方按需选择，平台方也把算力成本分档定价，形成一个良性的商业闭环。

3.2 量化实操：从FP32到INT8，精度损失怎么评估

量化是模型压缩里性价比最高的手段。我的经验是：FP32到FP16几乎无损，可以大胆做，NVIDIA GPU支持也好。但到INT8就要谨慎了，特别是对小模型，精度回落可能很明显。

实操步骤大致是：

1. 准备校准集，不用太大，500到1000条有代表性的样本即可。
2. 用校准数据统计每层激活值的分布，确定量化参数。推荐用TensorRT的PTQ（训练后量化）或者ONNX Runtime的INT8量化工具。
3. 量化后用验证集对比FP32和INT8的输出差异。重点关注两个指标：整体准确率差值，以及"不一致样本率"——即FP32下正确、INT8下错误的样本比例。这个比例如果超过5%，就要考虑是不是某些敏感层不能量化。

我们在一个图像分类模型上做过INT8量化，离线评测显示准确率只从92.5%掉到92.1%，看起来完全可接受。但上线之后业务方反馈"效果明显变差"，后来排查到头发现是训练时的图像缩放算法和TensorRT量化版推理时用的插值方式不一致导致的。这个坑我后面详细讲。

3.3 蒸馏实操：用大模型带小模型

蒸馏（Knowledge Distillation）的思路是：用一个强Teacher模型（往往是大模型或集成模型）的软标签，去训练一个轻量Student模型。算法市场场景里，最适合做蒸馏的是两类：一类是BERT这样的Transformer结构，可以直接做层数缩减加蒸馏；另一类是图像模型，用大模型的中间特征图做蒸馏。

我们一个实体抽取项目，Teacher是340M参数的模型，蒸馏后Student只有60M参数，精度只掉了0.8个百分点，但推理延迟从180毫秒降到了45毫秒，QPS翻了大概3倍。这个收益放在算法市场里非常可观——同样的GPU资源，承载的调用量接近翻倍。

不过要提醒一句：蒸馏训练本身是有成本的，不是所有模型都值得做。我的建议是只在"调用量大、延迟敏感"的模型上做蒸馏，那些一天调用几百次的冷门模型，优先做量化就够了，别投入太多工程时间。

3.4 版本管理与血缘关系：分档发布最容易踩的坑

分档发布之后，算法市场里会出现同一模型的多版本共存。这里最容易踩的坑是版本管理混乱——模型结构更新了，旗舰版和标准版的输出行为不一致，调用方在切换档位时发现"结果不一样了"，以为是平台出了Bug。

我们的经验是：同一个"模型产品"下的所有档位，必须共享同一个语义版本号，并且每个档位的注册信息里要标明"基于哪个主版本蒸馏/量化而来"。这样调用方在市场里看到的档位切换是透明的，不会因为压缩手段不同而把同一个模型当成完全不同的产品。

更进一步，我们把"模型产品"和"模型实例"做了区分。调用方看到的是产品名和档位，平台侧管理的是具体的版本和实例。当调用方说"把类目识别模型切到标准档"时，平台在后台要做的事包括：检查该档位是否存在、模型是否已加载、是否有足够的配额、是否需要冷启动。这套关系如果一开始没想清楚，市场上线第一天就会乱套。

4. 技巧三：动态批处理与结果缓存——给吞吐装上两个轮子

第三个技巧是推理服务端的吞吐优化。模型压缩得再快，如果服务架构撑不住高并发，算法市场一样会崩。这里讲两个最实用的杠杆：动态批处理和服务端缓存。

4.1 动态批处理：让GPU不再空转

GPU推理和CPU推理有个本质区别：GPU是"吞吐优先"的处理器。单个请求跑一次推理，和十个请求攒在一起跑一次推理，时间差距远小于10倍。所以如果能把一批请求同时送进模型，整体吞吐会有非常大的提升，这是深度学习推理领域被反复验证过的结论。

但算法市场里，请求到来是随机的、不均匀的。等批攒满了再推理，单请求延迟增加；不攒批，GPU又大量空转。这就是动态批处理（Dynamic Batching）要解决的问题。

实践中主要调两个参数：

• max_batch_size：最多一次处理多少个请求，一般根据GPU显存和模型大小来定。比如一个BERT模型在16G V100上，max_batch_size设为32到64比较合理。
• max_latency：最多等多久就触发推理，哪怕批次没攒满。这个值直接决定了延迟的上限，一般跟模型服务的SLA挂钩。比如要求P99小于200毫秒，max_latency可以设在50毫秒左右。

这两个参数需要一起调。max_batch_size拉高会提升吞吐，但max_latency设得太大，延迟就失控。我们上线前的做法是用压测做一组正交实验（batch_size × latency），画出"延迟-吞吐"曲线，找到拐点，再取一个偏保守的值配置上去。

Triton Inference Server、TorchServe这些推理框架都内置了动态批处理，建议直接用，不要自己造轮子。我们早期自己写了一个简单的队列批处理，结果在高并发下出现请求丢失，排查了两天才发现是队列超时和线程池不匹配导致的。

4.2 服务端缓存：算法市场里被低估的"免费性能"

缓存是我们算法市场性能优化里性价比最高的一项，没有之一。原因是算法市场里的调用模式有明显的重复性，比如：

• 同一个商品图片可能被不同业务方反复请求做类目识别。
• 同一个文本片段经常被多个下游系统做情感分析。
• 离线批量任务跑完后，在线又开始调用同一个模型处理同一批数据。

这三种情况如果没有缓存，每次都是全量推理，成本非常高。加一层缓存就完全不一样了。

我们实现了两种缓存策略：

• 精确缓存：以输入内容的哈希值为key，命中直接返回结果。TTL按模型语义来定——类目识别一天内基本不变，TTL设12到24小时；文本分类结果可能变化，TTL设短一些，比如10分钟。
• 语义缓存：以embedding相似度为key。比如两个输入向量的余弦相似度超过0.99，就认为语义一致，直接复用结果。这个方法非常适合文本分类、检索类任务，但要注意精度风险——不是所有任务都适合语义级别的结果复用，需要单独评估。

一点实操心得：缓存一定要做成"可选能力"，而不是默认强制。算法市场里有部分业务方明确要求"每次都要最新结果"（比如实时价格预测），如果默认缓存，等于悄悄改了业务逻辑。我们在平台上给每个模型增加了一个cache_policy字段，调用方在申请调用时可以自己选择no_cache、exact_cache_ttl或semantic_similarity。

缓存命中率也值得监控。我们通过日志分析发现，有相当一部分模型的缓存命中率超过了40%。这意味着平台上40%的重复调用请求没有消耗额外的推理算力。前期不加缓存，等于白白烧掉了大量GPU费用。

5. 技巧四：数据预处理下推——把IO瓶颈从CPU手里抢回来

第四个技巧关注的是一个经常被忽视的隐藏瓶颈：数据预处理。在算法市场里，模型是给不同业务方复用的，输入数据形态五花八门，预处理逻辑往往非常重。这块做不好，CPU经常跑满，GPU却在旁边闲着。

5.1 预处理到底吃了多少性能

举一个OCR模型的例子。输入是图片，预处理包括图像解码、尺寸缩放、色彩空间转换、归一化、文本检测框切图、扭曲矫正。这一套预处理在CPU上用Python PIL或OpenCV跑，平均一张图要花60到80毫秒，而模型推理本身（切图后并行推理）只需要40毫秒。也就是说，预处理比推理还慢。

很多团队容易忽略这个点，因为本地开发时数据已经处理好了，根本测不出真实耗时。只有上了算法市场、面对真实多样的业务方输入时，问题才彻底暴露出来。

5.2 怎么"下推"：把预处理挪进推理管线

核心思路是：不要让CPU单独串行做预处理，而是把预处理尽量放到与模型推理同一张GPU卡上执行，或者放到同一进程内的高效实现里。

具体手段有三个：

1. GPU图像解码：NVIDIA的DALI库可以基于GPU做图像解码和增强，吞吐比CPU上的OpenCV高好几倍。我们的OCR项目用DALI重构后，预处理环节从CPU 60毫秒压到了GPU上不到10毫秒，批处理场景收益更大。
2. 预处理算子合并：很多预处理步骤可以合成一个算子，减少Python层多次调用C扩展的切换开销。比如归一化、均值减法、通道重排，可以一次性用TensorRT的预处理层完成。
3. 预处理与模型打包：把预处理逻辑直接封装进模型本身。在ONNX Runtime里可以前置一个预处理算子，或者用CustomOp。这样做的好处是调用方不需要关心"该传什么格式"，市场内部统一接收原始数据即可。

5.3 为什么算法市场特别需要这个技巧

在单模型服务里，你还能靠"多几个CPU核"硬扛预处理。但算法市场里几十个模型同时运行，CPU资源是共享的。一个模型的预处理把CPU打满，会连累其他所有模型——这是完全不可接受的。

所以我在架构设计时定了一个原则：CPU资源是算法市场的公共资源，任何模型都不得长期占用超过设定阈值的CPU。

我们平台的做法是：默认要求所有模型走统一的"接入SDK"，SDK里对预处理做了两件事——一是尽量提供GPU实现，二是在CPU上限制线程数和并发度。前者是性能优化，后者是资源保护。两者一起做，才能保证"一个模型不拖垮整个市场"。

注意：预处理下推不是对所有模型都有效。如果你的模型很小（比如多层感知机），预处理也很轻（比如几个数值特征归一化），就别折腾GPU预处理器了，收益很低，复杂度反而增加。建议按模型QPS和预处理耗时占比来判断：只有预处理耗时占比超过30%，且QPS超过一定阈值的模型，才值得做。

6. 技巧五：弹性资源分配与冷热分层——别让所有模型挤在同一条车道上

第五个技巧要从平台级的视角看资源管理。算法市场里有大量模型，有的每天调用百万次，有的一周才被调几次。如果所有模型都常驻GPU，成本会爆炸；如果所有模型都按需加载，高QPS模型又会因为加载开销而延迟飙升。所以必须做冷热分层。

6.1 冷热模型的三层分类

我把算法市场里的模型按调用模式分成三类：

• 热模型：QPS持续大于某个阈值（比如平均QPS大于50）。需要常驻GPU，而且最好有多个副本做负载均衡。
• 温模型：调用有周期性，比如每天集中在某几个时段，或者每周有几次波峰。这类模型不能永久驻留，但要有较快的冷启动能力。
• 冷模型：极少被调用（比如周QPS小于5），主要给部分业务方做"备用能力"，或者只是挂在市场上展示。这类模型不能占用常驻资源。

6.2 平台落地：K8s与Serverless混合调度

我们在实践中用的是K8s加轻量级Serverless框架的混合方案：

• 热模型：部署为常驻Deployment，用HPA（水平Pod自动扩缩容）基于QPS、CPU、GPU指标扩缩容。GPU指标采集用DCGM，比单纯看CPU可靠得多。
• 温模型：部署为Serverless函数，但开了"保持存活"策略——比如最后一次调用后15分钟内不释放实例，减少重复冷启动的开销。
• 冷模型：部署为按需加载的Pod，调用时启动，用完即销毁。冷启动时间要求控制在可接受范围内（我们要求30秒内完成镜像拉取加模型加载），否则调用方会超时。

这里有个很关键的优化：模型镜像瘦身。有些模型镜像里装了训练环境、各种依赖，体积好几个GB，冷启动拉镜像就要一分钟。我们把模型推理镜像从训练镜像里剥离出来，只装推理运行时，体积从3GB压到了400MB，冷启动时间从50秒降到了8秒。8秒的冷启动虽然还是不能用于实时场景，但冷模型已经够用了。

6.3 预测式扩缩容：应对"已知的未知"流量

算法市场里有个很有意思的场景：月初对账模型、月末报表模型、大促活动日的类目识别模型——这些模型的调用量有明确周期，但不是实时可预测的。

我们做了一个简单的预测式扩缩容：基于过去30天的调用历史，用"每周同一天同一小时的平均QPS"作为预测值，对未来15分钟的资源需求做预估，提前扩容。效果非常明显——某个活动场景的类目识别模型，在高峰期提前扩容后，P99从450毫秒降到了120毫秒。

这个功能不需要做得很复杂，先从一个简单的"周期模板"开始：

• 统计每个模型过去N周的QPS曲线模板；
• 预测未来15分钟的QPS等于模板值乘以系数（系数按当天实际流量手动微调）；
• 如果预测值超过当前容量，提前扩容。

弹性调度最大的坑是扩缩容振荡——指标一高就扩容，一低就缩容，导致Pod频繁被拉起和销毁。解决方案是给扩缩容加"冷却时间"，比如扩容后至少保持10分钟，缩容前至少观察15分钟。在K8s HPA里可以配置稳定窗口（stabilization window），别偷懒省这一步。

7. 技巧六：线上性能监控与劣化自动回滚——算法市场不能靠人肉盯

最后一个技巧，也是最容易被低估的：性能监控体系。模型上了算法市场之后，性能不是一直不变的，劣化是常态。如果没有有效的监控和自动回滚机制，出了问题只能靠业务方先发现、再反馈、然后平台方三班倒地排查。

7.1 模型性能劣化的三种典型原因

1. 数据漂移：业务方传过来的输入数据分布变了。比如一个模型本来是识别自然场景图片的，业务方后来传了大量截图，模型输出质量明显下降。
2. 上游依赖变慢：模型推理依赖的特征服务、数据库、外部API变慢了，导致整体调用延迟上升。
3. 代码或环境变更：平台版本升级、依赖库更新、GPU驱动变更，都可能让某个模型的性能发生退步。

这三种原因都不是模型代码本身"坏了"，而是环境或数据变了。如果不监控，你根本不知道是哪一天、因为什么变化导致的。

7.2 指标设计：三层指标体系

我设计了三个层次的监控指标，缺一不可：

• 业务性能指标：延迟分位数（P50/P95/P99）、错误率（5xx、超时、空结果）、缓存命中率。按模型维度、调用方维度、版本维度分别聚合。
• 资源性能指标：GPU利用率、显存使用量、CPU使用率、内存使用量、GPU降频事件。资源指标是"先兆"——GPU利用率异常升高往往是流量异常或性能劣化的前奏。
• 数据质量指标：输入长度分布、输入图片分辨率分布、模型输出类别的比例分布。输出类别分布是经常被忽略的，比如原本"正向/负向"比例是6比4，某天突然变成9比1，说明输入数据分布大概率变了。

7.3 自动回滚机制怎么设计

监控发现问题还不够，必须能自动止损。我们的算法市场里做了这样一套自动回滚机制：

• 每个模型上线前，记录一个"性能基线"——也就是技巧一里的延迟画像，再加上一个错误率基线。
• 基线不是固定的，而是移动窗口基线：取过去7天的P99和错误率中位数作为"正常值"，当天的指标如果连续5分钟超出正常值的1.5倍，就触发告警。
• 告警之后进入判断：如果错误率超过红线（比如5%），自动切回上一个稳定版本，并给模型负责人发通知。如果只是延迟升高但请求成功率高，先不自动回滚，只告警等人工确认——因为延迟升高可能只是流量突增，回滚反而会中断服务。

自动回滚的阈值不是拍脑袋定的，建议按模型重要性分级。核心交易链路相关的模型，阈值收紧；普通分类模型，阈值放宽。

7.4 监控可视化：从指标看板到"性能时间线"

很多监控看板就是一堆曲线堆在一起，看着累还没法定位。我推荐做一个"模型性能时间线"视图：横轴是时间，纵轴叠加版本变化、发布事件、扩缩容事件、指标变化曲线。

这样当一个指标异常时，你能在同一屏上看到"哦，昨天上了新版本P99就开始涨了"，或者"今天凌晨扩容了一次，延迟反而降了"。版本和事件关联是定位根因的最快路径。

我们内部用Prometheus加Grafana搭了这套体系，Grafana里做了一个"模型详情页"，把分位数曲线、版本时间线、资源水位、调用方维度都放进去。这个页面现在是算法市场运营同学每天上班第一个打开的页面。

8. 上线之后回头看：几个让我印象深刻的踩坑瞬间

讲完6个技巧，最后分享几个我们在算法市场上线初期踩过的坑。这些经验有时候比技巧本身更值钱。

8.1 坑一：平均延迟达标了，业务方还是说卡

这个坑我在技巧一里提过：只盯平均延迟，结果P99严重超标。但这里补充一个细节：很多团队的压测环境里根本测不出P99毛刺，因为压测工具发请求的模式太规整了。真实业务里请求大小分布极不均匀，有的文本只有几个字，有的文本几万字，大请求会拖慢所有请求的排队。所以压测数据必须模仿真实的输入分布，不能只发规格统一的请求。

8.2 坑二：量化模型"精度没降"，上线后效果却变了

起初我们的图像分类模型做INT8量化，离线评测准确率只从92.5%掉到92.1%，觉得完全可接受，就直接上了市场。结果业务方反馈说"效果明显变差"。排查后发现，问题不在模型本身，而在预处理不一致——训练时的图像缩放算法是双线性插值，量化版推理时在TensorRT上用了默认的最近邻插值，导致部分输入图片的细节发生了变化。这种隐藏的不一致在算法市场上很有迷惑性，接口都一样，但送到模型里的数据已经不是同一份了。

经验是：任何版本（量化、蒸馏、剪枝）发布前，不但要比精度，还要比中间结果——把同样的输入丢进FP32版和INT8版，比对模型第一个卷积层的输出分布，分布偏移大的坚决不能上线。

8.3 坑三：缓存导致"新鲜度"事故

我们曾在一个舆情分析模型上开了缓存，TTL设了30分钟。结果有次突发舆情事件，半小时内的新信息全被旧缓存覆盖，业务方拿到的结果和实时内容完全对不上。那次之后，我们把所有时效敏感模型的默认缓存策略改成了no_cache，只有调用方主动申请才开缓存。

教训是：缓存开关的默认值应该是"保守"的，而不是"激进"的。算法市场上面对的是多样化的业务场景，平台方不能替调用方决定"这份数据多久不变"。

8.4 坑四：响应式扩缩容根本来不及

最早的资源调度是装了开源的指标采集器，QPS涨上来再扩容，但GPU Pod拉起加模型加载需要好几分钟。等扩容完成，流量高峰已经过去了，业务方早就经历了延迟飙升的痛苦。这也是我们后来做预测式扩缩容的直接原因。

算法市场的流量不是随机的，是有模式和周期的。提前预测永远比事后响应靠谱。

8.5 给首次建设算法市场的同学一句实在话

如果你是第一次做算法市场，我的建议是别一上来就铺开做十几个技巧。先从这6个里面挑最贴合你现状的几个做起，并且随业务演进不断迭代你的性能基线和容量规划。模型性能优化在算法市场里永远没有"结束"的一天——业务方在变、数据在变、模型在变、流量在变，性能优化的价值就在于你跟得上这些变化。我自己踩过的坑，希望你看完之后能少走几步弯路。