企业要上 AI，先别谈自研算法：把大模型能力封装成自己的 API 服务
企业上 AI 的大多数场景用不到自研算法，缺的是把第三方模型封装成自己的 API 服务那段工程：统一抽象、异步队列、多端复用，以及「定制还是买 SaaS」的三个判断标准。
文中客户一律用描述性别名，不出现客户名称。
不少企业负责人决定「上 AI」之后，第一反应是找人谈自研算法。我们会先反问一个问题：你要的是算法，还是一个能被你的产品、你的员工稳定调用的能力？这个问题决定后面完全不同的两条路。我们的经验来自后者——我们给一个内容类产品做过一套模型服务：图生文、图生视频、音乐生成、提示词扩写，四类能力封装成一套 API，iOS、H5、Java 三端都在调用它，产品最终在 App Store 美国区在架。这篇文章拆的就是这套服务的结构，以及「定制还是买 SaaS」怎么判断。
一、先想清楚：你要调模型，不是造模型
先划清边界：企业 AI 落地的大多数场景，用不到自研算法。大模型能力市场上已经存在，缺的是把「别人的模型」变成「你自己的服务」的那一段工程——统一接口、稳定调用、异步排队、多端复用。我们做过的几类 AI 应用，多模态模型服务化、AI 创作工作台、对话与识别入口，本质上都在做这一段。
把这段工程做好的价值在于：模型厂商可以换，你的业务接口不用变。今天用 A 家的多模态模型，明天换 B 家，前端和业务系统照常工作。这是「封装」两个字的实际含义。
二、一套真实的服务结构长什么样
拿我们那套服务举例。它是基于 FastAPI 搭的 Python 服务，按能力拆成多个接口模块：图生文接口、图生视频接口、音乐生成接口、提示词扩写接口，各自独立成文件。图生文底层接的是通义千问 VL 多模态模型，工程里有专门的封装类；提示词扩写接的是 DeepSeek，配置里能看到它的对话补全接口地址。
这套结构里最值得说的是两件事：
第一，统一抽象。 不同厂商的模型，参数格式、返回结构、错误方式都不一样。封装层把它们归一到自己的接口定义里，路由前缀、标签、请求体都按自己的规范来。前端永远只面对一套 API，不知道也不需要知道背后是哪家模型。
第二，异步队列。 图生视频、音乐生成这类任务，跑起来不是毫秒级的，请求必须排队。这套服务里配了 RabbitMQ 做异步任务队列：接口接收请求后入队，任务完成后再取结果。没有这一层，高并发时服务会被长任务拖死；有了这一层，慢任务和快任务互不影响。
同一套服务同时供 iOS 端、H5 端和 Java 后端调用，三端不用各自对接模型厂商。这是我们判断「服务化做没做对」的标准之一：新增一个调用端，应该是加一个客户端，而不是重做一遍集成。
三、同一段经验，换个行业照样成立
这套「把模型能力封装成服务」的打法不只用在内容生成。我们还做过能源设备方向的能效监测、故障预警、设备知识库，其中知识库那一块，同样是把 AI 能力包成业务系统可调用的服务，而不是做一个孤立的 AI 演示页。区别只在业务对象，结构是同一套。
四、定制还是买 SaaS：三个判断标准
不是所有场景都需要自建服务。给一个实用的判断框架：
- 看调用方数量。 只有一个内部页面偶尔用用，直接买 SaaS 或按次调云服务，成本最低；要是多个产品、多个端都要用同一批能力，封装成自己的 API 服务才开始划算——对接一次，处处复用。
- 看要不要沉淀。 提示词模板、模型组合方式、队列与重试策略、调用日志与计费口径，这些东西沉淀下来就是你自己的 AI 中间层；SaaS 里它们都在别人手上，换供应商就归零。
- 看业务耦合深度。 AI 能力只是「点个按钮出结果」，SaaS 够用；要是 AI 输出要进你的业务流程——进订单、进作品库、进审核链——就需要按自己的数据模型来封装，这是定制发挥的地方。
一句话：轻场景买 SaaS，重场景做封装。判断错了方向，两头都会浪费——该买的做了定制，该建的只买了账号。
写在最后
企业上 AI，第一步不是选模型，是画出「能力要从哪些地方被调用」的图。调用方清楚了，接口层、队列层、模型层的边界自然就出来了。我们交付这类项目时，服务源码、部署说明是完整移交的——这套封装能力应该长在客户自己的系统里，而不是锁在服务商手上。
如果你的团队正在评估 AI 落地方案，可以先拿这套结构对照一下现状，聊聊哪里补、哪里建。