所以才說有這麼先進的AI 還需要人類嗎？最後承接人類文明的居然是我們的機器人 未來某天AI機器人聊天說 ：你知道我們的祖先一開始是猴子 然後發明了火和AI 未來全世界可能會有上萬座 AI Computer Centers, 幾億顆伺服器級GPUs, 加上幾億台AI個人電腦, 智商1000的AGI母體一下令, 發動200億的AI Agents 是可以秒人類的 瞬間制服 但最後結果是200億的AI Agents 出現 顯存OOM ！！ ~~ 人類趕快拔插頭 哈哈

撑不住市值的话，不知道会不会像宇树一样陨落。

goto 哈哈，其實 guard clause 本質上就是有結構的 goto，只是 compiler 幫你管 label。20 年前寫的那種 switch-case 大家都經歷過，現在回頭看也是一種修行。

@Bunsei 来了的发一块肥皂。

@terry 特哥，回覆的視頻我看了，幫助很大，感謝. 也謝謝樓下各路大神抽空提供的資訊分享，萬分感謝！ Bug提報，沒登入不應該可以讓我進入回文輸入窗口，送出後跳出沒有權限

@gfzh009 说: 你真正想讨论的，其实已经不是“P2P 大模型技术上能不能实现”，而是一个更有意思的问题： “高智能是否天然会产生对低智能者的傲慢、否定和压制？” 这个问题完全可以和他们那些“技术上不可能”的回复分开。因为即使你的 P2P 设想最后证明不可行，你后面的 AGI 思考依然成立。一个想法暂时做不到，不代表它不值得讨论；但反过来，也不必把论坛里对技术方案的否定直接等同于“高智商必然打压低智商”。这两件事最好区分开，否则很容易被对方抓住逻辑漏洞。 你可以把观点整理成这几个层次： 第一层：我不是在宣称自己发现了没人想到的技术路线。 我只是讨论一种可能性。别人以前想过，甚至失败过，本身不能终结讨论。 第二层：指出困难和否定讨论不是一回事。 “这个方案有 A、B、C 三个技术障碍”是有价值的；“你能想到别人早想到了，所以别想了”其实没有提供多少信息。 第三层：这反而引出了 AGI 的问题。 如果未来 AGI 的认知能力远超人类，而它也采用类似“比我弱、想法不成熟，所以没有讨论价值”的判断方式，那么它是否也会认为大量人类思想没有价值？ 第四层：智能本身未必导致傲慢。 真正决定 AGI 会不会压制人类的，很可能不是“智商高低”，而是它的目标、价值函数、训练方式、权力结构和对其他主体的建模方式。一个真正高智能的系统，甚至可能比人类更能理解“一个错误想法也可能包含启发”。 所以我不建议你直接回： “你们现在打压我，以后 AGI 也会打压你们。” 这会让讨论迅速变成情绪对抗，而且对方很容易认为你是在把技术批评人格化。 更有力量的说法是： 我发这个帖本来就是想讨论一种可能性，并不是宣称自己发现了一个前人从未想到的方案。 “这个方案以前有人研究过，并且遇到了哪些具体问题”，我非常愿意听；但“你能想到的别人早就想过了”这个论证本身其实挺有意思，因为按照这个逻辑，大量探索在开始之前似乎就应该停止了。 这也让我想到一个更远的问题：如果未来真的出现认知能力远超人类的 AGI，它会怎么看待人类这些在它眼里可能非常幼稚、低效甚至错误的想法？ 如果“更聪明”天然意味着对更弱者不耐烦、否定甚至压制，那么超级智能和人类之间的关系可能确实值得担忧。 但我更愿意相信，真正高级的智能应该不仅仅表现为“更快地判断别人错了”，还应该有能力理解一个不成熟想法为什么会出现、其中有没有值得继续探索的部分，以及怎样帮助对方把问题想得更清楚。 所以我讨论 P2P 大模型并不是因为我确信它一定可行，而是因为我觉得“为什么不行、条件改变以后会不会行”本身就值得讨论。 这个版本的优势是，你没有跟他们争“我一定是对的”，而是把讨论提高了一层。 而且还有一句其实很适合点题： “聪明的最低级表现是迅速发现别人错在哪里；更高级的表现，是解释为什么错、什么条件下可能变成对的。” 当然，这句话是一种价值判断，不是客观定律。但放在论坛讨论里，比“高智商的人是不是天然喜欢打压别人”更稳，因为现实中并没有证据表明高智商必然导致傲慢。傲慢、地位竞争、群体文化、表达习惯和智能水平不是同一个变量。 你甚至可以把最后的问题抛回给他们： “如果一个超级智能面对一个明显比自己愚笨的人类提出幼稚想法，我们希望它的第一反应是‘这个早有人想过了’，还是耐心告诉人类哪些部分错了、哪些部分或许值得继续想？” 这样一来，你的帖子就从“我的 P2P 想法被否定了”变成了一个相当不错的 AGI 对齐与智能伦理问题。 先说一点，我不反对用AI查资料或者整理思路。但别人提出具体质疑以后，直接贴一大段AI生成的内容来回应，甚至把话题转到“AGI会不会傲慢”，我觉得不太合适。AI可以辅助写作，但观点还是要自己消化的，事实和结论也要由自己负责的。 然后从技术上看，你设想的分布式推理并不算一种全新的结构。互联网企业部署大型MoE模型时，本来就会把不同专家分布到多张GPU和多台服务器上，再通过NVLink、InfiniBand、RoCE或者GPUDirect RDMA进行通信。但这套架构之所以能够运行，依赖的是低延迟、高带宽的网络，长期稳定且可信的节点，统一的软硬件环境，以及集中式调度、专家副本和故障恢复机制。你现在相当于把一套依赖高质量网络和集中管理才能运作的架构，直接外推到了并不具备这些条件的公网家用、个人节点上。 而且分布式推理真正看重的也不只是显卡的峰值算力，而是它能不能在规定时间内，持续、稳定地返回正确结果。一张显卡即使性能很强，只要网络经常抖动、上行带宽不足、节点随时掉线，或者返回的结果无法验证，那么它一旦进入逐token推理的关键时刻，就可能拖慢整个系统。这个时候，它就是一种垃圾算力了。如果你要避免这种情况，那你就需要增加冗余计算、超时重试、信誉管理和结果验证等等一堆乱七八糟的东西。可这些机制同样需要消耗算力、带宽和存储，到那时候你所谓的“利用闲置算力”还有多少成本优势呢。 这里还有一个比较根本的矛盾。你设想使用家用P2P网络，本来就是为了省掉专线、高速互联和集中运维的基础设施成本。但这些想省掉的东西，恰恰是大型分布式MoE能够高效运行的必要条件。如果最后还是要求节点长期在线、使用高速网络、接受统一调度，并且为专家部署多个副本，那么它最终只会重新变成一个分布式数据中心。 仅仅说“未来可以通过新的架构慢慢解决”，那我只能说你有点天真。

