企业官网建设流程全解析

从 2024 年到 2026 年，大模型已经走过了“能跑通”的阶段，大量团队开始认真考虑“怎么稳定、省钱、高效率地跑生产流量”。我前前后后帮团队和客户做过不下十套大模型服务器部署方案，从单卡 4090 原型验证，到八卡 A100/H800 集群承载线上 Agent 服务，中间踩过的坑很值得整理出来。这篇指南就围绕大模型服务器部署的完整链路展开：硬件与显存规划、推理和微调框架选型、云服务商对比，以及一套能直接落地的生产级部署流程，适合正在做技术选型、准备上线大模型服务的开发者和运维同学参考。

1. 部署前先定调：这张卡能跑什么模型

很多人在选服务器、买显卡或者租云实例之前，根本没算过模型到底要吃多少显存，结果买回来发现跑不动，或者租了一天八卡 A100 结果只用到 20% 的算力。这步其实特别关键，可以先不聊框架、不聊服务，先把显存这笔账算清楚。

1.1 显存是第一硬指标，怎么算

模型部署时的显存占用主要有三块：模型权重、KV Cache、中间激活值。推理场景下前两块占大头，中间激活值通常不用太担心；如果是微调场景，激活值和优化器状态会暴增，同样一个模型需要的显存可能是推理的 3 到 6 倍。

模型权重的计算很直观，以 7B 参数模型为例，FP16/BF16 精度下，每个参数占 2 字节，权重约 14GB。INT8 量化后约 7GB，INT4 量化后约 3.5GB。13B 模型在 BF16 下就是 26GB 左右，70B 模型在 BF16 下约 140GB。也就是说，单张 24GB 的显卡在 BF16 精度下，最多放得下 7B-8B 级别的模型权重，再大的模型就要考虑量化、多卡张量并行或者干脆上更大显存的卡。

KV Cache 是很多人容易忽略的部分。它存储的是推理时每个 token 对应的 Key 和 Value，占用大小可以用一个粗略公式估算：KV Cache 字节数约等于 2（K 和 V 两组）乘以层数乘以 KV 头维度乘以序列长度乘以并发数乘以精度字节数。层数、注意力头维度都能从模型配置里读到，我用 LLaMA 7B 举例：32 层、KV 头维度 128、序列长度 2048、并发 16、BF16 精度，算下来大概 2 × 32 × 128 × 2048 × 16 × 2 = 536MB 左右。这个量级看着不大，但注意序列长度翻到 32K、并发翻到 128，KV Cache 就会到几十个 GB，直接决定你能开多少并发。生产环境里建议把模型权重和 KV Cache 合在一起看，并预留 10%-20% 的余量。

1.2 推理还是微调，硬件策略完全不同

推理场景看重的是显存容量和吞吐，计算上其实 4090 这类消费卡就能做事，瓶颈往往在显存不够放长上下文和多人并发。微调场景则是另一个维度，梯度、优化器状态都是额外的显存开销。以 LoRA 这类参数高效微调为例，单张 24GB 显卡能微调 7B 模型，但全参数微调就要谨慎很多。全参数微调 7B 模型，混合精度训练下通常需要 60GB 以上显存才比较舒服，所以要么上 A100/H100 80GB 版本，要么做多卡数据并行+张量并行。

做硬件策略时我的建议是：如果你主要做推理，优先把显存容量和显存带宽放在第一位；如果你要频繁微调和全参数训练，优先考虑多卡互联带宽，也就是 NVLink、InfiniBand 这类，因为梯度同步和流水线并行对卡间通信特别敏感。我自己踩过坑，曾经用普通 PCle 4.0 x16 广口连接两张卡做张量并行，性能远不如带 NVLink 的双卡，差距能到 30% 以上，训练场景下更夸张。

1.3 消费卡、专业卡和云上实例，到底怎么选

