我坐在会议室最后一排，看着AI组那个比我晚来两年的同事在白板上画Kubeflow Pipeline，手心里开始出汗。不是因为空调开得太低，是因为我发现自己听不懂他在说什么。五年来我调过OpenStack、搭过K8s集群、做过云原生日志采集，自认是团队里最能扛基础设施的人。可那一刻，白板上的"ML Pipeline"、“Experiment Tracking”、"Model Registry"这些词像一堵墙，把我挡在外面。

会议结束后，我回到工位，打开内部Wiki搜了搜MLOps，跳出来的文档大多是AI组的人写的。他们说的不再是CPU、内存、磁盘，而是训练任务、模型版本、推理延迟。我看着自己维护的那套IaaS平台监控大屏，CPU利用率曲线平稳得像心电图，心里却一点都不平静。

一、玩了五年IaaS，突然发现自己不是最吃香的那个人

我在云计算平台组干了五年，从OpenStack虚拟机调度到K8s容器编排，再到Prometheus + Grafana监控体系，基础设施这摊事我门儿清。高峰期，我一个人能同时处理三个项目的资源扩容，半夜两点被告警电话叫醒，也能在十分钟内定位是Ceph存储池满了还是K8s某个节点CPU被抢占。

公司最早做传统SaaS，我们的云平台是给业务部门跑Web服务、跑微服务的。那时候我的工作很有存在感：上线一个新业务，我得算资源、分Namespace、配Ingress、调HPA。业务方喊我"老师"，因为我不光懂K8s，还懂怎么让他们的服务在双十一不崩。

但变化是悄无声息的。大概一年前，公司成立了独立的AI事业部，开始做自己的大模型应用。刚开始我没太在意，觉得他们不也是用我们的GPU集群吗？我们给机器、给网络、给存储，他们跑训练，各司其职。我甚至还有点优越感：AI再火，也得跑在基础设施上。

直到那次资源争抢事件。AI组提交了一个训练任务，要占用20张A100，跑三天。业务方的一个推荐服务当晚也要扩容，两者撞上了。我按老规矩，先保障线上业务，把AI训练任务往后排。结果第二天AI组的负责人直接找到我老板：

“你们云平台的人根本不理解训练任务的特性。模型训练不是Web服务，断一次就要从头跑，三天变六天。我们需要的是资源预留、队列调度、故障自动迁移，不是简单的先到先得。”

我老板没吭声，看了我一眼。那一瞬间我知道，自己那套"基础设施思维"在AI场景下不够用了。我们不是不懂调度，我们是不懂AI业务对调度的要求。而这种"不懂"，正在让我从核心岗位滑向边缘。

更让我难受的是，公司开始压缩云平台编制。HR的内部公告里，基础架构岗HC冻结，AI基础设施岗却在扩招。招聘JD上写着：熟悉Kubeflow/MLflow、有GPU集群调度经验、懂模型服务化部署。我一条都对不上。

二、转折点：一张被我自己否掉的架构图

真正让我决定转方向的，是一次内部技术评审会。AI组要做一个"模型服务平台"，让业务方可以像调用微服务一样调用大模型。我画了一版架构图：K8s Deployment + Service + HPA，和部署一个普通后端服务没什么两样。

评审会上，AI组一个年轻同事举手问：

“这个方案里，模型加载时间怎么算？QPS 100的时候，Pod冷启动要多久？如果一次推理要生成500 token，HPA按CPU扩能不能及时响应？”

我愣了一下。这些问题我不是没想过，但我的答案都是"按经验配"——配大点内存、把CPU阈值设低一点、预热一下。可对方要的是具体数字：vLLM的TTFT（Time To First Token）是多少？TPOT（Time Per Output Token）怎么压？KV Cache占多少显存？batch size对吞吐的影响曲线是什么？

我答不上来。那张架构图被否了。会后我把它从电脑里删了，坐在椅子上发了半小时呆。不是挫败感，是一种更强烈的焦虑：我熟悉的战场，规则已经变了。

那天晚上我没加班，也没打游戏，打开笔记本开始搜索"MLOps engineer 是什么"。看了十几个网页和两段视频之后，我意识到一件事：云计算工程师的底子，其实离MLOps并不远。分布式系统、资源调度、高可用、可观测性，这些正是MLOps平台最需要的底层能力。问题是，我之前一直站在最下面一层，没看见上面那层楼的风景。

我决定往上走一层。

三、从零开始补MLOps：不是学AI，是学AI怎么跑起来

我先做的第一件事，是把自己放到AI组的项目里当一个"旁听生"。不是正式转岗，是利用内部协作的机会，跟他们的训练任务、部署流程、问题排查。我厚着脸皮参加了三次他们的站会，第四次终于有人问我：“你不是云平台组的吗，来这儿干嘛？”

