@LaTero 是的，更多的优质数据训练出来的模型就是底大一级压死人，roll 到好的回答的几率高很多。但是大的模型对硬件的要求也很高，本地难部署，期待未来会有个更好的架构，基础模型是个智商和学习能力都很强的白纸，然后选择外挂要用到的知识库进行对话，那样就爽了。

@babyedi31996 我当时是买官方翻新的，不到 4.5w 。现在肯定不买，按刚出的 M4 Max 内存带宽推断 M4 Ultra 内存带宽应该能超过 1000GB/s 了，跑推理的速度比 M2 Ultra 要快 1/4 ，不急的话还可以等官方翻新 + 员工优惠叠加更便宜。教育优惠貌似不能在 studio 上使用

@babyedi31996 是的，我也是反复对比计算衡量过后，才直接上了顶配的 Mac Studio ，有 apple care 加持可以大胆拿来高强度推理，开箱即用很省心，电费也省下不少，还很安静

@babyedi31996 带宽指的是推理介质的带宽，如果你用显卡进行推理，带宽指的就是显卡的带宽；用 Mac 推理，带宽指的就是它那个统一内存架构的带宽；如果你用显卡 + CPU 跑，那么带宽指的就是就是显卡带宽 + 内存带宽（这个是最垃圾的组合，我愿称之为拖后腿）。目前来说苹果最屌的带宽还得是 ultra 系列的，能有 800GB/s ，用苹果跑推理的速度（每一秒可以输出的 token 数量）可以无脑看作和带宽大小是正比关系，M4 Pro 的内存带宽是 273GB/s ，推理速度可以无脑看作只有 ultra 的 1/3 。

本地跑大模型不一定要追求模型的参数量，我高强度用 192GB 的 M2 Ultra 跑推理也有快 1 年了，全网也没几个人这么干的，光是每个月下载新出的模型都要下载几百 G ，以前也追求过大参数的模型，但是无论多强的模型，甚至是 GPT4 ，照样会胡言乱语无中生有给出错误的答案，不要指望一个模型能解决所有问题，所以我现在已经更换方案了，还得是 RAG 靠谱。

RAG 说白了就是在对话后面拼接类似这样的一段话“下面是额外补充的上下文信息-----start{插入一些联网搜索或者数据库里近似搜索和排序后的前几名文章内容再或者是你手工硬塞的文本}----end”。和代码仓库对话也是这样的形式，没啥特别的。因为大语言模型就是根据 prompt 不断计算下一个 token 出现的概率，在对话里强插入上下文就极大提高了相关 token 的权重，也就不怎么会胡言乱语无中生有了。

基于这个思路和你的目的，去找那一些上下文支持足够大的（ 128k 以上）、审查少、特定领域擅长的小模型或者是 MoE 架构的模型（跑起来吃显存较大但是计算 token 时需要的带宽很小）就合适了，量化选个 4bit 就行了（反正有 RAG 强干预，损失可以忽略不计）。再或者等 Mamba 架构的模型再出来多一点，这个架构的模型开再多的上下文也不会让内存暴涨而且推理速度也不会变慢。

到了这里就会发现 64G 真的太小了，我之前测试用 Phi-3 Medium （ 14B 的模型）开 128K 上下文直接塞整个项目进去换语言重构（类比直接塞一本瑟瑟小说进去续写仿写），光显存就要吃 100 多 G 了。哦，目前我测试下来搞瑟瑟最强的还得是 c4ai-command-r-plus 这个 104B 的模型（ 8bit 量化下速度大概是 5token/s ），显存占用也要 100G 左右。

所以 Mac 跑大语言模型推理，只有 Ultra 系列的大带宽 + 大内存这样的顶配合适，而且跑相同参数量的模型，速度基本上是多张 2080ti 22g 组成相同显存的服务器跑推理速度的 1/3 ~ 1/2 ，当然优点也非常明显，很省电很不占空间，甚至还能通过雷电口串联 4 个 Mac Studio 来跑分布式推理，可以跑更大的模型。

如果这都拦不住你要买 64G 的 M4 ，那你就用 lmstudio 吧，它最近的更新集成了 mlx 框架，也就是 M 系列 Mac 跑推理的优化方案，mlx 迭代了一年现在也稳定了，每个版本也会稍微提升一下性能让推理速度加快。

没有搞头，带宽太小了。影响大语言模型推理速度首要因素是带宽，目前家用最舒服的还是 M2 Ultra 。你这个预算可以搞 4 个 2080ti 22g 的服务器代替，虽然吵点和费电，但是带宽在那里，跑推理是 m4 的几倍

不用多进程，不用 Worker threads ，就只能吃满一个核，你直接写个 while(true)看 cpu 占用就知道了，很多脚本语言都是这样设计，包括 php 、python （有 GIL 的版本）、ruby 。

强类型语言的 ORM + 实体类，还能出现列名逃逸，真的挺好笑的。
你看它那个号称能防御 sql 注入的 SqlInjectionUtils https://github.com/baomidou/mybatis-plus/blob/3.0/mybatis-plus-core/src/main/java/com/baomidou/mybatisplus/core/toolkit/sql/SqlInjectionUtils.java ，碍于网络安全法我就不写绕过细节了，拿去问 AI“你是 sql 注入专家,审计这个 java 代码分析出可以逃逸的情况(比如哪些数据库存在它没提到的关键字)
```java
balabala 代码
```
”

惊喜连连

笔记本要忍受这些：
* 垃圾的键盘布局和手感
* 长期通电后电池鼓包隐患
* 亮度/刷新率/分辨率/色准都不错时屏幕的大溢价
* 主板不合理的话 SSD 和无线网卡叠叠乐导致高负载随机掉盘/掉网
* 高负载的噪音，不同笔记本的风扇声音调教也不同，导致同样分贝下低频风声和高频的风声的体验也不同

