很多人觉得，AI模型搭建就是把预训练模型下载下来，跑通推理就算完成任务。其实不是，从需求梳理，到模型选型，环境准备，微调训练，验证优化，再到部署上线，整个链路都属于AI模型搭建的范围。很多刚接触的开发者，对AI模型搭建的范围理解常有偏差，常常只看重中间模型跑通这一步，忽略前后环节的准备和校验，最后就容易出各种本来可以避免的问题。
需求匹配先于参数选型
我接触过好几个小团队做AI模型搭建，第一个常见错误就是上来挑参数最大的模型，觉得参数越大效果越好，完全不考虑自己的实际需求。比如有个团队要做内部知识库的问答，总共只有不到两万份内部文档，日常并发最多也就同时十几个人用，业务要求单请求响应延迟不能超过两秒。结果他们一开始选了一个超大参数的开源模型，光是模型加载就占了全部四张显卡的显存，推理一次平均要八秒，远超过需求要求的延迟上限，根本没法用。
后来重新梳理需求调整方案，换了小一半参数的模型，再做了量化压缩，不仅只用两张卡就放下，推理延迟还降到了一点五秒，完全满足业务需求，还省了一半的硬件成本。
从实际经验来看，做AI模型搭建之前，先把三个核心问题整理清楚写下来，比急着选模型下载要稳妥得多。第一，最终输出要满足什么硬性指标，比如准确率不能低于多少，单请求响应不能超过多少秒，可用性要求到什么程度；第二，可使用的硬件资源上限是多少，总共有多少显存，多少内存，多少存储空间，这些都是不能突破的边界；第三，需求的定制化程度有多高，是不是必须调整模型结构或者重新训练才能满足要求。把这三个问题理清楚，再对应选合适的模型，能避免很多不必要的浪费。
资源预留不能大意
做AI模型搭建的时候，很多人计算资源需求的方法是错的。比如要跑一个模型，大家都会先算模型本身参数占多少显存，比如半精度的7B参数模型，大概占13G左右的显存，很多人就正好选16G显存的显卡，觉得还剩3G的富余足够用，结果一启动跑任务就报显存不足的错误。我自己第一次做AI模型搭建的时候也踩过这个坑，折腾了半天才想明白，模型本身参数占的显存只是总需求的一部分，推理框架本身、输入数据的预处理、运行过程中的临时缓存，这些都需要占用显存空间。不同的深度学习框架占用的预留空间不一样，一般最少也要留1到2G的预留空间，如果要做批量推理或者微调训练，预留的空间还要更多。
除了显存，存储的IO性能也很容易被忽略。很多大模型解压之后有几十上百G，如果用普通的SATA机械盘存放，加载一次模型就要十几分钟，开发调试阶段，每次改一点配置就要重启服务，光等待就要花掉很多时间，非常影响开发效率。哪怕是上线之后，要是遇到服务异常需要重启，过长的启动时间也会拉长故障恢复的窗口，影响业务的整体可用性。
还有内存资源，做AI模型搭建，不管是训练还是推理，数据从存储到显存之间都要经过内存做中转，如果内存空间不够，哪怕显存还有富余，也会出现卡顿甚至加载失败的问题。这个点很多新手开发者都会忘记，我之前就遇到过一个案例，模型加载到一半就卡住不动，排查了大半天显存占用是正常的，最后才发现是内存空间不够，放不下解压后的临时模型文件，这个问题说小不小，排查起来还挺费时间。
验证不能只看测试集
很多人做完模型微调，在测试集上算出准确率达到了预期，就觉得AI模型搭建已经完成，可以直接上线了，其实这个认知也有偏差。测试集的数据一般都是提前整理好的，分布比较均匀，也很少有脏数据，和真实场景的实际输入差别很大。比如做客服问答模型，测试集里的问题都是用户输入的完整规范句子，没有错别字，也没有语义模糊的提问，但是真实场景里，用户的问题有很多不规范的地方，还有很多简短的口语化提问，这些都会影响模型的输出效果，只看测试集的准确率根本反映不了真实情况。
除了准确率，性能验证也很容易被忽略。很多人测试的时候只测单请求的响应时间，从来不测并发场景下的表现，结果上线之后，两三个用户同时使用就出现超时。我之前知道的一个内部项目，就是遇到了这个问题，开发测试阶段一切正常，第一次开放给内部使用，一下子来了二十多个并发请求，服务直接卡死，最后只能紧急回滚才恢复服务。后来排查原因发现，做AI模型搭建的时候，根本没开启框架的并发推理优化，框架默认是单线程处理请求，所以同一时间只能处理一个请求，并发请求一多就全部堵死了。
所以一般来说，上线之前最好模拟真实场景的峰值并发，跑几个小时的压力测试，看看平均延迟和错误率有没有超过预设的阈值，这个步骤一定不能省。除此之外，还要验证模型输出的稳定性，有些模型在大部分常见输入上效果都不错，但是遇到少量特殊输入就会输出异常结果，这种问题也要提前排查，不然上线之后容易出意想不到的问题。
另外还有一个常见的误区，就是做AI模型搭建微调的时候，觉得数据数量比数据质量重要，越多越好。很多人攒了几十万条收集来的数据，没做清洗和过滤就直接拿去训练，结果微调出来的模型准确率比不微调还低。这是因为数据里有很多错误标注，还有大量重复、无关的内容，模型学了很多无用的噪音，反而把原来预训练好的通用能力给破坏了。从实际的经验来看，先花足够的时间整理数据，去掉错误标注，去掉重复和无关内容，哪怕只有一两万条干净的标注数据，微调出来的效果也比几十万条脏数据好很多，这一点是很多人踩过坑之后总结出来的经验。
总的来说，很多普通开发者第一次接触AI模型搭建，容易把重点放在硬件性能和模型参数上，觉得堆够了参数和硬件就一定能做成。实际做下来就会发现，大部分影响可用性的问题，都来自前期的需求梳理和细节处理，把这些基础环节做扎实，比盲目堆硬件要有效得多。
