q3 装个 vlc ，拉一个超大窗口躺着看电影也蛮爽的

大致流程就是：
fallocate 一个 img 文件，然后挂载到系统上；
建一个 fat 分区和一个 ext4 分区，开头留够空间放 uboot ；
启动脚本 boot.scr 、脚本的环境变量 uEnv.txt 、内核 uImage 丢进 fat 分区，有的还有个 initrd.gz 放起机的根文件系统；
系统根分区（ Debian 或者别的）放进 ext4 分区。Debian 可以用的 bootstrap 做；
最后 umount 一下，你就得到可以刷 sd 卡的 img 文件了。

qwen-vl 系列的论文里一直有让 vlm 操作手机的 demo 展示，阿里应该一开始就有瞄着上移动操作系统的方向做布局

好事，安卓上能搞更多骚操作了

但是看着这个 linux development environment 的隔离和虚拟机也差不多了，termux 这种轻量而且 api 丰富的方案估计没那么快 g

手头在用 2080ti 22g 跑，32b q4_k_s 性能大概是 prompt_token/s: 475.37, response_token/s: 23.82
qwen2.5-coder-32b 的输出感觉和 qwen2.5-32b 差不太多，之前耍 qwen2.5 已经觉得有很高的可用性了

有损压缩后的知识库

之前用过一段时间 poco f4 ，其实就是港版的红米 k40s ，用的 MIUI14 国际版。可以装国内的应用商店，把国行应用商店的 apk 提取出来装上就行，银行 app 基本都没问题。

不过这些银行 app 其实找个比如酷安这样的三方商店也能找得到，更新的时候签名验证能过就行。

用 OpenWebui 跑的 qwen2.5 14b ，启用计算器工具，看起来就能算对了:

根据提供的上下文，这些数字相加的和是 64 。所以答案是 64 。

要让语言模型做准确的计算，还是得给一个计算器让它按

openwrt 那个，之前整过一个野路子：主机上把路由器固件的根分区解包出来，然后用 chroot 和 qemu-static 直接进入这个根分区，opkg 装 gcc ，源码放进去，编译需要的软件。最后把编译产物拷贝到路由器上，一般直接就能跑。

这个操作的优点是不用折腾交叉编译环境，有的时候折腾交叉编译环境都要搞一天，或者有些固件不太好找配套的编译环境。

缺点就是主机模拟其他架构的程序，跑编译很慢，只适合偶尔用。

推荐一个这个

https://apps.apple.com/us/app/ti-nspire-cas/id545351700

以前高中开始一直用到本科毕业，就是价格有点小贵

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 的主业会比较有帮助。