“自研还是采购”经常被误解成二选一：要么自己训练模型，要么把全部能力交给供应商。真实系统通常位于中间地带。团队可能采购基础模型 API，自建检索与权限；也可能部署开放权重模型，同时采购托管推理和监控。
AI21 只是一个观察窗口。其 2026 年公开资料同时提供 Jamba2 开放模型、开发平台和编排系统，恰好说明模型、运行环境与业务系统是不同层，应该分别决策。
## 先问什么必须形成差异
如果价值来自独有工作流、私有数据和业务判断，团队应把这些层掌握在自己手中。通用语言生成、向量检索或基础推理未必值得重复建设。
列出系统中真正影响客户结果的五个步骤。对每一步问：外部服务是否已达到质量门槛，内部数据是否能安全接入，切换供应商是否会破坏业务逻辑。
自研不是“代码由自己写”，而是承担路线、质量、运行和更新责任。采购也不是“什么都不做”，仍需评测、集成、权限和故障处置。
## 把选择拆成四层
第一层是模型：闭源 API、开放权重或专用小模型。第二层是推理：供应商托管、云市场、私有 VPC 或本地设备。第三层是系统：检索、工具调用、验证和人工复核。第四层是产品：界面、业务规则与用户反馈。
四层可以不同组合。把它们捆成一个总问题，会让团队因为某一层不满意而推翻整套架构。
AI21 当前文档把开放的 Jamba 模型、云端访问和企业部署并列呈现。评估时应以实际版本和合同为准，不能把厂商博客中的性能描述当成自己的生产结果。
## 先做任务级评测
不要从综合排行榜选模型。收集一百到五百个真实任务，覆盖常见、困难、长尾和失败代价高的情况。为每项定义可自动或人工判断的通过条件。
检索问答要检查引用是否支持结论；结构化抽取要检查字段与类型；工具调用要检查参数、权限和副作用。生成风格只是其中一项。
候选方案使用相同提示、上下文、输出限制和数据版本。至少重复运行几次，观察方差。模型一次表现好，不代表在长流程里稳定。
## 总拥有成本不等于调用单价
采购成本包括输入输出 token、检索、存储、网络、限流冗余、支持与最低消费。自建成本包括 GPU、空闲容量、模型加载、监控、升级、安全补丁和团队时间。
建立三种负载：日常、峰值和增长后。对每种计算每个成功任务成本，而不是每次调用成本。若便宜模型导致更多重试或人工返工，实际成本可能更高。
还要计入机会成本。六个月后才上线的自研系统，可能错过验证需求的窗口；但长期被高额调用费和封闭格式锁定，也会压缩改进空间。
## 数据边界决定部署形态
先给数据分级，再决定能否发送到外部服务。敏感原文可以在本地检索，只把最小必要片段交给模型；极高敏感场景可能要求整个推理链在受控环境中运行。
确认日志保存、训练使用、删除时间、区域和子处理服务。技术团队要用实际请求追踪验证配置，而不是只阅读销售材料。
开放权重并不自动等于安全。模型文件、量化包、容器、依赖和下载来源都属于供应链，需要哈希、版本与漏洞管理。
## 自研能力要看值班表
能把模型跑起来，不等于能长期运营。列出模型升级、性能回归、容量、故障、数据更新和安全事件分别由谁负责。若关键问题只能等一位研究员上线，系统并未准备好生产。
采购方案也要问同样的问题：服务故障由谁响应，状态页与支持时限是否匹配业务，能否获得请求级诊断，版本是否会自动切换。
给每个依赖设定降级路径，例如切换备用模型、退回搜索结果或转人工，而不是让整个产品随单一接口中断。
## 退出成本必须在签约前测试
用一个备用模型跑同一评测集，确认提示和工具协议是否可迁移。把供应商专有字段隔离在适配层，业务代码只依赖内部统一接口。
定期导出知识库源文件、评测样本、配置和可携带日志。不要让重要资产只存在供应商控制台。
所谓多模型并不是每次都同时调用多个模型，而是保持替换能力。真正切换时仍要重新评测质量、延迟和费用。
## 一个六周决策实验
第一周定义任务、质量门槛与数据边界。第二周用采购 API 做基线。第三周部署一个开放权重候选，保持系统其他部分一致。
第四周加入真实峰值与故障注入，第五周让目标用户盲测，第六周计算成功任务成本、维护时间和迁移难度。每个结论都链接到原始日志。
最终可能得到混合方案：采购通用推理，自建检索、验证和权限；或自托管稳定高频任务，把复杂长尾交给外部模型。好决策不追求“全部拥有”或“完全省事”，而是把差异化能力、责任和成本放在合适的层。
## 参考资料