Ayahuasec

TP 的家用产品稳定性挺好，有一台 WDR4310 用了可能有六七年了到现在还很稳定。5 口的千兆交换机当时干到只有几十块的时候买了一台，到现在也五六年了没出过问题。
但是感觉 TP 企业级交换机有点不太行，用过一次 48 口的非管理型千兆交换机，当时部署完测试的时候各种丢包断流，最后一路排查到只插 1 台台式机和 1 台服务器，都会 ping 丢包和长达几十秒的断流，多次更换网口也是一样，而台式机和服务器直连是正常的。最后申请退掉这台交换机，换了个其他牌子的才把内网搞定。

刚格式化完的话，可能是 ext4 的 lazy init 导致的，以前有碰到过一次这个问题，导致几块硬盘一直不休眠。印象里是 mkfs.ext4 加一个啥参数可以立即把初始化数据写完的，而不是慢慢写。

@zzz22333 是的。但是至少虚拟系统是可以跑在带有硬件支持的 arm64 虚拟化环境下的，跑起来会比直接模拟整个 x86 虚拟机来得快一些。

可以试试装 arm 版的 linux 虚拟机，然后上 qemu-binfmt 跑 x86 的可执行程序？

之前这么干过一次，在 arm 板子上跑只提供 x86 二进制的程序，效果还行。这样搞的话系统还是 arm 的，只是用户态要走 x86 转译，效率比直接虚拟化整个 x86 系统会高一点。

@godqueue 现在软件兼容性上，AMD 和 Intel 没有太大区别吧。我感觉支持 AVX 然后内存带宽不差、内存容量够的话，CPU 跑起来 int4 的 14b 左右的模型，虽说不算快但是起码可用了。

虚拟机的话主要考虑 GPU 能不能直通进去，或者虚拟机内部要能调用到主机的 CUDA ，不然 GPU 加速跑不起来。

用 7840HS+RTX4050Laptop 的笔记本跑过 llama.cpp ，卸载了 20 层到 GPU 上，把 context 限制在 2048 的话，跑 q4km 量化的 14b 模型，日志文件里记录的一次速度如下：
llama_print_timings: prompt eval time = 1300.29 ms / 385 tokens ( 3.38 ms per token, 296.09 tokens per second)
llama_print_timings: eval time = 52142.44 ms / 331 runs ( 157.53 ms per token, 6.35 tokens per second)

有 GPU 加速的话 Prompt Eval 的速度会非常快，基本上发出几百个字的文本给模型以后，马上就能开始回复了。纯 CPU 计算的话 Prompt Eval 的速度只有 10 Tokens/s 左右，体现在应用上就是发了一段比较长的文本给模型要等很久才开始回复（ 500 字可能要等半分钟的样子）。

但是 RTX4050 的显存比较小，如果要开启比较大的 context 的话，就只能往显存上放更少的层，模型的输出速度就会慢下来。不过我感觉可用性还是挺好的，至少出门在动车上的时候连不上网就可以直接问本地模型了。

“研究生+要解决实际问题” 看到这两个条件，我感觉可以了解下 MatLab ？学校没买授权也不想掏钱买学生版的话，可以用开源的 Octave 平替。

MatLab 的文档很全，学过 Python 的话上手也应该很快，而且有问题也可以问 AI 。比如如果需要数据支撑或者论证观点的时候，就可以问 AI 需要什么数学工具或方法，然后用 MatLab 实现，以及可以输出合理的图可以放进论文里之类的。感觉可能对 op 的主业会比较有帮助。

我在用 N100 的小主机跑 q4km 量化的 14b 的 qwen ，机器装了根 32G 的内存，效果还可以，就是速度大概只有 2-3 tokens/s ，而且跑的时候风扇狂转