1. 部署前必须想清楚的三件事先说说我自己的经历。去年帮一家做智能客服的创业公司搭建大模型推理环境团队一开始的想法特别朴素买几张顶级显卡装个最火的框架把模型跑起来就完事。结果呢前半个月全在折腾环境依赖冲突和显存溢出真正调模型效果的时间反而不多。后来我重新梳理了整个部署流程把决策顺序反过来——先确定场景和约束再选框架最后选云服务商。这版指南就是按照这个思路整理的。在碰任何服务器和框架之前有三个问题必须拿到明确答案。第一个问题你的业务到底需要什么样的模型能力是要跑开源大模型做私有化部署比如 Llama、Qwen、DeepSeek 这些还是用 API 调用做应用层开发就行如果是私有化部署是要做推理inference还是要做微调fine-tuning这两个场景对硬件资源的需求差异非常大。纯推理的话量化后的 7B 模型一张 24G 显存的卡就够跑但你要是想做全参数微调7B 模型得上好几张 80G 的卡这一下就把预算天花板抬上去了。第二个问题线上流量预估是多少就我自己接触的项目来看大部分团队根本用不着搞分布式推理集群。日活一万以内的应用QPS 峰值也就几十单卡部署一个 7B 或 14B 的量化模型再加个简单的请求排队机制完全顶得住。但你要是做的是那种面向公众的 AI 产品比如聊天机器人、AI 陪伴之类的就需要考虑多卡负载均衡和弹性伸缩了。第三个问题你的运维能力到什么水平这一点最容易被低估。我见过不少团队模型训练和研究搞得风生水起一到部署就抓瞎——Linux 基础不牢、Docker 不熟、GPU 驱动一装就崩。如果你的团队没有专职的运维或者 DevOps 工程师老实上云托管服务别自己买物理机。反之如果团队里有懂 Linux 内核和容器网络的老手自建机房或者租裸金属服务器能省不少钱。把这三个问题想明白了后面的选型和方案才能落地。不然你就是跟着热点走今天看这框架火就换这个明天看那个云厂商搞活动就迁那个永远在折腾的路上。2. 2026 年主流推理框架横向选型框架选型是整个部署流程里最需要沉淀经验的环节。2026 年这个时间点上圈子里的格局已经比较清晰了。我自己平时用得最多的四个框架是 vLLM、SGLang、TGI 和 TensorRT-LLM各有各的适用场景。另外 llama.cpp 在低配环境里的地位依然无可替代。2.1 高并发推理首选vLLM如果你只打算接触一个框架我会推荐 vLLM。这框架最大的特点是引入了 PagedAttention 机制一句话解释就是把 KV Cache 按页管理像操作系统管理内存一样管理显存显存利用率能拉到 90% 以上。我实测过同样一个 7B 模型环境配置完全一致用原始 HuggingFace 的 Transformers 代码做推理单请求延迟可能和 vLLM 差不多但一旦把并发拉起来差距就非常明显。vLLM 支持 Continuous Batching连续批处理新请求不需要等当前批次全部跑完再排队而是动态插入到现有批次里。这不光带来吞吐量的提升还大幅降低了排队等待时间。vLLM 的部署成本很低读官方文档的话你会看到pip install vllm然后就能启动了vllm serve Qwen/Qwen2.5-7B-Instruct --tensor-parallel-size 1 --gpu-memory-utilization 0.9但这里我要多说一句新手上路第一件事不是直接跑命令而是搞清楚你需要的关键参数--tensor-parallel-size张量并行度简单说就是模型被切成几份放在几张卡上。单卡机器填 1 就行多卡机器要确保卡之间走 NVLink否则通信开销反而拖慢速度。--gpu-memory-utilization控制 vLLM 使用显存的百分比。默认 0.9但机器上如果还跑着别的进程建议调低到 0.7~0.8给其他服务留空间。--max-model-len最大上下文长度。很多人忽略这个参数要知道显存里给 KV Cache 留的空间和最大上下文长度直接相关模型默认支持 32K 甚至 128K 的上下文但你实际用不到那么长把它改成 4096 或者 8192 能大幅减少显存占用。2.2 极致吞吐场景SGLangSGLang 是这两年跑出来的黑马核心优势是 RadixAttention 技术。它会把请求之间的公共前缀缓存下来比如你在一个机器人服务里系统提示词System Prompt往往是固定的这个前缀占了整个请求的很大一部分。SGLang 能把这一段计算直接复用在大规模多用户场景下吞吐量提升非常可观。我给一个客户做私有化知识库问答的时候QA 系统的 system prompt 有大概两千字用户的问题平均八十字用 SGLang 部署之后能明显感觉到首字延迟比 vLLM 低。如果你的业务场景是典型的“长系统提示 短用户输入”SGLang 值得重点评估。SGLang 部署能兼容 vLLM 的接口pip install sglang python -m sglang.launch_server --model-path Qwen/Qwen2.5-7B-Instruct --port 30000不过 SGLang 的社区规模和生态成熟度目前还是比 vLLM 差一档。我给它定义的角色是“性能备选”。两种框架我都建议团队掌握平时线上跑 vLLM遇到吞吐量瓶颈、需要压测优化的时候换成 SGLang 对比。2.3 生态集成深度TGITGI 是 HuggingFace 出品的推理服务器和 Transformers 生态绑定得最紧。如果你部署的模型是比较冷门的架构或者经常需要直接从 HuggingFace Hub 拉权重TGI 的兼容性通常比 vLLM 好。TGI 还内置了对多种量化格式的原生支持包括 GPTQ、AWQ、bitsandbytes 这些你不需要自己做任何额外的转换工作。对于不追求极限性能、但希望少踩坑的团队来说TGI 是个稳健的选择。部署方式上用 Docker 直接拉镜像跑docker run --gpus all --shm-size 1g -p 8080:80 \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id Qwen/Qwen2.5-7B-Instruct注意--shm-size 1g这个参数。TGI 并行加载分片权重默认的共享内存只有 64M不够用。这是我见过 TGI 部署最容易忽略的坑之一。2.4 极致性能优化TensorRT-LLMTensorRT-LLM 是英伟达官方的推理引擎主打性能极限优化。它在英伟达的卡上确实能做到同规格模型的最佳吞吐和最低延迟尤其是在 A100、H100、H200 这种高端卡上表现非常出色。但代价是用起来麻烦。你要把模型先构建成 TensorRT 的 engine 文件这个过程耗时且密切依赖具体的 GPU 架构。换一张卡engine 就得重建。我的个人建议是只有那些 GPU 型号完全确定、业务场景非常稳定的生产环境才考虑 TensorRT-LLM。每天都有新模型上线、经常要换 GPU 的团队用这个框架是自找苦吃。2.5 低配环境守门员llama.cpp这个框架用纯 C/C 实现CPU 推理优化做得极好。GPU 不够时拿一张老旧的 P40 或者 T4甚至纯 CPU 跑量化过的小模型llama.cpp 都能稳定运行。它也是 GGUF 量化格式的生态源头很多边缘设备上的模型部署都用它。如果你预算有限先用 llama.cpp 把模型跑通验证效果之后再迁到 vLLM 上做高并发这个路径很顺畅。整理成一张选型速查表方便收藏框架核心优势劣势推荐场景vLLM连续批处理生态成熟社区活跃冷门架构兼容性一般大多数生产环境默认选择SGLangRadixAttention 前缀缓存吞吐高生态较年轻文档不够全长系统提示、高复用前缀场景TGI与 HuggingFace 生态完美融合极致性能不如 TensorRT-LLM冷门模型、依赖 HF 生态的团队TensorRT-LLM英伟达平台性能极限构建流程繁琐跨 GPU 迁移成本高GPU 固定、纯性能导向场景llama.cppCPU 可跑GGUF 量化生态并发能力有限个人学习、边缘设备、低配机器3. 微调场景下框架怎么选可能有人会问不是部署指南吗怎么又扯到微调了因为生产级流程里微调和推理是强相关的——微调完的 LoRA 权重要合并回基座模型再交给推理框架加载如果微调出的模型格式推理框架不认你前面的功夫全白费。3.1 阿里的生态组合LLaMA-Factory Qwen如果你用的基座模型是 Qwen通义千问系列那就直接选 LLaMA-Factory 没毛病。这是目前开源社区里微调框架里对中文支持最好、模型覆盖最全、上手最轻松的一个。它的核心价值是屏蔽了底层复杂的技术细节把LoRA、QLoRA、全参微调、DPO、ORPO 这些训练方式全封装成了简单的命令行参数。我自己在客户项目里经常这么操作。拿到一份领域数据集格式整理成{instruction: ..., input: ..., output: ...}的 JSON 文件然后用一行命令启动训练llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --template qwen \ --finetuning_type lora \ --dataset_dir data \ --dataset my_dataset \ --output_dir output/qwen-lora \ --num_train_epochs 3 \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 4 \ --learning_rate 1e-4 \ --fp16这里面--finetuning_type lora是性价比最高的方式只训练很小一部分参数几张消费级显卡也能跑。等训练结束把 LoRA 权重合并回原模型llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path output/qwen-lora \ --template qwen \ --finetuning_type lora \ --export_dir output/qwen-merged合并完的模型直接丢给 vLLM 加载兼容性完全没问题。3.2 多模型覆盖、训练风格自由的 AXolotlAXolotl 是另一个稳定维护的训练框架对主流开源模型如 Llama、Mistral、Qwen、DeepSeek 都有完善的配置示例。如果你用的基座模型不是 Qwen 系列同时又想对训练过程做更细粒度的控制比如配置 Flash Attention、DeepSpeed 的 ZeRO 策略、不同的学习率调度器等AXolotl 更顺手。它的配置是用 YAML 文件写的比如model: base_model: mistralai/Mistral-7B-Instruct-v0.3 data: dataset: mydata.jsonl train: lora_rank: 8 num_epochs: 3 micro_batch_size: 2 gradient_accumulation_steps: 8 learning_rate: 2e-5我的习惯是快速出效果做实验用 LLaMA-Factory跟它提供的预置数据集和模型模板能节省很多时间做复杂实验、需要精细控制训练策略时用 AXolotl。3.3 原生训练框架 UnslothUnsloth 这套框架在微调领域口碑一直不错特别是它对显存的优化让很多资源紧张的团队眼前一亮。Unsloth 通过手动推导反向传播过程、减少中间激活值占用来降低训练时的显存需求量。它整合了 QLoRA 及量化加载技术在消费级显卡上微调 7B 模型成为可能。而且 Unsloth 支持导出多种格式包括原生的 HuggingFace 格式、GGUF 量化格式等这就意味着微调出来的模型可以直接供 vLLM、llama.cpp 等推理框架加载。官方给的代码示例大概是这样的from unsloth import FastLanguageModel model, tokenizer FastLanguageModel.from_pretrained( model_nameqwen/Qwen2.5-7B-Instruct, max_seq_length4096, load_in_4bitTrue, ) model FastLanguageModel.get_peft_model(model, r16, lora_alpha16)接下来就是标准的训练流程体验上和 HuggingFace Transformers 非常接近。建议选择框架前先确认是否兼容你想用的模型。3.4 国内本土框架带来的更多选择2026 年这个节点还冒出了不少优秀的国产框架像以原生长上下文和代理能力见长的 LLaMA-1.5 系框架、以及更多面向强化学习场景的微调工具链。这些框架的共性是针对中文文本做了更多优化文档也更贴近国内开发者的阅读习惯。选型建议很简单你的基座模型是什么优先看它的官方推荐。比如官方发布了基于某种框架的微调脚本你就别自己折腾别的框架了官方推荐的兼容性是最稳的。4. 云服务器的选择与成本控制方案框架选定之后硬件部署就提到日程上了。2026 年这个时间点大家的共识是大部分中小团队不需要自建机房云服务器是效率最高、最灵活的选择。4.1 自建机房还是云服务器自建机房最大的诱惑是长期边际成本低但它的隐形开销容易被忽略机房电力扩容、制冷、硬件故障运维、网络带宽成本、GPU 硬件淘汰速度。这些加起来真不一定比云服务器便宜。云服务器的优势在于弹性业务量没起来时不买那么多卡等压力上来了开几台高配机器扛过高峰再释放。我自己带过的项目很多是从单台 4 卡机器起步的日活做到五万之后才扩张到 8 卡、16 卡的集群。这种从小到大平滑演进在自建机房很难做到。4.2 国内主流云厂商的部署选项对比国内能选的主流云我个人用得最多的是阿里云腾讯云和华为云在特定场景下也各有优势。做一个客观的对比维度阿里云腾讯云华为云GPU 机型丰富度覆盖全面从入门 T4 到旗舰 H20 都有主打性价比活动机型多全栈国产化方案最完整昇腾系列深度绑定生态工具链PAI 平台与开源模型兼容性好TI 平台部署简洁但底层细节封装较深ModelArts 平台化能力强适合国企等有私有化需求的场景海外节点覆盖覆盖最广跨地域组网方便亚太地区有优势海外节点较少技术支持响应工单响应快有专门的 AI 服务团队响应速度比较看运气针对大客户有专项支持团队再补充一点很多人忽略的抢占式实例Spot Instance。如果你跑的是离线批量任务比如批量数据集推理、模型评估用抢占式实例能把成本降到按量付费的两折甚至更低。缺点是实例可能随时被回收所以必须做断点续跑。模型加载要从对象存储拉取权重每次从头加载一个 7B 模型的权重几十 GB 也要几分钟因此我会先存一份快照抢到机器之后验证权重存在就直接开工不复下。4.3 云上资源估算方法硬件型号选型最实用的方法是“向前推算”。先确认你是否跑量化模型现在主流开源中文模型都出了对应的量化版本。量化最简单的理解就是降低模型参数的精度来节省显存占用比如把 FP16 变成 INT4代价是效果略微有损。其次确认你要支撑的并发量然后套这个公式模型显存需求的粗算公式显存 ≈ 参数总量(以 GB 为单位) × 精度位宽 ÷ 8举例7B 模型 FP16 权重大约 14GB运行时还要加上 KV Cache 和 激活值的空间所以单卡 24G 只能勉强跑 FP16。换 INT4 量化后权重降到约 4GB同样的 24G 卡可能做到几十路并发吞吐量完全不是一回事。再用一个实际例子来算部署 Qwen2.5-14BINT4 量化后权重约 8GB假设你希望支持 50 路并发每路平均输出长度 512 tokensKV Cache 预留 12GB那么单张 24G 卡是改不动的建议直接用 2×24G 的配置或者干脆上 1×48G如 A6000 级别。具体选型建议先跑最少 3 个线程的压测观察显存实际占用和延迟再开足马力。推理性能的关键瓶颈在哪里很多新手以为推理慢是算力不够但真实瓶颈往往在显存带宽上。大模型推理是典型的内存密集型任务每生成一个 token都要把全部的权重参数从显存里读一遍这时主频算力反而其次。这也是为什么显存带宽更高的卡比如 H200 这种主打大显存带宽的型号在推理场景可能比理论算力更高的卡还快。预算有限时优先保证显存充足预算充足时关注显存带宽。4.4 省钱的第一课按需开停机很多人部署完服务就把服务器 7×24 小时开着一个月下来账单吓人。如果你只是白天调模型、晚上休息的场景完全可以在不用的时候把机器释放掉或者做成停机不收费的模式记得把系统盘和数据盘分别配成云盘并定期做好快照。省下来的钱几个月就够买一张新卡了。5. 生产级部署的标准流程现在把整个流程串起来。一个生产级的大模型服务绝对不只是“把模型跑起来”就完事了。5.1 模型权重获取与管理第一步是拿到模型权重。国内访问 HuggingFace 经常出现中断问题业内默认的做法是用 ModelScope 魔搭社区紧跟阿里系生态Qwen、DeepSeek 等模型都有官方托管国内服务器下载速度快、也不容易断。下载时务必校验哈希值避免下载不完整导致加载报错。下载完权重放到对象存储或机器本地后建议做一个简单的版本目录管理/models /qwen-2.5-7b-instruct /v1 /v2每次上线微调后的模型版本把版本号打在路径里方便查询回滚。5.2 容器化的正确姿势生产环境中强烈建议用 Docker 容器打包部署。我踩过太多次“代码在我机器上能跑”的坑容器化之后这种问题基本绝迹了。一个标准的 vLLM 容器示例FROM vllm/vllm-openai:latest COPY ./models /models ENV HF_HOME/models CMD [--model, /models/qwen-2.5-7b-instruct, --served-model-name, qwen, --port, 8000]构建镜像之后用--gpus all参数启动容器docker run --gpus all --shm-size 2g \ -p 8000:8000 \ -v /models:/models \ vllm-server:latest--shm-size 2g设置共享内存否则数据加载阶段容易 OOM。5.3 API 网关与服务编排模型起起来之后还需要一层网关来对外提供 OpenAPI 兼容的接口并处理权限认证、流量控制、路由转发这些事。在小规模团队里用 FastAPI 或者 Nginx 反代基本上是最合理的选择。Nginx 可以做最基础的负载均衡upstream llm_backend { server 127.0.0.1:8000; server 127.0.0.1:8001; keepalive 32; } server { listen 80; location /v1/ { proxy_pass http://llm_backend; proxy_buffering off; } }并发量上来后Nginx 不够灵活可以换成 Kubernetes 做容器编排。K8s 的优势在于自动扩缩容和故障恢复模型实例挂了会自动重启流量大了自动加副本。但代价是运维复杂度显著上升就看团队的运维能力能不能接得住。5.4 监控告警与可观测性建设生产级部署最后一道防线是监控。GPU 显存、GPU 利用率、请求延迟 P95、错误率这四个指标必须无死角覆盖。开源方案组合是 Prometheus Grafana再配合 exporternvidia_smi_exporter采集 GPU 相关指标prometheus_http_exporter采集请求指标Grafana 做可视化面板告警规则是另一项关键配置比如 GPU 显存超过 90% 持续五分钟、服务 5xx 错误率超过 1% 这类规则要提前配好。常见用 Alertmanager 推送到钉钉或企业微信机器人。5.5 模型加载失败与推理卡顿怎么排查来说说真实环境里概率最高的几个坑CUDAout of memory。最常见的原因是部署时忘了在 vLLM 参数里限制显存利用率。--gpu-memory-utilization 0.9只给模型留了 10% 的余量如果你的机器上还有其他进程就容易炸。解决办法是先nvidia-smi看显存占用把没用的进程干掉或者调低显存利用率参数。illegal memory access这类崩溃。大概率是驱动和 CUDA 版本不匹配。排查公式很简单nvidia-smi看驱动支持的 CUDA 版本再nvcc --version看运行时版本。两者不一致就重装驱动。请求排队时间持续增长。这不是故障是容量预警。说明当前的并发处理能力已经到瓶颈要么缩减上下文长度要么加机器。别等到请求超时才处理。首次 token 延迟特别慢。大概率是模型权重从磁盘加载的冷启动开销或者输入长度特别长。可以把模型常驻内存或预先加载件避免每次重启都重新加载权重。5.6 内网穿透的正确用法内网穿透这个话题经常被误解。我自己在工作中使用内网穿透主要是两种情况把云上的大模型服务映射到本地端口方便用本地调试工具测试以及在没有公网 IP 的开发机上把服务临时暴露给外围协作同事联调。需要特别强调一下内网穿透本身是一种常规网络工具有大量合规合法的应用场景比如开发调试、远程运维、家庭网络设备访问等。使用时必须要遵守当地法律法规和平台服务条款只能用于你自己有权限管理的设备和业务系统绝不能用来搭建任何规避监管的服务这一点红线意识必须清晰。比较常见的做法是准备一台有公网 IP 的云服务器作为跳板在内网机器上安装客户端工具主动向外发起加密连接建立一条反向隧道到公网跳板机的指定端口。这样外部访问跳板机端口数据就被安全地转发到内网机器上。操作上避免直接暴露需要配合密钥认证或随机密码并且在用完隧道后立即关闭端口。一个典型的用法是把本地调试中的大模型推理服务通过内网穿透暴露到云端跳板机上方便团队成员在任何地方通过统一地址做模型联调。注意只绑定127.0.0.1的调试端口映射过去权限控制在团队内网范围并对连接做白名单限制。危险操作是把没有任何认证的端口直接映射到公网那基本就是把服务裸奔在互联网上会被人当肉鸡刷接口。6. 部署完成后的压测与调优服务上线之前压测和调优是必经之路尤其要做并发测试验证框架选型的判断是否正确。6.1 用 wrk 或 Locust 做性能摸底压测工具不限wrk 轻量、实现简单Locust 通过 Python 脚本可以模拟更复杂的用户行为。我的习惯是先跑一轮小并发确认功能正常再逐级拉高并发观察延迟曲线。以 vLLM 为例压测时重点关注三个参数吞吐量Tokens/s每秒生成的 token 数首 token 延迟TTFT用户发出请求后到收到第一个 token 的时间尾 token 延迟TPOT生成每个后续 token 的平均时间压测结果不理想时调优优先级建议如下检查是否开启 Continuous BatchingvLLM 默认开对于 SGLang 检查服务端前缀缓存是否生效调低max-model-len限制调整gpu-memory-utilization确保 KV Cache 有足够空间检查模型是否量化到位INT4 比 INT8 能省一半显存6.2 模型量化如何不伤效果很多团队对量化模型望而却步怕模型效果大幅下降。实测下来做得好的 INT4 量化方案GPTQ、AWQ在通用任务上损失很小大约 1%~3%。技巧是量化前多准备一些代表性数据做校准量化粒度用 group size 128 平衡压缩比和效果。推荐先量化到 INT8 试跑一轮再量化到 INT4 对比效果。BNB 的 NF4 在部分中文任务上有惊喜但它不改变模型权重文件结构只存在内存里每次加载都要重新量化一遍。6.3 多模型并存与路由策略生产环境往往不只有一个模型。比如你既要一个轻量模型快速响应简单问题又要一个重量模型做复杂推理。这时候用路由层把简单的请求分给 7B 模型复杂的请求转发给 72B 模型成本和效果能达到最优平衡。最简单的方式是用一个 Redis 计数做限流再叠加参数判断在网关侧做模型路由。7. 总结一些实践经验听着可能不够高大上但真的帮我在项目里少踩了很多坑做 AI 部署这几年我最大的体会有这么几条写下来给你参考。第一别过度设计。很多项目刚起步时每天就几百个请求有人非得上 K8s搞微服务最后运维成本比云服务器费用还高。先用最直接的方式跑通比如一台 GPU 服务器加载 vLLM再用 Nginx 反代直到规模确实撑不住了再考虑复杂的架构。第二权重文件管理一定要认真。我见过不止一次团队因为权重存放混乱换个人就找不到对应版本最后重新下载耗时半天。把模型目录、版本、哈希值记清楚配合脚本让模型加载可复现这比任何高端架构都重要。第三框架升级别盲目跟风。每次 vLLM 发新版本别急着升级。先看 changelog明确知道这一个版本解决了你的什么问题再动。生产环境里稳定压倒一切一个pip install -U vllm把你的依赖全破坏掉的案例我见得太多了。最后再分享一个小技巧生产环境第一次部署大模型服务把详细的启动命令、参数含义、踩过的坑都记在项目的 README 里。这不是形式主义——三个月后你自己回来看都会感谢当初那个认真的自己。如果你还在犹豫部署方案就从小处着手一台带 24G 显存的机器一个量化过的 7B 模型一条vllm serve命令。先把这条路跑通后面的一切都有章可循。
1. 部署前必须想清楚的三件事先说说我自己的经历。去年帮一家做智能客服的创业公司搭建大模型推理环境团队一开始的想法特别朴素买几张顶级显卡装个最火的框架把模型跑起来就完事。结果呢前半个月全在折腾环境依赖冲突和显存溢出真正调模型效果的时间反而不多。后来我重新梳理了整个部署流程把决策顺序反过来——先确定场景和约束再选框架最后选云服务商。这版指南就是按照这个思路整理的。在碰任何服务器和框架之前有三个问题必须拿到明确答案。第一个问题你的业务到底需要什么样的模型能力是要跑开源大模型做私有化部署比如 Llama、Qwen、DeepSeek 这些还是用 API 调用做应用层开发就行如果是私有化部署是要做推理inference还是要做微调fine-tuning这两个场景对硬件资源的需求差异非常大。纯推理的话量化后的 7B 模型一张 24G 显存的卡就够跑但你要是想做全参数微调7B 模型得上好几张 80G 的卡这一下就把预算天花板抬上去了。第二个问题线上流量预估是多少就我自己接触的项目来看大部分团队根本用不着搞分布式推理集群。日活一万以内的应用QPS 峰值也就几十单卡部署一个 7B 或 14B 的量化模型再加个简单的请求排队机制完全顶得住。但你要是做的是那种面向公众的 AI 产品比如聊天机器人、AI 陪伴之类的就需要考虑多卡负载均衡和弹性伸缩了。第三个问题你的运维能力到什么水平这一点最容易被低估。我见过不少团队模型训练和研究搞得风生水起一到部署就抓瞎——Linux 基础不牢、Docker 不熟、GPU 驱动一装就崩。如果你的团队没有专职的运维或者 DevOps 工程师老实上云托管服务别自己买物理机。反之如果团队里有懂 Linux 内核和容器网络的老手自建机房或者租裸金属服务器能省不少钱。把这三个问题想明白了后面的选型和方案才能落地。不然你就是跟着热点走今天看这框架火就换这个明天看那个云厂商搞活动就迁那个永远在折腾的路上。2. 2026 年主流推理框架横向选型框架选型是整个部署流程里最需要沉淀经验的环节。2026 年这个时间点上圈子里的格局已经比较清晰了。我自己平时用得最多的四个框架是 vLLM、SGLang、TGI 和 TensorRT-LLM各有各的适用场景。另外 llama.cpp 在低配环境里的地位依然无可替代。2.1 高并发推理首选vLLM如果你只打算接触一个框架我会推荐 vLLM。这框架最大的特点是引入了 PagedAttention 机制一句话解释就是把 KV Cache 按页管理像操作系统管理内存一样管理显存显存利用率能拉到 90% 以上。我实测过同样一个 7B 模型环境配置完全一致用原始 HuggingFace 的 Transformers 代码做推理单请求延迟可能和 vLLM 差不多但一旦把并发拉起来差距就非常明显。vLLM 支持 Continuous Batching连续批处理新请求不需要等当前批次全部跑完再排队而是动态插入到现有批次里。这不光带来吞吐量的提升还大幅降低了排队等待时间。vLLM 的部署成本很低读官方文档的话你会看到pip install vllm然后就能启动了vllm serve Qwen/Qwen2.5-7B-Instruct --tensor-parallel-size 1 --gpu-memory-utilization 0.9但这里我要多说一句新手上路第一件事不是直接跑命令而是搞清楚你需要的关键参数--tensor-parallel-size张量并行度简单说就是模型被切成几份放在几张卡上。单卡机器填 1 就行多卡机器要确保卡之间走 NVLink否则通信开销反而拖慢速度。--gpu-memory-utilization控制 vLLM 使用显存的百分比。默认 0.9但机器上如果还跑着别的进程建议调低到 0.7~0.8给其他服务留空间。--max-model-len最大上下文长度。很多人忽略这个参数要知道显存里给 KV Cache 留的空间和最大上下文长度直接相关模型默认支持 32K 甚至 128K 的上下文但你实际用不到那么长把它改成 4096 或者 8192 能大幅减少显存占用。2.2 极致吞吐场景SGLangSGLang 是这两年跑出来的黑马核心优势是 RadixAttention 技术。它会把请求之间的公共前缀缓存下来比如你在一个机器人服务里系统提示词System Prompt往往是固定的这个前缀占了整个请求的很大一部分。SGLang 能把这一段计算直接复用在大规模多用户场景下吞吐量提升非常可观。我给一个客户做私有化知识库问答的时候QA 系统的 system prompt 有大概两千字用户的问题平均八十字用 SGLang 部署之后能明显感觉到首字延迟比 vLLM 低。如果你的业务场景是典型的“长系统提示 短用户输入”SGLang 值得重点评估。SGLang 部署能兼容 vLLM 的接口pip install sglang python -m sglang.launch_server --model-path Qwen/Qwen2.5-7B-Instruct --port 30000不过 SGLang 的社区规模和生态成熟度目前还是比 vLLM 差一档。我给它定义的角色是“性能备选”。两种框架我都建议团队掌握平时线上跑 vLLM遇到吞吐量瓶颈、需要压测优化的时候换成 SGLang 对比。2.3 生态集成深度TGITGI 是 HuggingFace 出品的推理服务器和 Transformers 生态绑定得最紧。如果你部署的模型是比较冷门的架构或者经常需要直接从 HuggingFace Hub 拉权重TGI 的兼容性通常比 vLLM 好。TGI 还内置了对多种量化格式的原生支持包括 GPTQ、AWQ、bitsandbytes 这些你不需要自己做任何额外的转换工作。对于不追求极限性能、但希望少踩坑的团队来说TGI 是个稳健的选择。部署方式上用 Docker 直接拉镜像跑docker run --gpus all --shm-size 1g -p 8080:80 \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id Qwen/Qwen2.5-7B-Instruct注意--shm-size 1g这个参数。TGI 并行加载分片权重默认的共享内存只有 64M不够用。这是我见过 TGI 部署最容易忽略的坑之一。2.4 极致性能优化TensorRT-LLMTensorRT-LLM 是英伟达官方的推理引擎主打性能极限优化。它在英伟达的卡上确实能做到同规格模型的最佳吞吐和最低延迟尤其是在 A100、H100、H200 这种高端卡上表现非常出色。但代价是用起来麻烦。你要把模型先构建成 TensorRT 的 engine 文件这个过程耗时且密切依赖具体的 GPU 架构。换一张卡engine 就得重建。我的个人建议是只有那些 GPU 型号完全确定、业务场景非常稳定的生产环境才考虑 TensorRT-LLM。每天都有新模型上线、经常要换 GPU 的团队用这个框架是自找苦吃。2.5 低配环境守门员llama.cpp这个框架用纯 C/C 实现CPU 推理优化做得极好。GPU 不够时拿一张老旧的 P40 或者 T4甚至纯 CPU 跑量化过的小模型llama.cpp 都能稳定运行。它也是 GGUF 量化格式的生态源头很多边缘设备上的模型部署都用它。如果你预算有限先用 llama.cpp 把模型跑通验证效果之后再迁到 vLLM 上做高并发这个路径很顺畅。整理成一张选型速查表方便收藏框架核心优势劣势推荐场景vLLM连续批处理生态成熟社区活跃冷门架构兼容性一般大多数生产环境默认选择SGLangRadixAttention 前缀缓存吞吐高生态较年轻文档不够全长系统提示、高复用前缀场景TGI与 HuggingFace 生态完美融合极致性能不如 TensorRT-LLM冷门模型、依赖 HF 生态的团队TensorRT-LLM英伟达平台性能极限构建流程繁琐跨 GPU 迁移成本高GPU 固定、纯性能导向场景llama.cppCPU 可跑GGUF 量化生态并发能力有限个人学习、边缘设备、低配机器3. 微调场景下框架怎么选可能有人会问不是部署指南吗怎么又扯到微调了因为生产级流程里微调和推理是强相关的——微调完的 LoRA 权重要合并回基座模型再交给推理框架加载如果微调出的模型格式推理框架不认你前面的功夫全白费。3.1 阿里的生态组合LLaMA-Factory Qwen如果你用的基座模型是 Qwen通义千问系列那就直接选 LLaMA-Factory 没毛病。这是目前开源社区里微调框架里对中文支持最好、模型覆盖最全、上手最轻松的一个。它的核心价值是屏蔽了底层复杂的技术细节把LoRA、QLoRA、全参微调、DPO、ORPO 这些训练方式全封装成了简单的命令行参数。我自己在客户项目里经常这么操作。拿到一份领域数据集格式整理成{instruction: ..., input: ..., output: ...}的 JSON 文件然后用一行命令启动训练llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --stage sft \ --template qwen \ --finetuning_type lora \ --dataset_dir data \ --dataset my_dataset \ --output_dir output/qwen-lora \ --num_train_epochs 3 \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 4 \ --learning_rate 1e-4 \ --fp16这里面--finetuning_type lora是性价比最高的方式只训练很小一部分参数几张消费级显卡也能跑。等训练结束把 LoRA 权重合并回原模型llamafactory-cli export \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path output/qwen-lora \ --template qwen \ --finetuning_type lora \ --export_dir output/qwen-merged合并完的模型直接丢给 vLLM 加载兼容性完全没问题。3.2 多模型覆盖、训练风格自由的 AXolotlAXolotl 是另一个稳定维护的训练框架对主流开源模型如 Llama、Mistral、Qwen、DeepSeek 都有完善的配置示例。如果你用的基座模型不是 Qwen 系列同时又想对训练过程做更细粒度的控制比如配置 Flash Attention、DeepSpeed 的 ZeRO 策略、不同的学习率调度器等AXolotl 更顺手。它的配置是用 YAML 文件写的比如model: base_model: mistralai/Mistral-7B-Instruct-v0.3 data: dataset: mydata.jsonl train: lora_rank: 8 num_epochs: 3 micro_batch_size: 2 gradient_accumulation_steps: 8 learning_rate: 2e-5我的习惯是快速出效果做实验用 LLaMA-Factory跟它提供的预置数据集和模型模板能节省很多时间做复杂实验、需要精细控制训练策略时用 AXolotl。3.3 原生训练框架 UnslothUnsloth 这套框架在微调领域口碑一直不错特别是它对显存的优化让很多资源紧张的团队眼前一亮。Unsloth 通过手动推导反向传播过程、减少中间激活值占用来降低训练时的显存需求量。它整合了 QLoRA 及量化加载技术在消费级显卡上微调 7B 模型成为可能。而且 Unsloth 支持导出多种格式包括原生的 HuggingFace 格式、GGUF 量化格式等这就意味着微调出来的模型可以直接供 vLLM、llama.cpp 等推理框架加载。官方给的代码示例大概是这样的from unsloth import FastLanguageModel model, tokenizer FastLanguageModel.from_pretrained( model_nameqwen/Qwen2.5-7B-Instruct, max_seq_length4096, load_in_4bitTrue, ) model FastLanguageModel.get_peft_model(model, r16, lora_alpha16)接下来就是标准的训练流程体验上和 HuggingFace Transformers 非常接近。建议选择框架前先确认是否兼容你想用的模型。3.4 国内本土框架带来的更多选择2026 年这个节点还冒出了不少优秀的国产框架像以原生长上下文和代理能力见长的 LLaMA-1.5 系框架、以及更多面向强化学习场景的微调工具链。这些框架的共性是针对中文文本做了更多优化文档也更贴近国内开发者的阅读习惯。选型建议很简单你的基座模型是什么优先看它的官方推荐。比如官方发布了基于某种框架的微调脚本你就别自己折腾别的框架了官方推荐的兼容性是最稳的。4. 云服务器的选择与成本控制方案框架选定之后硬件部署就提到日程上了。2026 年这个时间点大家的共识是大部分中小团队不需要自建机房云服务器是效率最高、最灵活的选择。4.1 自建机房还是云服务器自建机房最大的诱惑是长期边际成本低但它的隐形开销容易被忽略机房电力扩容、制冷、硬件故障运维、网络带宽成本、GPU 硬件淘汰速度。这些加起来真不一定比云服务器便宜。云服务器的优势在于弹性业务量没起来时不买那么多卡等压力上来了开几台高配机器扛过高峰再释放。我自己带过的项目很多是从单台 4 卡机器起步的日活做到五万之后才扩张到 8 卡、16 卡的集群。这种从小到大平滑演进在自建机房很难做到。4.2 国内主流云厂商的部署选项对比国内能选的主流云我个人用得最多的是阿里云腾讯云和华为云在特定场景下也各有优势。做一个客观的对比维度阿里云腾讯云华为云GPU 机型丰富度覆盖全面从入门 T4 到旗舰 H20 都有主打性价比活动机型多全栈国产化方案最完整昇腾系列深度绑定生态工具链PAI 平台与开源模型兼容性好TI 平台部署简洁但底层细节封装较深ModelArts 平台化能力强适合国企等有私有化需求的场景海外节点覆盖覆盖最广跨地域组网方便亚太地区有优势海外节点较少技术支持响应工单响应快有专门的 AI 服务团队响应速度比较看运气针对大客户有专项支持团队再补充一点很多人忽略的抢占式实例Spot Instance。如果你跑的是离线批量任务比如批量数据集推理、模型评估用抢占式实例能把成本降到按量付费的两折甚至更低。缺点是实例可能随时被回收所以必须做断点续跑。模型加载要从对象存储拉取权重每次从头加载一个 7B 模型的权重几十 GB 也要几分钟因此我会先存一份快照抢到机器之后验证权重存在就直接开工不复下。4.3 云上资源估算方法硬件型号选型最实用的方法是“向前推算”。先确认你是否跑量化模型现在主流开源中文模型都出了对应的量化版本。量化最简单的理解就是降低模型参数的精度来节省显存占用比如把 FP16 变成 INT4代价是效果略微有损。其次确认你要支撑的并发量然后套这个公式模型显存需求的粗算公式显存 ≈ 参数总量(以 GB 为单位) × 精度位宽 ÷ 8举例7B 模型 FP16 权重大约 14GB运行时还要加上 KV Cache 和 激活值的空间所以单卡 24G 只能勉强跑 FP16。换 INT4 量化后权重降到约 4GB同样的 24G 卡可能做到几十路并发吞吐量完全不是一回事。再用一个实际例子来算部署 Qwen2.5-14BINT4 量化后权重约 8GB假设你希望支持 50 路并发每路平均输出长度 512 tokensKV Cache 预留 12GB那么单张 24G 卡是改不动的建议直接用 2×24G 的配置或者干脆上 1×48G如 A6000 级别。具体选型建议先跑最少 3 个线程的压测观察显存实际占用和延迟再开足马力。推理性能的关键瓶颈在哪里很多新手以为推理慢是算力不够但真实瓶颈往往在显存带宽上。大模型推理是典型的内存密集型任务每生成一个 token都要把全部的权重参数从显存里读一遍这时主频算力反而其次。这也是为什么显存带宽更高的卡比如 H200 这种主打大显存带宽的型号在推理场景可能比理论算力更高的卡还快。预算有限时优先保证显存充足预算充足时关注显存带宽。4.4 省钱的第一课按需开停机很多人部署完服务就把服务器 7×24 小时开着一个月下来账单吓人。如果你只是白天调模型、晚上休息的场景完全可以在不用的时候把机器释放掉或者做成停机不收费的模式记得把系统盘和数据盘分别配成云盘并定期做好快照。省下来的钱几个月就够买一张新卡了。5. 生产级部署的标准流程现在把整个流程串起来。一个生产级的大模型服务绝对不只是“把模型跑起来”就完事了。5.1 模型权重获取与管理第一步是拿到模型权重。国内访问 HuggingFace 经常出现中断问题业内默认的做法是用 ModelScope 魔搭社区紧跟阿里系生态Qwen、DeepSeek 等模型都有官方托管国内服务器下载速度快、也不容易断。下载时务必校验哈希值避免下载不完整导致加载报错。下载完权重放到对象存储或机器本地后建议做一个简单的版本目录管理/models /qwen-2.5-7b-instruct /v1 /v2每次上线微调后的模型版本把版本号打在路径里方便查询回滚。5.2 容器化的正确姿势生产环境中强烈建议用 Docker 容器打包部署。我踩过太多次“代码在我机器上能跑”的坑容器化之后这种问题基本绝迹了。一个标准的 vLLM 容器示例FROM vllm/vllm-openai:latest COPY ./models /models ENV HF_HOME/models CMD [--model, /models/qwen-2.5-7b-instruct, --served-model-name, qwen, --port, 8000]构建镜像之后用--gpus all参数启动容器docker run --gpus all --shm-size 2g \ -p 8000:8000 \ -v /models:/models \ vllm-server:latest--shm-size 2g设置共享内存否则数据加载阶段容易 OOM。5.3 API 网关与服务编排模型起起来之后还需要一层网关来对外提供 OpenAPI 兼容的接口并处理权限认证、流量控制、路由转发这些事。在小规模团队里用 FastAPI 或者 Nginx 反代基本上是最合理的选择。Nginx 可以做最基础的负载均衡upstream llm_backend { server 127.0.0.1:8000; server 127.0.0.1:8001; keepalive 32; } server { listen 80; location /v1/ { proxy_pass http://llm_backend; proxy_buffering off; } }并发量上来后Nginx 不够灵活可以换成 Kubernetes 做容器编排。K8s 的优势在于自动扩缩容和故障恢复模型实例挂了会自动重启流量大了自动加副本。但代价是运维复杂度显著上升就看团队的运维能力能不能接得住。5.4 监控告警与可观测性建设生产级部署最后一道防线是监控。GPU 显存、GPU 利用率、请求延迟 P95、错误率这四个指标必须无死角覆盖。开源方案组合是 Prometheus Grafana再配合 exporternvidia_smi_exporter采集 GPU 相关指标prometheus_http_exporter采集请求指标Grafana 做可视化面板告警规则是另一项关键配置比如 GPU 显存超过 90% 持续五分钟、服务 5xx 错误率超过 1% 这类规则要提前配好。常见用 Alertmanager 推送到钉钉或企业微信机器人。5.5 模型加载失败与推理卡顿怎么排查来说说真实环境里概率最高的几个坑CUDAout of memory。最常见的原因是部署时忘了在 vLLM 参数里限制显存利用率。--gpu-memory-utilization 0.9只给模型留了 10% 的余量如果你的机器上还有其他进程就容易炸。解决办法是先nvidia-smi看显存占用把没用的进程干掉或者调低显存利用率参数。illegal memory access这类崩溃。大概率是驱动和 CUDA 版本不匹配。排查公式很简单nvidia-smi看驱动支持的 CUDA 版本再nvcc --version看运行时版本。两者不一致就重装驱动。请求排队时间持续增长。这不是故障是容量预警。说明当前的并发处理能力已经到瓶颈要么缩减上下文长度要么加机器。别等到请求超时才处理。首次 token 延迟特别慢。大概率是模型权重从磁盘加载的冷启动开销或者输入长度特别长。可以把模型常驻内存或预先加载件避免每次重启都重新加载权重。5.6 内网穿透的正确用法内网穿透这个话题经常被误解。我自己在工作中使用内网穿透主要是两种情况把云上的大模型服务映射到本地端口方便用本地调试工具测试以及在没有公网 IP 的开发机上把服务临时暴露给外围协作同事联调。需要特别强调一下内网穿透本身是一种常规网络工具有大量合规合法的应用场景比如开发调试、远程运维、家庭网络设备访问等。使用时必须要遵守当地法律法规和平台服务条款只能用于你自己有权限管理的设备和业务系统绝不能用来搭建任何规避监管的服务这一点红线意识必须清晰。比较常见的做法是准备一台有公网 IP 的云服务器作为跳板在内网机器上安装客户端工具主动向外发起加密连接建立一条反向隧道到公网跳板机的指定端口。这样外部访问跳板机端口数据就被安全地转发到内网机器上。操作上避免直接暴露需要配合密钥认证或随机密码并且在用完隧道后立即关闭端口。一个典型的用法是把本地调试中的大模型推理服务通过内网穿透暴露到云端跳板机上方便团队成员在任何地方通过统一地址做模型联调。注意只绑定127.0.0.1的调试端口映射过去权限控制在团队内网范围并对连接做白名单限制。危险操作是把没有任何认证的端口直接映射到公网那基本就是把服务裸奔在互联网上会被人当肉鸡刷接口。6. 部署完成后的压测与调优服务上线之前压测和调优是必经之路尤其要做并发测试验证框架选型的判断是否正确。6.1 用 wrk 或 Locust 做性能摸底压测工具不限wrk 轻量、实现简单Locust 通过 Python 脚本可以模拟更复杂的用户行为。我的习惯是先跑一轮小并发确认功能正常再逐级拉高并发观察延迟曲线。以 vLLM 为例压测时重点关注三个参数吞吐量Tokens/s每秒生成的 token 数首 token 延迟TTFT用户发出请求后到收到第一个 token 的时间尾 token 延迟TPOT生成每个后续 token 的平均时间压测结果不理想时调优优先级建议如下检查是否开启 Continuous BatchingvLLM 默认开对于 SGLang 检查服务端前缀缓存是否生效调低max-model-len限制调整gpu-memory-utilization确保 KV Cache 有足够空间检查模型是否量化到位INT4 比 INT8 能省一半显存6.2 模型量化如何不伤效果很多团队对量化模型望而却步怕模型效果大幅下降。实测下来做得好的 INT4 量化方案GPTQ、AWQ在通用任务上损失很小大约 1%~3%。技巧是量化前多准备一些代表性数据做校准量化粒度用 group size 128 平衡压缩比和效果。推荐先量化到 INT8 试跑一轮再量化到 INT4 对比效果。BNB 的 NF4 在部分中文任务上有惊喜但它不改变模型权重文件结构只存在内存里每次加载都要重新量化一遍。6.3 多模型并存与路由策略生产环境往往不只有一个模型。比如你既要一个轻量模型快速响应简单问题又要一个重量模型做复杂推理。这时候用路由层把简单的请求分给 7B 模型复杂的请求转发给 72B 模型成本和效果能达到最优平衡。最简单的方式是用一个 Redis 计数做限流再叠加参数判断在网关侧做模型路由。7. 总结一些实践经验听着可能不够高大上但真的帮我在项目里少踩了很多坑做 AI 部署这几年我最大的体会有这么几条写下来给你参考。第一别过度设计。很多项目刚起步时每天就几百个请求有人非得上 K8s搞微服务最后运维成本比云服务器费用还高。先用最直接的方式跑通比如一台 GPU 服务器加载 vLLM再用 Nginx 反代直到规模确实撑不住了再考虑复杂的架构。第二权重文件管理一定要认真。我见过不止一次团队因为权重存放混乱换个人就找不到对应版本最后重新下载耗时半天。把模型目录、版本、哈希值记清楚配合脚本让模型加载可复现这比任何高端架构都重要。第三框架升级别盲目跟风。每次 vLLM 发新版本别急着升级。先看 changelog明确知道这一个版本解决了你的什么问题再动。生产环境里稳定压倒一切一个pip install -U vllm把你的依赖全破坏掉的案例我见得太多了。最后再分享一个小技巧生产环境第一次部署大模型服务把详细的启动命令、参数含义、踩过的坑都记在项目的 README 里。这不是形式主义——三个月后你自己回来看都会感谢当初那个认真的自己。如果你还在犹豫部署方案就从小处着手一台带 24G 显存的机器一个量化过的 7B 模型一条vllm serve命令。先把这条路跑通后面的一切都有章可循。