消费卡的代表是 4090、5090 这类，算力强、显存 24G 或 32G，性价比极高，但有两个天生问题：一是显存带宽和专业卡有差距，二是机架式服务器里供电散热不好处理。个人开发机和原型验证我非常推荐用消费卡，但要上生产环境，稳定性优先，专业卡如 A10、L20、L40S、A100、H100、H20 更合适。专业卡的优势是显存 ECC 纠错、持久化显存模式、更好的散热设计，还有驱动支持周期长。

这里要给个云上的现实建议：如果是 1-2 张卡的推理需求，租一台带 4090 的云服务器最省成本；如果是 8 卡级别的训练或服务，直接租整机，不要自己买。因为整机功耗几千瓦，机房、电费、故障率都是隐性成本，而云上的 H800/H20 集群随时可扩，按小时计费，弹性好得多。云服务这块我会在第三章详细对比。

2. 框架选型：推理与微调分开谈

框架不是越新越好，而是要和你的场景匹配。我的实践经验是：推理服务选 vLLM 系或 SGLang 系，不要自己从头写调度；微调用 LLaMA-Factory 这类统一框架，不要每个模型都单独找仓库里的 training 脚本。

2.1 主流推理框架速览：vLLM、SGLang、LMDeploy

vLLM 是目前生产环境里事实上的标准。它用 PagedAttention 把显存里的 KV Cache 按页管理，配合 Continuous Batching，能把单卡吞吐压榨到接近理论上限。社区支持极其庞大，几乎所有开源模型发布时都会顺手给一个 vLLM 的适配，新模型支持补丁也最快。我个人推荐所有刚起步的项目直接上 vLLM，文档全、坑少、社区问答多，踩坑成本最低。

SGLang 在 vLLM 基础上做了 RadixAttention，适合多轮对话和 Agent 这类有大量前缀复用的业务。它对结构化输出、并行采样、多模态输入的支持也比 vLLM 更激进。如果你的服务是高频多轮对话，或者大量用户共享相同的 system prompt，SGLang 的前缀缓存命中率优势明显。不过它的版本迭代快，偶发兼容性问题多一点，建议在测试环境充分压测后再上生产。

LMDeploy 是国内团队维护的推理框架，TurboMind 引擎性能优秀。它的量化支持比较完善，AWQ 和 KV Cache INT8 量化都能直接用。如果是国产算力环境，比如昇腾、寒武纪等，LMDeploy 的适配度往往比 vLLM 更好。我建议国产卡场景优先考虑它，NVIDIA 卡场景还是首选 vLLM。简单总结一下这张选型表：

2.2 关于 TCC 和 WDDM 的误区

选型群里经常能看到有人问“大模型选 TCC 还是 WDDM”，这里要先说明，TCC（Tesla Compute Cluster）和 WDDM（Windows Display Driver Model）不是推理框架的选择，而是 NVIDIA 驱动在不同系统下的两种运行模式。

WDDM 是 Windows 图形驱动模型，驱动里包含图形调度、桌面合成这些逻辑，适合游戏、设计软件、桌面 GPU 直连显示器。TCC 是专门面向计算卡的模式，不加载图形显示功能，GPU 直接作为纯计算设备使用，CPU 可以直接访问显存，这在 CUDA 计算里效率更高，也支持 GPU 持久性模式和更稳定的大规模并行。所以如果你在 Windows 上用消费卡做实验，驱动默认 WDDM，没问题；但一旦上服务器、上 Linux，或者用 Tesla/专业计算卡，就应该切到 TCC 模式，尤其多卡环境。一个最简单的判断：你不需要这块卡输出画面，它就应该是 TCC 模式。

2.3 微调框架：LLaMA-Factory 与 Axolotl 怎么选

做微调的主流工具还有 LLaMA-Factory 和 Axolotl 两个，以及它们背后的生态。LLaMA-Factory 的全称是用于大模型微调的统一 Web UI 和命令行框架，对初学者特别友好，支持 LoRA、QLoRA、全参数微调，内置了大量模型架构适配。我自己的经验是，LLaMA-Factory 的 WebUI 适合快速做实验、看训练 loss、下采样数据，团队内部做任务型微调时非常高效。

