在單張 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 上的實際基準測試。
• 探討代理式 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、代理式 RAG、內部工具，以及快速前進的新創公司。」
• 轉變：
• 著重於讓高效能 GPU 能力更容易取得且負擔得起。希望聽眾帶走的重點：
• 普及性：
• 「p5.4xlarge 讓『一般』使用案例也能運用 NVIDIA H100 的效能，不需要龐大叢集。」
• 效率：
• 「更簡單、更便宜，而且大小恰好適合大多數開放原始碼 LLM 服務與實驗。」
• 最佳解決方案：
• 「如果你想為 GenAI 使用最好的 GPU，現在只需取得一張，不需要叢集。」– 單張 H100 究竟能容納什麼？用於一般聊天與強大推理的 Qwen3‑32B：
• 「Qwen3‑32B 是一個擁有 32.8B 參數的稠密模型，支援最多 32k token 的上下文，因此實際的文件聊天、程式設計，甚至代理式使用案例都能運作得很好。」
• 效能：
• 「在單張 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 嗎？一張 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、代理式工作流程；每一種都能以一張 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 使用案例不需要這麼多資源！那麼，有更好的方法嗎？
• 團隊預設為開放原始碼 LLM 採用龐大的多 GPU 雲端組態，只為求保險。
• 這會帶來複雜的分散式推論、速度降低與高昂成本，而實際工作負載往往很輕。
• 實際上，大多數現代產品使用案例搭配單張強大 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 執行
• 非常適合代理式聊天機器人與 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 代理式工作流程
• 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、代理式工作流程，全都在一張 GPU 上
• 何時使用：開發、內部工具、早期產品及中等並行處理 自己動手試 + 參考架構
• 啟動 Amazon EC2 p5.4xlarge；使用 vLLM／TensorRT-LLM 部署
• 衡量自己的延遲、輸送量與成本節省