我说：“我想学学你们怎么把模型跑起来的。”

那人叫老周，是AI组的MLOps负责人。他看了我一眼，说：“你会K8s？”

我点头。

“那行，你先从Kubeflow Pipelines开始。别急着学模型训练，先把一个训练任务从数据准备到模型导出串成一条流水线。你懂CI/CD，这个不难理解。”

老周这句话点醒了我。我过去的误区是觉得转MLOps要先去学Transformer、去学PyTorch，其实不对。MLOps的核心是"让机器学习流程像软件工程一样可靠、可复现、可扩展"。我的CI/CD经验、K8s编排经验、监控告警经验，完全可以平移过来，只是对象从代码变成了模型。

我开始系统学习三个东西：Kubeflow、MLflow、模型服务化推理。

Kubeflow是Google开源的K8s机器学习工具集，里面最有用的是Kubeflow Pipelines（KFP）和Katib超参搜索。我用业余时间搭了一个最小化的Kubeflow环境，在一台单卡A100的机器上跑通了一个简单的图像分类训练Pipeline。它的组件包括数据预处理、模型训练、模型评估、模型保存。每个步骤都是一个Docker容器，通过KFP的DSL串起来。这让我恍然大悟：这不就是AI版的Jenkins Pipeline吗？

MLflow解决的是实验管理和模型版本管理。过去我管理代码版本用Git，但AI组的人还要管理数据集版本、模型参数、训练指标。MLflow Tracking可以记录每次实验的loss曲线、超参数、模型文件；MLflow Model Registry可以管理模型从Staging到Production的流转。我在本地起了一个MLflow server，把之前那个图像分类实验接进去，看着自己跑出来的十几个实验记录排在页面上，有种"原来他们是这样管理的"的感觉。

模型服务化推理是另一块硬骨头。我一开始以为用Flask包一个模型接口就行，后来发现生产环境用的是专门的推理服务框架：vLLM和TGI（Text Generation Inference）。vLLM通过PagedAttention优化KV Cache管理，能显著提升大模型推理的吞吐；TGI是HuggingFace出的，支持连续批处理（continuous batching）和模型分片。我用vLLM在A100上部署了一个7B参数的开源模型，测了一下延迟：单请求TTFT大约80ms，TPOT大约15ms，batch size=16的时候吞吐从单请求时的20 token/s提升到接近180 token/s。这些数字让我第一次对"推理优化"有了体感。

四、第一个实战：把大模型服务真正接到业务里

学了两个月后，机会来了。公司内部要做一个"智能客服助手"，需要把一个大模型部署成内部API，供客服系统调用。AI组的人忙着调模型，没空做服务化。老周在群里问：“有没有人愿意接部署这一摊？”

我私信他：“我来。”

这个任务不大，但对我来说意义重大。它要求我把模型从HuggingFace格式转成可服务的推理服务，还要对接公司内部的K8s平台、监控、日志、告警。

我做的第一件事是模型镜像构建。AI组给的是基于Llama架构的模型权重文件，我要把它和vLLM一起打包成一个Docker镜像。镜像里装了CUDA 12.1、PyTorch 2.1、vLLM 0.3.0，启动命令是：

python -m vllm.entrypoints.openai.api_server \
  --model /models/chat-model \
  --tensor-parallel-size 2 \
  --max-num-batched-tokens 4096 \
  --gpu-memory-utilization 0.85

--tensor-parallel-size 2 表示用两张A100做张量并行；--gpu-memory-utilization 0.85 是控制显存占用，预留一点给KV Cache和系统开销。

镜像构建完成后，我写了K8s Deployment和Service。这里有个关键决策：模型文件太大，有14GB，不能直接打进镜像。我把它挂在了一个共享的NFS存储上，通过PVC挂载到Pod里。这样既避免镜像臃肿，也方便多个模型版本切换。

然后是资源调度。客服系统的调用峰期是上午9点到11点、下午2点到4点，和训练任务错峰。我向老板申请把推理服务跑在一个独立的GPU节点池上，用K8s的nodeAffinity把推理Pod和训练Pod分开。训练任务用裸金属A100节点，推理服务用带高主频CPU、大显存的节点。这样两边互不干扰。

监控是最让我花心思的部分。过去我监控的是CPU、内存、磁盘、网络，现在要监控的是模型特有的指标：P99推理延迟、TTFT、TPOT、队列长度、GPU显存利用率、token生成速率。我在Prometheus里加了vLLM暴露的metrics endpoint，用Grafana做了一个专门的模型服务监控大盘。上线第一天晚上，大盘显示P99 TTFT 120ms，TPOT 18ms，QPS 50，GPU显存占用78%。这个画面让我有种久违的成就感——我又回到了核心战场。