Axolotl 更偏“配置文件驱动”，用 YAML 定义数据集、模型、训练参数，可复现性特别好。它更适合搭建标准化训练流水线，比如我需要把微调任务固化到 CI/CD 里，每次训练用同一份配置，改数据集重新跑就可以。如果你的团队有专门的训练工程师，追求实验可复现和数据记录规范，Axolotl 是更好的选择。个人或者小团队做业务微调，我建议先从 LLaMA-Factory 上手，跑通后如果发现需要大量自动化实验再切 Axolotl。

3. 云服务对比：从省钱到省心

很多人对云 GPU 的认知停留在“租个带显卡的机器”，但真到了生产，要考虑的远不止 GPU 型号。网络带宽、磁盘 IO、存储价格、数据迁移这些环节，哪一个没规划好，后面都要付出真金白银的代价。

3.1 主流云 GPU 平台横向对比

我把云服务商分成三类：一类是大型综合云厂商，比如阿里云、腾讯云、华为云，以及 AWS、Azure、Google Cloud 这些；第二类是专门做 GPU 算力租赁的平台，常见的有 AutoDL 这类共享 GPU 服务、Vast.ai 这类去中心化算力市场；第三类是大模型一体机或私有化交付方案。大模型场景我推荐优先看第一类里的 GPU 云主机或者模型服务平台，比如阿里云的 ECS GPU 实例、PAI-EAS，腾讯云的 TI 平台，华为云的 ModelArts。

综合云厂商的优势在稳定性和周边生态。阿里云 ECS 的 GPU 实例可以搭配 VPC、负载均衡、云监控、KMS 密钥管理系统，生产环境直接把 API 网关、数据库、对象存储都串起来。AWS 的 SageMaker 对 MLOps 的支持更完整，从数据处理到训练到推理部署都有托管组件。Google Cloud 在 TPU 和 Kubernetes 集成上有优势，但国内团队访问不便，我一般不太推荐。AutoDL 这类平台适合做算法实验和临时跑训练任务，价格可能比综合云便宜 30%-50%，但不适合承载生产流量，因为实例网络隔离、SLA 保障、数据持久化能力都偏弱，真出故障的时候平台响应速度也不够。

3.2 按场景选：原型验证、训练、长期服务

我的建议是分三种场景来选。原型验证追求低成本快速起，租 1 张 4090 或者 2 张 3090 足够，平台选 AutoDL 这类灵活的就行，跑通模型、测完效果立刻释放。长期训练任务要买整机或包周期实例，重点看卡间互联，比如阿里云的 P100/A100 集群，尽量选带 NVLink 或 InfiniBand 的规格，不然 8 卡训练会卡在通信上。推理服务则要优先看服务可用性和弹性扩容能力，我建议用云厂商的托管推理平台，比如阿里云 PAI-EAS，或者自己在 GPU 云主机上部署 vLLM，配合 SLB 负载均衡和弹性伸缩，这样流量上来就扩容，流量下去就缩容。

很多团队忽略跨云迁移和数据回流的成本。如果你一开始在共享算力平台训练，数据存储用的是对方平台的对象存储，后续要把模型和数据迁到正式生产云，比如阿里云 OSS，下载上传会产生大量流量费用和耗时。我吃过这个亏：训练好的几十 GB 模型文件迁移加上数据集，来回折腾了很久，费用也不低。所以在最开始做原型验证时，就顺手把数据放在标准格式的对象存储里，后面迁移会顺畅很多。

3.3 部署时容易被忽略的周边配置

云服务器部署大模型服务时，光配好 GPU 驱动还不够。第一个容易忽略的是安全组和防火墙入方向规则，很多人在云控制台打开端口之后，又在服务器里遇到 iptables/ufw 拦截，导致 API 端口外部访问不通。我的习惯是统一在云平台安全组层面管控，服务器内部默认不开额外防火墙，减少一层排查变量。

