在生产环境中运行大型语言模型，已不再局限于训练、测试、部署模型以及监控仪表板。现代系统可能会将提示词、向量数据库和知识源连接起来，然后生成开放式文本；这些文本除了准确性之外，还要根据语气、安全性和可信度进行评估。正因如此，丹尼尔·布莱恩特在CNCF博客发表的一篇文章中提出了一个实际问题：谁应该拥有人工智能流水线？
作者认为，答案并不是为LLMOps划出一个独立王国，而是将其整合到组织良好的工程平台中，通过与开发团队处理其他工作负载时使用的相同接口，提供所需能力。
什么是LLMOps？
LLMOps指的是在大型语言模型整个生产生命周期中开发、部署和管理这些模型所需的一组实践、工具和工作流。该生命周期包括数据管理、提示词工程、微调、部署和推理服务、监控与评估，以及安全和治理。
根据这项分析，LLMOps并不只是对MLOps的重新命名。大型语言模型的微调和服务成本更高，而且其输出的评估也更加困难，无法将性能简化为一个明确的准确率数字。模型准确并不足够；它还应当安全且值得信赖，而这些特性的衡量更加复杂。
此外，模型运行并不会在首次部署时结束。模型可能偏离此前的行为，成本可能上升，提示词可能不再像以往那样正常工作，与客户关系管理系统或内部知识库的集成也需要持续跟进。
与平台工程交叉的生命周期
LLMOps生命周期从数据准备和提示词工程开始，其中提示词应被视为可版本化的资产，而不是临时文本；随后还包括使用Hugging Face Transformers等库对开放基础模型进行微调。该生命周期还包括模型和提示词的版本管理及其谱系追踪、通过由图形处理器支持的端点提供推理服务，以及依靠人工反馈进行监控，以发现偏移并跟踪成本。
生命周期的每个部分都需要基础设施、访问控制和运行环境，而这些领域本来就属于平台工程的范围。不过，作者区分了两个领域的性质：平台工程以基础设施为中心，而MLOps以模型为中心。因此，他认为有用的问题不是“谁拥有流水线？”，而是“谁拥有每一层，以及是否有某个主体真正负责协调这些层？”
创建平行技术栈的风险
该分析将软件交付格局划分为：可能淹没在部署请求中的DevOps团队；构建标准化自助服务路径的平台工程团队；以及由于DevOps工具并非为管理数据版本或监控偏移而设计、因此创建了平行技术栈的MLOps团队。随着LLMOps加入其中，还可能出现第三个独立技术栈，负责提示词、向量数据库和RAG流水线，并远离承担治理责任的主体。
作者将这种可能性与“隐性人工智能运维”问题联系起来。某个团队可能创建自己的RAG流水线，将其连接到未经审核的向量数据库，而负责方并不清楚实际运行的内容。根据该分析，最大的运营风险并不只是聊天机器人产生幻觉，而是这些能力扩散到平台之外，随后处于可见性和控制范围之外。
作者并不建议通过放慢团队速度来阻止这种情况，而是主张让平台能够快速满足需求，并将治理纳入使用路径本身。缺少现成路径可能会促使团队在平台之外构建能力；而提供标准路径则有助于将这些能力重新带回可管理的环境。
平台层中的LLMOps
布莱恩特借鉴了CNCF下属TAG App Delivery小组发布的平台白皮书构想。该构想将环境划分为三层：顶部是产品，中间是平台，作为合理的最薄集成层；底部则是能力提供方。
按照这一构想，可以将微调任务、向量数据库、提示词日志和推理端点等功能视为另一种平台能力。与其他能力一样，它们也需要API、版本和明确的所有权。作者指出，CNCF生态中的一些工具能够支持这种模式：Backstage在产品层展示标准路径，Crossplane在底层编排基础设施，而Kratix、KusionStack和KubeVela等框架则在中间层发挥作用，通过类似于其他服务的自助服务接口提供LLM流水线。
治理流水线的实际控制措施
该分析建议平台团队采用一组实际控制措施：
- 使用受治理的API，而不是非正式脚本：微调任务、提示词部署和推理端点应通过与其他开发者需求相同的自助服务接口提交。
- 在请求时实施策略：应在任务开始之前检查成本上限、数据驻留规则和模型访问控制，而不是等云服务账单出现后再检查。
- 与影响范围相称的人工审批：并非每个提示词都需要事先批准，但处理客户个人数据或做出自主决策的模型可能需要审批。
- 清晰的审计日志：日志应能够回答诸如“改变了什么以及为什么改变”等问题，无论变化涉及模型、提示词还是数据，还应记录谁批准了它，或批准了什么。
作者总结说，LLM流水线是平台能力的另一个自动化消费者，需要获得与人类开发者或自主代理相同的保障。在这种模式下取得成功的团队，不会在DevOps、平台和MLOps之间的争论中选择一方，而是将整个流水线视为一种可版本化、可监控且需要考虑成本的产品，并配备持续的反馈环路。
从这个意义上说，布莱恩特认为LLMOps并不会取消所有权问题，也不会重新发明这一问题；相反，由于模型规模更大、成本更高且更难评估，它使现有平台承受更大压力。在他看来，解决方案是一次性构建标准路径，然后通过共享API或用户界面，将其作为受治理的能力提供给开发者、数据科学家和智能代理。他指出，这场讨论仍在CNCF内部持续，尤其是在TAG App Delivery下属的Platforms Working Group中；该小组向希望参与讨论的人开放。