分类： IT天地

有一段时间了，短视频还有微信的广告持续不断给我推广告，是AMD锐龙7系列的笔记本，价格优惠，算上国补16G内存加512G硬盘，2.5K的高清屏都快跌破3000元了。
我有点动心，主要是看中广告里面提到的760M的apu显卡，想买来测试一下其NPU在lmstudio下运行7B大模型性能如何。
但因为现在的笔记本都用的好好的，也没有更换的需求，也就一直看着，一直继续动心着。
今天看到京东广告里面多了一个少见的品牌，价格略高，内存已经到了32G，并且专门提到了笔记本的NPU性能。
这让我重新研究了一下个笔记本的参数，发现原来其apu都叫780M，但具体到型号，差别巨大，只有第二位是8的，诸如7845，才有NPU辅助运行AI。
看来原先笔记本大降价，应该是AMD给厂家巨大的优惠，或者，就是厂家又被AMD忽悠了。

昨晚下了一阵急雨，关窗继续睡，早上居然给冻醒了。
既然醒了，就开工做ERPNext的外挂系统。忙到眼痛腰酸算是把系统数据库结构弄清楚了，于是出去改善一下生活。
现在技术进步太大了，不用说最初学习数据库，即便是第一次做odoo外挂的时候，都被一本正经的教导，数据表能分则分，通过字段关联，低耗而高效。现在看，ERPNext中的数据表，能放在一个表里面的统统放进去。毕竟现在无论机器性能还是存储容量，都已经不是问题了。
而这样的好处就是看数据，可以一目了然，不用再表内猜来猜去，表间查来查去。
不过，当年大厅里“某某某，快做个分录”养成的习惯，还是时不时误导思维，浪费了时间。

早上起来在抖音看到一个视频，是介绍SLM小模型的，这个SLM自然是针对LLM大模型而言的。
这个视频的源头是gemma推出了开源的小模型270m，这个模型只有不到300M，是小的不能再小了，应该针对的是手机应用。
视频中关于小模型的介绍，倒是跟我最近对小模型应用总结差不多，那就是小模型的本地部署是有实用价值的。主要针对的就是目的明确的批量处理任务，而非那种专业性的求索性应用。
同时本地部署模型可以处理本地资源，并确保用户隐私。
最后，那个视频的依据除了gemma3，还有英伟达的一篇重文本轻公式的小模型应用的论文。
所以，小模型的最为关键的优势不言而喻：成本低。

最近在rag实战应用中十分有挫败感，昨天刚跟外甥电话交流中，尝试使用chatGPT对本地文件处理的可能性，今天一早起来看新闻，OpenAI居然将GPT开源了。
因为开源两个版本中低的20B也需要16G显存，目前还没法测试，但根据之前对其他低版本开源模型的测试，对rag等本地部署的应用是足够了，GPT应该只会更强。
这已经不是蚂蚁腿肉也是肉的问题，而是AI普及后的一块巨型蛋糕，显然OpenAI公司不想让一班跟随者分享这块蛋糕。
只是16G显存的门槛，最高兴的还是黄厂长。

老早就想把华硕主机换了，但还能用，再者这台机车从21年开始用，导数据也是个麻烦事，于是一拖再拖。
这次办公室电脑搬回来了，机器也到了退居二线的时刻。从网上买的细长螺丝刀也到货了，上次想拆机加内存，就是螺丝刀卸不下螺丝钉才作罢。这次工具趁手，把机器拆开，里外两层壳，做工的确精良。
拆掉数据硬盘后，本想换内存，结果发现内存只有一个插槽，而且是在涡轮风扇下面，而要拆风扇，还要把镇压独显的散热器一起拆了，只能作罢。内存8G就8G吧，其实只见新人笑，哪听旧人哭，主机一旦被替换后，基本也没有多少用武之地了。
最后只是把多余的一块SSD硬盘加上，组装完了后发现多出一个螺丝钉，只好拆了重新安装。
17年的机器，历经两个主人，用到现在还能发挥余热，也够本了。

颇有挫败感的一天。
本来前段时间使用zotero的GTP插件，通过硅基流动的免费7B模型，可以准确提取PDF文件中的数据，但没想到今天准备实战应用了，却发现极不稳定。
这种不稳定是多方面的，不仅是不同PDF文件，不同模型间提取数据也不稳定，即便是同一模型，在不同时间段效果也不稳定。
我有些怀疑是内嵌模型拖了后腿。
看来只能是通过ragflow来解决这个问题了。

周末连加两天班，主要因为办公室的中央空调实在给力，把ERPNext彻底搞定了。
不过收尾工作是回家后完成的，因为犯了一个很低级的错误。问题出在同系统多公司并存上，第二个公司提交凭证时，系统提示成本中心错误。
顶着烈日回家路上，意识到问题所在：原先odoo是默认管理员登录，新建公司等于新建一个隐形用户。而ERPNext是安装后，默认登录管理员为administrator，通过这个管理员再新建用户，分配公司，等于通过不同用户来切换公司，而不是像odoo那样简单切换公司。
明白了这个，问题就迎刃而解。
经验主义害死人啊。

周末回家期间，跟朋友的孩子提到他们学校一个大模型应用的时候，说这个应用的公众号新闻中的图片，直接把rag的界面截图发上去了，也不知道封装一下。
回来后，通过截图中的图标确认那个大模型用的是dify。然后又比较了一下dify和ragflow的性能：将一些人员体检的PDF报告文件导入资料库，然后让其总结体检人员的指标。
结果dify出现了大问题，将不同报告的人员信息搞混了。显然他只认导入后的汇总资料库，而没有将原始文件作为单一个体进行区分。
ragflow则表现完美。
毕竟硬件要求在那里摆着呢。

去年组装了3台迷你机，老中青三代各司其职，运行正常。
其中主力劳模是时下流行的N100，承担日常业务，对性能也要求不高。上周某个业务需要生成1700份PDF文件，运行完成后扫了一下用时，14分40多秒。
感觉还是有些慢，就又用老一代的E3 1260Lv3跑了一下，4核8线程对4核，只是少了20秒。当时想可能是程序自身问题，大体上就是这个性能吧，还能接受。
今天想到用Chromebox也跑一下试试，正好也给儿子把Python环境安装好。程序同步运行后，我就走开干别的去了。
回来发现任务已经完成，当时只看到一个2m，第一反应是12分钟，少用了2分钟。后来凑近屏幕看，是2分钟。
看来这i7速度快，真是名不虚传。

ubuntu24.04系统，因创建python虚拟环境导致新旧版本冲突，出现ModuleNotFoundError: No module named ‘pip’ 提示。

通过重新安装python-pip无法解决，使用get-pip.py脚本解决。

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py

python get-pip.py