第二个是存储类型。GPU 实例的系统盘默认是云盘，但如果把模型文件放在系统盘，加载几百 GB 模型时会很慢，而且系统盘扩容代价高。建议使用独立的云盘或高性能文件存储，比如阿里云 NAS 或文件存储 CPFS，多个 GPU 节点共享同一个模型目录，省去每台机器拷贝一份的时间。我经历过 4 台节点手动同步模型文件，先后顺序和版本不一致导致线上推理结果异常，后面改成共享存储才彻底解决。

第三个是内网访问策略。生产环境的模型服务应该只对 VPC 内网开放，不要直接暴露公网。如果需要从个人电脑调试访问，可以用安全组临时放开白名单 IP，或者通过堡垒机跳转。有个常规技巧，用 frp 之类的工具把云服务器的内网端口映射到本地调试，不能替代生产访问路径，但确实能让开发调试舒服很多。不管哪种方式，公网接口一定要有鉴权，别裸奔。

4. 生产级部署流程：从镜像到监控

前面的选型和云资源定下来后，接下来的部署流程就相对固定了。我以 Ubuntu 22.04 系统、NVIDIA GPU、vLLM 推理服务为例，给出一套我实际验证过的生产级流程。这套流程的目标是：可重复、可回滚、可监控，而不是跑起来就行。

4.1 环境准备与驱动安装

拿到一台 GPU 云主机后，第一步确认 GPU 型号和驱动。执行nvidia-smi能看到 GPU 状态，如果提示找不到命令，说明驱动还没装。Ubuntu 下安装 NVIDIA 驱动建议通过 apt 安装，比如安装 550 版本驱动：apt install nvidia-driver-550。装完重启，再nvidia-smi确认 GPU 出现在列表里。

接下来是 CUDA 和 cuDNN，其实现在很多推理框架自带 CUDA 运行时环境，尤其是用 Docker 部署的话，镜像里已经包含 CUDA。我强烈建议生产环境直接用 NVIDIA NGC PyTorch 镜像或 vLLM 官方镜像，不要在自己宿主机里折腾 CUDA 环境。有一个经验法则：宿主机只装驱动，CUDA 版本跟随容器走，这样可以避免框架依赖的 CUDA 版本冲突。

Docker 环境也在这里一并装好，NVIDIA Container Toolkit 是必需组件。安装后执行docker run --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi验证容器能访问 GPU。

4.2 模型下载与格式准备

模型文件建议提前下载到共享存储或多节点本地磁盘。使用 Hugging Face CLI 或 ModelScope 的 SDK 都可以，国内环境用 ModelScope 下载速度会更稳。重点是下载后确认模型目录结构完整，包含 config.json、tokenizer 相关文件，以及权重分片文件。如果下载的是源格式，vLLM 能直接加载大多数主流架构，不过有一些小众模型或者 GGUF 格式可能需要做转换。

GGUF 格式在 llama.cpp 生态里很常见，但 vLLM 不直接加载 GGUF，需要通过 llama.cpp 转换回 HF 格式，或者直接用支持 GGUF 的工具。这个细节经常害人白等半天。我用过一个笨办法，在上生产前先跑一个小脚本，用transformers库直接加载一遍模型，能加载成功基本就说明权重没损坏，格式也正确。这个验证步骤很值得做，能省掉后续服务起不来的排查时间。

4.3 vLLM 服务化与 GPU 显存参数配置

vLLM 启动一条命令就能起服务，但参数配置直接决定服务质量和并发上限。基本的 OpenAI 兼容服务命令大概长这样：

python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b-instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 32768 \ --host 0.0.0.0 \ --port 8000

这里最值得讲的是--gpu-memory-utilization参数，它控制 vLLM 最多使用多大比例的 GPU 显存。我建议设置在 0.85 到 0.9 之间，不要用默认的 0.9 甚至更高，因为显存管理需要留一部分余量给 Python 运行时、CUDA context 和碎片化开销。设到 1.0 很容易在并发高峰直接 OOM，服务恢复起来非常痛苦。

