随着 AI 应用从单点验证走向更多业务场景,企业对模型服务的要求也在变化:模型不仅要能够运行,还需要被统一交付、集中治理,并在真实负载下持续验证性能。

从 SmartX 医疗、金融等行业用户的建设实践来看,企业 AI 平台通常会经历模型运行、统一管理、模型治理和性能验证等阶段。不同企业的建设节奏并不相同,但平台能力往往随着应用范围扩大而逐步完善。

一、模型运行:从单个场景开始验证

在 AI 应用建设初期,企业通常围绕一个具体业务场景部署模型,例如知识库问答、文档处理、报告生成、OCR、语音识别或影像分析。这一阶段的重点,是先验证模型能否部署、应用能否调用,以及模型是否能够支持业务场景。模型服务可能由基础架构团队、应用团队或外部服务商分别建设,平台形态相对分散。

二、统一管理:从单个模型走向算力与模型协同

当企业内部同时运行多类模型,平台需要管理的就不再只是某一个模型服务,还包括模型文件、GPU 资源、运行环境和交付方式。这一阶段的核心,是将算力资源和模型资源纳入统一的管理体系,使大模型、小模型以及传统机器学习模型能够根据各自的负载特点获得合适的运行资源。

以 SmarX 某三甲医院客户的实践为例,其同时存在两类需求:一类是面向大语言模型的统一部署和调用,模型规模覆盖 27B 到百 B 级参数量;另一类面向科研、影像识别等场景,使用传统机器学习和图像识别小模型,更关注算力资源本身的按需交付。因此,用户希望在统一平台上同时管理模型资源和算力资源,既支撑大参数模型运行,也满足小模型的灵活部署。

三、模型治理:从统一交付走向可视、可控和可追溯

当模型服务开始被多个团队和业务系统调用,企业需要进一步了解模型资源如何被使用,并对访问权限、调用边界和服务过程进行管理。这一阶段,模型平台需要从单纯提供调用接口,扩展到模型接入、请求路由、用量统计、配额控制和访问审计等环节。对于金融等对安全和合规要求较高的行业,治理还需要逐步覆盖调用前、调用中和调用后的相关流程。

SmartX 金融行业用户的实践体现了多种模型交付方式并存时的治理需求。某证券机构同时采用标准模型统一部署和非标准模型资源交付两种方式,基础架构团队关注 AI 网关能力,包括用量统计、模型降级、负载均衡和智能路由等。其中,用量统计的重点是了解不同模型、团队和应用的资源消耗,为预算、扩容和资源分配提供依据。

此外,另一家资管机构则更关注模型服务的安全审计和精细化管控。该机构的 AI 场景主要围绕投研和文档处理展开,当前关注敏感词、文件内容和高风险输入输出的审核与拦截,以及智能体 Skills 的安全扫描、高危操作识别和按团队授权。

四、模型性能:从模型可用走向效果可验证

当 AI 应用进一步走向生产,企业关注的重点会从“模型能否部署”转向“模型服务能否在真实负载下稳定运行”。这一阶段,平台需要帮助用户持续观察 GPU、容器、推理实例和调用链路的运行状态,并在明确硬件、模型、推理框架和测试负载的基础上,验证高并发、长上下文等场景下的服务表现。

以 SmartX 某金融用户实践为例,该用户已经具备多台 H20 GPU 服务器,并在投研和智能体应用中关注算力管理、模型管理和 Kubernetes 等平台能力。在实际验证中,用户重点关注大模型在高并发、长上下文场景下的运行效果,包括 TTFT(首 Token 延迟)和 TPOT(每 Token 生成时间)等指标。

榫卯 AI 平台:覆盖从模型部署到统一治理的建设需求

上述实践表明,企业 AI 平台建设往往从模型部署开始,随后逐步扩展到算力与模型管理、模型调用治理和性能验证。平台能力如果能够与企业所处阶段相匹配,就可以支持用户在验证、交付和生产运行之间持续推进。

榫卯 AI 平台围绕模型服务这一核心场景,分别从模型交付、算力与模型统一管理、模型网关治理和服务观测等方面,为企业逐步完善 AI 基础设施提供支持。

从模型运行到标准化交付

在模型建设初期,用户首先需要缩短模型部署和上线过程,降低不同模型、不同运行环境带来的交付复杂度。

针对这一需求,榫卯 AI 平台提供模型目录、标准化模型模板和可组合的推理引擎,帮助用户以相对统一的方式部署模型服务。结合独立部署、物理机 Kubernetes 或虚拟机 Kubernetes 等部署形态,企业可以根据模型规模、并发需求和现有基础设施条件选择运行方式。>>了解更多

从单一资源到算力与模型统一管理

当企业同时运行大模型和小模型时,平台需要根据模型特征和业务负载分配算力,而不是采用单一的资源交付方式。

榫卯 AI 平台支持对不同类型的 GPU 资源进行统一管理。对于性能要求较高的大模型,可以使用 GPU 直通运行整卡资源;对于 OCR、语音、Embedding、Rerank 等轻量模型,则可以使用 GPU 虚拟化能力,对显存和算力资源进行切分,让多个模型实例共享 GPU。平台同时支持统一管理模型文件和模型服务,帮助用户将算力、模型和运行环境纳入同一套交付体系。>>了解更多

从模型调用到模型网关治理

当模型服务被多个团队和应用调用后,企业需要知道资源消耗情况,并控制不同业务对模型服务的访问范围和使用额度。

针对 AI 网关和模型治理需求,榫卯 AI 平台在模型接入、路由和密钥管理的基础上,提供用量统计、配额管理、访问控制和访问日志等能力。管理员可以按 API Key 和模型等维度查看 Token 用量及请求情况,也可以设置 Token 配额、请求限速、并发上限和可访问模型范围。

对于问题定位和安全审计,平台可记录访问来源、调用模型、请求状态、Token 消耗、吞吐和耗时等信息,为资源规划、调用分析和审计追溯提供基础。

观看视频,了解更多功能特性

从模型性能到性能观测与验证

当模型服务进入高并发、长上下文等生产场景,用户需要将模型性能与 GPU、容器、推理服务和调用链路联系起来分析。

榫卯 AI 平台可协同容器存储网络和安全等基础设施能力,形成从 GPU 硬件状态、容器运行状态,到推理实例健康度、模型资源消耗和调用链路延迟的观测基础。这些能力有助于用户了解模型服务的运行状态,并在不同硬件、推理框架和测试负载下建立统一的性能验证条件。

AI 平台建设,从“部署模型”走向“模型治理”

AI 应用的持续落地,最终会将模型服务纳入企业基础设施的日常运行体系。榫卯 AI 平台通过统一管理算力与模型,并提供模型网关和服务观测能力,帮助企业在保障运行稳定性的基础上,持续推进模型服务的交付、治理和优化。

点击获取《构建 Agent Ready 的企业云基础设施》白皮书。

推荐阅读:

榫卯AI平台1.1:增强GPU虚拟化与模型治理能力,让资源使用和模型管理更高效

SmartX 榫卯 AI 平台企业版正式发布:助力企业构建简单、灵活、开放的 AI 基础设施

AI 模型从部署到上线:击破这 5 大挑战,效率将翻倍!

AI知识科普丨ModelOps / MLOps / LLMOps 有什么区别?

继续阅读