上线一周后，客服系统反馈说偶尔会有请求超时。我排查日志，发现是连续批处理在某些情况下会出现"长请求拖慢短请求"的问题。一个用户问了很长的上下文，导致整个batch里的其他请求都在等。我调整了vLLM的max-num-seqs参数，从默认的256降到128，同时增加了推理Pod的副本数。调整后P99延迟从380ms降到210ms，超时率从0.8%降到0.05%。

老周在复盘会上说：

“云平台组的人来做MLOps，确实有优势。你们对稳定性、资源调度和问题的理解，比我们更扎实。”

我没说话，但心里知道，这句话我等了半年。

五、MLOps平台化：从跑一个模型到跑一百个模型

单个模型跑通之后，我开始思考更大的问题：公司未来可能有十几个模型在跑，怎么管理？训练任务、推理服务、模型版本、数据集、实验记录，这些能不能平台化？

这是MLOps工程师的真正价值所在。不是只会部署一个模型，而是能搭建一套让AI团队高效工作的基础设施。

我牵头做了一个内部项目：模型训练与推理调度平台。它的核心能力包括：

1. 训练任务队列和优先级调度。基于Volcano（K8s上的批调度系统），实现GPU资源的gang scheduling，避免一个任务占不满卡、多个任务互相挤。我们设置了三级优先级：高优先级任务可抢占低优先级任务的资源，但低优先级任务会被checkpoint保存状态，恢复后从断点继续训练。

2. 模型版本管理。MLflow Model Registry作为单点，所有模型训练完成后自动注册；推理服务从Registry拉取指定版本。每次上线都有一次审批流，Stg到Prod必须跑一遍回归测试。

3. 推理服务自动扩缩容。基于自定义metrics：当队列长度超过10时扩容，低于2时缩容。我们不直接用CPU，因为GPU推理服务的CPU波动不大，真正反映负载的是排队长度和token生成速率。

4. 全链路可观测。Prometheus + Grafana做指标，Loki做日志，Jaeger做推理链路追踪。一个客服请求从前端发出，经过API网关、推理服务、模型内部前向传播，最后返回，整个链路的延迟都能拆分。

项目上线三个月后，AI组的训练任务资源利用率从45%提升到72%，推理服务的平均部署时间从人工操作的3天缩短到自动化流水线里的40分钟。老板在季度会上把这张图放了出来，我第一次觉得，云平台工程师在AI时代不是被淘汰的对象，而是被需要的人——只是需要更新一下技能树。

六、云计算工程师的下一站，不是离开云，而是升级云

现在回头看，我转MLOps最大的体会是：这不是换赛道，而是同一套底层能力的延伸。

云计算工程师做了这么多年分布式系统、资源调度、高可用、可观测性，这些能力在大模型时代不仅没有贬值，反而更稀缺了。因为大模型训练和推理对基础设施的要求，比传统互联网服务苛刻得多：GPU资源贵、训练任务容错低、推理延迟敏感、模型版本复杂。纯AI背景的工程师往往关注算法和模型效果，但要把模型真正稳定地跑在生产环境里，离不开懂云和系统的人。

如果你也是做IaaS/PaaS的云计算工程师，想往MLOps转，我有几个具体建议：

第一，不要先去学Transformer，先去跑通一个训练到部署的完整流程。用Kubeflow或MLflow做一个最小可行Pipeline，把模型从训练到推理串起来。你会很快理解MLOps要解决的是什么问题。

第二，重点补三块：GPU资源调度、模型服务化推理、模型可观测。工具上可以从Kubeflow、vLLM/TGI、Prometheus + Grafana开始。这三块是MLOps平台的核心骨架。

第三，找一个真实的AI项目参与进去，哪怕只是帮忙部署。不要停留在看文档和跑Demo，真正的问题都在生产环境里：模型加载慢、推理超时、资源争抢、版本回滚。这些问题才是让你成长最快的地方。

第四，保持你的系统思维优势。MLOps里最有价值的不是会调超参数，而是能把一个不可靠的AI流程变成可靠的工程系统。这正是云计算工程师最擅长的。

我现在已经在MLOps组待了八个月，带了一个三人小团队。上周有个新同事问我，云计算背景转MLOps是不是很有劣势？

我跟他说：

“不是劣势。只是你得证明，你不仅懂K8s，还懂AI模型怎么在K8s上跑得又快又稳。”

说完我自己笑了。半年前的那个下午，我正是被这个问题问倒的人。现在，我成了能回答这个问题的人。AI时代，云计算工程师不会被淘汰，但只会搭虚拟机的人，确实会。把云的底子叠加上MLOps的能力，才是我们这一代云计算人最好的出路。

