1. 部署前最重要的不是选框架而是先定位场景我接触过的不少团队拿到部署大模型这个任务后第一反应就是搜框架排名vLLM 还是 SGLang群里的朋友推荐了哪个然后照着最热门的方案拉一个镜像模型放上去能回复就开始欢呼。但这样做往往撑不过两周——要么并发一上来延迟直线飙升要么微调需求一出现又要推倒重来。到了 2026 年大模型服务器部署早就不是跑起来这么简单了。模型文件该怎么放、用哪个推理服务暴露接口、云主机选什么规格、怎么在不暴露内网风险的情况下对外开放服务这些才是决定项目长期可维护的关键。本文就围绕我自己从 2024 年到 2026 年真实部署过的几条路线展开把框架选型、云服务对比和生产级流程讲透至少能帮你省下几轮部署完发现设计错了的返工成本。1.1 三种典型场景决定完全不同的技术路线我先说结论不同场景对框架、硬件、云资源的需求几乎是互斥的。常见大模型服务器部署场景大致分成三类。第一类是在线推理服务。典型表现是公司内部 AI 应用、客服机器人、代码助手这类需要实时响应的业务。这类场景的核心指标是首字延迟TTFT、单用户交互流畅度、并发承载量。你可能需要一个 OpenAI 兼容的 API 服务让业务端不用改代码就能接进来。推荐的路线是 vLLM 或 SGLang选型理由后面详细讲。第二类是微调 推理一体化的平台。团队不只部署一个现成模型还需要周期性用企业内部数据微调然后把微调产物直接上线。这类场景关注的不只是推理性能还包括显存利用率、训练与推理的资源调度平衡。LLaMA-Factory 这类支持全参数、LoRA、QLoRA 微调和推理的一体化框架会更合适。第三类是批量离线推理。比如用模型跑大量文档解析、知识库向量化前的文章总结、批量打标签等。这类任务不在乎首字延迟和并发只在乎单位时间吞吐量能跑得越久越划算。这时候你可以选择 TensorRT-LLM 做极致吞吐也可以直接用 SGLang 的离线批处理能力配合抢占式云实例把成本压到最低。我见过最典型翻车案例是什么一个团队租了 4 卡 A 系列 GPU 云主机想做一个内部知识库 QA 机器人结果因为没用流式输出、又没做并发限制模型推理线程被单请求长时间占住客服团队接入不到 10 个人就频繁超时。问题不在框架在于他们压根没问自己这个服务器主要服务谁、大概多少人同时用。1.2 先定模型规模和显存预算再倒推框架大模型框架选型还有一个前提算力边界。2026 年主流部署的模型从 7B 到 70B 不等量化等级从 FP16、INT8 到 INT4/HQQ 都有。显存 24G、48G、80G 这三种主流配置对应完全不同的部署策略。拿 7B~8B 级别模型来说FP16 大约需要 15GB 左右的显存用来装权重加上 KV Cache 和激活值一张 24G 卡比如 RTX 4090、L4、A10勉强能跑单实例但如果并发打到 20 以上24G 大概率不够。这时候更实际的做法是 INT8/W4A16 量化把权重压到 7GB 以下给 KV Cache 留出充足空间。你要是直接用 vLLM 默认的 FP16 加载加上高频调度一张 24G 卡并发一高就开始 OOM这是很多新手第一道坎。而 70B 级别模型哪怕 W4A16 量化也接近 45GB 权重内存加上 KV Cache至少需要 2×48G 或者 80G 单卡才够推理。如果还想做微调那显存占用会翻着倍涨预算差距巨大。所以我的习惯是先算这个简表模型规模量化方式权重占用推荐 GPU 组合典型场景7B-8BFP1615GB1×24G在线对话、代码助手7B-8BINT8/W4A164-8GB1×16G/24G高并发轻量服务13B-14BINT814GB1×24G中等复杂度任务32B-33BINT833GB1×48G 或 2×24G强推理任务70BINT8/W4A1667GB/45GB2×48G 或 1×80G通用大参数量服务70B多卡并行视量化而定4×80G高精度生产服务这套账算清楚了框架选择就很有针对性单卡场景优先 vLLM 或 SGLang多卡并行的生产服务可以上 TensorRT-LLM多模型、多任务切换频繁的情形又要认真考虑灵活性和运维成本了。2. 框架选型推理和微调不能用同一套标准很多人容易把部署框架和微调工具混为一谈。实际到了 2026 年这个领域分化非常明显推理侧拼的是吞吐、显存复用、调度效率微调侧拼的是内存优化、训练速度、配置便利性。你要是在推理服务里混进训练框架或者在微调任务里硬套推理框架都会处处别扭。2.1 推理框架横向对比vLLM、SGLang、TGI、TensorRT-LLM框架核心优势典型劣势适合场景vLLMPagedAttention 显存管理成熟生态最大OpenAI 兼容接口开箱即用极端长上下文和复杂调度场景略逊于 SGLang绝大多数在线推理服务SGLang调度优化激进RadixAttention 对多轮对话/前缀缓存增益明显新版迭代快配置项偏前沿稳定性需要测试高并发多轮对话、批量推理TGIHuggingFace 官方团队维护对 HF 生态兼容最好性能表现在这几家里相对中庸和 HF 生态深度绑定的老项目TensorRT-LLMNVIDIA 亲儿子推理吞吐上限最高模型转换复杂动态形状支持麻烦对成本极敏感、流量固定的批处理生产环境多数场景我会优先推荐vLLM因为它已经把在标准 GPU 上跑起来这件事做到最简单。2026 年的 vLLM 默认支持了连续批处理、前缀缓存、投机采样开箱即用。启动命令比两年前简洁得多vllm serve /data/models/meta-llama/Llama-3.1-8B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen-7b \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --enable-prefix-caching如果并发对话特别多我会切到 SGLang。它的 RadixAttention 在多轮对话中是实打实的收益——公共前缀直接复用 KV Cache服务端不用重复计算显存使用率会有可感知的提升。代价是 SGLang 的更新节奏太快有时候一些小版本之间配置会变上生产之前必须压测一轮。我自己就吃过亏以为只是小版本升级结果某个 Launch 参数被移除了服务直接启动失败。TensorRT-LLM 是最后一类选择。如果你的流量足够大、路径足够长值得花一周时间把模型转换流程整理顺。但它对动态 batch 和动态形状的支持不如 vLLM 灵活业务侧请求频繁变化时会增加不少匹配成本不建议中小团队一上来就搞。2.2 微调工具选型LLaMA-Factory 与主流方案的边界说完推理再聊微调。2026 年主流的微调工具框架选型集中在 LLaMA-Factory、Axolotl、unsloth 这几条线。LLaMA-Factory是目前覆盖面最广的选择也是我的首选。它把全参数微调、LoRA、QLoRA、DPO、ORPO 都收编到一套配置体系里YAML 写好就能跑。对大模型服务器部署来说这种一体化能力很省事同一套环境里先微调微调完直接导出 checkpoint再挂到前面的 vLLM 服务里发布出来。新手引导也做得好出问题网上能找到大量案例。unsloth的优势在于 LoRA 训练显存占用极低速度比原生 Transformers 快不少。如果你主要做 7B~32B 级别的 LoRA 微调而且卡比较紧张unsloth 几乎是最佳选择。它对长上下文训练优化很到位单张 4090 上微调 32B 也不是神话级别的事。不过它的设计思路贴近实验室和个人开发者想接入企业级训练流水线时需要多封装一层。Axolotl用 YAML 配置驱动自由度更高适合有算法工程师深度参与、需要精细控制训练各阶段参数的团队。它支持的模型家族和数据集格式很广甚至能处理多模态训练。代价是学习曲线陡出错时排查成本高。选择微调框架之前请先问一个问题微调产物最后要不要部署到生产很多团队用 HuggingFace Transformers 直接训完然后不知道怎么接回推理服务。其实微调完以后建议统一导出成 HF 或 GGUF 格式再由 vLLM/SGLang 做服务化。流程上可以这样走unsloth 或 LLaMA-Factory 训练 LoRA → 合并权重 → 输出到模型目录 → vLLM 拉起服务 → 压测确认效果。3. 云服务对比单价之外这几项才是真正的性价比分水岭2026 年买 GPU 云服务器单看芯片型号很容易踩坑。同一个 A100在不同云厂商的售价、计费方式、带宽和存储策略差别极大。这里把影响实际使用体验的关键项拉出来对比一下。3.1 主流云厂商 GPU 实例的算力价格场国内市场目前可选的就那几个主力厂商阿里云、腾讯云、华为云、京东云海外则有 AWS、Azure、GCP 系。按 2026 年初的市场行情不同规格的 GPU 实例价格不再像 2024 年那么夸张但依然是预算大头。厂商代表实例GPU 配置计费模式备注阿里云ecs.gn7i-c16g1.4xlarge1×A10包年包月约 4000-5000 元/月国内生态完善按量秒级计费方便阿里云ecs.gn6v-c10g1.20xlarge8×V100竞价实例可低至按量 1-2 折适合离线任务腾讯云GN7vw / GN10Xp1×T4 / 1×A100包月灵活活动价波动大游戏/音视频业务常用华为云Pi2 / Pnt11×T4 / 昇腾310对昇腾生态有特别优化自研芯片适配需特殊调试AWSg4dn / p4d / g5T4 / A100 / A10G按小时计价长期用有 Saving Plan海外节点网络延迟要测试AutoDL 类多种共享 GPU4090/3090 等按小时性价比高但隔离性一般这里我的经验是国内面向业务生产首选阿里云和腾讯云重点看安全组、弹性 IP、VPC 这些网络能力如果你跑的是离线批处理且能容忍实例中断用竞价实例能省下大量成本如果只是想快速调试验证共享 GPU 平台按小时租更划算。3.2 带宽、存储与自动快照比 GPU 型号更值得关注很多人的误区是 GPU 选好就完事了。实际上大模型部署项目里模型文件下载、推理服务对外响应、日志收集这些环节对带宽和存储 IO 的依赖远高于普通 Web 服务。先说带宽。国内云厂商默认公网带宽很小严重的时候 5Mbps 都算低配。你要是从 HuggingFace 拉一个 70B 的模型文件FP16 大约 140GB5Mbps 带宽要下整整两天多。所以我的习惯是先用对象存储或者内网镜像把模型文件放到与云服务器同地域的存储桶里再用内网传输速度能翻几十倍对外服务带宽按业务量估动态对话场景每个并发大约消耗 2-5Mbps建议预留至少 20Mbps 起步。再说存储。GPU 实例的数据盘直接决定模型加载时间用普通云盘加载 100GB 模型可能要几分钟用高性能 ESSD 能把加载压缩到几十秒内。如果模型文件大、又要频繁做版本切换建议单独买一块 ESSD 云盘挂载在 /data 下不要把系统盘和生产数据混在一起。最后是自动快照。大模型部署最怕什么微调之后模型权重出错、配置文件被改坏、环境依赖炸了。给 GPU 实例数据盘按天做自动快照是最便宜的保险几块钱一个月的成本能在灾难恢复时把重建时间从小时级压到分钟级。4. 生产级部署流程从模型文件到可对外服务的完整链路拿到框架选型和云资源以后部署流程的套路其实相当固定。下面是我一个 80G 单卡实例 vLLM 部署 70B 量化模型的完整过程。这套流程我重复过很多次改改路径和版本号就能直接抄。4.1 模型准备、目录规范与启动服务第一步模型文件准备。不要直接从 HF 下载完就乱放。我统一用下面的目录结构/data/models/ workspace/ model_name/ config.json model.safetensors.index.json model-00001-of-0000x.safetensors tokenizer.json tokenizer_config.json检查点很关键必须是safetensors格式因为这格式规范简单、加载速度快还能带上 JSON 索引vLLM 加载时不用预扫描整个目录。如果是别人给的bin旧格式优先做一次转换避免加载时爆内存。第二步用 Docker 起服务是最省心的做法。2026 年 vLLM 官方镜像已经足够完善我直接拉官方镜像宿主机只装 NVIDIA 驱动和容器运行时docker run -d --gpus all \ --ipchost \ -v /data/models:/models \ -p 8000:8000 \ --restartalways \ --name vllm-70b \ vllm/vllm-openai:latest \ --model /models/workspace/model_name \ --served-model-name model-name \ --gpu-memory-utilization 0.92 \ --max-model-len 4096 \ --host 0.0.0.0 \ --port 8000--ipchost这个参数一定要加不加在某些环境下会出共享内存不足的问题。--gpu-memory-utilization不要无脑设满 0.95留在 0.9 左右给 CUDA 上下文和驱动留点余量能避免不少玄学 OOM。第三步做一次最基础的健康检查。服务起来后先不要急着接业务用 curl 直接验证响应curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: model-name, messages: [{role: user, content: 你好请做一句话自我介绍}], max_tokens: 200, stream: true }注意这里用的是流式返回生产环境我强烈建议所有大模型接口都开流式。原因很简单模型生成几十到几百个 token 需要几秒如果非流式前端界面会一直转圈用户体感极差流式以后用户 300ms 内就能看到第一个字。4.2 压测、监控与灰度发布三板斧部署完成不等于生产就绪。我把压测放在第四步因为基础设施和模型目录调整完了以后压测的数据才有参考价值。压测工具有很多2026 年比较稳的是用vllm bench这种内置工具简单配置一下并发、输入输出长度就能跑vllm benchmark --model /models/workspace/model_name \ --requests 200 \ --concurrency 32 \ --input-len 512 \ --output-len 256重点关注两个数字TTFT首 token 延迟和吞吐output tokens/s。比如单张 A100 跑 70B INT4压测输出如果吞吐能稳定在 200 tokens/s 以上说明服务基础状态不错要是 TTFT 明显波动先查前缀缓存是否开启、KV Cache 是否卡在显存边界。监控和日志这块生产环境一定不能裸奔。最简单的做法是我一直沿用的组合vLLM 服务自带 Python 日志加上 GPU 状态实时监控脚本甚至用 Prometheus Grafana 采集nvidia_smi指标设定显存占用阈值告警。下面这段脚本是我最早部署时就一直在用的#!/bin/bash while true; do GPU_UTIL$(nvidia-smi --query-gpuutilization.gpu,memory.used,memory.total \ --formatcsv,noheader,nounits | awk -F, {print $1,$2/$3}) echo $(date %Y-%m-%d %H:%M:%S) $GPU_UTIL /var/log/gpu_monitor.log sleep 10 done灰度发布的操作相对简单了模型更新时另起一个容器实例用新的端口 or 新的--served-model-name先让内测用户访问确认效果没问题再切换网关的路由权重把流量从旧服务平滑迁移到新服务。我通常用 Nginx 做这个三层代理配一次权重分流就能长期复用。5. 没有公网 IP 时用一台轻量 ECS 完成内网穿透与安全暴露很多开发者的 GPU 环境其实是放在机房、实验室或者自己有内网 IP 的工作站上并没有直接分配公网固定 IP。这时候想把服务展示给同事、客户或者部署到云上的统一入口面临一个很现实的问题怎么让外网访问到内网里的 GPU 服务买公网 IP 绑定到内网机器很多机房不提供服务而且价格不低。直接改内网设备映射公网配置危险又容易暴露整个内网。我在这块试过不少方案最稳定的组合是一台廉价的公网 ECS 做转发节点 frp 内网穿透工具把 GPU 服务器的推理端口转发过去。这也是社区里很多人一直在提的免费思路——frp 本身完全开源官方有免费服务端/客户端你只需要付一台最低配 ECS 的钱甚至能和其他服务共用这台 ECS。5.1 为什么 frp 方案适合大模型部署场景frp 的核心逻辑很简单内网机器主动向外网的 frp server 建立一条长连接然后外部用户访问公网 ECS 的某个端口时请求会通过这条连接被转发到内网 GPU 机器的对应服务上。用户看到的是 ECS 的 IP 和端口实际干活的是内网 GPU。整个过程对 vLLM 等推理服务是透明的服务本身不用做任何改动。对大模型部署场景来说frp 有三个特别合适的点端口即服务。GPU 机器上启动的 vLLM 默认监听 8000 端口frp 客户端把这个端口完整映射到公网 ECS 的 8000 端口外网拿着http://公网IP:8000/v1/chat/completions直接请求和请求一台真正的公网 GPU 服务器没有区别。安全性收紧在公网侧。你不需要暴露 GPU 机器的任意其他端口只映射 8000 这一个端口即可内网其他设备不会被波及。成本低。frp server 常年占用资源极低一台 1 核 1GB 的轻量 ECS 就足够支撑几十个并发的转发。5.2 frp 配置实操与安全注意事项frp 的部署分两步。第一步在公网 ECS 上启动 frps 服务端。2026 年的版本可以直接用 TOML 配置bindPort 7000 auth.method token auth.token your-strong-token allowPorts [{ start 8000, end 8005 }]其中bindPort是服务端监听端口auth.token是客户端认证凭据allowPorts限制允许映射的公网端口范围。这里我特别强调千万不要让 frps 允许任意端口映射。默认放开所有端口等于给内网开了一扇大后门入侵者只要能拿到一个客户端 token 就能把内网其他服务全暴露出来。第二步在内网 GPU 服务器上启动 frpc 客户端serverAddr 你的ECS公网IP serverPort 7000 auth.token your-strong-token [[proxies]] name vllm type tcp localIP 127.0.0.1 localPort 8000 remotePort 8000 transport.useEncryption true transport.useCompression truelocalIP用127.0.0.1意味着只转发本机 vLLM 端口不代理内网其他主机。transport.useEncryption true建议一定开避免推理数据明文走过公网链路。启动后外网就可以通过http://ECS公网IP:8000/v1/chat/completions调用你内网 GPU 上的大模型服务了。在实际使用中我把这个端口主要开放给公司内部业务和少量合作方测试。如果要暴露到更大范围前面必须加一层 API Key、IP 白名单或者 Nginx 的 Basic Auth。安全永远不能靠 frp token 一重保障生产环境应该做成多级防线。配置 frp 的时候有两个非常容易踩的坑ECS 安全组没放行端口。很多用户费了半天劲发现外网连不上其实云厂商安全组把端口挡在境外了。记得在 ECS 控制台把 7000frp 通信和 8000推理服务都加入安全组入方向规则。frpc 断线重连。内网机器重启后 frpc 如果没设成开机自启或者没有守护进程外网入口就悄悄断了。我用 systemd 托管 frpc加Restartalways和RestartSec5恢复速度比手动快得多。这台轻量 ECS 如果只是做 frp 转发服务器几乎跑不满负载你还可以直接在上面部署 Nginx承担后面静态资源或者 API 网关的职责——一台小机器做多种边缘功能成本控制更理想。6. 踩坑之后我总结出的几条无价经验文章最后不打算写空泛的总结直接分享我在真实部署过程中反复踩过的几个坑。这几条是文档里不会写、只有长期实际操作才能攒下来的经验。第一条经验别把最优框架和最优实践混为一谈。vLLM 再火不适合你团队的水平就是不适合。我带过的团队里有人一天就能玩转 SGLang有人在 vLLM 上跑了三个月还是只会改参数。选框架要结合团队维护能力别为了追求新特性牺牲稳定。第二条经验云资源采购永远要为回滚留一手。大模型服务最怕模型版本升级后业务侧出现异常比如新增的模型能力边界和旧版不一样。我现在的习惯是每次发布前必须先保存当前可用镜像和权重路径压测通过以后才推进生产。出了问题直接回滚到上一个 Docker 镜像五分钟恢复。第三条经验流量进来前先打好日志和监控的地基。这是我早期吃过最大亏的地方服务上线第一天就遇到调用方反馈有时候特别慢但我根本没有历史数据可查只能靠猜。后来我对所有推理请求都做了一条基础日志时间、请求内容大小、TTFT、输出 token 数、耗时。排查问题的时候这几项数据能直接定位链路上哪一环出了问题。第四条经验送给预算有限的个人开发者和中小团队生产环境不要把所有鸡蛋放在一个篮子里。模型服务、微调任务、对象存储、数据库尽量拆开规划哪些跑包年抢占式实例、哪些必须用稳定包年包月事先分清楚。我用阿里云 ECS frp 这套组合最频繁的场景其实是把实验室里一台 4090 工作站变成可供团队使用的大模型 API 服务器整体成本只多了一台轻量 ECS 的费用。这种成本控制思路在对外 demo、内部测试、小型产品落地阶段尤其有优势——先用最小的钱把链路跑通确认业务有真实需求后再往大规模 GPU 实例迁。最后关于部署这件事实话说一句大模型服务器的价值不在你用了多贵的卡、多新的框架而在于你能否稳定、低延迟、安全地把模型能力交到使用者手里。模型的选型和推进都是有周期的但部署流程、压测方法、安全策略、回滚预案这些基本功一旦沉淀下来之后换任何框架、迁移任何云平台都可以反复复用。先把手头这一套跑顺跑稳比什么都重要。
1. 部署前最重要的不是选框架而是先定位场景我接触过的不少团队拿到部署大模型这个任务后第一反应就是搜框架排名vLLM 还是 SGLang群里的朋友推荐了哪个然后照着最热门的方案拉一个镜像模型放上去能回复就开始欢呼。但这样做往往撑不过两周——要么并发一上来延迟直线飙升要么微调需求一出现又要推倒重来。到了 2026 年大模型服务器部署早就不是跑起来这么简单了。模型文件该怎么放、用哪个推理服务暴露接口、云主机选什么规格、怎么在不暴露内网风险的情况下对外开放服务这些才是决定项目长期可维护的关键。本文就围绕我自己从 2024 年到 2026 年真实部署过的几条路线展开把框架选型、云服务对比和生产级流程讲透至少能帮你省下几轮部署完发现设计错了的返工成本。1.1 三种典型场景决定完全不同的技术路线我先说结论不同场景对框架、硬件、云资源的需求几乎是互斥的。常见大模型服务器部署场景大致分成三类。第一类是在线推理服务。典型表现是公司内部 AI 应用、客服机器人、代码助手这类需要实时响应的业务。这类场景的核心指标是首字延迟TTFT、单用户交互流畅度、并发承载量。你可能需要一个 OpenAI 兼容的 API 服务让业务端不用改代码就能接进来。推荐的路线是 vLLM 或 SGLang选型理由后面详细讲。第二类是微调 推理一体化的平台。团队不只部署一个现成模型还需要周期性用企业内部数据微调然后把微调产物直接上线。这类场景关注的不只是推理性能还包括显存利用率、训练与推理的资源调度平衡。LLaMA-Factory 这类支持全参数、LoRA、QLoRA 微调和推理的一体化框架会更合适。第三类是批量离线推理。比如用模型跑大量文档解析、知识库向量化前的文章总结、批量打标签等。这类任务不在乎首字延迟和并发只在乎单位时间吞吐量能跑得越久越划算。这时候你可以选择 TensorRT-LLM 做极致吞吐也可以直接用 SGLang 的离线批处理能力配合抢占式云实例把成本压到最低。我见过最典型翻车案例是什么一个团队租了 4 卡 A 系列 GPU 云主机想做一个内部知识库 QA 机器人结果因为没用流式输出、又没做并发限制模型推理线程被单请求长时间占住客服团队接入不到 10 个人就频繁超时。问题不在框架在于他们压根没问自己这个服务器主要服务谁、大概多少人同时用。1.2 先定模型规模和显存预算再倒推框架大模型框架选型还有一个前提算力边界。2026 年主流部署的模型从 7B 到 70B 不等量化等级从 FP16、INT8 到 INT4/HQQ 都有。显存 24G、48G、80G 这三种主流配置对应完全不同的部署策略。拿 7B~8B 级别模型来说FP16 大约需要 15GB 左右的显存用来装权重加上 KV Cache 和激活值一张 24G 卡比如 RTX 4090、L4、A10勉强能跑单实例但如果并发打到 20 以上24G 大概率不够。这时候更实际的做法是 INT8/W4A16 量化把权重压到 7GB 以下给 KV Cache 留出充足空间。你要是直接用 vLLM 默认的 FP16 加载加上高频调度一张 24G 卡并发一高就开始 OOM这是很多新手第一道坎。而 70B 级别模型哪怕 W4A16 量化也接近 45GB 权重内存加上 KV Cache至少需要 2×48G 或者 80G 单卡才够推理。如果还想做微调那显存占用会翻着倍涨预算差距巨大。所以我的习惯是先算这个简表模型规模量化方式权重占用推荐 GPU 组合典型场景7B-8BFP1615GB1×24G在线对话、代码助手7B-8BINT8/W4A164-8GB1×16G/24G高并发轻量服务13B-14BINT814GB1×24G中等复杂度任务32B-33BINT833GB1×48G 或 2×24G强推理任务70BINT8/W4A1667GB/45GB2×48G 或 1×80G通用大参数量服务70B多卡并行视量化而定4×80G高精度生产服务这套账算清楚了框架选择就很有针对性单卡场景优先 vLLM 或 SGLang多卡并行的生产服务可以上 TensorRT-LLM多模型、多任务切换频繁的情形又要认真考虑灵活性和运维成本了。2. 框架选型推理和微调不能用同一套标准很多人容易把部署框架和微调工具混为一谈。实际到了 2026 年这个领域分化非常明显推理侧拼的是吞吐、显存复用、调度效率微调侧拼的是内存优化、训练速度、配置便利性。你要是在推理服务里混进训练框架或者在微调任务里硬套推理框架都会处处别扭。2.1 推理框架横向对比vLLM、SGLang、TGI、TensorRT-LLM框架核心优势典型劣势适合场景vLLMPagedAttention 显存管理成熟生态最大OpenAI 兼容接口开箱即用极端长上下文和复杂调度场景略逊于 SGLang绝大多数在线推理服务SGLang调度优化激进RadixAttention 对多轮对话/前缀缓存增益明显新版迭代快配置项偏前沿稳定性需要测试高并发多轮对话、批量推理TGIHuggingFace 官方团队维护对 HF 生态兼容最好性能表现在这几家里相对中庸和 HF 生态深度绑定的老项目TensorRT-LLMNVIDIA 亲儿子推理吞吐上限最高模型转换复杂动态形状支持麻烦对成本极敏感、流量固定的批处理生产环境多数场景我会优先推荐vLLM因为它已经把在标准 GPU 上跑起来这件事做到最简单。2026 年的 vLLM 默认支持了连续批处理、前缀缓存、投机采样开箱即用。启动命令比两年前简洁得多vllm serve /data/models/meta-llama/Llama-3.1-8B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --served-model-name qwen-7b \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --enable-prefix-caching如果并发对话特别多我会切到 SGLang。它的 RadixAttention 在多轮对话中是实打实的收益——公共前缀直接复用 KV Cache服务端不用重复计算显存使用率会有可感知的提升。代价是 SGLang 的更新节奏太快有时候一些小版本之间配置会变上生产之前必须压测一轮。我自己就吃过亏以为只是小版本升级结果某个 Launch 参数被移除了服务直接启动失败。TensorRT-LLM 是最后一类选择。如果你的流量足够大、路径足够长值得花一周时间把模型转换流程整理顺。但它对动态 batch 和动态形状的支持不如 vLLM 灵活业务侧请求频繁变化时会增加不少匹配成本不建议中小团队一上来就搞。2.2 微调工具选型LLaMA-Factory 与主流方案的边界说完推理再聊微调。2026 年主流的微调工具框架选型集中在 LLaMA-Factory、Axolotl、unsloth 这几条线。LLaMA-Factory是目前覆盖面最广的选择也是我的首选。它把全参数微调、LoRA、QLoRA、DPO、ORPO 都收编到一套配置体系里YAML 写好就能跑。对大模型服务器部署来说这种一体化能力很省事同一套环境里先微调微调完直接导出 checkpoint再挂到前面的 vLLM 服务里发布出来。新手引导也做得好出问题网上能找到大量案例。unsloth的优势在于 LoRA 训练显存占用极低速度比原生 Transformers 快不少。如果你主要做 7B~32B 级别的 LoRA 微调而且卡比较紧张unsloth 几乎是最佳选择。它对长上下文训练优化很到位单张 4090 上微调 32B 也不是神话级别的事。不过它的设计思路贴近实验室和个人开发者想接入企业级训练流水线时需要多封装一层。Axolotl用 YAML 配置驱动自由度更高适合有算法工程师深度参与、需要精细控制训练各阶段参数的团队。它支持的模型家族和数据集格式很广甚至能处理多模态训练。代价是学习曲线陡出错时排查成本高。选择微调框架之前请先问一个问题微调产物最后要不要部署到生产很多团队用 HuggingFace Transformers 直接训完然后不知道怎么接回推理服务。其实微调完以后建议统一导出成 HF 或 GGUF 格式再由 vLLM/SGLang 做服务化。流程上可以这样走unsloth 或 LLaMA-Factory 训练 LoRA → 合并权重 → 输出到模型目录 → vLLM 拉起服务 → 压测确认效果。3. 云服务对比单价之外这几项才是真正的性价比分水岭2026 年买 GPU 云服务器单看芯片型号很容易踩坑。同一个 A100在不同云厂商的售价、计费方式、带宽和存储策略差别极大。这里把影响实际使用体验的关键项拉出来对比一下。3.1 主流云厂商 GPU 实例的算力价格场国内市场目前可选的就那几个主力厂商阿里云、腾讯云、华为云、京东云海外则有 AWS、Azure、GCP 系。按 2026 年初的市场行情不同规格的 GPU 实例价格不再像 2024 年那么夸张但依然是预算大头。厂商代表实例GPU 配置计费模式备注阿里云ecs.gn7i-c16g1.4xlarge1×A10包年包月约 4000-5000 元/月国内生态完善按量秒级计费方便阿里云ecs.gn6v-c10g1.20xlarge8×V100竞价实例可低至按量 1-2 折适合离线任务腾讯云GN7vw / GN10Xp1×T4 / 1×A100包月灵活活动价波动大游戏/音视频业务常用华为云Pi2 / Pnt11×T4 / 昇腾310对昇腾生态有特别优化自研芯片适配需特殊调试AWSg4dn / p4d / g5T4 / A100 / A10G按小时计价长期用有 Saving Plan海外节点网络延迟要测试AutoDL 类多种共享 GPU4090/3090 等按小时性价比高但隔离性一般这里我的经验是国内面向业务生产首选阿里云和腾讯云重点看安全组、弹性 IP、VPC 这些网络能力如果你跑的是离线批处理且能容忍实例中断用竞价实例能省下大量成本如果只是想快速调试验证共享 GPU 平台按小时租更划算。3.2 带宽、存储与自动快照比 GPU 型号更值得关注很多人的误区是 GPU 选好就完事了。实际上大模型部署项目里模型文件下载、推理服务对外响应、日志收集这些环节对带宽和存储 IO 的依赖远高于普通 Web 服务。先说带宽。国内云厂商默认公网带宽很小严重的时候 5Mbps 都算低配。你要是从 HuggingFace 拉一个 70B 的模型文件FP16 大约 140GB5Mbps 带宽要下整整两天多。所以我的习惯是先用对象存储或者内网镜像把模型文件放到与云服务器同地域的存储桶里再用内网传输速度能翻几十倍对外服务带宽按业务量估动态对话场景每个并发大约消耗 2-5Mbps建议预留至少 20Mbps 起步。再说存储。GPU 实例的数据盘直接决定模型加载时间用普通云盘加载 100GB 模型可能要几分钟用高性能 ESSD 能把加载压缩到几十秒内。如果模型文件大、又要频繁做版本切换建议单独买一块 ESSD 云盘挂载在 /data 下不要把系统盘和生产数据混在一起。最后是自动快照。大模型部署最怕什么微调之后模型权重出错、配置文件被改坏、环境依赖炸了。给 GPU 实例数据盘按天做自动快照是最便宜的保险几块钱一个月的成本能在灾难恢复时把重建时间从小时级压到分钟级。4. 生产级部署流程从模型文件到可对外服务的完整链路拿到框架选型和云资源以后部署流程的套路其实相当固定。下面是我一个 80G 单卡实例 vLLM 部署 70B 量化模型的完整过程。这套流程我重复过很多次改改路径和版本号就能直接抄。4.1 模型准备、目录规范与启动服务第一步模型文件准备。不要直接从 HF 下载完就乱放。我统一用下面的目录结构/data/models/ workspace/ model_name/ config.json model.safetensors.index.json model-00001-of-0000x.safetensors tokenizer.json tokenizer_config.json检查点很关键必须是safetensors格式因为这格式规范简单、加载速度快还能带上 JSON 索引vLLM 加载时不用预扫描整个目录。如果是别人给的bin旧格式优先做一次转换避免加载时爆内存。第二步用 Docker 起服务是最省心的做法。2026 年 vLLM 官方镜像已经足够完善我直接拉官方镜像宿主机只装 NVIDIA 驱动和容器运行时docker run -d --gpus all \ --ipchost \ -v /data/models:/models \ -p 8000:8000 \ --restartalways \ --name vllm-70b \ vllm/vllm-openai:latest \ --model /models/workspace/model_name \ --served-model-name model-name \ --gpu-memory-utilization 0.92 \ --max-model-len 4096 \ --host 0.0.0.0 \ --port 8000--ipchost这个参数一定要加不加在某些环境下会出共享内存不足的问题。--gpu-memory-utilization不要无脑设满 0.95留在 0.9 左右给 CUDA 上下文和驱动留点余量能避免不少玄学 OOM。第三步做一次最基础的健康检查。服务起来后先不要急着接业务用 curl 直接验证响应curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: model-name, messages: [{role: user, content: 你好请做一句话自我介绍}], max_tokens: 200, stream: true }注意这里用的是流式返回生产环境我强烈建议所有大模型接口都开流式。原因很简单模型生成几十到几百个 token 需要几秒如果非流式前端界面会一直转圈用户体感极差流式以后用户 300ms 内就能看到第一个字。4.2 压测、监控与灰度发布三板斧部署完成不等于生产就绪。我把压测放在第四步因为基础设施和模型目录调整完了以后压测的数据才有参考价值。压测工具有很多2026 年比较稳的是用vllm bench这种内置工具简单配置一下并发、输入输出长度就能跑vllm benchmark --model /models/workspace/model_name \ --requests 200 \ --concurrency 32 \ --input-len 512 \ --output-len 256重点关注两个数字TTFT首 token 延迟和吞吐output tokens/s。比如单张 A100 跑 70B INT4压测输出如果吞吐能稳定在 200 tokens/s 以上说明服务基础状态不错要是 TTFT 明显波动先查前缀缓存是否开启、KV Cache 是否卡在显存边界。监控和日志这块生产环境一定不能裸奔。最简单的做法是我一直沿用的组合vLLM 服务自带 Python 日志加上 GPU 状态实时监控脚本甚至用 Prometheus Grafana 采集nvidia_smi指标设定显存占用阈值告警。下面这段脚本是我最早部署时就一直在用的#!/bin/bash while true; do GPU_UTIL$(nvidia-smi --query-gpuutilization.gpu,memory.used,memory.total \ --formatcsv,noheader,nounits | awk -F, {print $1,$2/$3}) echo $(date %Y-%m-%d %H:%M:%S) $GPU_UTIL /var/log/gpu_monitor.log sleep 10 done灰度发布的操作相对简单了模型更新时另起一个容器实例用新的端口 or 新的--served-model-name先让内测用户访问确认效果没问题再切换网关的路由权重把流量从旧服务平滑迁移到新服务。我通常用 Nginx 做这个三层代理配一次权重分流就能长期复用。5. 没有公网 IP 时用一台轻量 ECS 完成内网穿透与安全暴露很多开发者的 GPU 环境其实是放在机房、实验室或者自己有内网 IP 的工作站上并没有直接分配公网固定 IP。这时候想把服务展示给同事、客户或者部署到云上的统一入口面临一个很现实的问题怎么让外网访问到内网里的 GPU 服务买公网 IP 绑定到内网机器很多机房不提供服务而且价格不低。直接改内网设备映射公网配置危险又容易暴露整个内网。我在这块试过不少方案最稳定的组合是一台廉价的公网 ECS 做转发节点 frp 内网穿透工具把 GPU 服务器的推理端口转发过去。这也是社区里很多人一直在提的免费思路——frp 本身完全开源官方有免费服务端/客户端你只需要付一台最低配 ECS 的钱甚至能和其他服务共用这台 ECS。5.1 为什么 frp 方案适合大模型部署场景frp 的核心逻辑很简单内网机器主动向外网的 frp server 建立一条长连接然后外部用户访问公网 ECS 的某个端口时请求会通过这条连接被转发到内网 GPU 机器的对应服务上。用户看到的是 ECS 的 IP 和端口实际干活的是内网 GPU。整个过程对 vLLM 等推理服务是透明的服务本身不用做任何改动。对大模型部署场景来说frp 有三个特别合适的点端口即服务。GPU 机器上启动的 vLLM 默认监听 8000 端口frp 客户端把这个端口完整映射到公网 ECS 的 8000 端口外网拿着http://公网IP:8000/v1/chat/completions直接请求和请求一台真正的公网 GPU 服务器没有区别。安全性收紧在公网侧。你不需要暴露 GPU 机器的任意其他端口只映射 8000 这一个端口即可内网其他设备不会被波及。成本低。frp server 常年占用资源极低一台 1 核 1GB 的轻量 ECS 就足够支撑几十个并发的转发。5.2 frp 配置实操与安全注意事项frp 的部署分两步。第一步在公网 ECS 上启动 frps 服务端。2026 年的版本可以直接用 TOML 配置bindPort 7000 auth.method token auth.token your-strong-token allowPorts [{ start 8000, end 8005 }]其中bindPort是服务端监听端口auth.token是客户端认证凭据allowPorts限制允许映射的公网端口范围。这里我特别强调千万不要让 frps 允许任意端口映射。默认放开所有端口等于给内网开了一扇大后门入侵者只要能拿到一个客户端 token 就能把内网其他服务全暴露出来。第二步在内网 GPU 服务器上启动 frpc 客户端serverAddr 你的ECS公网IP serverPort 7000 auth.token your-strong-token [[proxies]] name vllm type tcp localIP 127.0.0.1 localPort 8000 remotePort 8000 transport.useEncryption true transport.useCompression truelocalIP用127.0.0.1意味着只转发本机 vLLM 端口不代理内网其他主机。transport.useEncryption true建议一定开避免推理数据明文走过公网链路。启动后外网就可以通过http://ECS公网IP:8000/v1/chat/completions调用你内网 GPU 上的大模型服务了。在实际使用中我把这个端口主要开放给公司内部业务和少量合作方测试。如果要暴露到更大范围前面必须加一层 API Key、IP 白名单或者 Nginx 的 Basic Auth。安全永远不能靠 frp token 一重保障生产环境应该做成多级防线。配置 frp 的时候有两个非常容易踩的坑ECS 安全组没放行端口。很多用户费了半天劲发现外网连不上其实云厂商安全组把端口挡在境外了。记得在 ECS 控制台把 7000frp 通信和 8000推理服务都加入安全组入方向规则。frpc 断线重连。内网机器重启后 frpc 如果没设成开机自启或者没有守护进程外网入口就悄悄断了。我用 systemd 托管 frpc加Restartalways和RestartSec5恢复速度比手动快得多。这台轻量 ECS 如果只是做 frp 转发服务器几乎跑不满负载你还可以直接在上面部署 Nginx承担后面静态资源或者 API 网关的职责——一台小机器做多种边缘功能成本控制更理想。6. 踩坑之后我总结出的几条无价经验文章最后不打算写空泛的总结直接分享我在真实部署过程中反复踩过的几个坑。这几条是文档里不会写、只有长期实际操作才能攒下来的经验。第一条经验别把最优框架和最优实践混为一谈。vLLM 再火不适合你团队的水平就是不适合。我带过的团队里有人一天就能玩转 SGLang有人在 vLLM 上跑了三个月还是只会改参数。选框架要结合团队维护能力别为了追求新特性牺牲稳定。第二条经验云资源采购永远要为回滚留一手。大模型服务最怕模型版本升级后业务侧出现异常比如新增的模型能力边界和旧版不一样。我现在的习惯是每次发布前必须先保存当前可用镜像和权重路径压测通过以后才推进生产。出了问题直接回滚到上一个 Docker 镜像五分钟恢复。第三条经验流量进来前先打好日志和监控的地基。这是我早期吃过最大亏的地方服务上线第一天就遇到调用方反馈有时候特别慢但我根本没有历史数据可查只能靠猜。后来我对所有推理请求都做了一条基础日志时间、请求内容大小、TTFT、输出 token 数、耗时。排查问题的时候这几项数据能直接定位链路上哪一环出了问题。第四条经验送给预算有限的个人开发者和中小团队生产环境不要把所有鸡蛋放在一个篮子里。模型服务、微调任务、对象存储、数据库尽量拆开规划哪些跑包年抢占式实例、哪些必须用稳定包年包月事先分清楚。我用阿里云 ECS frp 这套组合最频繁的场景其实是把实验室里一台 4090 工作站变成可供团队使用的大模型 API 服务器整体成本只多了一台轻量 ECS 的费用。这种成本控制思路在对外 demo、内部测试、小型产品落地阶段尤其有优势——先用最小的钱把链路跑通确认业务有真实需求后再往大规模 GPU 实例迁。最后关于部署这件事实话说一句大模型服务器的价值不在你用了多贵的卡、多新的框架而在于你能否稳定、低延迟、安全地把模型能力交到使用者手里。模型的选型和推进都是有周期的但部署流程、压测方法、安全策略、回滚预案这些基本功一旦沉淀下来之后换任何框架、迁移任何云平台都可以反复复用。先把手头这一套跑顺跑稳比什么都重要。