--tensor-parallel-size是多卡并行参数。一张卡放不下模型时，比如 70B 模型在 2 张 80GB 卡上，可以设成 2。跨多卡会多一层通信开销，但这是大模型部署必经之路。

--max-model-len控制最大上下文长度，设太大显存预留的 KV Cache 就会很大；设置太小用户的长文档输入会被截断。合理的策略是先跑一个最长输入样例，观察显存占用和实际 KV Cache 用量，再反向调这个参数。我这里给一个实操过的案例：7B 模型、24GB 显存、max-model-len设置为 16384、并发 32 时，需要把gpu-memory-utilization设置在 0.8 左右才不容易爆显存。

提示：vLLM 提供了--enable-prefix-caching参数，多轮对话或者多用户共享 system prompt 的场景建议开启，它能显著提升吞吐。开启后要留意监控指标的prefix_cache_hit_rate，这个数值越高，说明缓存收益越大。

4.4 网关、鉴权与负载均衡

模型服务起来了，还不能直接暴露给业务方。生产环境至少要做三层：Nginx 做反向代理和负载均衡、API Key 做鉴权、Prometheus 做监控采集。vLLM 本身开放了/metrics端点，格式就是 Prometheus 标准格式，直接接入即可。

Nginx 侧的配置不难，把 /v1 路径代理到 vLLM 端口就行。需要注意的一点是模型输入输出都是大 JSON，请求体大小限制一定要调大，默认的 1MB 根本不够，建议至少client_max_body_size 100m。另外要给 Nginx 和 vLLM 之间配置 keepalive，降低 TCP 连接重建开销。我见过线上服务每次请求都重新建立 TCP 连接，长文本生成的耗时里可能有 20% 都花在连接建立上。

鉴权建议通过网关层统一做，最简单的方案是 Nginx 里校验一个自定义 Header，当然更规范的做法是用服务网格或 API 网关统一下发 Token。关键点是不要在代码逻辑里到处散落密钥，而是集中到环境变量或者 Secret 管理服务里。这个点看似基础，但真实项目里泄露 API Key 的事故一点都不少见。

生产流程里我还会加一个滚动发布环节。新版本模型上线时，先在灰度节点启动新服务，用少量流量验证效果和稳定性，观察监控指标没有异常后，再把 Nginx upstream 切到新节点。回滚时同理，保留上一个版本的容器镜像和模型路径，一条命令切回去就行。这样比直接替换服务要稳妥得多。

5. 常见问题与排查实录

这部分内容是我在实际部署中被折腾最久的经验集合。大模型服务看起来简单，但故障场景非常刁钻，很多问题不会在测试环境暴露，只会在线上流量高峰时突然出现。

5.1 OOM 与显存碎片

OOM 是部署大模型绕不开的坎，它的表现有很多种：服务启动时直接报CUDA out of memory，运行中进程崩溃，或者推理请求突然超时。这里的经验是，不要把 OOM 的原因简单归到“显存不够”，要分情况看。

第一种是权重就放不下。比如 24GB 卡尝试加载 13B 模型，BF16 下权重 26GB，这属于硬性不足，只能量化或者换卡。第二种是运行时显存被其他进程占用，特别是多卡机器上其他任务没释放，nvidia-smi里能看到其他进程占着显存，查一下进程并清理即可。第三种是 vLLM 的预留给 KV Cache 太少，导致高并发下请求排队，看似没有报错但延迟飙升。这种情况我一般先看nvidia-smi的显存使用率曲线，如果长期处于 95% 以上，可以逐步上调--gpu-memory-utilization，每次加 0.05 观察稳定性。

排查 OOM 的最好工具就是nvidia-smi加vllm日志。vLLM 日志里会输出注册到模型引擎的并发数和显存情况。如果发现 PagedAttention 触发了频繁的显存换页，说明 KV Cache 不够，需要调大显存利用率或降低并发上限。

