做了这么多年运维我几乎是眼睁睁看着“大模型”三个字从科技新闻里的小众词汇变成老板、产品、开发嘴里每天都要提的必选项。但说实话身边很多运维同事对它的第一反应是这东西听起来全是数学公式跟我有什么关系等真要部署的时候才发现大模型落地最依赖的恰恰是运维——服务器加不加卡、显存怎么规划、模型服务挂了怎么快速恢复、并发上来后怎么调度这些都是要运维拿主意的。所以这篇就用最接地气的话把大模型拆开讲清楚全程不碰数学推导也不要求你懂神经网络底层原理。读完你至少能回答四个问题大模型到底是什么、为什么这么吃硬件、本地部署一般走什么路径、踩坑之后怎么排查。适合正在被“大模型”这三个字困扰的运维工程师也适合刚转岗到AI基础设施方向的同学快速建立概念。1. 大模型是什么从“超级老员工”说起1.1 一个老员工的比喻参数就是它的记忆体如果不看内部结构大模型给我的感觉就像一个“超级老员工”。公司招了一个天赋很强、但什么都不懂的新人你把过去十年的合同、会议纪要、客服工单、代码仓库全扔给他看让他自己慢慢总结规律。这个新人看了足够多的材料后自己摸索出一套经验合同一般长什么样、客服遇到什么关键词通常要退换货、代码里哪个函数该用什么命名。从这时候起你再问他任何问题他就能根据看过的经验给出一个像模像样的回答。大模型也是类似的逻辑。训练阶段让它读海量文本不需要有人一条条告诉它“苹果是水果”它见过的文本够多自己就把“苹果”和“水果”的关联记了下来。这里有个关键点它是通过概率和统计规律来“记住”东西而不是真正理解了世界逻辑。所以它看起来什么都懂但有时候会一本正经地胡说八道——就像那个整体优秀、偶尔编细节的老员工。对运维来说理解这个特性很重要因为它意味着模型推理结果不能直接当数据库查询结果用生产环境里做完推理之后往往还需要一层校验和兜底。大模型里的“参数”你可以粗暴理解为这个老员工的脑容量。参数量越大能记住的细节越多、表达越丰富但代价也很直接占用的显存更大推理耗时更长对服务器要求更高。后面讲部署时会反复提到参数和显存的换算关系这是运维绕不开的一个门槛。1.2 三层结构骨架、预训练和微调把大模型的生产过程拆成三步会更容易理解。第一步是搭骨架也就是神经网络结构。这一步偏学术运维不用管得太深只需要知道它是一个分层的信息处理结构输入一句话经过很多层处理后再输出下一个词。第二步是预训练相当于让模型读万卷书。模型被喂给几十TB甚至更大的文本数据一遍遍学习任务过程极其消耗算力训练成本动辄几百万美元通常只有大厂和顶级开源社区能承担。这也是为什么普通人不会从零训练模型而是直接使用别人开源出来的、训练好的底座模型。第三步是微调。底座模型虽然博学但它是“通才”不熟悉你公司的业务。就像那个看了大量书的新员工能力很强但你不给他讲一遍公司具体流程他没法按你的格式写周报。微调就是拿一批行业数据或企业内部数据在底座模型上做小规模继续训练让它在特定领域里表现更好。这也是AI大模型本地部署中最常见的环节之一很多团队不需要从零训练只要拿一个开源底座模型再用自己的数据微调出一版“懂行”的模型。对运维来说理清这三个概念后最大的意义是知道自己的主要工作集中在“部署和推理”这一段而不是“训练”这一段。后面讲硬件规划和工具选型都是基于这个前提展开的。2. 运维最关心的几个大模型技术概念2.1 Token、上下文窗口和显存有什么关系运维同学可能第一个听懵的词就是Token。简单理解Token是模型处理文本的最小单位你可以把它粗略理解为“半个词”或者“一个词的一部分”。英文里一个普通单词大致是1个Token中文因为分词方式不同一个字通常对应1到2个Token。也就是说用户给模型发一段500字的中文请求模型内部实际看到的可能是500到1000个Token。为什么要关心Token因为Token数量直接影响两个东西成本和显存。如果用的是云端APIToken越多越贵如果自建部署Token越长占用的显存和内存也越多。每一个正在处理的请求模型都要在显存里维护一份上下文缓存业内叫KV Cache你可以把它理解为一段“会议临时记录”。这个缓存的大小和上下文长度成正比所以并发一旦上来显存会迅速被吃光。我们遇到过最典型的情况是单个请求跑得很稳一上并发就立刻OOM。原因就是很多人只算了模型权重的显存没算KV Cache的显存。做容量规划时脑子里要有一个粗略公式模型服务实际占用的显存大致等于模型权重显存加上所有并发请求的上下文缓存显存。同一个7B模型可能一个用户时占14GB100个并发且每条请求都很长时就可能飙到40GB以上。这也是为什么生产环境里模型服务器很少只按“模型权重多大”来选显卡而要看峰值并发和请求长度总量。2.2 参数量、量化和推理速度如何做取舍说到参数量7B、13B、70B这些数字经常看到。B是Billion的意思7B就是70亿个参数。参数越多模型能力通常越强但硬件开销也直线上升。权重部分有一个非常实用的估算方式如果按FP16精度保存每个参数占用2字节。那么7B模型的权重就是约14GB13B约26GB70B约140GB。一张80GB显存的卡跑70B满精度根本放不下更不用提训练了。这里引出一个大模型部署里最重要的概念——量化。量化的本质是降低参数的保存精度换取更小的体积。比如FP16的2字节每参数压到INT4后占用直接降到0.5字节每参数7B模型的权重从14GB缩到大约4GB。这就是为什么很多个人开发者在普通显卡上也能跑中等规模模型靠的全是量化。实际运行中INT4量化对效果的影响在大部分场景下可以接受但也不是无损压缩特别小的模型或复杂推理场景下效果下降会比较明显。运维在选型时我一般建议按这个经验去配7B模型FP16建议24GB显存以上INT4量化后最低6-8GB可跑12GB卡体验比较好。14B模型INT4量化后权重约9GB加上缓存推荐16GB显存以上。70B/72B模型INT4量化后权重仍有约40GB单卡推荐80GB显存40GB的卡只能靠极限压缩和缩小上下文来硬凑。推理速度方面每秒生成多少个Token由很多东西决定显卡算力、显存带宽、量化程度、并发数量、上下文长度。不能说“换了更好的卡就一定更快”因为很多时候瓶颈在显存带宽和缓存命中率。这些内容后面第4部分实际部署时我会结合真实场景再讲。3. 从概念到落地给运维的一份上手路线图3.1 硬件选型先算显存再看算力手上还没有GPU服务器的话第一步先不要急着下单把上面那段估算方式用起来。小团队做PoC一张消费级显卡比如RTX 4090 24GB足够跑7B FP16或14B INT4量化版本。这种卡在推理场景里最大的优势是显存大、显存带宽高性价比比专业卡高不少。如果是在公有云上临时测试可以租A10、A100、H100这类实例按小时付费。如果有条件自己买服务器我建议优先看显存容量和整体散热功耗其次才是浮点算力。推理场景不像训练那样把算力打满很多时候模型权重和KV Cache才是卡脖子的地方。另外供电和散热不能省多卡机箱一定要做好风道否则温度一高GPU会自动降频推理速度断崖式下滑。这个坑我在机房踩过不止一次GPU温度从65℃升到85℃以上时同样的请求延迟能涨三四倍。软件环境上要注意驱动和CUDA版本总是最先出问题的地方。装了新卡先nvidia-smi看驱动是否正常驱动OK了再装CUDA Toolkit和cuDNN版本尽量参考推理框架的官方文档。这里我强烈建议用容器方式部署把环境依赖全部打进镜像里避免不同项目之间互相污染CUDA版本。NVIDIA官方提供NVIDIA Container Toolkit装好后加--gpus all参数就能把GPU映射进容器这也是目前主流部署方式。3.2 部署工具选型Ollama跑通再上vLLM第一次尝试本地部署我推荐从Ollama开始。理由很简单它把模型下载、运行、服务化全部封装成了几个命令几乎让初学者零门槛上手。下面是完整体验流程。先安装Ollama官方一键脚本即可。装好后拉取一个开源底座模型比如Qwen2.5系列ollama pull qwen2.5:7b ollama run qwen2.5:7b运行后会在命令行里直接进入对话界面你可以敲几句“你好”“介绍一下你自己”测试。Ollama默认在本地11434端口起一个HTTP服务所以它其实也是一个开箱即用的大模型API服务。用curl也能直接测curl http://localhost:11434/api/generate \ -d {model:qwen2.5:7b,prompt:你好介绍一下你自己,stream:false}这段请求会返回模型生成的完整文本验证API通不通非常方便。跨机器联调时注意Ollama默认只监听127.0.0.1需要外部访问就得设置OLLAMA_HOST环境变量比如OLLAMA_HOST0.0.0.0:11434。但这样直接暴露端口会有安全风险生产环境一定要在网关层做鉴权和限流。Ollama虽然好用但并发一上来就扛不太住了。这里就要把vLLM拉出来。vLLM是目前生产环境里最主流的推理服务框架之一核心优势是显存管理效率高支持PagedAttention。简单理解它把“会议临时记录”的存储管理得像操作系统的虚拟内存一样避免因为碎片浪费显存并发吞吐能力比Ollama强得多。部署vLLM的方式也简单pip install vllm vllm serve /data/models/qwen2.5-7b-instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192启动后它会提供一套OpenAI兼容的API端口默认8000地址是/v1/chat/completions。这意味着应用层可以直接用OpenAI的SDK接过来不用改业务代码。需要注意--gpu-memory-utilization这个参数它决定模型服务最多占用多少显存默认是0.9也就是90%。如果服务器上还要跑其他进程要相应调低。3.3 服务上线前网关、限流和监控一个都不能少模型推起来只是开始真正让运维头疼的是服务稳定性和可观测性。第一步是网关。无论前面用的是Ollama还是vLLM都不要把端口裸奔到业务网络里建议在模型服务前面挂一层网关Nginx、APISIX、Higress都可以。网关统一做三件事鉴权、限流、路由。模型服务不像普通Web服务单请求时间长、显存消耗大没有限流的话只要有一个用户疯狂发请求整个推理集群的资源都会被拖垮。第二步是监控。GPU资源监控建议用dcgm-exporter采集NVIDIA指标配合Prometheus存储、Grafana展示这套组合是当前的事实标准。关键指标至少盯这几个GPU显存使用率、GPU利用率、温度、功耗、vLLM的排队请求数、推理平均延迟和P95延迟。告警规则要根据实际压测数据来设置比如显存使用率超过85%持续5分钟或者P95延迟超过设定阈值就应该触发告警。第三步是日志和链路。推理请求的输入输出通常比较大不建议全量打印到日志里可以只记录元信息谁调的、模型名、Token数、延迟、是否成功。完整的输入输出可以保留在专门的抽样日志或审计系统里。有一次我们线上排查“某个用户的请求总是超时”就是因为没有链路信息翻了几小时日志才定位到是网关到vLLM之间的连接池被占满。后来在网关层补了访问日志和全链路Trace再遇到类似问题五分钟就能定位。4. 本地部署与微调一次真实的完整记录4.1 用Ollama在普通显卡上跑通大模型我这里用一台24GB显存的消费级卡来做演示。装完Ollama后执行ollama pull qwen2.5:7b ollama run qwen2.5:7b模型文件下载到本地后Ollama会把它加载进显存默认会占满所有空闲显存用于加速。这一步很多新手看不明白怎么我明明只跑一个7B模型显存使用率却显示96%因为Ollama默认会把上下文预加载到尽量大的空间以应对随机长度的请求。如果想限制它别占满整个显存可以设置OLLAMA_KEEP_ALIVE来控制模型在显存中的驻留时间或者用--keepalive参数。不过单机测试场景让它占满也没问题。跑通之后可以用ollama list查看本地有哪些模型ollama ps查看当前正在加载的模型和占用资源。还有一个实用小技巧把模型默认存储目录改到大磁盘分区通过OLLAMA_MODELS环境变量指定模型存放路径。模型文件动辄几个GB甚至几十GB系统盘很快就会被塞满我强烈建议一上来就设置好。4.2 用LLaMA-Factory微调一个专属模型很多团队问开源模型已经很能打了为什么还要微调我的判断是如果需求只是让模型回答通用问题那直接部署即可配合RAG检索增强就能解决大部分业务问题。但如果需要模型固定输出某种格式、强调某种语气或者希望它精通你们行业特有的术语体系那就值得做微调。工具方面我推荐LLaMA-Factory。它是一个开源的一站式微调平台图形界面下点点鼠标就能完成LoRA微调对运维特别友好。基本流程是这样的。先安装git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e . llamafactory-cli webui然后准备数据集。微调需要一批“指令-回复”格式的数据LLaMA-Factory支持Alpaca格式的JSON数据大概长这样[ { instruction: 请生成一段巡检总结, input: CPU使用率85%内存剩余2GB磁盘使用率70%, output: 当前服务器CPU使用率偏高建议重点关注内存剩余不足建议排查常驻进程磁盘使用率正常。 } ]数据量不需要多到吓人几百条高质量的业务样本就能明显改变模型在特定场景下的表现。把数据放到data目录后在Web界面选择基座模型勾选LoRA设置学习率、epoch等参数就可以开始训练。以7B模型为例LoRA方式在16GB显存显卡上可以小batch跑起来如果是全量微调则建议至少两块40GB以上的专业卡。训练完成后LoRA权重可以单独保存也可以合并回基座模型导出新模型。合并导出后的模型就是一个“懂你业务”的模型后续可以通过Ollama或vLLM正常部署。4.3 显存不足、OOM和慢推理我踩过的坑我在实际部署和微调过程中踩过不少坑挑几个最典型的说说。第一个坑是OOM。某次给一个推理服务加并发压力一开始8并发很稳定加到16并发突然所有请求都超时GPU显存一直在90%以上。用nvidia-smi观察后发现vLLM的KV Cache已经把整个显存吃满新请求全部进入排队。解决办法是调低--gpu-memory-utilization比如从0.9降到0.8给里面留出弹性空间同时上游网关限制最大并发数超过阈值直接拒绝不要无限制地往模型服务里塞请求。第二个坑是慢推理不一定是算力不够。有一次业务反馈“响应速度从2秒涨到10秒”我第一反应是GPU卡是不是降频了查了一圈温度正常后来发现是某个开发把上下文窗口调到了32K所有请求都带着超长历史记录进来KV Cache瞬间膨胀每个Token的生成时间被拉得很长。这其实是个典型问题上下文长度对推理延迟的影响经常被低估。第三个坑是内存OOM。模型在加载进显存之前会先从磁盘读到CPU内存加载过程中模型文件加反序列化开销内存占用会比模型文件大小高不少。有的部署环境CPU内存只有32GB模型文件40GB加载直接崩。所以生产服务器内存不能太抠一般建议内存至少是模型文件的1.5倍以上。5. 常见问题与排查技巧速查整理了一张我在实际工作中不断更新的排查表按“部署、推理、日常运维”三个场景分类希望能帮大家少走弯路。现象可能原因解决思路启动时报CUDA版本错误推理框架和驱动、CUDA不匹配检查nvidia-smi和框架官方要求用容器打包依赖环境模型拉取失败网络或镜像源问题使用国内模型镜像站点如魔搭社区等确认磁盘空间足够显存OOM权重显存加KV Cache超显存降低上下文长度、开启量化、调整vLLM显存利用率参数推理速度慢上下文过长、GPU降频、量化过重看nvidia-smi温度、观察请求平均Token长度、适当换量化档位并发一高就超时队列堆积、资源耗尽网关限流调大max-num-seqs或拆分多实例模型输出乱码分词器与模型不匹配检查是否加载了带Instruct或Chat后缀的指令微调版本服务进程莫名退出内存OOM被kill增加内存设置合理swap并监控内存水位最后分享几个我自己保留的排障习惯。第一每个推理服务上线前先做一轮小规模压测并发按1、4、8、16逐级增加每轮记录延迟和显存曲线找到服务的临界点然后按临界点的60%到70%配置生产限流阈值。这样即使突发流量进来也不会直接拖垮整个服务。第二不要盲目追新模型。确认新模型能正常部署后再灰度替换替换前把新旧模型同时挂在不同路由上观察几天对比延迟、效果和显存占用再决定是否全量切换。第三监控大盘上除了GPU指标一定要有API成功率和端到端延迟。因为GPU利用率再高如果业务接口已经超时对用户来说依然是事故。大模型对运维岗位的未来影响我自己的体会是它更像是一大堆新工具和新问题被塞进了运维的日常工作里。以后运维不仅要管服务器、网络、数据库还要管模型、显存、KV Cache这些新资源。工具链会越来越多但底层的思路没有变——理解系统资源、做好容量规划、保证服务可用、快速恢复故障。把大模型当成一个需要特殊照顾的“服务器应用”用运维的老办法去驯服它就没有那么神秘了。等你自己从拉模型、起服务、做压测、看监控跑完一整套流程再回去看那些论文和源码分析时你会完全不一样。 大模型运维实战：从显存规划到推理部署与排障
做了这么多年运维我几乎是眼睁睁看着“大模型”三个字从科技新闻里的小众词汇变成老板、产品、开发嘴里每天都要提的必选项。但说实话身边很多运维同事对它的第一反应是这东西听起来全是数学公式跟我有什么关系等真要部署的时候才发现大模型落地最依赖的恰恰是运维——服务器加不加卡、显存怎么规划、模型服务挂了怎么快速恢复、并发上来后怎么调度这些都是要运维拿主意的。所以这篇就用最接地气的话把大模型拆开讲清楚全程不碰数学推导也不要求你懂神经网络底层原理。读完你至少能回答四个问题大模型到底是什么、为什么这么吃硬件、本地部署一般走什么路径、踩坑之后怎么排查。适合正在被“大模型”这三个字困扰的运维工程师也适合刚转岗到AI基础设施方向的同学快速建立概念。1. 大模型是什么从“超级老员工”说起1.1 一个老员工的比喻参数就是它的记忆体如果不看内部结构大模型给我的感觉就像一个“超级老员工”。公司招了一个天赋很强、但什么都不懂的新人你把过去十年的合同、会议纪要、客服工单、代码仓库全扔给他看让他自己慢慢总结规律。这个新人看了足够多的材料后自己摸索出一套经验合同一般长什么样、客服遇到什么关键词通常要退换货、代码里哪个函数该用什么命名。从这时候起你再问他任何问题他就能根据看过的经验给出一个像模像样的回答。大模型也是类似的逻辑。训练阶段让它读海量文本不需要有人一条条告诉它“苹果是水果”它见过的文本够多自己就把“苹果”和“水果”的关联记了下来。这里有个关键点它是通过概率和统计规律来“记住”东西而不是真正理解了世界逻辑。所以它看起来什么都懂但有时候会一本正经地胡说八道——就像那个整体优秀、偶尔编细节的老员工。对运维来说理解这个特性很重要因为它意味着模型推理结果不能直接当数据库查询结果用生产环境里做完推理之后往往还需要一层校验和兜底。大模型里的“参数”你可以粗暴理解为这个老员工的脑容量。参数量越大能记住的细节越多、表达越丰富但代价也很直接占用的显存更大推理耗时更长对服务器要求更高。后面讲部署时会反复提到参数和显存的换算关系这是运维绕不开的一个门槛。1.2 三层结构骨架、预训练和微调把大模型的生产过程拆成三步会更容易理解。第一步是搭骨架也就是神经网络结构。这一步偏学术运维不用管得太深只需要知道它是一个分层的信息处理结构输入一句话经过很多层处理后再输出下一个词。第二步是预训练相当于让模型读万卷书。模型被喂给几十TB甚至更大的文本数据一遍遍学习任务过程极其消耗算力训练成本动辄几百万美元通常只有大厂和顶级开源社区能承担。这也是为什么普通人不会从零训练模型而是直接使用别人开源出来的、训练好的底座模型。第三步是微调。底座模型虽然博学但它是“通才”不熟悉你公司的业务。就像那个看了大量书的新员工能力很强但你不给他讲一遍公司具体流程他没法按你的格式写周报。微调就是拿一批行业数据或企业内部数据在底座模型上做小规模继续训练让它在特定领域里表现更好。这也是AI大模型本地部署中最常见的环节之一很多团队不需要从零训练只要拿一个开源底座模型再用自己的数据微调出一版“懂行”的模型。对运维来说理清这三个概念后最大的意义是知道自己的主要工作集中在“部署和推理”这一段而不是“训练”这一段。后面讲硬件规划和工具选型都是基于这个前提展开的。2. 运维最关心的几个大模型技术概念2.1 Token、上下文窗口和显存有什么关系运维同学可能第一个听懵的词就是Token。简单理解Token是模型处理文本的最小单位你可以把它粗略理解为“半个词”或者“一个词的一部分”。英文里一个普通单词大致是1个Token中文因为分词方式不同一个字通常对应1到2个Token。也就是说用户给模型发一段500字的中文请求模型内部实际看到的可能是500到1000个Token。为什么要关心Token因为Token数量直接影响两个东西成本和显存。如果用的是云端APIToken越多越贵如果自建部署Token越长占用的显存和内存也越多。每一个正在处理的请求模型都要在显存里维护一份上下文缓存业内叫KV Cache你可以把它理解为一段“会议临时记录”。这个缓存的大小和上下文长度成正比所以并发一旦上来显存会迅速被吃光。我们遇到过最典型的情况是单个请求跑得很稳一上并发就立刻OOM。原因就是很多人只算了模型权重的显存没算KV Cache的显存。做容量规划时脑子里要有一个粗略公式模型服务实际占用的显存大致等于模型权重显存加上所有并发请求的上下文缓存显存。同一个7B模型可能一个用户时占14GB100个并发且每条请求都很长时就可能飙到40GB以上。这也是为什么生产环境里模型服务器很少只按“模型权重多大”来选显卡而要看峰值并发和请求长度总量。2.2 参数量、量化和推理速度如何做取舍说到参数量7B、13B、70B这些数字经常看到。B是Billion的意思7B就是70亿个参数。参数越多模型能力通常越强但硬件开销也直线上升。权重部分有一个非常实用的估算方式如果按FP16精度保存每个参数占用2字节。那么7B模型的权重就是约14GB13B约26GB70B约140GB。一张80GB显存的卡跑70B满精度根本放不下更不用提训练了。这里引出一个大模型部署里最重要的概念——量化。量化的本质是降低参数的保存精度换取更小的体积。比如FP16的2字节每参数压到INT4后占用直接降到0.5字节每参数7B模型的权重从14GB缩到大约4GB。这就是为什么很多个人开发者在普通显卡上也能跑中等规模模型靠的全是量化。实际运行中INT4量化对效果的影响在大部分场景下可以接受但也不是无损压缩特别小的模型或复杂推理场景下效果下降会比较明显。运维在选型时我一般建议按这个经验去配7B模型FP16建议24GB显存以上INT4量化后最低6-8GB可跑12GB卡体验比较好。14B模型INT4量化后权重约9GB加上缓存推荐16GB显存以上。70B/72B模型INT4量化后权重仍有约40GB单卡推荐80GB显存40GB的卡只能靠极限压缩和缩小上下文来硬凑。推理速度方面每秒生成多少个Token由很多东西决定显卡算力、显存带宽、量化程度、并发数量、上下文长度。不能说“换了更好的卡就一定更快”因为很多时候瓶颈在显存带宽和缓存命中率。这些内容后面第4部分实际部署时我会结合真实场景再讲。3. 从概念到落地给运维的一份上手路线图3.1 硬件选型先算显存再看算力手上还没有GPU服务器的话第一步先不要急着下单把上面那段估算方式用起来。小团队做PoC一张消费级显卡比如RTX 4090 24GB足够跑7B FP16或14B INT4量化版本。这种卡在推理场景里最大的优势是显存大、显存带宽高性价比比专业卡高不少。如果是在公有云上临时测试可以租A10、A100、H100这类实例按小时付费。如果有条件自己买服务器我建议优先看显存容量和整体散热功耗其次才是浮点算力。推理场景不像训练那样把算力打满很多时候模型权重和KV Cache才是卡脖子的地方。另外供电和散热不能省多卡机箱一定要做好风道否则温度一高GPU会自动降频推理速度断崖式下滑。这个坑我在机房踩过不止一次GPU温度从65℃升到85℃以上时同样的请求延迟能涨三四倍。软件环境上要注意驱动和CUDA版本总是最先出问题的地方。装了新卡先nvidia-smi看驱动是否正常驱动OK了再装CUDA Toolkit和cuDNN版本尽量参考推理框架的官方文档。这里我强烈建议用容器方式部署把环境依赖全部打进镜像里避免不同项目之间互相污染CUDA版本。NVIDIA官方提供NVIDIA Container Toolkit装好后加--gpus all参数就能把GPU映射进容器这也是目前主流部署方式。3.2 部署工具选型Ollama跑通再上vLLM第一次尝试本地部署我推荐从Ollama开始。理由很简单它把模型下载、运行、服务化全部封装成了几个命令几乎让初学者零门槛上手。下面是完整体验流程。先安装Ollama官方一键脚本即可。装好后拉取一个开源底座模型比如Qwen2.5系列ollama pull qwen2.5:7b ollama run qwen2.5:7b运行后会在命令行里直接进入对话界面你可以敲几句“你好”“介绍一下你自己”测试。Ollama默认在本地11434端口起一个HTTP服务所以它其实也是一个开箱即用的大模型API服务。用curl也能直接测curl http://localhost:11434/api/generate \ -d {model:qwen2.5:7b,prompt:你好介绍一下你自己,stream:false}这段请求会返回模型生成的完整文本验证API通不通非常方便。跨机器联调时注意Ollama默认只监听127.0.0.1需要外部访问就得设置OLLAMA_HOST环境变量比如OLLAMA_HOST0.0.0.0:11434。但这样直接暴露端口会有安全风险生产环境一定要在网关层做鉴权和限流。Ollama虽然好用但并发一上来就扛不太住了。这里就要把vLLM拉出来。vLLM是目前生产环境里最主流的推理服务框架之一核心优势是显存管理效率高支持PagedAttention。简单理解它把“会议临时记录”的存储管理得像操作系统的虚拟内存一样避免因为碎片浪费显存并发吞吐能力比Ollama强得多。部署vLLM的方式也简单pip install vllm vllm serve /data/models/qwen2.5-7b-instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192启动后它会提供一套OpenAI兼容的API端口默认8000地址是/v1/chat/completions。这意味着应用层可以直接用OpenAI的SDK接过来不用改业务代码。需要注意--gpu-memory-utilization这个参数它决定模型服务最多占用多少显存默认是0.9也就是90%。如果服务器上还要跑其他进程要相应调低。3.3 服务上线前网关、限流和监控一个都不能少模型推起来只是开始真正让运维头疼的是服务稳定性和可观测性。第一步是网关。无论前面用的是Ollama还是vLLM都不要把端口裸奔到业务网络里建议在模型服务前面挂一层网关Nginx、APISIX、Higress都可以。网关统一做三件事鉴权、限流、路由。模型服务不像普通Web服务单请求时间长、显存消耗大没有限流的话只要有一个用户疯狂发请求整个推理集群的资源都会被拖垮。第二步是监控。GPU资源监控建议用dcgm-exporter采集NVIDIA指标配合Prometheus存储、Grafana展示这套组合是当前的事实标准。关键指标至少盯这几个GPU显存使用率、GPU利用率、温度、功耗、vLLM的排队请求数、推理平均延迟和P95延迟。告警规则要根据实际压测数据来设置比如显存使用率超过85%持续5分钟或者P95延迟超过设定阈值就应该触发告警。第三步是日志和链路。推理请求的输入输出通常比较大不建议全量打印到日志里可以只记录元信息谁调的、模型名、Token数、延迟、是否成功。完整的输入输出可以保留在专门的抽样日志或审计系统里。有一次我们线上排查“某个用户的请求总是超时”就是因为没有链路信息翻了几小时日志才定位到是网关到vLLM之间的连接池被占满。后来在网关层补了访问日志和全链路Trace再遇到类似问题五分钟就能定位。4. 本地部署与微调一次真实的完整记录4.1 用Ollama在普通显卡上跑通大模型我这里用一台24GB显存的消费级卡来做演示。装完Ollama后执行ollama pull qwen2.5:7b ollama run qwen2.5:7b模型文件下载到本地后Ollama会把它加载进显存默认会占满所有空闲显存用于加速。这一步很多新手看不明白怎么我明明只跑一个7B模型显存使用率却显示96%因为Ollama默认会把上下文预加载到尽量大的空间以应对随机长度的请求。如果想限制它别占满整个显存可以设置OLLAMA_KEEP_ALIVE来控制模型在显存中的驻留时间或者用--keepalive参数。不过单机测试场景让它占满也没问题。跑通之后可以用ollama list查看本地有哪些模型ollama ps查看当前正在加载的模型和占用资源。还有一个实用小技巧把模型默认存储目录改到大磁盘分区通过OLLAMA_MODELS环境变量指定模型存放路径。模型文件动辄几个GB甚至几十GB系统盘很快就会被塞满我强烈建议一上来就设置好。4.2 用LLaMA-Factory微调一个专属模型很多团队问开源模型已经很能打了为什么还要微调我的判断是如果需求只是让模型回答通用问题那直接部署即可配合RAG检索增强就能解决大部分业务问题。但如果需要模型固定输出某种格式、强调某种语气或者希望它精通你们行业特有的术语体系那就值得做微调。工具方面我推荐LLaMA-Factory。它是一个开源的一站式微调平台图形界面下点点鼠标就能完成LoRA微调对运维特别友好。基本流程是这样的。先安装git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e . llamafactory-cli webui然后准备数据集。微调需要一批“指令-回复”格式的数据LLaMA-Factory支持Alpaca格式的JSON数据大概长这样[ { instruction: 请生成一段巡检总结, input: CPU使用率85%内存剩余2GB磁盘使用率70%, output: 当前服务器CPU使用率偏高建议重点关注内存剩余不足建议排查常驻进程磁盘使用率正常。 } ]数据量不需要多到吓人几百条高质量的业务样本就能明显改变模型在特定场景下的表现。把数据放到data目录后在Web界面选择基座模型勾选LoRA设置学习率、epoch等参数就可以开始训练。以7B模型为例LoRA方式在16GB显存显卡上可以小batch跑起来如果是全量微调则建议至少两块40GB以上的专业卡。训练完成后LoRA权重可以单独保存也可以合并回基座模型导出新模型。合并导出后的模型就是一个“懂你业务”的模型后续可以通过Ollama或vLLM正常部署。4.3 显存不足、OOM和慢推理我踩过的坑我在实际部署和微调过程中踩过不少坑挑几个最典型的说说。第一个坑是OOM。某次给一个推理服务加并发压力一开始8并发很稳定加到16并发突然所有请求都超时GPU显存一直在90%以上。用nvidia-smi观察后发现vLLM的KV Cache已经把整个显存吃满新请求全部进入排队。解决办法是调低--gpu-memory-utilization比如从0.9降到0.8给里面留出弹性空间同时上游网关限制最大并发数超过阈值直接拒绝不要无限制地往模型服务里塞请求。第二个坑是慢推理不一定是算力不够。有一次业务反馈“响应速度从2秒涨到10秒”我第一反应是GPU卡是不是降频了查了一圈温度正常后来发现是某个开发把上下文窗口调到了32K所有请求都带着超长历史记录进来KV Cache瞬间膨胀每个Token的生成时间被拉得很长。这其实是个典型问题上下文长度对推理延迟的影响经常被低估。第三个坑是内存OOM。模型在加载进显存之前会先从磁盘读到CPU内存加载过程中模型文件加反序列化开销内存占用会比模型文件大小高不少。有的部署环境CPU内存只有32GB模型文件40GB加载直接崩。所以生产服务器内存不能太抠一般建议内存至少是模型文件的1.5倍以上。5. 常见问题与排查技巧速查整理了一张我在实际工作中不断更新的排查表按“部署、推理、日常运维”三个场景分类希望能帮大家少走弯路。现象可能原因解决思路启动时报CUDA版本错误推理框架和驱动、CUDA不匹配检查nvidia-smi和框架官方要求用容器打包依赖环境模型拉取失败网络或镜像源问题使用国内模型镜像站点如魔搭社区等确认磁盘空间足够显存OOM权重显存加KV Cache超显存降低上下文长度、开启量化、调整vLLM显存利用率参数推理速度慢上下文过长、GPU降频、量化过重看nvidia-smi温度、观察请求平均Token长度、适当换量化档位并发一高就超时队列堆积、资源耗尽网关限流调大max-num-seqs或拆分多实例模型输出乱码分词器与模型不匹配检查是否加载了带Instruct或Chat后缀的指令微调版本服务进程莫名退出内存OOM被kill增加内存设置合理swap并监控内存水位最后分享几个我自己保留的排障习惯。第一每个推理服务上线前先做一轮小规模压测并发按1、4、8、16逐级增加每轮记录延迟和显存曲线找到服务的临界点然后按临界点的60%到70%配置生产限流阈值。这样即使突发流量进来也不会直接拖垮整个服务。第二不要盲目追新模型。确认新模型能正常部署后再灰度替换替换前把新旧模型同时挂在不同路由上观察几天对比延迟、效果和显存占用再决定是否全量切换。第三监控大盘上除了GPU指标一定要有API成功率和端到端延迟。因为GPU利用率再高如果业务接口已经超时对用户来说依然是事故。大模型对运维岗位的未来影响我自己的体会是它更像是一大堆新工具和新问题被塞进了运维的日常工作里。以后运维不仅要管服务器、网络、数据库还要管模型、显存、KV Cache这些新资源。工具链会越来越多但底层的思路没有变——理解系统资源、做好容量规划、保证服务可用、快速恢复故障。把大模型当成一个需要特殊照顾的“服务器应用”用运维的老办法去驯服它就没有那么神秘了。等你自己从拉模型、起服务、做压测、看监控跑完一整套流程再回去看那些论文和源码分析时你会完全不一样。