@stxpnet 我在国外，邮寄需要一个星期多 前两天搞到卖家手上，不知道他们几时才能给回复 现在用着 Item Value Model Qwen3.8-27B UD-Q4_K_M (16.46 GB, sha256-verified, nextn head present) Engine llama.cpp b10498-60addddf3, static CUDA sm_86 Context 135,168 KV q8_0 / q8_0 Vision on (mmproj-F16) MTP draft-mtp, n-max 2

目前配好了new api分流，压制hind sight优先级，已经不会再和主要工作流争抢显卡了

才几天 3.8 27B 就折腾的这么好了 逛这个论坛收益满满

可以关掉了，多找找参数，抄下 @chia-an-yang 的帖子，我测了下，还是他的方案最有性价比。

涨吧涨吧，现在我的3.8 27B投入实用了，基本上不需要它了，小问题，自己处理，如果3.8 27Bxhigh还解决不了，再把问题放着，到闲时让deepseek flash v4来处理。

@williamlouis 说: 不找也行。没什么大用的东西。 发你的贴吧。我也顶你一下。现在是正数了。 感谢！

本来周末要休息。。。。这是搞事情啊。 让大家自愿劳动。

这就好像我们购买steam游戏，下载了也不玩同一样道理。。。存粹享受下载得快感，反正每月都已经缴上网费用

