小雨果1号1. 部署的本质：训练只是起点，模型能跑起来才是终点
1.1 为什么“能用”和“好用”之间隔着一条护城河
做AI训练师这行时间久了，你会发现一个特别有意思的现象：很多团队在训练阶段投入了大量精力，数据集清洗、特征工程、调参、跑实验，一套流程下来模型指标刷得漂漂亮亮，但真到了要落地的时候，反而卡壳了。模型文件躺在服务器上，谁都能说“我训了一个准确率不错的模型”，但能不能把它变成一个稳定的、可被业务调用的服务，完全是另一码事。
我之前给一家中小型公司做过咨询，他们的算法工程师花了两周微调了一个文本分类模型，在测试集上F1分数做到0.91，结果到了部署环节，发现模型推理一次要800毫秒，接口一压测就超时，GPU显存还时不时爆掉。最后折腾了快一个月，才把模型切成量化版本、加了批处理逻辑，勉强上线。这个案例特别典型，它说明一个道理：训练阶段追求的是“指标最优”，部署阶段追求的是“资源可控、响应及时、运行稳定”，这两件事的KPI是完全不同的。
所以我一直觉得，AI训练师这个岗位，不应该只懂训练，还要懂部署。说得直白一点，你的模型训得再好，如果部署环节出了岔子，业务方看到的不是你的F1分数，而是“这个AI怎么这么卡”“怎么又挂了”。在外部视角里，推理速度、稳定性、成本，远比论文里的指标更真实。
1.2 部署前必须回答的4个核心问题
在真正开始部署之前，我建议每个AI训练师都先冷静下来，回答下面4个问题。它们决定了你后续所有的技术选型，一定要在动工前想清楚。
第一个问题：你的模型跑在什么场景里？如果是离线任务，比如批量文档审核、定时数据分析，那对延迟的要求就低很多，哪怕一次推理两三秒都能接受。但如果是线上实时接口，比如对话机器人、实时推荐、内容审核拦截，那你得把单次推理延迟压到几百毫秒以内，甚至更低。
第二个问题：你的用户量有多大，并发峰值得多高？这个直接决定你要不要上多卡、要不要做推理服务化、要不要引入负载均衡。我见过有人给内部管理后台部署了一个大模型，就三五个人用，结果上了vLLM加Kubernetes一套重方案，纯属杀鸡用牛刀。反过来，也有人做一个对外的小应用，日活就几百，却只搞了个最简单的Python脚本起服务，一压测就崩。
第三个问题：你的部署环境是裸机、虚拟机，还是容器化平台？环境不同，踩的坑完全不同。裸机部署相对直接，但环境迁移麻烦；容器化部署可移植性好，但GPU透传、驱动兼容这些够你喝一壶的。这个问题越早想清楚越好，因为到时候重建环境的时间成本，往往会超出你的预期。
第四个问题：你手头的硬件预算到底有多少？这直接决定了你在模型量化、显存优化上要花多大功夫。手里只有一张消费级显卡，和你背后有A100集群，那是两个完全不同的玩法。这里没有标准答案，但一定得诚实面对自己的资源上限。
这四个问题有了清晰的答案，选型才不会跑偏。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 本地部署工具选型：Ollama和vLLM到底怎么挑
2.1 Ollama：个人开发者和轻度使用者的首选
先聊Ollama，这两年提到本地部署大模型，这个名字出现的频率实在是太高了。它的核心设计理念就是降低准入门槛，把过去让人头疼的环境配置、模型下载、依赖管理全部封装到几个简单的命令里。你只需要一条ollama run，就能把一个大模型在本地拉起来，直接对话。
Ollama的目录机制也做得相当友好，模型文件统一管理，按名称和标签区分版本，切换模型就是改一行配置的事。它还内置了OpenAI兼容的API接口，这意味着你之前写的那些调用OpenAI接口的业务代码，只需要把base_url换个地址，端口改成11434，就能无缝切到本地模型上。
我自己实测下来的感受是，Ollama对于“个人电脑上跑个模型体验一下”和“小团队内部搭建一个实验性服务”这两个场景，体验非常顺滑。它甚至简化了量化流程，你在拉取模型的时候可以直接通过参数指定不同的量化精度级别，比如q4_K_M这种常见选择，不用自己跑一遍量化工具。这种“拿来就能用”的特性，是它能够迅速普及的最重要原因。
不过Ollama也有明显的边界。它的性能优化相对保守，如果遇到高并发请求，虽然也能撑住，但吞吐量和延迟表现不如专门为高性能推理而生的框架。而且它在细粒度控制上偏弱，比如你要自定义KV Cache的分配策略，或者精确控制batch大小，Ollama能给你的操作空间很有限。
2.2 vLLM：服务化部署和高并发场景的主力军
如果说Ollama解决的是“跑起来”的问题，那vLLM解决的就是“跑得爽”的问题。vLLM的核心优势之一是PagedAttention技术，它把KV Cache按块管理，几乎消除了显存碎片化的问题，显存利用率比传统方式高出不少，这让它在处理大批量并发请求时有非常亮眼的表现。
vLLM还有一个很实用的特性是continuous batching，也就是连续批处理。传统方式的处理逻辑是攒够一批再统一推理，而vLLM能在每个请求完成时立刻把新的请求塞进当前批次里，不需要等整批结束。这个机制对线上推理服务的吞吐提升非常明显，我实测过在同样硬件条件下，vLLM的每秒请求处理数可以比朴素的批处理方式高出一大截。
部署vLLM也谈不上复杂，一条vllm serve命令就能把一个模型以OpenAI兼容格式的API服务跑起来。但要注意，它背后涉及的调度策略、显存预留、分布式推理配置这些参数，你如果不去理解，出问题时排查起来会相当被动。用vLLM意味着你已经在用生产级的推理方案了，那就得有相应的专业能力去驾驭它。
2.3 选型决策表
我在实际给团队做方案的时候，习惯用一张表格来收敛工具的选用，不一定完全覆盖所有场景，但能帮初学者在第一步不跑偏：
| 维度 | Ollama | vLLM |
|---|---|---|
| 上手难度 | 极低，两条命令跑通 | 中等，需要理解推理参数 |
| 推理性能 | 够用，但优化空间有限 | 高，吞吐量优势明显 |
| 高并发能力 | 一般 | 强，适合服务化场景 |
| 资源占用 | 低，适合单机单卡 | 较高，但显存利用率高 |
| 适合场景 | 本地体验、小团队实验 | 生产环境、线上API服务 |
| 扩展性 | 弱，黑盒程度较高 | 强，支持分布式和多卡 |
一句话总结：自己电脑上跑着玩，或者三五个人内网用，Ollama足矣；要是做产品、做对外服务、要扛并发，直接上vLLM，别犹豫。当然，两者不冲突，你完全可以先用Ollama做原型验证，确定模型效果没问题之后，再切到vLLM上做正式的服务部署。
3. 实操落地：从模型权重到可服务的推理接口
3.1 硬件准备与环境配置
部署模型的第一步，先摸清家底。以常见的7B到8B规模模型为例，如果只做推理，全精度FP16条件下的显存需求大约在14GB到16GB之间。这意味着你的显卡显存至少要到16GB才跑得动全精度版本。如果显存只有8GB，那就得分两步走：要么选择4bit量化的版本，把模型体积压到5GB左右；要么就得接受CPU推理的缓慢速度。
这里分享一个粗略的估算公式：模型权重显存占用量约等于参数量乘以精度字节数。7B模型用FP16就是7乘以2，约14GB；用INT4量化就是7乘以0.5，约3.5GB，再加上推理过程中KV Cache和中间激活值的消耗，总显存需求大约再乘以1.2到1.5的系数。我一般会按这个系数先把余量留足，免得部署到一半发现显存不够。
环境配置方面，如果你是NVIDIA显卡，核心就三件事：驱动装好、CUDA装对版本、PyTorch装匹配版本。很多部署问题最后都出在版本不匹配上，尤其是CUDA和PyTorch的对应关系。我的建议是直接参考官方文档的兼容性矩阵来装，别凭感觉来。如果条件允许，直接用官方镜像起容器，环境隔离做得好，以后换机器也省心。
3.2 Ollama部署流程与常用管理命令
Ollama的部署流程简洁得让人心情愉快。安装完成后，拉取模型的命令是：
bash复制ollama pull qwen2.5:7b
这里要注意冒号后面是标签，你可以指定量化版本，比如：
bash复制ollama pull qwen2.5:7b-instruct-q4_K_M
拉取完成，直接运行：
bash复制ollama run qwen2.5:7b
一个交互式对话环境就起来了。要在后台以服务方式运行，让它提供API接口，则用：
bash复制ollama serve
默认监听11434端口，调用方式和OpenAI接口一致，只是base_url换成http://localhost:11434。我在自己的一个小工具里，就是把原先的GPT调用地址改成了这个，代码几乎没怎么动，模型就从云端模型切到了本地模型。
管理方面，ollama list查看本地已有的模型列表，ollama rm删除不要的模型，ollama cp还能复制模型副本。这些命令虽然简单，但无论是清理磁盘空间还是维护多个模型版本，都非常实用。
我在实操中踩过的一个坑是：直接用ollama run在终端里跑服务，窗口一关服务就没了。正确做法是要常驻服务就用ollama serve配合systemd或nohup管理进程。不然你兴致勃勃调完接口，第二天发现服务没了，又要排查半天。
3.3 vLLM部署流程与关键参数调优
vLLM的部署走的是另一个路线，它对Python环境的要求更严格。我建议直接建一个独立的虚拟环境，避免和系统Python打架。然后用pip安装：
bash复制pip install vllm
启动一个离线推理进程很简单：
python复制from vllm import LLM, SamplingParams
llm = LLM(model="Qwen/Qwen2.5-7B-Instruct")
output = llm.generate("讲一个短笑话", SamplingParams(temperature=0.7, max_tokens=512))
print(output[0].outputs[0].text)
要把它变成API服务，一条命令就能实现：
bash复制vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000
然后通过http://localhost:8000/v1/chat/completions调用，格式和OpenAI完全一样。这里有个参数值得专门拿出来说：--gpu-memory-utilization，它控制模型在显存中的占用比例上限。默认是0.9，意思是最多用90%的显存。如果你的显存比较紧张，或者你想预留一部分显存用于其他任务，就调低这个值。但调太低了会影响推理性能，我一般建议保持在0.85到0.95之间。
另一个关键参数是--max-model-len，它决定了模型能处理的最长序列长度。默认值通常按模型的能力上限设置，但这会导致显存预留过大。如果你的实际业务场景不需要那么长的上下文，可以把这个值调小，比如从默认的32768调到8192，这样KV Cache的显存占用会明显下降，能省出不少空间来处理更大并发。
3.4 模型管理：版本、量化与生命周期
模型管理这个环节，很多初学者容易忽略，但它的重要程度不亚于部署本身。你可以把模型文件类比成代码，训练过程中的每一个版本都对应着一次代码提交。上线之后发现效果有问题，你要能快速回滚到上一个可用版本，而不是翻聊天记录找模型文件。
Ollama的标签机制和vLLM的HuggingFace仓库机制都支持多版本管理。我的习惯是，模型名字里带上精度和日期信息，比如qwen2.5-7b-instruct-fp16-20250601。这样看着繁琐，但上线后排查问题能少走很多弯路。
量化策略也值得单独说。FP16精度最高，但吃显存；INT8损失很小，速度中等；INT4最省资源，但效果下降需要测试评估。我这里的建议是，对你的核心业务场景，量化前和量化后各跑一批验证集，量化后的效果如果损失在可接受范围内，就优先用INT8。如果显存实在紧张，再考虑INT4。
4. 推理性能调优：让模型跑得更快更稳
4.1 显存瓶颈与批量推理策略
推理性能的核心瓶颈，90%的情况出在显存上。大模型生成是逐token自回归解码的过程，除了模型权重占用的显存，每一步生成还会产生KV Cache。这些缓存是随着生成长度线性增长的，如果生成长度长、并发请求多，KV Cache的显存占用很快就会超过模型权重本身。这也是为什么很多人在部署后跑单条请求一切正常，一上并发就显存溢出。
解决思路很直接：通过batch size参数控制同时处理的请求数。vLLM里可以通过--max-num-seqs来控制最大并发序列数，我一般从16起步，观察显存使用情况和延迟变化，再逐步往上加。找到一个平衡点：并发数太低，GPU利用率上不去；并发数太高，可能触发显存溢出。这个平衡点没有固定数值，和显卡型号、模型大小、生成长度都相关，只有实测才能确定。
还有一个容易忽略的小技巧：如果业务允许，尽量限制max_tokens的值。每个请求默认可以生成1024甚至2048个token，但实际业务里很多场景根本不需要这么长。把这个值调低一半，KV Cache的显存压力立刻降下来，吞吐量反而能提升。
4.2 量化、多卡与KV Cache的取舍
量化显然能减少模型权重占用的显存，但是要注意，它也会对输出质量产生微妙影响。我在实际项目里发现，对于通用对话任务，INT8量化几乎感觉不到差异；但如果是代码生成、数学推理这类对逻辑准确性要求极高的场景，量化的损失会被放大。所以，量化不是无脑上的，得分场景来。
多卡部署又是另一个维度。vLLM支持张量并行，可以把一个大模型切分到多张显卡上共同推理。但这里有个容易被误解的点：张量并行并不是性能提升的万金油。卡间通信的开销是实打实的，并行度越高，通信开销越大。我实测下来，两卡并行和单卡跑同样规模的模型，速度往往提升有限，除非你已经逼近单卡显存上限，否则不必急着上多卡。
KV Cache的分配策略也是调优的抓手。vLLM提供了多种缓存替换算法，默认的auto模式适合大多数场景，但如果你的业务有很强的局部性，比如大量请求都集中在少数几个系统提示词模板上，手动配置KV Cache策略可以进一步压缩显存占用。这个属于进阶玩法，先提一句，后面大家遇到了再深入研究也行。
5. 常见问题与排查技巧实录
5.1 部署后推理速度慢怎么办
这是被问得最多的问题。我先给一个排查顺序，大家照着走一遍基本能定位问题：
第一步，确认模型是否在GPU上运行。不要笑，我遇到太多“感觉速度慢”的案例，最后发现模型压根没加载到显卡上，一直在CPU里硬算。确认方法很简单，跑推理的时候另一个窗口执行nvidia-smi，看GPU的利用率是不是起来了。如果利用率一直上不去，说明模型在CPU上跑。
第二步，确认是否用了量化版本。同样的模型，FP16和INT4的推理速度差好几倍。如果延迟要求高，而你又跑的是FP16，优先考虑换成INT8试试。
第三步，看并发设置。如果vLLM的max-num-seqs设得太低，GPU算力根本没有被填满，大量请求都在排队等待。把并发数往上调，吞吐量会立竿见影地提升。
这三步排查完，90%的速度问题都能有一个清晰的结论。如果还是慢，那就得结合具体的模型大小和硬件配置来进一步分析了。
5.2 显存溢出的三层排查路径
显存溢出（OOM）是部署中不可避免会遇到的问题。我把它分成三层排查路径：
第一层，最粗粒度：模型本身放不放得下。直接看模型量化精度对应的大概大小，和你显卡的显存容量比一比。7B模型的FP16版本14GB，一张8GB显存的显卡硬跑，那没办法，只能换量化或者换小模型。
第二层，中粒度：推理过程的峰值显存超限。这种情况常见于生成长度过长时，KV Cache快速膨胀，把显存撑爆。解法是把max_tokens调小，或者把gpu-memory-utilization调高一点，前提是你别把启动参数改得太狠。
第三层，细粒度：显存碎片化严重。这种情况在Ollama里不常见，但vLLM如果运行时间特别长，大量请求的KV Cache反复分配和释放之后，也可能出现碎片化问题。最简单的解法是重启服务进程，把显存彻底清一遍。这也提醒我们，生产环境的推理服务一定要有监控和自动重启的机制。
5.3 量化后效果下降的补偿措施
如果你已经量化到INT4，发现模型效果下降明显，先别慌，有几个补救措施可以尝试。最直接的办法是升级到INT8，精度恢复明显，显存增加也有限。如果必须用INT4，还能在提示词层面做文章：把提示词写得更明确、给更多示例、降低temperature参数。这些做法对小模型的效果稳定特别有帮助。
还有一个容易踩的坑：量化版本和原版的行为差异，在白盒评估里体现得可能不明显，但放到真实业务场景里会被放大。所以在量化模型正式上线前，我强烈建议做一轮针对性回归测试，把你业务里最高频的二三十个场景跑一遍，人工对比量化前后输出差异。这一步虽然费时间，但能避免上线后的各种突发状况。
6. 我的一些部署实操心得
最后分享一个我自己的体会。在整个AI模型部署这件事上，做得越多越觉得，技术本身并不复杂，复杂的是“理解业务要什么”和“清楚手里的资源边界”。
我见过太多人上来就直接拉最新最大的模型，也不管自己显卡扛不扛得住，也不管业务是不是真的需要那么强的能力，结果部署到一半发现显存不够、延迟超标，又回到起点重新选型。反过来，我也见过一些团队务实得很，拿一个小模型加精心设计的提示词，把业务做得稳稳当当，用户根本感知不到背后模型的大小。这两者之间的差距，不在技术能力，而在决策判断。
所以，我的建议是：部署模型之前，先问问自己，这个任务最低需要什么样能力的模型？用8B能解决的事情，不必非得拉70B过来。模型越小，部署成本越低，响应越快，出故障的概率也越小。这个取舍，是AI训练师在部署环节最核心的能力之一。
另外，有条件的话，建议把部署文档和模型管理规范化。哪怕只是给自己看，也要把命令、版本、参数、踩坑记录都写下来。人在同一个地方跌倒两次不可怕，可怕的是每次跌倒都要花两小时才能想起来当初是怎么爬起来的。把这些经验积累成一个团队内部的部署手册，后面新同事上手会快很多。
这个系列走到这里，模型的训练、评估、管理、部署基本上串成了一条完整的链路。大家如果在自己动手的过程中遇到什么特别有意思的问题，也欢迎拿出来聊一聊，我后面会继续更新系列的内容，敬请期待。