想入门 AI 大模型却找不到清晰方向？备考大厂 AI 岗还在四处搜集零散资料？别再浪费时间啦！2026 年 AI 大模型全套学习资料已整理完毕，从学习路线到面试真题，从工具教程到行业报告，一站式覆盖你的所有需求，现在全部免费分享！

👇👇扫码免费领取全部内容👇👇

​

一、学习必备：100+本大模型电子书+26 份行业报告 + 600+ 套技术PPT，帮你看透 AI 趋势

想了解大模型的行业动态、商业落地案例？大模型电子书？这份资料帮你站在 “行业高度” 学 AI：

1. 100+本大模型方向电子书

2. 26 份行业研究报告：覆盖多领域实践与趋势

报告包含阿里、DeepSeek 等权威机构发布的核心内容，涵盖：

• 职业趋势：《AI + 职业趋势报告》《中国 AI 人才粮仓模型解析》；
• 商业落地：《生成式 AI 商业落地白皮书》《AI Agent 应用落地技术白皮书》；
• 领域细分：《AGI 在金融领域的应用报告》《AI GC 实践案例集》；
• 行业监测：《2024 年中国大模型季度监测报告》《2025 年中国技术市场发展趋势》。

3. 600+套技术大会 PPT：听行业大咖讲实战

PPT 整理自 2024-2025 年热门技术大会，包含百度、腾讯、字节等企业的一线实践：

• 安全方向：《端侧大模型的安全建设》《大模型驱动安全升级（腾讯代码安全实践）》；
• 产品与创新：《大模型产品如何创新与创收》《AI 时代的新范式：构建 AI 产品》；
• 多模态与 Agent：《Step-Video 开源模型（视频生成进展）》《Agentic RAG 的现在与未来》；
• 工程落地：《从原型到生产：AgentOps 加速字节 AI 应用落地》《智能代码助手 CodeFuse 的架构设计》。

二、求职必看：大厂 AI 岗面试 “弹药库”，300 + 真题 + 107 道面经直接抱走

想冲字节、腾讯、阿里、蔚来等大厂 AI 岗？这份面试资料帮你提前 “押题”，拒绝临场慌！

1. 107 道大厂面经：覆盖 Prompt、RAG、大模型应用工程师等热门岗位

面经整理自 2021-2025 年真实面试场景，包含 TPlink、字节、腾讯、蔚来、虾皮、中兴、科大讯飞、京东等企业的高频考题，每道题都附带思路解析：

2. 102 道 AI 大模型真题：直击大模型核心考点

针对大模型专属考题，从概念到实践全面覆盖，帮你理清底层逻辑：

3. 97 道 LLMs 真题：聚焦大型语言模型高频问题

专门拆解 LLMs 的核心痛点与解决方案，比如让很多人头疼的 “复读机问题”：

三、路线必明： AI 大模型学习路线图，1 张图理清核心内容

刚接触 AI 大模型，不知道该从哪学起？这份「AI大模型 学习路线图」直接帮你划重点，不用再盲目摸索！

路线图涵盖 5 大核心板块，从基础到进阶层层递进：一步步带你从入门到进阶，从理论到实战。

L1阶段:启航篇丨极速破界AI新时代

L1阶段：了解大模型的基础知识，以及大模型在各个行业的应用和分析，学习理解大模型的核心原理、关键技术以及大模型应用场景。

L2阶段：攻坚篇丨RAG开发实战工坊

L2阶段：AI大模型RAG应用开发工程，主要学习RAG检索增强生成：包括Naive RAG、Advanced-RAG以及RAG性能评估，还有GraphRAG在内的多个RAG热门项目的分析。

L3阶段：跃迁篇丨Agent智能体架构设计

L3阶段：大模型Agent应用架构进阶实现，主要学习LangChain、 LIamaIndex框架，也会学习到AutoGPT、 MetaGPT等多Agent系统，打造Agent智能体。

L4阶段：精进篇丨模型微调与私有化部署

L4阶段：大模型的微调和私有化部署，更加深入的探讨Transformer架构，学习大模型的微调技术，利用DeepSpeed、Lamam Factory等工具快速进行模型微调，并通过Ollama、vLLM等推理部署框架，实现模型的快速部署。

L5阶段：专题集丨特训篇 【录播课】

四、资料领取：全套内容免费抱走，学 AI 不用再找第二份

不管你是 0 基础想入门 AI 大模型，还是有基础想冲刺大厂、了解行业趋势，这份资料都能满足你！
现在只需按照提示操作，就能免费领取：

👇👇扫码免费领取全部内容👇👇

​

2026 年想抓住 AI 大模型的风口？别犹豫，这份免费资料就是你的 “起跑线”！