redock

@Xudong07452910 should I buy a M5 Max 128G 4T MacBook Pro? asking for a friend.

一个 295B 参数的旗舰大模型，现在单张 96GB 推理显卡就能跑，而且解码速度还提升了 50%。 腾讯混元团队为 Hy3（295B 参数）推出量化版本。1bit 版本（IQ1_M）把权重从 598GB 压缩到 85.5GB，缩小 6.7 倍，单张 96GB 推理显卡即可部署；4bit 版本（Q4_K_M）体积 169.9GB，两张显卡可承载，性能接近满血模型。配合 MTP 投机解码，1bit 版本解码速度提升约 50%，4bit 版本提升近 60%。 这件事的意义不只是「更便宜了」。之前 295B 参数级别的模型，推理动辄需要多机多卡，只有大型云厂商和顶级实验室能负担。现在单张 96GB 显卡就能跑，意味着更多中小机构和独立研究者可以在本地接触这个能力层级，这样不用通过 API 租用，可以直接持有和控制模型权重。 Agent、多语言代码、工具调用、长文理解等任务上，量化版表现接近满血。全部版本已开源，GGUF 格式，兼容 llama.cpp 生态。 大模型量化的核心趋势不再是「性能损耗可以接受」，而变成了「性能损耗本身越来越小」，当 1bit 版本还能保留接近满血能力，量化不再是妥协，而是另一种部署策略。 现在同等能力下是否可以实现最小的部署门槛已经变成了接下来大模型落地最重要的竞争维度。 Hy3 模型：huggingface.co/tencent/Hy3 低比特GGUF模型：huggingface.co/AngelSlim/Hy3-… GPTQ Int4 模型：huggingface.co/AngelSlim/Hy3-…

@mengyan1234567 缺乏一个防沉迷机制

两个月过去了， 他的心里还是会忍不住默念一声： “ C H I N A ”

@tyr0new 本地跑的意义在哪，token 费很多年都挣不回来

来自 ChatGPT 5.6 Sold 的采购建议 理性最优：M5 Pro 48GB + 2TB，¥30,499。 它已经覆盖你的 iOS 开发、AI Coding、工作流开发和 30B 级本地模型。 能力边界最优：M5 Pro 64GB + 2TB，¥33,499。 它最有价值的地方只有一个：让 70B 四位模型和更复杂的多任务本地 AI 环境从“勉强运行”进入“可以使用”

@jun_song should I buy a M5 Max 128G 4T MacBook Pro? asking for a friend.

Yes. If you don’t understand why people are jumping into Local AI, you are not smart.

@ZeroZ_JQ data store skill，auth skill 和 deployment skill

产品说：我已经拿 Ai 做了一套报告系统了，领导们很满意，但是要稍微改下，我大头都做完了，剩下的你帮我弄一下？ 我一看，剩下了用户认证体系对接，数据原来是本地改成数据库，原来是 html 直接部署，现在要放到服务器。 你管这叫大头做完了？？

@wey_gu 有没有哪些 benchmark 对比一下量化之后性能的损失？

腾讯的混元 3 是 deepseek v4 flash sized 模型 关注一下 这个模型量化之后其实是 128GiB MacBook 可跑的了

@mranti opencode 的套餐呢

今天上午很快就用爆了Ollama Pro 的GLM5.2 5小时额度，所以我开始尝试买讯飞199元套餐，因为额度是Ollama Pro的6倍。但一用起来就不停的服务忙报错，虽然有自动重试，但有时也会重试10次都失败，需要键入“继续”。看来最现实的方法是买第二份Ollama Pro了。Ollama的性能实在好。

@andy88988696 将帅困在九宫格，安全感来自不移动。士象是亲信，因为无能才被信任。车马炮有战斗力，但被视为威胁。卒只能前进，没有退路。

突然发现一件事情 西洋棋与中国象棋最大的差别在于 西洋棋里 职务越高的棋子能力越大 中国象棋里 官阶越高的越接近废物 不得不说 老祖宗的智慧还是不容置疑的

@tcdwww skills 还有渐进式披露

