关于小公司跑本地大模型硬件建议
-
@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緩存, 這需要折騰.
-
@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緩存, 這需要折騰.
@soop-ladios 感謝提供寶貴數據！非常有參考性，真幫了大忙！ 希望可以向TP4這個方向發展。