5.2 接口响应慢

接口响应慢其实要区分为两种：首 token 延迟高和生成吞吐低。首 token 延迟高通常是模型计算没有开始就卡在排队上，或者请求带了极长的历史上下文，全量预填充耗时太久。前者看并发队列长度，后者可以优化为对超过阈值的旧上下文做截断或摘要，避免每次全量走一遍。生成吞吐低则常是张量并行效率不高，需要检查卡间通信和模型拆分粒度。

还有一个被很多人忽略的因素是 CPU Offload 到磁盘的交换。如果max-model-len设置过大，vLLM 可能把部分 KV Cache 换到 CPU 内存，推理速度断崖式下降。我在排查时观察到nvidia-smi里 GPU 利用率不到 30%，但磁盘读写很高，才知道是换页导致的。解决办法就是调小max-model-len，或者减少并发。

5.3 安全组与访问异常

服务部署完，外部访问不通是最常见的开局问题。排查顺序我建议从外到内：先看云控制台安全组有没有放行端口，再看服务器本地防火墙状态，然后看服务进程监听地址是不是0.0.0.0。vLLM 如果监听默认localhost，外部访问自然不通，启动命令里--host 0.0.0.0必须明确写上。

访问异常还有一个隐蔽原因：云服务器的带宽或者 QPS 限制。GPU 实例的规格不同，公网带宽上限也不同，大模型请求响应体动辄几 MB，如果带宽不足，客户端会表现为超时或下载极慢，但服务端nvidia-smi显示 GPU 利用率很低。这个坑我见过很多人在生产第二天才暴露出来，一查公网带宽已经打满了。建议如果业务流量大，尽量走内网调用，比如同一个 VPC 下的其他业务服务器直接访问 GPU 实例内网 IP，避开公网瓶颈。

提示：如果在云上做生产推理服务，优先把模型服务放在内网，让应用服务和模型服务同 VPC 互通。大模型响应体大，走公网既慢又贵，内网调用延迟和带宽都更可控。

6. 一些实践中的体会

最后分享几个我长期踩坑攒下来的心得。大模型服务器部署这件事，难点从来不是“启动一个模型”，而是让它稳定跑在线上、成本可控、可观测、可回滚。我个人最深的体会是，不要迷信所谓“推荐配置”，每台机器、每个模型、每类业务流量都有自己的脾气。启动参数、显存利用率、并发上限，这些都要用真实业务流量去压测后确定。我的习惯是先把最小可用服务跑起来，再用 JMeter 或者自写脚本发送不同并发和不同上下文长度的请求，观察响应时间、吞吐和显存曲线，把gpu-memory-utilization、max-model-len、并发上限这几个参数调到相互匹配。

另外一个很实用的技巧是：在做容量规划时，先估算业务高峰期的最高并发和平均输入长度，再反推需要的显存和卡数，而不是反过来先买卡再想跑什么模型。比如你的业务是客服问答，平均输入 2K tokens、高峰期并发 50，那 7B 级别的模型一张 24GB 卡就够用；如果是代码生成或者长文档分析，平均输入 16K tokens，那至少需要 40GB 以上的显存，建议直接 80GB 卡。

还有一个小 TIP 想分享给正在做微调的朋友：微调完成后，一定要把模型权重从训练框架里导出为 Hugging Face 格式，再放到 vLLM 里验证推理结果。这一步经常被忽略，导致模型在训练阶段 loss 很好看，上线推理却出现输出乱码或不符合预期。我习惯在微调结束后用一套固定的评测 prompt 做回归测试，对比微调前后的回答质量，确认没问题再进入部署流程。整个链路都走顺之后，你会发现大模型服务器部署没有那么神秘，它无非是显存计算、框架匹配、云资源规划和工程化流程的组合，把这些基础打牢，后面无论换什么模型、什么框架，都能快速上手。