笑不出来，因为我真的有过这种想法。 在 skills 刚被提出的时候，我还想，这玩意不就是我本地一直保存的「罐头话」吗？我需要叫 LLM 走某些固定流程的时候直接去引用我的文档就好。 但是我忽略了 skills 共享方式标准化这一大优势，更别说它可以自带脚本了……

@CatChen 买钠石灰

睡觉时卧室 CO2 浓度是一个我长年没解决的问题，有时候一个人睡一觉都能超过 1000ppm。如果大家有什么有效降低 CO2 的办法，请告诉我。

@cloudwu @passluo 这个也有道理，目前 claude code / codex / copilot-cli 好像就这么干的。但二十年前的手机端肯定不能这样。如果今天从 0 开发一个微信，或许可以这样做。

@redockzz @passluo 为什么要画蛇添足恢复到数据库。聊天信息和记录，最简单就是一个对话打开就全部加载到内存，哪怕一百万字你也感知不到时间。再长？加载最新的 10 万字够用吗？

还是搞不懂为啥你们的微信能聊出几百 G

@cloudwu @passluo 算法能写出来，但工程不一定就该这么做。1. 聊天记录不仅是文本，是包含类型，状态等元数据的结构化数据。2. 数据的增删改查，sqlite 已经给出最优解。在加密文本上强行手搓约等于重新发明。3. 移动端首重稳定性+性能敏感， append-only 在服务端OK，不一定能硬套移动客户端。求同存异，感谢交流～

@redockzz @passluo 微信没这么做只是因为大多数开发人员的思维和你其实差不多，大厂并不会不同。别说加密消息, zipgrep 都可以在 zip 文件中 grep 。这是个算法问题，不是真叫你用 shell 命令写个微信出来。

@cloudwu @passluo 就算更高效一点，不拉滚动条，vi 打开直接/搜索，这个过程中也是 O(n) 复杂度。为啥不用数据库自带的 log(n)呢

@redockzz @passluo 你打开文本编辑器是拉滚动条，还是一条条看，直到看到那个日期的

@cloudwu @passluo 你说的对，但拿日志恢复 ACID 不就是数据库的老本行嘛

@redockzz @passluo 你用的任何输出文本 log 的软件，见过因为断电把文件写坏导致 log 文件不可用的吗？文本文件才是最抗操，最不怕断电请后台的。

@cloudwu @passluo 你看看 tail 用起来方便，#L1941" target="_blank" rel="nofollow noopener">github.com/coreutils/core… 但是里面很吃 I/O 和 CPU。而且我刚想起来，微信为了安全，还加密了消息，这种情况文本文件怎么搜索。

@redockzz @passluo 知道 iphone 用的 ssd 每秒可以传输多少数据吗？一个 100M 的文件，找到最后 20 行文本数据需要暴力匹配吗？你在命令行上用过 tail -n 吗？

@cloudwu @passluo 没有，但是我效率低啊。要想效率高，肯定得重新发明 sqlite。

@redockzz @passluo 你去查看一个 100M 的文本 log 文件，让你找到某年某日某时间点的文本，你维护了一份字节偏移量索引吗？你在找 log 的时候，重新发明了 sqlite 吗？

@cloudwu @passluo 云风大神是服务端架构师，但是移动设备的客户端的生存环境要差很多（尤其是 20 年前），多种多样，且随时可能断电或者被清后台。如果出了脏数据也没人帮客户修。所以用文本文件+grep 不如用现成的 sqlite。虽然讨厌微信吃容量，但不认为有比 sqlite 更好的方案。

@cloudwu @passluo 10万字也就几百 K，内存肯定不怕的。但 I/O 和 CPU是瓶颈，在变长文件里“从后往前找最近 20 条”，只能暴力匹配。tail 20 可没那么高效。

@cloudwu @passluo 还有语音，群聊。而且消息是否发送成功、发送中、撤回，这些需要状态管理。可能还要配合监管，以及数字取证。写文档文件，如果多个一起写 或者写失败了怎么办？还有就是聊天记录非常大的时候，怎么分页加载？怎么按日期搜索？

@cloudwu @passluo 微信有好多文本以外的功能，比如说表情，投骰子，接龙，转发，和消息引用。