实践 指南 · 阅读需 11 分钟 # 在单个节点上部署 Llama 3.3 70B。 从五分钟前刚交付的服务器，到能响应请求的 OpenAI 兼容端点——包含悄悄让吞吐量减半的两个参数，以及会让您系统被攻破的那一个。 简短的答案 - **所需显存:** 4-bit 为 43 GB，FP8 为 82 GB，BF16 为 164 GB — 均为 8k 上下文 - **最简单的机型:** 一张 80 GB 显卡。无需拆分、无需互联、无需同步 - **首个 token 延迟:** 从交付到可用不到十五分钟，大部分时间用于下载权重 - **唯一的错误:** 把 8000 端口发布到公网地址。它没有身份验证 ## 您需要什么 700 亿参数。采用 4-bit 精度时，权重为 35 GB；在 8k 上下文、单个请求下，KV 缓存额外增加 2.5 GB，运行时开销约 15%。其余部分都由这三个数字决定——具体来源见[显存估算指南](https://gpuserver.io/zh/guides/vram-sizing)。 **Llama 3.3 70B 所需显存，按精度和上下文划分** | 精度 | 权重 | 8k 时的总量 | 32k 时的总量 | 128k 时的总量 | |---|---|---|---|---| | BF16 / FP16 公版品质 | 140 GB | 164 GB | 173 GB | 207 GB | | FP8 接近公版，Hopper 与 Blackwell | 70 GB | 82 GB | 86 GB | 103 GB | | 4-bit (AWQ, GPTQ) 权重最小，缓存保持 FP16 | 35 GB | 43 GB | 52 GB | 86 GB | 请注意 128k 那一行的 4-bit 数据：权重缩小到 35 GB，但缓存完全不会缩小，因为 AWQ 和 GPTQ 只量化权重。仅这一点，就决定了下面大部分的机型选择。 ## 选择节点 产品目录中，能在*单张*显卡上放下该模型的最便宜机型——如果可以选择，这正是您想要的配置：不拆分意味着不用同步，也少一件需要排查的事。 **能在单张显卡上放下 Llama 3.3 70B 的节点** | 节点 | 放得下的精度 | 显卡显存 | 预计 tok/s | 每月 | |---|---|---|---|---| | [NVIDIA RTX A6000](https://gpuserver.io/zh/gpu/rtx-a6000) PCIe 5.0 · 768 GB/s | 4-bit (AWQ, GPTQ) | 48 GB | ~10 | $286/月 | | [2 × NVIDIA RTX A6000](https://gpuserver.io/zh/gpu/rtx-a6000) PCIe 5.0 ×16 · 768 GB/s | 4-bit (AWQ, GPTQ) | 48 GB | ~10 | $597/月 | | [NVIDIA L40S](https://gpuserver.io/zh/gpu/l40s) PCIe 5.0 · 864 GB/s | 4-bit (AWQ, GPTQ) | 48 GB | ~11 | $714/月 | | [NVIDIA A100 PCIe](https://gpuserver.io/zh/gpu/a100-80gb) PCIe 5.0 · 1,935 GB/s | 4-bit (AWQ, GPTQ) | 80 GB | ~25 | $1,091/月 | 吞吐量指的是受显存带宽限制的单流生成速度，且刻意取保守值。在连续批处理下，多个并发请求的*总和*要高出好几倍——这正是 vLLM 的意义所在。 ## 十分钟搭建完成 除了地址之外，这里没有任何东西是我们特有的。Docker、NVIDIA 容器工具包和可用的驱动程序栈，服务器上都已经装好。 确认服务器，然后为权重找个存放的地方 ``` $ ssh root@203.0.113.42 $ nvidia-smi --query-gpu=name,memory.total --format=csv # Weights on the fast local NVMe, not the system volume. $ mkdir -p /scratch/models $ df -h /scratch # A gated model needs a token. Skip if yours is open. $ export HF_TOKEN=hf_xxxxxxxxxxxxxxxxxxxx ``` ## 启动服务 一个容器。首次运行会下载大约 40 GB 的量化权重，在 1 Gbit/s 端口上需要几分钟；之后每次重启只需几秒。 vLLM，单张显卡，4-bit ``` $ docker run -d --name vllm --restart unless-stopped \ --gpus all --ipc=host \ -v /scratch/models:/root/.cache/huggingface \ -e HF_TOKEN="$HF_TOKEN" \ -p 127.0.0.1:8000:8000 \ vllm/vllm-openai:latest \ --model casperhansen/llama-3.3-70b-instruct-awq \ --quantization awq_marlin \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 # Watch it load. "Application startup complete" is the signal. $ docker logs -f vllm ``` 首次请求 ``` $ curl -s http://127.0.0.1:8000/v1/models | head $ curl -s http://127.0.0.1:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{"model":"casperhansen/llama-3.3-70b-instruct-awq", "messages":[{"role":"user","content":"In one sentence: what is a KV cache?"}], "max_tokens":80}' ``` ## 真正重要的参数 --max-model-len 把它设为您实际提供的上下文长度 vLLM 会按声明的最大值预留 KV 缓存。声明 131072 而实际只用 8192，就白白浪费了 16 倍于所需的显存，表现出来的症状是“并发不够”，而不是报错。 --gpu-memory-utilization 0.90 到 0.95 vLLM 可占用的显卡比例。未被占用的部分都是浪费；在独享服务器上保留 0.90 的默认值，会让您损失实际可用的并发能力。不要超过 0.95。 --ipc=host 必需项，而非可选项 没有它，容器的共享内存会被限制在 64 MB。在单张显卡上您可能侥幸没事；但在拆分模型时，NCCL 会卡死且没有任何有用的错误提示。 --tensor-parallel-size 仅当模型放不下时 把一个单张显卡就能放下的模型拆分开，只会让它变*慢*。参见[互联指南](https://gpuserver.io/zh/guides/nvlink-vs-pcie)——这是让昂贵节点性能不如廉价节点最常见的原因。 --kv-cache-dtype fp8 让您的缓存减半 适用于 Hopper 和 Blackwell 架构。能让您可容纳的上下文或并发数翻倍，质量代价通常小到无法测量。这份清单里最容易拿到的收益。 --max-num-seqs 把它限制到您实际的并发数 在一台服务 8 个用户的机器上仍保持 256，意味着 vLLM 会按 256 来规划，并接受它其实容纳不下的请求，表现出来的是延迟骤增，而不是拒绝请求。 ## 不对外公开 **OpenAI 兼容 API 默认没有身份验证。** 若绑定到公网地址上的 `0.0.0.0`，就成了一个开放的推理服务器，扫描器几小时内就能找到它。请注意上面命令中的 `-p 127.0.0.1:8000:8000`——开头那个地址正是让它不暴露在公网上的关键，也是从别处复制命令时最容易被漏掉的一个字符。 通过 SSH 隧道从您自己的机器访问它——无需开放端口，无需管理证书，也没有什么能配置错： 从您的笔记本电脑 ``` $ ssh -N -L 8000:127.0.0.1:8000 root@203.0.113.42 # Now http://127.0.0.1:8000 on your laptop is the server. ``` 如果确实必须公开，请在前面加一个带 TLS 和 API 密钥的反向代理，同时在防火墙中限制来源地址。[文档](https://gpuserver.io/zh/docs#firewall)中有一套最小规则集。对于会回应任何请求的端点，多重防护才是正确的姿态。 ## 提升吞吐量 按值得尝试的顺序排列。前两项免费，通常也带来最大的收益。 1. **把 `--max-model-len` 降到您实际使用的上下文长度。**这几乎总是单项收益最大的调整，而且不会牺牲您原本在用的任何东西。 2. **把 `--gpu-memory-utilization` 提高到 0.95。**这是一台独享服务器，显卡上没有别的东西需要留出空间。 3. **如果显卡支持，开启 FP8 KV 缓存。**能让您可容纳的内容翻倍。 4. **在客户端做批处理。**连续批处理只有在请求并发到达时才有效。逐个发送的请求无论怎么配置，都会让显卡大部分时间处于空闲。 5. **到这一步之后，才该考虑更快的显卡。**生成速度受限于显存带宽，因此同一模型下，带宽为 4,800 GB/s 的 H200，大约是带宽为 2,000 的 H100 PCIe 的 2.4×——这是实实在在的提升，也是这份清单里最贵的一项。 调整前后都要测量——不要凭猜测 ``` $ docker exec vllm python -m vllm.entrypoints.openai.api_server --help | head -1 $ docker exec vllm vllm bench serve \ --model casperhansen/llama-3.3-70b-instruct-awq \ --num-prompts 200 --request-rate 8 # And watch the card while it runs: if utilisation sits below 90%, # the bottleneck is your client, not the GPU. $ nvidia-smi dmon -s um ``` ## 让它持续运行 有三件事值得在第一天就做好，因为这三件事如果拖到第十四天才发现，会很麻烦。 ### 重启策略 上面的命令中包含 `--restart unless-stopped`。重启后容器会自动恢复，权重已经在 `/scratch` 上，因此不到一分钟就能重新就绪。 ### 关注显卡，而不是进程 掉出总线的 GPU 仍会让容器看起来健康。健康检查中加入 `nvidia-smi -q -d PERFORMANCE` 才能发现这一点；仅检查端口发现不了。 ### 权重不会被备份 它们只存放在您本地的 NVMe 上，别无他处。这没关系——它们可以重新下载。但您微调过的适配器不行，请把它们存放在服务器之外的地方。 租期结束后，硬盘会在一小时内被清除，没有宽限期。`/scratch` 上的一切都会随之消失。这是刻意如此——正是同一份承诺，保证了您拿到的服务器上没有别人的数据——但也意味着，租期的最后一天不是开始搬移数据的时候。 ## 用这个模型对照我们出租的每一个节点进行核对。 配置器会显示哪些配置能用单张显卡容纳它，哪些需要拆分，以及每种配置各自的价格。 [打开配置器](https://gpuserver.io/zh/configure) [阅读指南](https://gpuserver.io/zh/guides) ## 其他指南 - [实践 · 10 分钟 在单张显卡上微调 70B 模型 在单张 48 GB 显卡上使用 QLoRA 微调：能放下什么样的模型、每月需要多少成本，以及为何完整微调需要完全不同量级的服务器。 阅读指南](https://gpuserver.io/zh/guides/lora-finetune) - [付款 · 8 分钟 用加密货币支付服务器费用 从点击支付按钮到最终获得 root 权限之间究竟发生了什么、应该选择哪种加密货币，以及首次付款时容易亏钱的四个常见错误。 阅读指南](https://gpuserver.io/zh/guides/pay-in-crypto) - [选型 · 9 分钟 模型实际需要多少显存 “能否放得下”背后的完整计算方法：模型的权重大小、KV 缓存占用，以及经验法则常常出现三倍误差的两个关键环节，本文将为您逐一拆解。 阅读指南](https://gpuserver.io/zh/guides/vram-sizing) --- 来源：https://gpuserver.io/zh/guides/serve-llama-70b/。本文件由与网站相同的数据生成；如果此处的数字与页面不一致，以页面为准，本文件视为过期——权威来源是 https://gpuserver.io/。