使用指南2026 年 11 月 9 日

如何接入企业自有的模型和算力

接入企业自有的模型和算力，先要分清三件事：模型服务治理、推理运行时、算力资源。这是三层不同的责任，混成一个「本地部署」最容易把账算错。分清了，才知道自己缺的是哪一层、该买什么、该谁来维护。

以下说明的是三层的职责与边界，不代表任何特定模型、运行时或硬件已经在某个环境完成部署。具体可用能力以当前模型目录、测试结果与项目验收为准。

01 先分清三层：MaaS 管治理，运行时管执行，算力管资源

把三层混成一件「本地部署」，是这类项目最常见的成本误判来源。三层可以组合，但职责、采购边界、验收方法和运行责任各不相同。

这张表只说明职责划分。三层都不是「第四个服务要素」，算力位于平台下方，提供运行条件，不属于平台本体。

MaaS 的价值不等于部署一个模型，它解决的是多个模型如何被组织、选择、替换、审计和持续运营。只跑一个模型、只服务一个应用时，这套治理看起来是多余的；一旦出现第二个模型或第二个业务，缺它就很难管。

模型目录需要记录的是能力类型、适用任务、上下文限制、多模态输入、输出形式、质量基线、响应特征、授权范围、版本和有效状态。调用策略按任务风险、质量要求、时延、资源消耗和数据边界来选模型，而不是让所有应用绑定同一个模型。

这里有一条常被忽略的边界：没有完成接入、评测和授权的模型，只能列为候选，不能表述为已经可用的能力。外部模型、托管模型和本地模型都可以进入统一治理，但三者的接入方式、数据边界和责任分工必须分别写清。

推理运行时决定模型跑得稳不稳、快不快，但它本身不提供治理能力。一个运行时可以支撑 MaaS 中的本地模型，MaaS 也可以治理外部服务提供的模型，两者不是同义词。

选型要评估的是模型格式、硬件适配、并发模式、上下文长度、精度要求、启动时间、资源占用、监控能力和故障恢复。这些项目里没有一项能靠理论吞吐量回答，必须用真实任务的样本跑一遍。

升级运行时也要按变更管理来做：与模型版本、驱动环境、回归测试联动，升级前保存可回退版本，升级后复测关键任务、资源占用、错误率和输出一致性。运行时异常属于执行层问题，上层应能识别到不可用状态并切换备用模型，或者返回明确的降级结果。

并不是所有企业都需要建设本地的算力资源层，轻量问答、验证阶段和调用外部托管模型的场景可以不建。只有本地模型推理、离线环境、高频多模态任务、统一资源治理或数据不出域这几类条件成立时，才需要专门建设或接入。

方案里应根据数据边界、任务负载、峰值并发、模型规模和运维能力来判断，不要虚构硬件清单，也不要把资源数量当成平台能力的成熟度。已有算力卡的企业还要先确认卡型与目标模型的适配情况，这一项决定的是「能不能跑」，而不是「跑得好不好」。

三类验收不能相互替代：算力验收看资源可用、隔离、配额、监测、调度和故障恢复；模型服务验收看接入、路由、评测、权限和回退；智能体验收看任务完成、工具调用、证据、人工责任和业务结果。

判断顺序应该是：先看调用需求和数据边界，再看要不要本地模型，最后才看要不要自己出算力。顺序反了，通常会先买硬件、再找用途。

这张表只给判断方向，不构成任何环境已具备能力的说明。硬件规格、部署方式与运维责任需要结合企业实际环境另行确认。

公司已经买了算力卡一直闲置，能直接用来跑模型吗？可以，但要先确认三件事：卡型与目标模型的格式是否适配、需要哪种推理运行时、由谁负责驱动升级与故障处置。这三项没确认之前，不建议按「买了卡就能跑」来安排计划。

把模型部署到自己服务器上，数据就安全了吗？本地部署不等于完全安全，外部调用也不等于一定不合规。判断依据是数据分类、传输范围、访问控制、保留期限、审计和实际合同责任，不是部署位置本身。

自建模型的效果会不会比外部大模型差？取决于参数规模、任务类型和数据准备情况，不能只看模型大小。建议用真实任务样本做一轮对比评测，再按任务风险决定哪些走本地、哪些走外部。