在单张 H100 上运行 OSS LLM：更智能、更便宜、更快速

场次笔记

P5.4xlarge 实例简介：

• AWS 推出 P5.4xlarge，让用户能够在单张 NVIDIA H100 GPU 上托管强大的开源 LLM（例如 Qwen-32B、Mistral 和 LLaMA 2）。
• 解决过去必须过度配置大型、昂贵多 GPU 集群的问题。目标受众：
• 希望托管 OSS LLM，又不愿承担高昂成本或牺牲性能的工程师、初创公司和个人爱好者。
• 希望智能扩展，而不是使用庞大集群纵向扩展的团队。主要优势：
• 成本效益：减少过度配置和管理复杂多 GPU 集群的需求。
• 性能：单张 H100 GPU 在内存或计算能力方面都不打折扣。
• 可及性：让更多开发者能够使用强大的 GenAI 功能。会议亮点：
• 探索 OSS 模型在 P5.4xlarge 上的真实基准测试。
• 探讨 Agent 式 GenAI 工作流和节省成本的策略。
• Hugging Face transformers 等模型和低延迟聊天机器人的实用部署技巧。实际成果：
• 了解哪些 OSS 模型可在单张 H100 上高效运行。
• 了解 P5.4xlarge 的预期性能。
• 设计符合特定需求且不会过度配置的基础设施策略。结论：
• “我们大多数人并不需要 8 张 GPU 的怪兽级设备，就能交付实用的聊天机器人或 GenAI 应用，但最终还是为这种设备付了钱。”
• 让小型团队和个人工程师能够使用 AWS P5.4xlarge，有效且经济高效地部署 OSS LLM。– 引出需求：
• “想象一下，不必只为使用一张 H100 而付费和管理 8 张 GPU，而是终于可以选择与工作负载匹配的实例大小。”
• 问题：
• 过度配置大型 GPU 集群造成的低效率和成本。宣布突破：
• 新产品：
• “AWS 最近推出了新的单 GPU P5 实例大小：p5.4xlarge 为你提供最新的 NVIDIA H100——不再过度购买，不再浪费。”
• 解决方案：
• 强调消除不必要的费用和复杂性。突出规格和简洁性：
• 实例规格：
• “p5.4xlarge 包含你需要的一切：1×H100 GPU、16 个 vCPU、256 GiB RAM、近 4 TB NVMe SSD，以及 100 Gbps 网络。”
• 优势：
• “拥有旗舰 GPU 的全部性能，同时部署简单、账单更低。”让价格对比变得切实：
• 成本对比：
• “在某些区域，每小时约 $3.90 即可租用；相比之下，使用更大型的 P5 必须为全部 8 张 GPU 付费。”
• 影响：
• “这大幅降低了小型团队开展实验、演示，甚至投入生产的门槛。”之前和现在：
• 过去的情况：
• “过去，H100 意味着‘企业级规模’和巨额前期成本。”
• 当前情况：
• “现在只需单击一下，就能获得专业级能力——非常适合单租户 API、Agent 式 RAG、内部工具和快速发展的初创公司。”
• 转变：
• 专注于让高性能 GPU 能力更易获取、价格更可负担。希望受众记住的重点：
• 可及性：
• “p5.4xlarge 让‘普通’用例也能使用 NVIDIA H100 的性能——不需要庞大集群。”
• 效率：
• “更简单、更便宜，而且大小恰好适合大多数开源 LLM 服务和实验。”
• 最佳解决方案：
• “如果你想为 GenAI 使用最好的 GPU，现在只需获得一张——不需要集群。”– 单张 H100 究竟能容纳什么？用于通用聊天和强大推理的 Qwen3‑32B：
• “Qwen3‑32B 是一个拥有 32.8B 参数的稠密模型，支持最多 32k token 的上下文——因此实际的文档聊天、编程，甚至 Agent 式用例都能出色运行。”
• 性能：
• “在单张 H100 上，它能以约 1,500 tokens/sec 轻松运行，同时为几个聊天会话提供服务后仍有余量。”追求效率的 Mistral／Mixtral：
• “Mistral 7B 和 Mixtral‑7x8B：它们针对推理进行了优化；尽管每个 token 激活的参数少得多，但在某些基准测试中的表现甚至超过 70B 稠密模型。”
• 性能：
• “H1100 上的 TensorRT‑LLM 提供约为 A100 3 倍的吞吐量。这意味着只需一小部分硬件，就能获得接近 70B 的性能。”Llama 2‑13B／70B：整体视角以及单张 GPU 何时不够用：
• “Llama 2‑13B 在单张 H100 上运行飞快（5,000+ tokens/sec）；70B 可以运行，但若要真正实现规模化，有时确实需要多张 GPU。”
• 用例：
• “对于大多数聊天和 RAG 产品，13–32B 不仅装得下，而且运行飞快。只有追求最高质量或最大模型时，70B 才是必需的。”
• “如果需要的是 ≤32B 稠密模型（或激活 13B 参数的 MoE），一张 H100 就足以支持实时聊天机器人和 GenAI API。”– 说明价值：
• “让我们看看三种能在单张 H100 上完美运行的常见 GenAI 架构——不需要分布式基础设施，也没有集群带来的麻烦。”模式 1 – 低延迟聊天／推理 API：
• “只用一台服务器即可提供真正的聊天机器人和推理 API：使用 Hugging Face Transformers 加载模型，通过 vLLM 或 TensorRT‑LLM 提供服务，并在前端搭配简单的 API gateway。”
• 优势：
• “H100 的强大算力意味着更高的并发能力和更低的代码复杂度——不需要分片或并行技巧。”模式 2 – 检索增强生成（RAG）：
• “使用 RAG 时，将向量数据库和文档放在 GPU 之外，让 H100 负责繁重的 LLM 生成工作。”
• 优势：
• “这样可以降低成本并提高性能。通过智能量化，现代 MoE 模型甚至能装进一张 H100——不需要特殊的硬件技巧。”模式 3 – Agent 式工作流：
• “想串联操作并构建 Agent？一张 H100 可运行 32B 规划模型，由该模型调用工具（通过 HTTP、Lambda、容器等）。”
• 优势：
• “GPU 只忙于‘思考’，因此每个实例都能同时支持多个 Agent 流程和用户。”总结：
• 只使用一个 H100 实例，即可构建大多数 GenAI 产品，包括聊天、API、RAG 和 Agent。”– 说明比较方式：
• “让我们把目前为止的所有内容转化为一个简单的决策：何时使用一张 H100 合理？何时真正需要集群？”效率：
• “研究显示，多 GPU 集群很少能实现完美的线性扩展。使用 8 张 GPU 时，通常只能获得预期速度的 75–85%——GPU 间通信会拖慢速度，对实时推理尤其如此。”成本和敏捷性优势：
• “p5.4xlarge 的价格约为 $3.90/hr，小型团队只需几美元即可运行生产级 GenAI，无需对大型集群做出巨额投入。”单张 H100 用例：
• “如果模型为 13–32B，或是激活约 13B 参数的 MoE，单张 H100 即可支持：开发、内部工具、早期生产和中等流量——而且完全没有集群的麻烦。”多 GPU 用例：
• “只有在需要真正的 70B+ 规模或必须支持巨大流量时，才使用多张 GPU。”未来参考：
• “如果未来超出单张 H100 的能力，吞吐量更高的 H200 即将到来。”
• “但对如今几乎所有人来说，H100 都是最佳平衡点。”– 总结主要要点：
• “对于大多数开源 LLM 工作负载，不需要庞大集群——只需一个根据需求调优的 H100 p5.4xlarge。”能容纳的模型：
• “我们已经看到能容纳的模型——Qwen3‑32B、Mistral、Llama2‑13B、Mixtral——全都能在单张 H100 上流畅运行。”现代架构：
• “我们探讨了三种现代架构——聊天 API、RAG、Agent 式工作流——每一种都能借助一张 H100 得到简化并实现扩展。”节省成本和复杂性：
• “而且可以节省资金并降低复杂性，只有在需要超高并发或使用最大型模型时才转向集群。”

