现在暂时没有完美的LLM小型设备。
本帖最后由 我輩樹である 于 2025-10-22 11:10 编辑金秋十月，又到了动物们交配的季节。
随着黄发布GB10的NVIDIA DGX SPARK，LLM小型设备的角逐应该暂时告一段落了。
三个设备的参数（数据均为Gemini从网络收集整理，随缘校对）：
特性Apple M4 Max 满配NVIDIA DGXSparkAMD AI Max+ 395满配
CPU 核心16 (12P + 4E)20 ARM (10 X925 + 10A725)16 Zen 5
GPU 核心/SMs/CUs40 核心 GPU 5120 ALU（A17Pro）6144 CUDA Cores(Blackwell)40 计算单元 2560 ALU(RDNA 3.5)
NPU/AI加速器/矩阵指令加速器16 核 Neural Engine第五代 Tensor Cores专用 AI 引擎 (XDNA 2)
制程工艺TSMC N3ETSMC 4NTSMC 4N
统一内存大小128GB128GB128GB（最大调度96GB）
FP16/BF16TFLOPS (GPU)~34~100~59
INT8 TOPS(GPU)~34~200（按1:2比例换算）~59
INT8/FP4 TOPS(NPU/AI)38 (INT8)1000 (INT8) / 1PetaFLOP (FP4稀疏)50 (NPU) / 126 (整体)
关键精度支持FP16, BF16, INT8,MXFP4FP16, INT8, FP8, FP6,MXFP4，NVFP4FP16,INT8，MXFP4（不支持FP8）
内存类型LPDDR5X-8533LPDDR5X-9400LPDDR5X-8000
峰值带宽 (GB/s)546301256
总线宽度 (位)1024256256
片上互联是否否
网络USBV2 80GB10GbE，ConnectX7SmartNIC 200GbE USBV2 80GB，10GbE
生态Core MLTensorRTMIGraphX
三种设备运行OpenAI G-P-T-O-S-S 120b（MoE架构，Top4，MXFP4时占用显存在60-70GB）推理任务收集而来的数据如下（数据均为Gemini从网络搜集整理，随缘校对）：
平台软件栈量化上下文长度 (令牌)预填充速度 (令牌/秒)解码速度 (令牌/秒)
NVIDIA DGXSparkllama.cppMXFP420481689.4752.87
NVIDIA DGXSparkllama.cppMXFP440961733.4151.02
NVIDIA DGXSparkllama.cppMXFP481921705.9348.46
NVIDIA DGXSparkllama.cppMXFP4163841514.7844.78
NVIDIA DGXSparkllama.cppMXFP4327681221.2338.76
Apple M4 Maxllama.cppMXFP42048871.1662.85
Apple M4 Maxllama.cppMXFP44096643.3256.48
Apple M4 Maxllama.cppMXFP48192516.7750.79
Apple M4 Maxllama.cppMXFP416384351.4246.2
Apple M4 Maxllama.cppMXFP432768235.8740.22
Apple M4 MaxMLXMXFP4 转 Q8~11000350.9532.86
Apple M4 Max不明~MXFP4短-50 - 74
AMD AI Max+395OllamaMXFP4短~3750~30
AMD AI Max+395LM StudioMXFP4 转 GGUF短-31.41
AMD AI Max+395llama.cppMXFP4短526.1543.14
AMD AI Max+395llama.cpp (Vulkan)MXFP4 转 GGUF短 (pp512)402.0149.4
AMD AI Max+395llama.cpp (ROCm)MXFP4 转 GGUF短 (pp512)711.6740.25
AMD AI Max+395不明MXFP4短293~43
注：要看TTFT（首个token输出时间），仅需取 上下文长度 (令牌) 除以 预填充速度 (令牌/秒) 即可。
自问自答几个问题：
1，看GPU还是NPU？
本世代的NPU/AI处理器在设计时主要关注的是无感智能。
LLM的运行显然无法也没必要实现无感，不在设计范畴内。
虽然NPU确实可以运行极小规模的大模型，但现实意义不大。
除了Spark外（Spark基于tensor core），其他两台设备主要还是基于GPU。
2，运行更小的模型性能怎么样？
我觉得这是一个相对不需要讨论的问题。
可以看一下SPARK运行小规格LLM的结果：
3，运行更大的模型性能怎么样？
当前比较热门的，且在128GB可以运行的大模型有：Qwen3-235B-A22B（MoE架构，Top8，Q4下占用120-140GB显存，Q3在110GB左右）。
但它的尺寸处于边界状态，情况比较复杂。
至于dense或者更大的模型，个人感觉意义已经不大。
首先AMD因为保留内存太多出局。
苹果只能跑Q3，为了保证TTFT性能，还需要使用UD2.0技术：
https://www.bilibili.com/video/BV1gmEqzDEM3
里面最有希望畅跑的应该是Spark了，目前尚未由相关数据。
4，彼此的优缺点。
苹果和395一个显著问题是算力太弱。
M系列构架在M1时代就定型了，设计时并未预料到LLM这个场景的出现。
好消息是，苹果在M5这代在神经引擎以外额外安装了神经加速器。
这是一种矩阵加速器，类似于tensor core。
其加速比根据B站UP主在iPhone17上的测试，在2.5到4倍之间。
395和SPARK的问题是并未采用先进封装，所以带宽上尚赶不上苹果。（好处是，395可以赛博神医扩容）
另外395的问题和苹果类似，算力上并不亮眼，并且没有适用于LLM的低精度矩阵加速器。
SPARK虽然看起来也很拉，价格也比较昂贵。
但是看到后面的ConnectX7 SmartNIC 200GbE了么？
老黄从来没说只能买一台！
more you buy more you save。
5，为什么做不好LLM廉价设备。
当前世代的小型设备没法流畅玩耍LLM主要还是缘于构架设计上针对现实任务变化的始料不及（SPARK除外）。
我相信在不远的下一代应该都会做出一些修正。
那么在显存大小满足的前提下，在运行MoE架构的LLM推理任务的时候，业界有没有一个黄金公式，可以让算力和显存带宽刚好不构成瓶颈。
这样就可以用刚刚好的性能、相对便宜的价格构建一个LLM小型硬件，让大家都有的玩呢。
现实是很难了，因为prefill阶段和decode阶段分别是计算密集型和访存密集型。
这等于你要一块田又长又宽面积还要小。这无疑加大了芯片的设计难度。
目前流行的方案除了3D并行外（主要还是集群用）
是在计算密集型设备上进行prefill，然后将kv cache stream到访存密集型设备上进行decode（exo labs的方案）：
最后：
当前没有完美的设备。
Spark主要在于其价格，我相信4台互联应该是完全体，但价格来到12w+。
m4max和395的话，看看下一代吧，苹果是明确要加了。
Strix halo下一代呢，据说位宽会提高一倍，但专用指令加速单元尚不明确。
另外，除了硬件外，还可以寄望于软件层面的创新。
比如最近的光学压缩技术（deepseek ocr），极大的降低了计算量消耗。
视觉令牌与文本令牌的加速比为1:10。
但是现阶段，如果有人或厂家推荐你买上面的设备来跑AI，他一定是你的好朋友。 大 MoE 完全是为了云端大规模设计的, 自己玩, 绝大部分钱都浪费在存这些参数上了, 这点无论硬件如何设计都是一样的 自己部署个70b左右 有个m4max+64g足够用了 qwen next 说不定会发展出 235b-a9b 这样的……那 PC插4根 DDR5 也能跑一下 4 位甚至 6 位量化了，性价比高很多 本帖最后由 os39000 于 2025-10-19 21:44 编辑
今天下载了 generative-pretrained-transformer oss 120B, 模型大小65GB，在双路8581C+16通道768GB配置下20tokens /s。
更小的20B 跑出了 161tokens/s, 20B完全靠显卡3090Ti, 120B纯靠CPU。推理引擎是llama.cpp，看了tensorRT fastllm ik_llama都要部署linux，又感觉双系统麻烦。不装linux的话这套配置性价比就比spark还低了 本地llm有任何意义吗
构建自己的数据库rag有点用 别的呢 个人来说80B到120B这个区间 等效8bit到4bit量化
20T/s 吐字 然后首字时间别太离谱
价格能做到20000以内吧 前两天看见个有个mac和两台Spark互联的，拆分充分利用内存带宽和算力
时间问题吧，现在算是起了个好头，后续应该会有更多设备的
本地LLM有意义啊，huggingface上面有解禁的模型，然后有些涉密的东西也不能忘在线的传，不是所有单位都自建平台，有这些需求的人还不少[困惑] 唉怎么全在测非原生mxfp4的跑法，明明vllm-flashinfer后端前阵子main brach+几个approve的pr以及修好了原生mxfp4了... 本帖最后由 l泰然处之01 于 2025-10-20 00:47 编辑
跑 LLM 推理主要是显存大小、显存带宽、计算单元数量，
显存大小决定能不能跑模型以及多轮对话长度，显存带宽影响token生成速度，计算单元数量决定了并发性能，
对于 N 卡来说就是，VRAM > 显存位宽 > CUDA / Tensor。
Spark 作为 3w 的专用设备，内存位宽小，推理性能也就和用 Mac M 和 AMD AI Max 这类通用设备打一打，感觉给定位成 LLM 推理用的设备就很尴尬，看看 NV 给 Spark 做了多少开发工具或者专用平台，可能主打做微调才是正确用途。 jcd_chh 发表于 2025-10-19 23:43
前两天看见个有个mac和两台Spark互联的，拆分充分利用内存带宽和算力
时间问题吧，现在算是起了个好头，后 ...
huggingface上的NSFW model，应该也可以在云服务器上部署吧？ 罗兰迦洛斯 发表于 2025-10-20 00:56
huggingface上的NSFW model，应该也可以在云服务器上部署吧？
这不放本地东西安全些[偷笑] jcd_chh 发表于 2025-10-20 01:00
这不放本地东西安全些
现在市面上还有出售这些API的，印度那边挺多，不过都不能涉及到名人/侵权类东西，不然违法，其他的高尺度的东西都没事儿，公开的。
不过....我是想做更大尺度的，可惜我的人脉找不到这类现成的API，只能是放到云服务器上自己搞了，但是完全不懂啊我X。
qwen3 next 80ba3b是我用过最好的，q8，设备是m3 max128g，输出速度40-50token/s
M5 Max看看内存带宽和GPU规格能堆到多少，现在mac上跑大模型差的就是prefill和并发，这代加入了tensor core，prefill速度应该提升不小，个人用的话并发速度不需要太在意。256G内存版本可以正
跑GLM 4.6 UD Q4的量化，个人开发用就很舒服了 期待M5Max上市 港城钢铁侠 发表于 2025-10-22 08:49
M5 Max看看内存带宽和GPU规格能堆到多少，现在mac上跑大模型差的就是prefill和并发，这代加入了tensor core ...
m5只是小改款，内存频率提升到9600，应该不会提升多少，10-20%吧。 我輩樹である 发表于 2025-10-22 11:14
m5只是小改款，内存频率提升到9600，应该不会提升多少，10-20%吧。
看m5普通版对比m4普通版跑大模型prefill提升了百分之30以上，m5 max不知道会不会gpu堆的规模更大，提升也更大 港城钢铁侠 发表于 2025-10-22 11:17
看m5普通版对比m4普通版跑大模型prefill提升了百分之30以上，m5 max不知道会不会gpu堆的规模更大，提升也 ...
m4普通版内存频率本来就低所以提升大， 有33%，但m4max的内存本来就是超过频的。
除非苹果还能继续超到10000以上。
不过内存带宽对苹果不是什么重要的问题。 我輩樹である 发表于 2025-10-22 11:20
m4普通版内存频率本来就低所以提升大， 有33%，但m4max的内存本来就是超过频的。
除非苹果还能继续超到1 ...
内存带宽对prefill影响不大的，甚至可以说基本上没啥影响，decode吃带宽 港城钢铁侠 发表于 2025-10-22 11:30
内存带宽对prefill影响不大的，甚至可以说基本上没啥影响，decode吃带宽
苹果设备的瓶颈在计算性能。 我輩樹である 发表于 2025-10-22 11:32
苹果设备的瓶颈在计算性能。
是的，这代加入了苹果自己搞得tensor core，希望能把算力拉上去 为什么内存不用GDDR7，LPDDR5X喂不饱吧 本帖最后由 用户 于 2025-10-22 13:16 编辑
granite rapids如果带hbm就完爆一票了。我搞了个spr-hbm，每颗64gb hbm，snc4读带宽跑满每颗可能是600G/s，两颗128gb跑很多模型都够用了。这玩意不需要插内存，理论上主板不用那么大。就是ollama支持多卡但不支持cpu numa，软件得自己从头写。
页:
[1]