TSMC救不了Intel：酷睿Ultra 7 255H（Arrow Lake H45）测试
https://blog.hjc.im/tsmc-cant-save-intel-core-ultra-255h-arrow-lake-h-review.html
https://blog.hjc.im/tsmc-cant-save-intel-core-ultra-255h-arrow-lake-h-review.html
双路epyc现在能堆出1.1 TB/s的带宽，跑单请求LLM理论上吐字速度已经不逊于5090以下的任何显卡。Xeon那边理论上用MCR-8800内存能堆到1.7 TB/s而且AMX有更高的算力，但是现在这内存全网都找不到几条卖的，只有闲鱼卖ES。。
https://x.com/Hydrogen0E7/status/1888771102056603752
https://x.com/Hydrogen0E7/status/1888771102056603752
在我看来两者性质没有什么太本质的区别，diffusion model无法生成真正符合现实世界逻辑的图像，而LLM并不真正理解编程语言的语法，吐出的代码甚至没法保证过编译。
只不过无效的代码不会被人到处截图传播来恶心码农但AI图不一样，要是每天有不懂写码的人到处晒AI生成的过不了编译的代码也会很烦（逃
https://x.com/NankyuSeiichi/status/1889223578710888692
只不过无效的代码不会被人到处截图传播来恶心码农但AI图不一样，要是每天有不懂写码的人到处晒AI生成的过不了编译的代码也会很烦（逃
https://x.com/NankyuSeiichi/status/1889223578710888692
VLIW NPU拿来跑计算密集的prefill问题不大。前阵子私底下试过基于OGA的AMD XDNA+RDNA的混合LLM方案（NPU跑prefill，GPU跑decode） ，NPU可以在2.5W内实现llama 8B 350+ t/s的pp。
这个性能大致相当于16CU的RDNA 3.5火力全开跑llama.cpp的水平，如果软件支持跟上了能真正用起来的话还是相当不错的。
https://x.com/karminski3/status/1889566828919214152
这个性能大致相当于16CU的RDNA 3.5火力全开跑llama.cpp的水平，如果软件支持跟上了能真正用起来的话还是相当不错的。
https://x.com/karminski3/status/1889566828919214152
🙃唉还想着等Asahi Linux支持M4 Pro之后把现在这一大堆LLM server搬过去，现在有点堪忧了
https://www.phoronix.com/news/Hector-Martin-Resigns-Asahi
https://www.phoronix.com/news/Hector-Martin-Resigns-Asahi
David's random thoughts
主流游戏卡真的是一点都不能用，说是双槽卡但是上下都要恰好入侵到相邻插槽，实际上就是个4槽卡。
为什么不像之前那样继续用延长线呢，是因为上次尝试用Intel GPU在Linux下玩游戏又出现了神秘的整机reset问题……只能把延长线拿掉先排除一下影响。
于是只能暂时喜提损失两个PCIe槽的惨痛代价。
于是只能暂时喜提损失两个PCIe槽的惨痛代价。
David's random thoughts
为什么不像之前那样继续用延长线呢，是因为上次尝试用Intel GPU在Linux下玩游戏又出现了神秘的整机reset问题……只能把延长线拿掉先排除一下影响。 于是只能暂时喜提损失两个PCIe槽的惨痛代价。
基本确认是延长线的问题，直连PCIe 4.0x16槽之后玩了几个小时都再也没有出现任何故障（
终于不当CloseAI了吗😅
要是能把o3 mini开源出来还是不错的，但是这个“-level”又显得有点可疑了
https://x.com/sama/status/1891667332105109653
要是能把o3 mini开源出来还是不错的，但是这个“-level”又显得有点可疑了
https://x.com/sama/status/1891667332105109653
X (formerly Twitter)
Sam Altman (@sama) on X
for our next open source project, would it be more useful to do an o3-mini level model that is pretty small but still needs to run on GPUs, or the best phone-sized model we can do?
看了一圈首发评测，测70B LLM基本上都是在windows上用基于llama.cpp vulkan版本的方案在共享显存里跑出来的成绩，性能损失比较大。所以参考价值比较一般，Linux下把vLLM搭起来再上个投机解码之类的可以快不少。
不过这种平台跑LLM根本上还是跟我之前M4 Pro文章里讲的有差不多的问题，状况都比较尴尬。
https://x.com/kele_plus/status/1892081534443630771
不过这种平台跑LLM根本上还是跟我之前M4 Pro文章里讲的有差不多的问题，状况都比较尴尬。
https://x.com/kele_plus/status/1892081534443630771
看着50系首发这么多drama我本来都懒得说啥，不过最近感觉NVIDIA这个公司在我心目中的形象已经成功升级成独一份了。
集合了Google，华为以及挤牙膏时期的Intel的所有《优点》，最顶上那位PPT吹牛的能力比马斯克还强，还有一帮神奇的信徒。如此强大的公司怎么能不招人喜欢呢。
集合了Google，华为以及挤牙膏时期的Intel的所有《优点》，最顶上那位PPT吹牛的能力比马斯克还强，还有一帮神奇的信徒。如此强大的公司怎么能不招人喜欢呢。
David's random thoughts
看了一圈首发评测，测70B LLM基本上都是在windows上用基于llama.cpp vulkan版本的方案在共享显存里跑出来的成绩，性能损失比较大。所以参考价值比较一般，Linux下把vLLM搭起来再上个投机解码之类的可以快不少。 不过这种平台跑LLM根本上还是跟我之前M4 Pro文章里讲的有差不多的问题，状况都比较尴尬。 https://x.com/kele_plus/status/1892081534443630771
为什么说vLLM在Strix Halo上值得一试
拿近似架构的W7900来说，双卡使用llama.cpp row split运行70B-72B q8的LLM大约是13 t/s左右的性能。但vLLM+投机解码可以实现30-40 t/s，当然96G显存极其紧张。
70-72B目前在STXH平台使用llama.cpp q4上限大约在5-6 t/s，提升后可能刚好到> 10t/s的高度可用水平。
拿近似架构的W7900来说，双卡使用llama.cpp row split运行70B-72B q8的LLM大约是13 t/s左右的性能。但vLLM+投机解码可以实现30-40 t/s，当然96G显存极其紧张。
70-72B目前在STXH平台使用llama.cpp q4上限大约在5-6 t/s，提升后可能刚好到> 10t/s的高度可用水平。