26

Adit Modi

在单张 H100 上运行 OSS LLM：更智能、更便宜、更快速

为什么要举办这场会议，它适合谁

• 运行 GenAI 真的需要 8 张 GPU 吗？
• 别再为 LLM 基础设施支付过高费用和进行过度设计。这场会议适合谁？
• 厌倦过度配置和管理笨重多 GPU 集群的小型团队、初创公司和个人工程师。
• 希望按自己的方式运行开源 LLM，又不想成为全职集群管理员的开发者。
• 想了解如何在不产生巨额账单的情况下，为聊天机器人、API 和 RAG 获得大型模型性能的任何人。这场会议不适合谁？
• 使用 Bedrock、SageMaker JumpStart 等托管式 LLM 平台，或偏好完全不控制基础设施的“LLM 即服务”的团队。
• 仅使用专有云 API（例如 OpenAl、Anthropic）进行构建，且没有自行托管模型计划的人。
• 需要以高 QPS 运行 70B+ 参数模型，且愿意使用大型分布式集群的任何人。OSS LLM 的“过度配置集群”问题 大多数 GenAI 用例不需要这么多资源！那么，有更好的方法吗？
• 团队默认采用庞大的多 GPU 云配置来运行开源 LLM——只是为了保险。
• 这会带来复杂的分布式推理、速度下降和高昂成本，而实际工作负载往往很轻。
• 事实上，大多数现代产品用例搭配单张强大 GPU 和较小的 7B／13B／32B 模型，运行得更快也更便宜。
• 合理调整硬件规模意味着更低延迟、更少麻烦和大幅节省。运行 LLM 并不一定意味着要使用复杂的多 GPU 集群。
• 过度配置会增加成本和复杂性，却是许多团队的默认选择。
• 对于大多数现代 OSS 模型和典型产品工作负载，只需一张配置完善的 GPU，即可兼顾速度、简洁性和成本节省。认识 p5.4xlarge：用单张 H100 处理实际工作负载 一张好 GPU 终于触手可及
• Amazon Web Services 最近推出了新的单 GPU P5 实例大小：
• p5.4xlarge 为你提供最新的 NVIDIA H100——不再过度购买，不再浪费 p5.4xlarge：规格与简洁性
• p5.4xlarge 包含你需要的一切：
• 1xH100 GPU、16 个 vCPU、256 GiB RAM、近 4 TB NVMe SSD，以及 100 Gbps 网络。拥有旗舰 GPU 的全部性能，同时部署简单、账单更低。
• 在某些区域，每小时约 $3.90 即可租用；相比之下，更大型的 P5 必须为全部 8 张 GPU 付费。

