模型应用们否可以解决业务需求海量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

在经过了与业务方多次沟通和迭代后，模型的效果获得了大家的一致认可，我们的模型进入了生产

待命的状态，即将迎来曙光。不过需要注意的一点就是，我们的目标是业务需求，而数据挖掘产出的结

果，不管是预测型的还是关联型的，都要结合业务场景，融入业务流程中去。

模型部署

我们的业务形态不同，部署的方案也就不同。你的模型可能独立部署成服务运行，也可能嵌入到其他的

项目代码中去，但是都逃不脱一个本质，那就是回归业务。所以，在这个阶段，我们就要考虑具体的业

务场景了：模型如何保存？如何根据业务需求优化？以及如何最终上线服务？下面为大家详细解答。

模型的保存

在有了优秀的模型，首先就是要把它保存好，以方便应用。我们要给它定义一个好的名字，甚至需

要一个详细的文档来记录模型所使用的算法、训练数据、评估结果等信息。因为在整个过程中会进

行很多次训练，产生很多的模型，或者要把很多的模型组合在生产中使用，同时还需要跟后面的重新训

练进行效果的对比，有时候模型的训练和部署可能由不同的人来实施，如果保存时没有注意到这些问

题，很有可能导致出现的情况。

所以我们要制定好模型保存的规范，包括存放的位置、名字的定义、模型所使用的算法、参数、数据、

效果等内容，防止发生比如遗忘、丢删除，甚至是服务器崩坏等人为的事故，造成不必要的损

失。

模型的优化

在模型训练阶段已经讲了一部分模型优化或者说提升效果的方法，为什么这里又出现了模型的优化呢？

这主要是因为在模型部署应用阶段的很多限制条件在模型训练阶段并不会显现出来，模型训练阶段优化

所追求的目标是效果要尽量好；而在模型应用阶段优化所追求的目标是在效果尽量不降低的前提下，适

配应用的限制。

比如，在对时延要求比较高的场景下，如果业务应用受模型的响应时间，那么我们就需要想办法

解决，是增加机器还是降低模型的复杂度以提高速度；还有，在对模型大小要求比较高的场景下，我们

期望把人脸识别模型部署到一个装置的小型上面，那么模型的大小就会受到限制，需要考

虑降低模型的参数维度等。

离线应用还是应用？

想想我们的业务需求，如果是要使用分类的类别结果，实时分发到用户App中，那我们的分

类模型就需要部署成的应用服务以实时响应新的内容请求。如果我们只是需要对一批已有的数

这里我主要来说一下应用。随着算力和业务需求的不断提升，~在~公司里有越来越多的服务需

要数据挖掘模型的支撑。这里我画了一幅可能的服务架构：

在通常的业务中，有很多客户端在发起请求，我们要在不同的服务器或者Docker中部署多个环境及模

型，然后使用Web框架和HTTP服务响应请求，当然中间还有一层负载均衡去处理请求负载转发，以

平均服务器的。

一个方案

通常算法工程师或者数据挖掘工程师都忙于解决模型问题，到了模型部署阶段就头疼不已，尤其是需要

大规模并行的线上服务，可能会耗费很多时间。我在这里介绍一个简单的部署方案，希望能够为大家节

约一点时间。

FlaskWeb框架：在日常的任务中可以使用Flask作为构建我们的Web服务框架，它是用Python来

实现的。

Gunicorn

HTTP服务：可以理解成HTTP服务器，需要注意的是Gunicorn只能运行在Linux服务器

上面。

Nginx负载均衡：Nginx是一个功能很强大的Web服务项目，它可以用作负载均衡器，很多大公司都

在使用。负载均衡用于通过集群中的多个服务器或实例将工作负载进行分布，目的是避免任何单一资源

发生过载，进而将响应时间最小化、程序吞吐量最大化。在上图中，负载均衡器是面向客户端的实体，

会把来自客户端的所有请求分配到集群中的多台服务器上。

客户端：业务的具体场景，可能是App，也可能是其他服务器应用，客户端会向托管用于模型预测

的架构服务器发送请求。比如今日头条App页面下拉，将会调用推荐算法模型进行推荐内容的计算。

当然，这里的方案并不是唯一的，在实际的工作中也有很多其他的工具具备同样的功能，可以根据自己

环境和需求灵活选用。如果是在一些大公司，这些环节可能甚至不需要你考虑，