上个月帮一个团队把一台八卡机变成对内的大模型服务前后折腾了大半个月。最耗时间的不是模型下载也不是推理框架跑不起来而是整个过程中一直在做取舍框架用哪个、模型量化不量化、GPU 买云上的还是自建、上线前还要过哪些坑。大模型服务器部署这件事资料不少但大多散在单篇教程里很少有人把框架选型、云资源、生产流程串成一条完整的链路。这篇内容想解决的问题很具体给手上有 GPU 资源、准备把大模型真正跑成服务的人一份 2026 年还能用的路线图。内容包括主流推理框架与微调工具的选型、显存和算力的估算方法、云 GPU 与自建的成本对比以及一套从模型版本化到灰度上线的生产级流程。不管你是刚接触本地部署、还是正准备从 demo 走向正式环境都可以照着一段段往下对。1. 部署形态大盘点裸机、云GPU、容器、Serverless 怎么选1.1 四种形态的特性与边界先厘清部署形态这个概念。很多人一上来就说我要部署大模型但其实第一步不是选框架而是先想清楚这模型跑在哪。目前主流无非四种本地裸机、云 GPU、容器化、Serverless/托管推理。它们不是互斥的实际项目里经常组合着用。本地裸机一台工作站或机柜里的服务器插一两张消费级显卡装个 Ubuntu驱动、CUDA、Python 环境自己配。优点是数据不出内网、没有按小时计的账单一次性投入后边际成本低缺点是供电、散热、驱动升级、环境维护全部自己扛出问题只能自己熬夜查日志。个人或小团队做技术验证这是最舒服的形态。我自己最早就是拿一张 3090 跑的 7B 模型花一个周末把环境理清楚后续切生产只是把同一套流程搬到云上。云 GPU按小时租用实例配置从单卡到整机都有。好处是弹性训练和推理高峰期随时扩不需要了直接释放坏处是长期占用比自建更贵而且每次开机都要重新考虑数据同步、镜像更新这些事。对绝大多数业务来说云 GPU 是生产效率最高的选择因为你买的是能跑 GPU 的时间而不是一台机器。容器化严格说不是部署形态而是解决环境一致性的基建。同一份镜像在开发机、测试机、生产机上表现一致依赖版本、CUDA 版本、模型路径全部锁进镜像里。后面讲生产流程时会专门展开这里先记住一句话只要开始做服务化Docker 基本绕不开。Serverless/托管推理平台把模型文件推到平台上平台帮你起容器、配 GPU、暴露 API你只需要调用接口。适合刚验证完效果、不想管运维的阶段缺点是长期成本高、定制性弱而且模型文件不掌握在自己手里。用于内部快速原型没问题核心业务我一般不建议长期挂在这儿。1.2 我的选型习惯先小后大先本地后云上这几年我养成了一个习惯任何大模型项目先拿本地机器把模型跑通验证业务效果再考虑上云和生产化。这样做的好处很明显模型没验证之前买云 GPU 都是花冤枉钱而在本地验证时优先选 Ollama 这类轻量方案十分钟就能用上一个量化好的 7B 模型。验证完效果决定上生产之后再按流量和并发重新选框架。这时候通常的做法是容器化 云 GPU vLLM/SGLang这套组合能把开发和运维成本压到最低。本地裸机反而常用于数据敏感、内网隔离要求高的场景。简单说选形态不是选最先进的而是选当前阶段最省事的。2. 推理框架选型vLLM、SGLang、TensorRT-LLM、Ollama 各自怎么定位2.1 主流框架对比表部署形态定了真正头疼的是推理框架。2026 年的主流选择里先给一张对比表后面再逐个讲背后的逻辑。框架核心机制适合场景上手难度备注vLLMPagedAttention、Continuous Batching高并发在线服务中生态最大自带 OpenAI 兼容接口SGLangRadixAttention、结构化生成长上下文、多轮、Agent 场景中新锐迭代快TensorRT-LLM预编译 Engine、算子融合全 NVIDIA 卡、低延迟优先高N 卡专属调优成本高TGIHF 官方Flash Attention 优化中规中矩的在线服务低~中历史包袱新特性偏慢Ollama / llama.cppGGUF 量化CPU/GPU 混合个人、小团队、边缘低最容易上手不适合高并发这张表不是我拍脑袋写的背后都是实测过的差异。vLLM 之所以是当前在线服务的主流核心是 PagedAttention它把 KV Cache 像操作系统的分页内存一样按块管理显存利用率一下子拉高连续批处理又让 GPU 始终在干活。直观地说同样一张 4090跑同一个 7B 模型Ollama 可能只能稳接几个并发vLLM 可以直接吃几十个请求输出速度还更稳。SGLang 这两年起来得快原因是长上下文和 Agent 场景变多了。它的 RadixAttention 会把多轮对话中重复的前缀缓存复用反复调用工具、反复把同一大段背景塞给模型的场景下省 token 非常明显。如果你要做 Agent 或工具调用值得重点试一下。TensorRT-LLM 是 NVIDIA 官方的东西需要把模型预先编译成 Engine启动和换模型都比较麻烦但换来的是最低延迟和最高吞吐。全 N 卡集群、延迟指标卡得死的场景才值得投入时间去调它。TGI 是老牌方案HF 官方出品兼容性好但相比 vLLM 已经少了很多新特性新项目我不会首选它。2.2 关键原理PagedAttention、RadixAttention 与引擎编译选框架如果只看名字是没法选的关键在于理解它们解决问题的路径。这里用最直白的话讲一下几个核心机制。PagedAttention模型推理时每个请求都要维护一份 KV Cache存已经算过的 Key 和 Value。不同请求长度不一样如果按最大长度提前分配一整块显存浪费就很大。PagedAttention 的思路是像操作系统分页一样把 KV Cache 切成小块按需分配还支持多个请求共享同一段前缀。原理听起来简单但这一项就把显存利用率从够用变成了够跑很多并发。RadixAttentionSGLang 的做法是把所有请求的 KV Cache 建成一棵前缀树。两个请求如果开头几轮是相同的系统提示词后面就没必要重新计算直接复用前面的缓存。这就是 SGLang 在长上下文、多轮对话里省时间的根本原因。引擎编译TensorRT-LLM 走的是另一条路它把模型、算子、显存布局全部在部署前固定下来生成一个高度特化的执行计划运行时不走通用逻辑只执行最优路径。代价是模型要预先 build换一次模型要忍受十分钟以上的编译时间换来的是延迟和吞吐的收益。2.3 一套能直接用的选型逻辑看再多对比落到自己项目里还是要有个判断顺序。我的做法很简单先回答三个问题模型多大、并发多少、延迟要求多高。如果是个人技术验证或者内部小团队用并发个位数、延迟不敏感别折腾直接用 Ollama模型选 GGUF 量化版一条命令启动自带 OpenAI 兼容接口省心到极点。如果是面向业务系统的正式 API并发可能要几十上百直接上 vLLM它自带 OpenAI 兼容接口业务方几乎零改造。如果是 Agent、工具调用、多轮对话为主的场景SGLang 值得优先考虑。如果公司本来就是全 NVIDIA 卡并且对延迟有硬指标再考虑 TensorRT-LLM。顺便说一句框架没有最好只有在当前场景下最合适。我会同时装 vLLM 和 SGLang模型文件在本地切换只改启动脚本实测哪个更合适就留哪个。3. 微调这一步别跳过LLaMA-Factory、Axolotl、Unsloth 怎么选3.1 为什么部署前要过一遍微调很多人把部署理解为把基座模型跑起来给接口这是最容易被坑的地方。基座模型是通用能力你的业务需要固定格式的回复、特定术语、特定语气光靠 Prompt 能解决一部分但解决不了全部。微调尤其是 LoRA 这类轻量微调在部署流程里其实是性价比最高的一环。它不重训整个模型而是给权重加一个低秩增量矩阵训练时只更新这个增量省显存省时间。QLoRA 更进一步把基座量化到 4bit让单张消费卡也能微调 7B 模型。一个 7B 模型全参数微调要几十 GB 显存QLoRA 可以把峰值压到 16GB 左右这个差距对大多数人来说是能做和做不了的区别。做微调有几个原则我反复跟团队讲数据质量永远比数据量重要格式一致性决定模型输出稳定性LoRA rank 不是越大越好常用 8 到 128 之间学习率一般从 1e-4 左右起步调target_modules 通常选 q、k、v、o 全上。微调完用测试集抽样例看输出格式别只看 loss 降没降——loss 降了不一定代表输出能直接用。3.2 常用微调工具对比与关键参数微调工具这几年也卷起来了我常用的几个放在表里对比。工具特点适合谁一句话总结LLaMA-FactoryWebUI CLI大量开源模型适配新手、业务工程师开箱即用LoRA 全家桶AxolotlYAML 配置社区活跃有经验的研究/工程者灵活但得自己折腾Unsloth省显存、训练快个人实验、快速验证效率优先DeepSpeed / FSDP全参数微调、ZeRO大集群、全量微调为了规模化LLaMA-Factory 是我最常用的起点。它把模型加载、LoRA、QLoRA、数据集格式、训练参数全部封装好WebUI 点一点也能跑命令行跑更方便进 CI。Axolotl 适合需要精细控制训练流程的人YAML 配置文件写清楚之后跟实验可复现性配合得很好。Unsloth 适合小规模快速验证一句话微调效果训练速度快显存占用低。大规模全参数微调才轮到 DeepSpeed 和 FSDP它们解决的是多机多卡如何切分模型和梯度的问题不是大多数中小团队日常用得上。微调完不是直接能部署LoRA 增量还要跟基座合并成完整权重合并后再拿去量化、再进推理框架。这一步别省特别容易出问题的是合并后忘记测一遍输出直接上线导致线上结果跟预期不一致。我会在模型版本化里专门强调每个微调版本都要记录基座版本、LoRA 配置、数据版本、评测结果否则一周之后你根本不知道线上跑的是哪个组合。4. 硬件与资源规划显存、算力、并发账先算清4.1 显存估算权重、KV Cache、激活值硬件规划的起点是显存显存的账算不清后面全是坑。一张显卡的显存要装四样东西模型权重、KV Cache、激活值、框架本身的冗余。其中激活值在推理阶段占比不如前两者高重点看权重和 KV Cache。以 7B 模型为例BF16 精度下权重大概是 14GB也就是参数数量乘以 2 字节。如果做 4bit 量化权重降到 3.5 到 4GB 左右。KV Cache 的估算公式大概是batch 大小乘以序列长度乘以层数乘以隐藏维度乘以 2K 和 V 各一份再乘以每个元素字节数。常见的 7B 架构是 32 层、隐藏维度 4096跑 8K 上下文、batch 为 1 时KV Cache 大概在 4GB 上下。这个数字乘以并发 batch 数就知道一张卡到底能兜住多大的上下文和多少并发。所以生产环境里经常看到好像显存够、跑起来 OOM的现象多半是没把 KV Cache 算进去。我的习惯是先设一个 max_model_len把上下文长度卡住再算每张卡能支持多少并发。默认跑 8K 上下文看起来很美好但如果并发一上来就爆显存不如先设 4K把稳定性和吞吐保住。4.2 GPU选型与量化方案的性价比GPU 选型没有一个万能解但可以按显存规模先粗筛。个人常用的几个卡型大致如下。GPU显存显存带宽量级适合的模型规模RTX 3090 / 409024GB约 900GB/s~1TB/s7B 量化、14B 量化、小并发A10G24GB约 600GB/s7B 量化、轻量服务A100 40G/80G40/80GB约 1.5~2TB/s7B/14B FP16、更大模型量化H10080GB约 3TB/s 级别大模型训练与高并发推理这里面容易被忽视的是显存带宽。模型推理是带宽密集型任务尤其单并发场景下带宽决定了 token 产出速度。24GB 的 4090 带宽比 A10G 高不少跑同样模型单人体验反而更好这也是为什么消费级卡在自建场景里很流行。如果在云上按实例选型别只看显存大小把带宽量级也拉出来对比。量化方案也要聊几句。目前主流有 AWQ、GPTQ、GGUF、FP8 这几类。AWQ 和 GPTQ 是 4bit 量化精度损失相对小适合跑 vLLM 这类服务化框架GGUF 是 Ollama 和 llama.cpp 的格式支持 2bit 到 8bit 的量化等级适合轻量部署FP8 在 Hopper 架构上原生支持省显存省带宽是未来在线服务的大方向。很多人把量化当成迫不得已才做的事我的看法正好相反量化是投入产出比最高的性能优化手段只要精度损失在业务可接受范围内能上就上。4.3 CPU内存与并发之间容易被忽略的关系除了显存CPU 内存也经常是瓶颈。一个 7B 模型4bit 量化后权重虽然只有 4GB但加载时多少要占一部分宿主内存多个模型并发加载的时候内存很容易被吃满。还有 tokenizer、缓存、日志、监控 agent七七八八加在一起一台服务器配 32GB 内存跑 7B 服务其实不算宽裕。另一个典型误区是用 CPU 推理做备份。CPU 上跑大模型不是不行但速度跟 GPU 差两个数量级一旦线上流量突然涨CPU fallback 会让整个系统变慢甚至比直接拒绝请求还糟糕。我自己只在纯本地实验时会跑 CPU 推理生产环境宁可少配一张卡也不会把 CPU 推理当兜底。并发估算这块与其用理论公式不如直接跑压测。起一个 vLLM 服务用并发工具逐步加请求观察 TTFT首个 token 生成时间和 TPOT每个 token 的生成时间的变化。这两个指标一个是响应快不快一个是打字快不快在线业务两个都要盯。跑几轮压测之后你会对这张卡配这个模型能扛多少并发有非常直观的认识比拍脑袋估的靠谱得多。5. 云GPU还是自建GPU2026年的账单、弹性与容易算漏的成本5.1 自建与云GPU的账本自建还是上云本质是一道成本账。自建的优势是长期持有时边际成本低一台多卡服务器买下来之后日常开销主要是电费和机房费用。但它有三个隐性成本硬件折旧、运维人力、GPU 利用率。大多数人忽略最后一个GPU 利用率一旦低于百分之二三十自建其实比云上按量计费更贵因为你为闲置时间付了全款。云 GPU 的优势是弹性。业务流量起来了扩容一张卡只需要几分钟流量降了释放实例账单立刻停。对绝大多数业务来说这个弹性带来的收益远超单价差异。我的建议是评估期用云稳定期再根据实际占用算账。如果确定一年 365 天都在跑、利用率能到百分之七十以上再考虑自建。5.2 云GPU的三个隐蔽成本竞价实例、带宽、数据盘云 GPU 的坑不是单价贵而是算漏成本。第一个是竞价实例。很多云厂商提供价格便宜很多的竞价实例适合训练任务这种可以中断重启的场景但不适合推理服务——一旦实例被回收线上就断了。所以竞价实例要配合多副本和自动拉起机制才能用于推理别为了省钱省掉容错设计。第二个是带宽费用。GPU 实例的带宽计费通常比 CPU 实例更敏感按量计费模式下推理服务如果对外提供大流量接口每月的网络账单可能比 GPU 费用还高。生产服务必须把公网入口和模型节点分层公网只承担入口转发内部走内网传输省下的流量费非常可观。第三个是数据盘和快照。模型文件动辄几十 GB每次开机从对象存储拉模型要等很久所以一般会挂一块数据盘缓存模型。数据盘和快照是按月计费的小钱但积少成多我见过有团队年底复盘才发现几块闲置盘交了一年钱。云上资源一定要定期盘点释放不用的数据盘和实例。这里顺便说一个团队联调的小经验如果云上实例固定时段用可以用定时启停的方案配合内网穿透工具把开发环境映射出去给同事联调比如常见的 frp 用法。白天开、晚上关账单能压到很低前提是你记得做数据落盘和自动启停的脚本。这条只适用于开发和演示场景正式生产还是得保持实例常驻。5.3 一句话回复工业AI部署场景经常有人问像工业质检、服装检测这类 AI到底用云还是单机用的什么大模型这类场景大多数走的根本不是大语言模型路线。工业缺陷检测、服装瑕疵识别主流方案是目标检测和图像分类模型比如 YOLO 系、RT-DETR 这类视觉模型部署形态是工厂局域网内的单机或边缘盒子模型体积小、推理延迟低数据不出厂区。只有在需要把检测结果生成质检报告、或做自然语言交互的时候才会配一个轻量语言模型做文案生成。如果你要部署的是这类业务先别急着选 LLM 框架把视觉检测模型跑好才是正事。大语言模型在这里只是辅助角色用 Ollama 起一个小的量化模型完全够用。6. 生产级部署流程从模型仓库到灰度上线的七步检查表6.1 模型版本化与环境容器化进入生产第一步不是写部署脚本而是先把模型和环境管起来。模型版本化的意思是每次部署都要记录一份模型清单包含模型来源、仓库 revision、微调后的合并权重、量化方式、Prompt 模板、评测结果。不要小看这个清单线上出问题时能让你十分钟内定位这版本是谁改的、改了什么而不是翻聊天记录。环境容器化同样关键。一个推理服务涉及 Python、PyTorch、CUDA、推理框架、依赖库任何一个版本不一致都会导致我本地能跑线上不能跑。我的做法是基于推理框架的官方镜像写 Dockerfile锁死依赖版本把模型路径和环境变量都写清楚。镜像构建完先在本机跑通一次再推到仓库。这一步做好之后换机器部署的时间可以从一个下午缩短到十分钟。6.2 API入口、网关与监控服务化之后接口设计直接决定业务方改造量。首选方案是暴露 OpenAI 兼容接口目前主流推理框架都内置这个协议业务方只要按标准格式调用就行。鉴权用 API Key入口加限流和超时控制流式输出必须支持因为大模型接口基本都是流式响应前端要打字机效果网关配置不对会卡很久。负载均衡层的配置要特别注意长连接。推理接口的回答时间可能几十秒网关如果默认超时时间太短请求会被中途断开。我自己踩过这个坑Nginx 配置里只调大了 proxy_read_timeout其他参数没动结果长文本生成时接口表现非常奇怪。网关和推理节点之间的连接要按业务超时上限配置不能套用普通 Web 服务的默认值。监控更是一开始就要铺。至少监控这几个指标GPU 利用率、显存占用、QPS、TTFT、TPOT、错误率。推理框架一般自带 metrics 端点配合 Prometheus 和 Grafana 就能搭起来。没有监控的线上推理服务等于盲跑出问题只能靠用户先发现。6.3 灰度、回滚与安全项模型换版本是生产里最危险的操作之一。同一套 Prompt、同一个模型版本效果可能因为输入数据分布变化而退化不能只靠离线评测拍板。灰度发布的做法是新旧两版模型同时在线先在权重里切一小部分流量到新版本观察线上错误率和用户反馈再逐步放大。回滚路径也要提前准备好一旦发现异常把流量切回旧版本比重新部署快得多。安全这块容易被人忽视。模型服务暴露在公网至少要处理几件事接口鉴权、限流、输出内容审核、防止提示词注入。文件上传接口如果有必须做类型和大小校验绝对不能把用户上传的内容直接当系统指令拼进 Prompt。内网部署和公网部署的安全模型完全不同只要接了公网就要按生产标准做安全加固。模型本身也要做好输出治理哪怕内部使用也一样避免生成内容进入业务流程造成不可控影响。7. 实战排障实录显存、速度、乱码这些高频问题的排查套路先放一张速查表再逐个展开说明。这张表基本上覆盖了我日常收到的大部分模型服务跑了但不对的问题。现象大概率原因第一步排查启动即 OOM权重 KV Cache 超显存调小 max_model_len量化运行中突然被杀显存峰值或宿主内存压力nvidia-smi dmon 盯峰值推理很慢未开并发批处理 / CPU fallback / swap看 GPU 利用率与内存换页容器看不到 GPU未装 nvidia-container-toolkit / 漏加 --gpus all宿主机 nvidia-smi容器查 /dev/nvidia*报 sm_ 架构错误CUDA/PyTorch 版本不匹配重装匹配的框架版本输出截断max_tokens 太小调大并同步调大网关超时中文乱码编码或 tokenizer 异常检查 UTF-8 编码与模型版本7.1 显存OOM与推理变慢显存不足是最常见的生产事故。现象很好认进程启动没问题一接请求就 OOM或者跑几分钟后被杀掉。排查顺序是先看实际显存占用用 nvidia-smi 和 nvidia-smi dmon 盯一会儿确认是权重超了还是 KV Cache 撑爆了。解决手段按优先级先限制 max_model_len、调低 max_num_batched_tokens再考虑量化最后才换大显存卡。不要一上来就买大卡先把参数调对。推理变慢的原因更隐蔽。常见的有请求并发没开起来导致 GPU 空转代码里用了 CPU fallback上下文太长导致 token 计算量暴涨系统 swap 触发导致读取模型权重都变慢。排查时先看 GPU 利用率利用率低说明瓶颈在调度或数据准备利用率高但响应慢说明是算力或显存带宽问题。再查系统日志确认有没有 swap 或异常调度。这两个方向基本能覆盖九成突然变慢的问题。7.2 Ollama模型文件、容器GPU、CUDA等系统级问题还有一个高频问题Ollama 安装的模型到底是什么文件。Ollama 拉下来的模型存放在用户目录下的 ~/.ollama/models/blobs 里文件名是一串哈希没有可读性实际内容是 GGUF 格式的二进制文件。很多人查了半天以为模型丢了其实只是路径太隐蔽。如果你想手动管理模型直接把 GGUF 文件拷到 Ollama 的模型目录或者改用 llama.cpp 都可以Ollama 只是一个启动器和进程管理器真正干活的是底层 llama.cpp 那套运行时。容器里访问不到 GPU 是另一个经典问题。现象是容器能启动但跑模型时报错找不到 CUDA 设备。原因基本是宿主机没装 NVIDIA Container Toolkit或者 docker run 时没加 --gpus all。先确认宿主机 nvidia-smi 正常再检查容器里是否有 /dev/nvidia* 设备两步就能定位。千万不要在容器里重装显卡驱动驱动跟着宿主机走容器只需要运行时。CUDA 版本对不上也很常见。报错信息往往是一串以 sm_ 开头的架构标识说明当前 PyTorch 或推理框架编译的目标架构跟驱动支持的架构不一致。常规解决办法是重新安装匹配的 PyTorch 或框架版本而不是升级驱动。驱动只要满足最低版本要求向上兼容通常更稳。7.3 输出截断与中文乱码输出截断十有八九是 max_tokens 设置太小。模型生成有 token 数量上限长报告或长代码场景下默认的几百个 token 根本不够。把生成参数的 max_tokens 调大同时注意响应超时配置要跟着变大不然生成到一半网关先断了。中文乱码的原因看场景。终端里乱码通常是编码问题把终端编码切到 UTF-8接口返回乱码则是 Prompt 或后处理逻辑的问题检查请求参数是否按 UTF-8 编码、返回内容是否做了正确解码。还有一类隐蔽场景是模型把中文 tokenize 得特别碎导致输出偶尔出现半个字或不连贯这种情况一般是模型或量化版本的问题换一个 tokenizer 正常的模型版本即可。最后说点个人习惯。每次接新机器我一定先写一段小脚本把 GPU 信息、CUDA 版本、模型加载日志全部打出来再跑一个几十行的冒烟测试确认 Generate 接口通了才往上叠服务。这个流程听着慢但真的能省掉后面排障的一大堆时间。部署的本质是让模型稳定地对外服务而不是把模型跑起来就算完。如果你也是第一次做大模型服务器部署建议从 Ollama 起一个 7B 量化模型开始跑通链路再一步步换成 vLLM、加上监控和灰度——这条路我走了很多遍是绕坑最少的一条。