一张 H100 能容纳什么？（Qwen-32B、Mistral、Llama-2 等）

Qwen3-32B — 强大推理，单张 GPU

• Qwen3-32B：32.8B 稠密参数、32k 上下文，具备强大的聊天／编程能力
• 在单张 H100 上以约 1,500–1,800 tokens/sec 运行
• 非常适合 Agent 式聊天机器人和 API 工作负载（可以批处理请求）Mistral／Mixtral — 高效性能
• Mistral 7B：在 H100 上运行飞快，使用 TensorRT-LLM 时吞吐量为 A100 的 3 倍
• Mixtral-7x8B (MoE)：接近 70B 的性能，VRAM 用量低得多
• 高效模型，在成本和速度方面表现出色——非常适合生产环境 Llama 2 (13B／70B) — 现实检验
• Llama 2-13B：在单张 H100 上达到 5,000–6,000 tokens/sec（经过优化）
• Llama 2-70B：可以运行，但延迟高——仅适合真正需要 70B+ 的情况
• 大多数产品使用一张 GPU 运行 13B– 32B 即可获得出色结果 经验法则——一张 H100 能做什么？
• 如果 LLM 是 <32B 稠密模型，或是激活约 13B 参数的 MoE，单张 H100 就足以支持响应迅速的多用户聊天和 RAG API H100：OSS GenAI 服务的新最佳平衡点
• 单张 GPU 上的设计模式：API、RAG 和 Agent 聊天及 API 服务模式
• 在单张 H100 上运行 LLM API：Hugging Face + vLLM／TensorRT-LLM
• 以低延迟服务多个用户——不需要集群运维或分片
• 简单、快速且可用于生产环境的部署 检索增强生成（RAG）
• 将向量数据库／文档存储在 GPU 之外；使用 H100 进行 LLM 生成
• 单张 H100 为 RAG API 提供高吞吐量和快速 GenAI
• Mixtral／MoE 模型：通过量化装进单张 GPU Agent 式工作流
• H100 上的“规划器”LLM（Qwen／Mistral）将任务路由到外部工具
• GPU 用于思考，工具在其他地方运行（HTTP、Lambda、容器）
• 在一个实例上支持多 Agent、多用户流程 回顾——一张 H100，多种模式
• 只使用一个 H100 实例，即可构建大多数 GenAI 产品，包括聊天、API、RAG 和 Agent。
• 成本和合理配置：何时一张 H100 就足够

一张 H100 与多 GPU 集群的比较

• 多 GPU 集群：效率为 75–85%，很少能加速 8 倍
• GPU 间通信拖慢扩展速度——硬件越多，复杂性越高
• 单张 H100 即可为大多数 OSS 模型提供强大性能 成本：p5.4xlarge 经济实惠
• 每小时仅 $3.90（Capacity Blocks，特定区域）
• 运行实验、开发或生产工作负载——无需为 8 张 GPU 付费
• 非常适合小型团队、初创公司和内部工具 何时选择 H100 或多 GPU
• 单张 H100：非常适合 7B– 32B 稠密模型或激活约 13B 参数的 MoE LLM，以及中等 QPS
• 多 GPU：真正的 70B+ 模型或大规模微调才需要
• H200：追求超高吞吐量的下一步（面向未来）回顾与主要要点
• 大多数 OSS LLM 工作负载：单张 H100 p5.4xlarge 是明智之选
• 没有集群复杂性，也不浪费支出——只需运行、调优和部署 三个要记住的要点
• 哪些模型能容纳？Qwen3-32B、Llama 2-13B、Mistral、Mixtral——最高 32B
• 哪些模式？聊天 API、RAG、Agent 式工作流——全部在一张 GPU 上
• 何时使用：开发、内部工具、早期产品和中等并发 自己动手试 + 参考架构
• 启动 Amazon EC2 p5.4xlarge；使用 vLLM／TensorRT-LLM 部署
• 衡量自己的延迟、吞吐量和成本节省