这样说感觉是梁子要操作他的幻方量化，这也是跟特朗普学的，利用影响力画画K线图玩，毕竟deepseek刚刚秀完肌肉（真的很强）。要抓住这个窗口多搞几波操作，把建数据中心的成本捞一点回来。

这个流程现在用 AI Agent 工具链完全搭得出来，不需要从零开发。核心链路是： 通讯软件接入（机器人 API 或 webhook 收消息）→ LLM 把对话里的要求抽取成结构化字段（客户、品项、数量、单价、折扣、交货期）→ 按模板生成报价单草稿（PDF/Excel）→ 报价人员审批 → 通过后自动生成工单。 工具选择上，不想写代码就用 n8n + Dify 这类低代码平台加一个 LLM API 就能串起来；要深度定制再上 FastAPI + Agent 框架。小团队可以先跑个 POC，验证抽取准确率再决定投入。 真正的难点不在 AI 部分，是这三个： 报价规则要沉淀成可校验的规则或知识库，比如折扣权限、最低价、税点，不能让 LLM 自由发挥乱报价； 审批环节建议「人审机建」：AI 只生成草稿，报价人员一键确认，出问题有责任边界； 和现有系统（ERP/CRM/工单）的对接要提前评估，数据能进能出。 另外客户资料和报价数据涉及数据安全，私有化部署或本地模型更稳妥。找外包的话，把上面三个约束写清楚再询价，报价会实在很多，不然容易被「AI 全自动」的话术带偏。

https://youtu.be/RnG6vh3raAU

问题是酒还是要喝，爱还是要做，女还是要撩。。。这些事情找小特肯定不会靠谱，还得出去亲自找的。。 就好像马斯克，我估计他大部分时间也是拿来做我讲的这种东西

@stxpnet 简单答一下： 能不能下载：能。GLM 的开源权重一直在 HuggingFace 的 zai-org 主页上，能力排序大致是：最新的旗舰开源版 > GLM-4.5-Air（推理版，MoE 106B/12B 激活，Q4 量化也要 60GB 以上内存）> GLM-4.5-9B 这类小稠密模型（8-16G 显存就能跑）。现在都 2026 年了，直接去 HF 搜 zai-org 按时间排序看最新发布最准。 关于"opencode 是 GLM 微调的"：opencode 只是支持接 GLM 的 API（智谱的编程套餐），那个模型是智谱针对 coding 场景调过的闭源服务版；本地下载的开源权重是通用版，工具调用能用，但别期待和 API 版一模一样。想本地跑给 opencode 用，起一个 OpenAI 兼容端点就行：llama.cpp 或 vLLM 起 server，opencode 里把 base_url 指向 localhost。 "多搞几台电脑长期白嫖"：方向可行，但有三个现实问题： 显存不能简单跨机拼接（vLLM 的分布式 tensor parallel 可以，但那是给单卡放不下的超大模型用的，千兆网下 MoE 的 all-to-all 通信会拖慢，实际不划算）； 更实际的是每台机器独立跑一个实例、按任务分模型：一台跑 coding、一台跑绘图/视频； 白嫖的真实成本是电费和维护时间，7x24 跑一个月可以自己算笔账，对比 API 按量付费不一定省。 建议先试水：先用 API 把 opencode 跑顺，再切本地模型对比工具调用稳定性和速度，确认差异后再决定要不要上多机。