现在暂时没有完美的LLM小型设备。

我輩樹である

金秋十月，又到了动物们交配的季节。

随着黄发布GB10的NVIDIA DGX SPARK，LLM小型设备的角逐应该暂时告一段落了。


三个设备的参数（数据均为Gemini从网络收集整理，随缘校对）：

特性	Apple M4 Max 满配	NVIDIA DGX  Spark	AMD AI Max+ 395  满配
CPU 核心	16 (12P + 4E)	20 ARM (10 X925 + 10  A725)	16 Zen 5
GPU 核心/SMs/CUs	40 核心 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 N3E	TSMC 4N	TSMC 4N
统一内存大小	128GB	128GB	128GB（最大调度96GB）
FP16/BF16  TFLOPS (GPU)	~34	~100	~59
INT8 TOPS  (GPU)	~34	~200（按1:2比例换算）	~59
INT8/FP4 TOPS  (NPU/AI)	38 (INT8)	1000 (INT8) / 1  PetaFLOP (FP4稀疏)	50 (NPU) / 126 (整体)
关键精度支持	FP16, BF16, INT8,  MXFP4	FP16, INT8, FP8, FP6,  MXFP4，NVFP4	FP16,  INT8，MXFP4（不支持FP8）
内存类型	LPDDR5X-8533	LPDDR5X-9400	LPDDR5X-8000
峰值带宽 (GB/s)	546	301	256
总线宽度 (位)	1024	256	256
片上互联	是	否	否
网络	USBV2 80GB	10GbE，ConnectX7  SmartNIC 200GbE	USBV2 80GB，10GbE
生态	Core ML	TensorRT	MIGraphX

三种设备运行OpenAI G-P-T-O-S-S 120b（MoE架构，Top4，MXFP4时占用显存在60-70GB）推理任务收集而来的数据如下（数据均为Gemini从网络搜集整理，随缘校对）：

平台	软件栈	量化	上下文长度 (令牌)	预填充速度 (令牌/秒)	解码速度 (令牌/秒)
NVIDIA DGX  Spark	llama.cpp	MXFP4	2048	1689.47	52.87
NVIDIA DGX  Spark	llama.cpp	MXFP4	4096	1733.41	51.02
NVIDIA DGX  Spark	llama.cpp	MXFP4	8192	1705.93	48.46
NVIDIA DGX  Spark	llama.cpp	MXFP4	16384	1514.78	44.78
NVIDIA DGX  Spark	llama.cpp	MXFP4	32768	1221.23	38.76
Apple M4 Max	llama.cpp	MXFP4	2048	871.16	62.85
Apple M4 Max	llama.cpp	MXFP4	4096	643.32	56.48
Apple M4 Max	llama.cpp	MXFP4	8192	516.77	50.79
Apple M4 Max	llama.cpp	MXFP4	16384	351.42	46.2
Apple M4 Max	llama.cpp	MXFP4	32768	235.87	40.22
Apple M4 Max	MLX	MXFP4 转 Q8	~11000	350.95	32.86
Apple M4 Max	不明	~MXFP4	短	-	50 - 74
AMD AI Max+  395	Ollama	MXFP4	短	~3750	~30
AMD AI Max+  395	LM Studio	MXFP4 转 GGUF	短	-	31.41
AMD AI Max+  395	llama.cpp	MXFP4	短	526.15	43.14
AMD AI Max+  395	llama.cpp (Vulkan)	MXFP4 转 GGUF	短 (pp512)	402.01	49.4
AMD AI Max+  395	llama.cpp (ROCm)	MXFP4 转 GGUF	短 (pp512)	711.67	40.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下一代呢，据说位宽会提高一倍，但专用指令加速单元尚不明确。

如果有人推荐你买上面的设备来跑AI，他一定是你的好朋友。

xy.

大 MoE 完全是为了云端大规模设计的, 自己玩, 绝大部分钱都浪费在存这些参数上了, 这点无论硬件如何设计都是一样的

huaxiac4

自己部署个70b左右 有个m4max+64g足够用了

Miner

qwen next 说不定会发展出 235b-a9b 这样的……那 PC  插4根 DDR5 也能跑一下 4 位甚至 6 位量化了，性价比高很多

os39000

今天下载了 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还低了

constansino

本地llm有任何意义吗
构建自己的数据库rag有点用 别的呢

kingofgu

个人来说80B到120B这个区间 等效8bit到4bit量化
20T/s 吐字 然后首字时间别太离谱
价格能做到20000以内吧

jcd_chh

前两天看见个有个mac和两台Spark互联的，拆分充分利用内存带宽和算力
时间问题吧，现在算是起了个好头，后续应该会有更多设备的

本地LLM有意义啊，huggingface上面有解禁的模型，然后有些涉密的东西也不能忘在线的传，不是所有单位都自建平台，有这些需求的人还不少

zhuifeng88

唉怎么全在测非原生mxfp4的跑法，明明vllm-flashinfer后端前阵子main brach+几个approve的pr以及修好了原生mxfp4了...

l泰然处之01

跑 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，应该也可以在云服务器上部署吧？

jcd_chh

罗兰迦洛斯 发表于 2025-10-20 00:56
huggingface上的NSFW model，应该也可以在云服务器上部署吧？

这不放本地东西安全些

罗兰迦洛斯

jcd_chh 发表于 2025-10-20 01:00
这不放本地东西安全些

现在市面上还有出售这些API的，印度那边挺多，不过都不能涉及到名人/侵权类东西，不然违法，其他的高尺度的东西都没事儿，公开的。
不过....我是想做更大尺度的，可惜我的人脉找不到这类现成的API，只能是放到云服务器上自己搞了，但是完全不懂啊我X。