关于小公司跑本地大模型硬件建议
-
场景： 一家小公司，主要是来跑本地知识库，提供20-25人同时使用，另外还有自家网页的ChatBot 及一些网站上的OCR API调用（流量200-500左右）
-
硬件规划方案 A： 已经有台全新HPE ProLiant DL380 Gen11 闲置的伺服器，64GB ECC DDR5 记忆体，10TB SSD硬盘。 打算采购RTX PRO 6000 96GB 伺服器版本。
-
硬件规划方案 B： 自组一套Workstation及RTX PRO 5000 72GB伺服器版本。但不能利用现有的伺服器硬件，分配显存也需要用其他手段来实现。
-
硬件规划方案 C：APPLE MAC STUDIO M5 ULTRA 256GB 统一内存。也不能利用现有的伺服器硬件，而且苹果生态跑AI也比较麻烦些。
原本考虑方案A ，因为RTX PRO 6000 有MIG技术，可以分配显存去不同应用VM，例如CHATBOX，OCR，本地知识库。但因为RTX PRO 6000价格一直上飙，由之前的13万港币，到现在16-20万港币了。
而方案B需要另外配一台工作站，成本也要13-14万。
因为苹果发布M5 Ultra 处理器的Mac Studio, 请问各位大神， 如果不考虑Confy UI等应用场景，是否方案C，10万左右的Mac Studio比较适合我们的应用场景？@KAKAHermes 我投mac studio，我也是从3090、5090后来转向mac 平台，macos反而最简单，少很多对硬件兼容性、散热、稳定性、可维护的时间和人力成本。我在跑omlx我觉得很友好，稳定。年初从m5 max 128开机部署好omlx以后它就一直在角落跑，甚至不是高密度长时间运行都可以直接用显示器的typec线充电，噪音可忽略，耗能少，环境友好。虽然不知道将来是否需要继续扩充多台，但是目前看4台m3 ultra也能达到内存池扩展的效果，就像老特说的，32G5090跑comfy ui就不算瓶颈了，这样mac做llm server endpoint，mac mini、macbook pro跑agent，5090跑comfy ui，系统风险也有隔离，看起来也是一个完整的场景了。
-
-
@KAKAHermes 我投mac studio，我也是从3090、5090后来转向mac 平台，macos反而最简单，少很多对硬件兼容性、散热、稳定性、可维护的时间和人力成本。我在跑omlx我觉得很友好，稳定。年初从m5 max 128开机部署好omlx以后它就一直在角落跑，甚至不是高密度长时间运行都可以直接用显示器的typec线充电，噪音可忽略，耗能少，环境友好。虽然不知道将来是否需要继续扩充多台，但是目前看4台m3 ultra也能达到内存池扩展的效果，就像老特说的，32G5090跑comfy ui就不算瓶颈了，这样mac做llm server endpoint，mac mini、macbook pro跑agent，5090跑comfy ui，系统风险也有隔离，看起来也是一个完整的场景了。
-
@KAKAHermes 你的計劃沒錯，不推你N卡單純是你的不太合成本，HPE伺服器機箱空間應該是 4~8 卡看型號2U~4U分佈在四周，GPU Power Cable Kit 規格 A/M/I 新卡基本上一樣是12Pin 300~600w ，RTX PRO 6000 RTX PRO 5000 48/72GB 不推薦單純是 vgpu 分割後的CP值對你來說不高，15萬 RMB/HKD 都還是很極限的預算，可能滿足不了併發 session 需求，除非你都跑同一個模型給不同用途。
畢竟多一張卡就可以多開一個 session 速度還穩定(慢但可用)， N卡 優勢是你可以跑更大的 context 還有速度超快(但多併發會拖慢)，
所以才說你最好先做一下實驗確定需求這部分我過幾週有空可以測試一下 PRO6000 跑 qwen 3.8 VLLM 到能併發多少用戶，
然後模擬 PRO6000 VS A100 / R9700 / 3090 對外 coding / RAG 服務的表現
真的要買 PRO6000 的話就要快，價格每天都在漲.....但有機會的話還是雙卡 PRO6000 起步會比較好 -
@CS6 悲劇，早上跟供應商確認，RTX PRO 6000 已經漲到20萬港幣以上了，反而有另一個選擇，NVIDIA RTX PRO 6000D 84GB 閹割版本這張的價格還是沒有變動，但仍然是10萬左右。如果10萬左右價格有80% PRO 6000 的效能，是否對我們來說是個比較好的選擇？ 未來可以加多張來跑併發。
-
@CS6 悲劇，早上跟供應商確認，RTX PRO 6000 已經漲到20萬港幣以上了，反而有另一個選擇，NVIDIA RTX PRO 6000D 84GB 閹割版本這張的價格還是沒有變動，但仍然是10萬左右。如果10萬左右價格有80% PRO 6000 的效能，是否對我們來說是個比較好的選擇？ 未來可以加多張來跑併發。
@KAKAHermes 别相信这个6000D有 80% PRO 6000 的效能。实测就是一半多点（不然凭什么价格没涨起来）
-
@KAKAHermes 我投mac studio，我也是从3090、5090后来转向mac 平台，macos反而最简单，少很多对硬件兼容性、散热、稳定性、可维护的时间和人力成本。我在跑omlx我觉得很友好，稳定。年初从m5 max 128开机部署好omlx以后它就一直在角落跑，甚至不是高密度长时间运行都可以直接用显示器的typec线充电，噪音可忽略，耗能少，环境友好。虽然不知道将来是否需要继续扩充多台，但是目前看4台m3 ultra也能达到内存池扩展的效果，就像老特说的，32G5090跑comfy ui就不算瓶颈了，这样mac做llm server endpoint，mac mini、macbook pro跑agent，5090跑comfy ui，系统风险也有隔离，看起来也是一个完整的场景了。
@KAKAHermes 我投mac studio，我也是从3090、5090后来转向mac 平台，macos反而最简单，少很多对硬件兼容性、散热、稳定性、可维护的时间和人力成本。我在跑omlx我觉得很友好，稳定。年初从m5 max 128开机部署好omlx以后它就一直在角落跑，甚至不是高密度长时间运行都可以直接用显示器的typec线充电，噪音可忽略，耗能少，环境友好。虽然不知道将来是否需要继续扩充多台，但是目前看4台m3 ultra也能达到内存池扩展的效果，就像老特说的，32G5090跑comfy ui就不算瓶颈了，这样mac做llm server endpoint，mac mini、macbook pro跑agent，5090跑comfy ui，系统风险也有隔离，看起来也是一个完整的场景了。
mac 只能一个人玩，现在来看mac M5 ultra 显卡的计算能力也就将将够一个人长上下文（跑170G 左右的deepseek flash v4） 。
M3 ultra 长上下文都 跑不过双机 DGX spark 。白瞎了那么大的内存带宽 -
@KAKAHermes 我投mac studio，我也是从3090、5090后来转向mac 平台，macos反而最简单，少很多对硬件兼容性、散热、稳定性、可维护的时间和人力成本。我在跑omlx我觉得很友好，稳定。年初从m5 max 128开机部署好omlx以后它就一直在角落跑，甚至不是高密度长时间运行都可以直接用显示器的typec线充电，噪音可忽略，耗能少，环境友好。虽然不知道将来是否需要继续扩充多台，但是目前看4台m3 ultra也能达到内存池扩展的效果，就像老特说的，32G5090跑comfy ui就不算瓶颈了，这样mac做llm server endpoint，mac mini、macbook pro跑agent，5090跑comfy ui，系统风险也有隔离，看起来也是一个完整的场景了。
-
@KAKAHermes 這個價格，我勸你就別買了，除非你老闆真的人好錢多....
你先去確認一下到底電源跟空間能差多少張卡？
單純跑推理的話 B70 R9700 八卡就算一張以300瓦來算上電費還是省很多錢...
甚至你可以買到四台 GB10 ...@CS6 考量伺服器兼容問題及卡的價格，現在最實際的方案似乎是 GB10了。不浪費現有伺服器的情況下，又可以快速部署服務：
現有的伺服器可以增加內存去128或512GB, 之後部署API Gateway，作爲API Load Balancing，對接兩臺GB10, 物理分隔內部及外部需求。也可以保留未來擴充的可能性。（Node C）
對內尖峰同時發問支持5人， 希望Token數要有15-25 每秒才可以接收。看看各位大神對這個方案有什麼看法。
-
@CS6 考量伺服器兼容問題及卡的價格，現在最實際的方案似乎是 GB10了。不浪費現有伺服器的情況下，又可以快速部署服務：
現有的伺服器可以增加內存去128或512GB, 之後部署API Gateway，作爲API Load Balancing，對接兩臺GB10, 物理分隔內部及外部需求。也可以保留未來擴充的可能性。（Node C）
對內尖峰同時發問支持5人， 希望Token數要有15-25 每秒才可以接收。看看各位大神對這個方案有什麼看法。
@KAKAHermes 帶寬有點吃緊就是 不跑文字以外的應該還可以八
-
@CS6 考量伺服器兼容問題及卡的價格，現在最實際的方案似乎是 GB10了。不浪費現有伺服器的情況下，又可以快速部署服務：
現有的伺服器可以增加內存去128或512GB, 之後部署API Gateway，作爲API Load Balancing，對接兩臺GB10, 物理分隔內部及外部需求。也可以保留未來擴充的可能性。（Node C）
對內尖峰同時發問支持5人， 希望Token數要有15-25 每秒才可以接收。看看各位大神對這個方案有什麼看法。
-
看计划应该资金不是很充足。
建议用在线 api 先顶一阵。等硬件降价吧。
如有加密不能外漏的。用现有硬件克服一下。 -
@CS6 考量伺服器兼容問題及卡的價格，現在最實際的方案似乎是 GB10了。不浪費現有伺服器的情況下，又可以快速部署服務：
現有的伺服器可以增加內存去128或512GB, 之後部署API Gateway，作爲API Load Balancing，對接兩臺GB10, 物理分隔內部及外部需求。也可以保留未來擴充的可能性。（Node C）
對內尖峰同時發問支持5人， 希望Token數要有15-25 每秒才可以接收。看看各位大神對這個方案有什麼看法。
對內尖峰同時發問支持5人， 希望Token數要有15-25 每秒才可以接收。
這一台GB10應該是做不到的. 需要TP才行. 建議買四台GB10跟一台CRS504 100G switch, 跑TP4 deepseek v4 flash vision exp, 或是不要switch跑兩組TP2
兩者我都跑過, TP2 多concurrency tok/s 80+應該是沒有問題, TP4的數據沒有留, 應該是更快.
跑litellm應該是不用那麼多ram, 數據分流litellm內部就可以做到, 不管下面接的是一組, 兩組還是多組.
我現在litellm接了glm 5.3 (GB10 x 8), qwen 3.8 27B Q8 (v100 x 2), ornith-1.5 35B Q4(3060 12G + dram offload), deepseek v4 flash 0731 (GB10 x 2), qwen 3.8 flash next (GB10 x 1), 分別服務兩個網段. litellm也才用了一台i5-1135G7, 16G ram的小電腦而已. -
我推荐你去跟老板申请笔钱（2K差不多），然后去实际租一下试试看，测试一下各类硬件配置。 以免后面买了不合适，来回折腾，花点小钱探探路也是不错的。你自己能在这测试过程中积累到不错的经验。
-
@Bunsei 我有嘗試租借GB10 ，但很難模擬多人使用場景。
-
@Bunsei 我有嘗試租借GB10 ，但很難模擬多人使用場景。
@KAKAHermes 可以用llama-benchy 測試多concurrency
https://github.com/eugr/llama-benchy -
對內尖峰同時發問支持5人， 希望Token數要有15-25 每秒才可以接收。
這一台GB10應該是做不到的. 需要TP才行. 建議買四台GB10跟一台CRS504 100G switch, 跑TP4 deepseek v4 flash vision exp, 或是不要switch跑兩組TP2
兩者我都跑過, TP2 多concurrency tok/s 80+應該是沒有問題, TP4的數據沒有留, 應該是更快.
跑litellm應該是不用那麼多ram, 數據分流litellm內部就可以做到, 不管下面接的是一組, 兩組還是多組.
我現在litellm接了glm 5.3 (GB10 x 8), qwen 3.8 27B Q8 (v100 x 2), ornith-1.5 35B Q4(3060 12G + dram offload), deepseek v4 flash 0731 (GB10 x 2), qwen 3.8 flash next (GB10 x 1), 分別服務兩個網段. litellm也才用了一台i5-1135G7, 16G ram的小電腦而已.@soop-ladios 是的，我也是計劃先買兩台GB10來跑TP，加上本身的伺服器跑LiteLLM。
-
@KAKAHermes 可以用llama-benchy 測試多concurrency
https://github.com/eugr/llama-benchy -
@soop-ladios 多謝提醒，我測試一部試試，但不能租用兩部GB10 模擬TP吧。。。。
@KAKAHermes 我趁沒人用的空檔跑了一下給你參考:
DeepSeek V4 Flash Concurrency Benchmark
- 測試時間：2026-09-02
- 工具：
llama-benchy 0.3.8.dev2+gff162bcfc - 模型：
deepseek-v4-flash - 參數：
PP=2048、TG=128、每組 5 runs、--no-cache
測試結果
Concurrency Prefill total Prefill/request TG total（持續） TG/request TG 1 秒峰值 4 1835.1 ± 24.0 tok/s 648.3 ± 327.4 tok/s 56.27 ± 3.52 tok/s 18.92 ± 2.84 tok/s 100.6 ± 5.2 tok/s 5 1820.6 ± 69.4 tok/s 598.5 ± 393.3 tok/s 56.97 ± 3.09 tok/s 16.30 ± 2.54 tok/s 108.6 ± 5.1 tok/s Individual prefill 的 median：c4 為
487.2 tok/s/request，c5 為485.5 tok/s/request。這是vllm跑的TP2, 看起來是勉強到你的最低要求. 還是TP4比較有餘裕.
附註:- 為了增加更多可用ctx (目前是500K x 6), 我把max-num-batched-tokens設4096 , 再多會OOM. 如果把KV cache減少, 可以留多一點空間, 就可以把這個值調大, prefill會更快
- 這是KV緩存完全沒命中的測試. 實際prefill數值要視使用情況而定, 可能更快也可能更慢. GB10是統一記憶體, KV緩存到ram不會是一個方案. 若常有長上下文冷啟動需求, 可能要考慮nvme緩存, 這需要折騰.
