極點宏觀｜Financial Cloud Cloud · AWS Amarathon 2025
極點宏觀｜Amarathon 2025 回顧 26：在單張 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 部署
● 衡量自己的延遲、輸送量與成本節省