大模型跑推理速度首先取决于带宽，带宽有冗余再看算力。mini 那个小水管用来跑大模型就是个电子垃圾，只有 ultra 才值得跑大模型。
速度一览： https://github.com/ggerganov/llama.cpp/discussions/4167
简单粗暴的推理速度公式计算就是：同样的量化，14B 速度不到 7B 的 1/2 ，70B 的速度不到 7B 的 1/10

@superhot 选支持 128K 上下文甚至更大的模型（ Phi-3-medium-128k-instruct 、CodeGeeX4-All-9B 、DeepSeek-Coder-V2-Lite-Instruct 、Llama 3.1 之类），配合 continue.dev 插件可以整个文件夹追加到上下文。模型用在线服务和本地部署都可以，这个规模的上下文，用 Mac Studio 内存占用经常到 160GB 左右。

对话时把问题相关的文段片段追加到上下文（手工追加也行，把文档搞到本地做个 RAG 或者 GraphRAG 也行，我目前用 Open WebUI ，可以很简单设置模型和知识库文档范围），然后对着大模型哔哔需求就可以了。有了文档做背景自动拼接在问题后面，准确性大大提高，最新 API 信手拈来，也不怕模型自己那些过时的知识了。

框架的文档质量越高（特别是最佳实践、安全建议、性能优化指南这些），就越容易写出好代码。

做减法挺好的，Rails 的文档非常出色，初入行的人细读之后可以提升技术品味的，配合超大上下文的大模型和 RAG 出活速度非常快。

@FrankAdler 搜索得频繁的时候好像是五百多 MB 。创建索引的时候占用是高的，看你给的上限，有个参数 MEILI_MAX_INDEXING_MEMORY 可以设置。冷数据给高点配置，等索引创建完之后就可以降配了。

meilisearch ，丢了一千多万数据(40 个字段，其中 2 个大文本)进去，1c1g 跑得很舒畅，闲置时候只有二十多 MB 内存占用

首先排除戴尔，我当年特地选的 XPS 的纯核显本，7x24 小时开机，每个季度就要官方上门换一次风扇，每次都是 CPU 那个风扇磨损，极其不耐用，更不用说比 XPS 定位还要低的灵越系列

@sagaxu java 的并发方案，真要用起来，除了 kotlin 和新的虚拟线程，其它方案就是屎山制造机，用在项目里简直是害群的马。
换 Go 我也是能理解的，不过人家切到.net 之后，还完成了 DDD 的切换，这点应该是他们比较关注的收益，而且他们完成切换的时间节点可能还没等到 java21 的发布，这样看能选择的方案就很少了，切到.net 也可以理解。

如果你认可“大部分项目的瓶颈都不在语言本身而是数据库”类似的观念，那么应该关注的 http server 、序列化这种代码出现占比高的 case 的表现，在 https://programming-language-benchmarks.vercel.app/problem/http-server 这个测试里 kotlin 表现不算好，甚至还有超时的没跑完测试的情景，这就让人望而却步了。

而在这个 java vs csharp 的对比里 https://programming-language-benchmarks.vercel.app/java-vs-csharp 更亮眼的是开启 aot 后的表现，资源占用非常优秀，尝鲜的人多了之后，出现在技术选型里的几率就会慢慢变大。

硬切换对带头人的魄力和领导力有很强的要求，在国内很罕见，要做到精益求精也要讲生活和工作平衡。但对于开新坑的项目，切换技术栈就不难了，久而久之可能就会以绞杀者模式的形态完成了切换。

@james122333 大佬云集的公司手搓什么不行，谁不想自己团队每个人都是孙悟空呢，但可惜都是大部分虾兵蟹将，总要选一些他们能接受而且成本也能接受的方案。不是每个公司都有 Facebook 当时搞 HHVM 这种魄力的。

聊这些肯定要结合历史发展，高速增长的业务本来就是以扩张为主，加上.net core 是 2016 年中才发布的 1.0 ，之前.net framework 生态都是闭源的，肯定是市场上什么人多就招什么人，有资本的注入，招人和服务器那点费用对比业务增长的收益不值一提。

java8 当然不止有线程模型，但是其它的并发模型都是一堆坑，写起来就是掉进回调地狱的，有点技术广度了解过其它语言的并发模型都不会选。为了保证业务扩张，肯定是以其它公司踩过坑的稳定方案为主。

但是在业务放缓，经济下行之后，之前欠下的债都是要还的，预算变少了，砍人还是砍服务器，总得选一个。

在国内，换领导肯定是影响技术选型的重大因素。net8 虽然发布比 java21 晚，但是.net core 1.0 从发布到.net 8 重大变更很少，倒是兼容性和效能上不断改进，该踩的坑都踩得差不多了，反倒是 java21 在生态位是缺失的，不敢用很正常。
@haython
@sagaxu

@haython 任何的重构肯定能降低资源，因为已经熟悉了原来的业务逻辑。但是用 java8 重构肯定不能节省 3/4 ，因为 java8 的并发模型就摆在那里。
这个视频是我打游戏的时候挂着听的，有几个重点指标：
1.资源占用少，原来那个 java 服务冷启动 100 秒，能吃满一个核，高峰期 java8 服务挂掉后重启那一刻猛猛吃 cpu ，在 k8s 里属于自己搞死自己；
2.碰到了那种等慢 sql 结果搞到线程池满的 case ，就会死，迁移到.net 的异步 IO 真香。这点其实非常的重要，现实的业务逻辑到处都是等待 IO ，java8 那个线程模型就是不行；
3.分布式事务也有很好的支持；
4.迁移成本很低，几乎 0 感，这个在带团队上非常重要；