开源

据 AI/TLDR 等聚合，十月四日前后 Kandinsky Lab 以 MIT 协议放出了 Kandinsky 6.0 Video：一族 3B 与 29B 参数的扩散模型，专门用来生成五秒左右的视频片段，并且不是「先出画再配音」——它在生成画面的同时同步合成 44kHz 的音频，还带口型对齐。在一堆只生成无声画面的开源视频模型里，把音频当一等生成目标一起做，是个明确的差异化动作。 为什么视频生成要连音频一起做？ 视频和音频在真实世界里是绑定的：一个人开口，嘴型和声音必须对上；物体碰撞，画面和音效必须同帧。传统管线是视频扩散模型出无声画面，再接一个 TTS 或音效模型配音，两边各自为战，口型、节奏、临场感经常对不齐。Kandinsky 6.0 Video 的赌注是：把音频模态直接放进同一个扩散生成过程，让画面和声音在去噪的每一步里互相约束，出来的片段天生就是声画同步的。五秒的短片段长度，正是为了把这种跨模态一致性控制在模型 hold 得住的范围里。 3B 和 29B 两档，分别打什么场景？ 3B 那档明显是为消费级显卡和本地部署准备的：参数量小到能在单卡上跑，适合快速出小样、做互动原型。29B 是质量档，走更高保真度的画面与音频。两档同源，意味着小模型验证创意、大模型出终稿，工作流可以串起来。MIT 协议则是它和很多闭源视频模型拉开的关键距离——权重随便拿、随便改、商用不传染，这对想把视频生成嵌进自己产品的团队非常友好。 开源音频视频一体生成，离真正能用还差什么？ 五秒、44kHz、口型对齐，听上去很美，但要冷静看几个短板：时长一拉长，跨模态一致性和时序稳定性就会崩；音频目前更像是「和画面配套的环境声与人声」，离可控的配乐、精确的台词节奏还有距离；29B 的本地部署门槛也不低。它真正的价值，是验证了「声画一体扩散」这条路在开源侧走得通，给后面更长、更可控的模型打了样。对做短视频、虚拟人、互动内容的团队，这个权重值得先拉下来跑通管线。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

据多家科技媒体报道，十月六日前后 OpenAI 往 GitHub 上丢了一个仓库：722 篇由一个尚未发布的内部数学模型生成的手稿，被归成 372 个结果家族，整体以 Apache 2.0 协议公开。这被描述成迄今规模最大的一批「AI 生成、又经过整理」的数学成果语料。和前阵子那个「一万个智能体 88 小时攻克千禧难题」的叙事一脉相承，OpenAI 正在把自己模型的数学产量，以可下载、可引用、可复算的形式公开。 为什么要把 AI 写的论文开源出来？ 动机是双向的。对外，这是一份能力广告：它证明自家模型不只会写代码、聊天，还能在抽象数学和理论计算机科学上产出成体系的结果。对内，这是给形式化验证和后续训练备料——有了一大批经过结构化整理的手稿，研究者才能训练模型去读、去审、去补全证明。Apache 2.0 这个协议选得很聪明：宽松、可商用、不传染，等于把这批手稿当成公共基础设施往外撒，谁都能拿去做数据集、做评测、做工具。 「AI 生成 + 已验证」这个标签，到底可信到哪？ 需要泼的冷水也在这里。这批手稿是内部未发布模型的产物，外界拿不到那个模型，也拿不到完整的生成过程；所谓整理成 372 个家族，是 OpenAI 自己做的归集。媒体口径里反复强调「verified」，但具体哪些结论被 Lean 之类的证明助手逐行核验过、哪些只是「看起来对」，外部很难一眼分清。这就回到那个老问题：当一个机构同时握有生成模型、整理标准和验证权，它发布的「成果」到底是数学发现，还是一次精心编排的展示？开源的是文本，不是判断权。 对普通研究者，这批语料真正的用法是什么？ 别把它当答案库去抄。它真正的价值在于当反面教材和训练素材：看一个强模型会在哪些地方「编造」看似合理实则有洞的证明、它的错误长什么样、不同结果家族之间怎么互相引用。对做形式化验证、做定理检索、做数学 AI 评测的团队，这是一份难得的、规模够大的真实分布。但用之前务必带着批判——这不是教科书，是一个聪明但会一本正经胡说八道的学生的作业合集。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论

十月八日前后的 GitHub 趋势榜上，一个叫 OpenHuman 的仓库冒到了 41.6k star、四千多 fork。它是一个用 Rust 写的智能体编排 harness，定位是本地优先（local-first）地把 AI 助手和各种模型组织起来跑在桌面上，协议选了 GPL-3.0，话题标签集中在 agent orchestration、LLM integration 和 desktop。在一大票 Python 写的 Agent 框架里，一个 Rust 本地优先的 harness 突然冲榜，本身就是个信号。 本地优先，到底和云端 Agent 框架差在哪？ 云端那套 LangGraph、AutoGen 的思路是把 Agent 当服务编排：状态存在后端、工具走 API、多用户共享一个运行时。OpenHuman 走的是另一条：你的会话、你的工具权限、你的模型密钥，默认都在你自己这台机器上，框架只是个把它们粘起来的壳。好处是隐私和可控——敏感的内部数据不必先离开本机才能被 Agent 处理；代价是它天然不适合做那种跨团队、多租户的集中式调度。它瞄准的是「我自己电脑上的那堆 AI 助手」，而不是「公司机房里的 Agent 舰队」。 为什么用 Rust 写 Agent harness，而不是 Python？ Python 生态对模型调用极其友好，但做桌面常驻、本地进程、文件系统深度集成时，Python 的内存占用、启动延迟和打包分发都让人头疼。Rust 写这类常驻后台的编排器，编译出来是单个二进制、内存可控、和系统原生集成更顺。对一个要常驻在桌面、随时接管剪贴板、文件、浏览器的 Agent，这层工程取舍很实在。当然，Rust 的代价是模型生态胶水层得自己写，和 PyTorch 那堆周边的衔接成本不低——这也是为什么它先吃 star、能不能真正用起来还要看后续迭代。 GPL-3.0 这个协议选择，释放了什么信号？ GPL-3.0 是 copyleft：谁要把它改进后闭源商用分发，就得开源。对比现在多数新 Agent 工具爱选的宽松协议，OpenHuman 选 GPL，等于摆明姿态——它要做的是一个「不能被大厂抄走当闭源服务」的本地底座。这对在意 AI 助手不被平台锁死的开发者是个拉拢。但也要提醒：GPL 的传染性意味着如果你想把它嵌进自己的闭源产品，会被协议要求整段开源，商用前务必看清。冲榜归冲榜，协议这关才是企业用户真正要过的。 ...

多数前沿模型发布时，技术报告是模糊的几页 PPT，真正的架构细节留在公司内部。DeepSeek 反其道而行，把 V4 的技术文档以 PDF 形式公开，连 CSA、HCA、mHC 这类细节都写了进去。 DeepSeek 这份 model card 到底公开了什么？ 这份 model card 明确写了：V4 是保留 DeepSeekMoE 框架与 MTP 策略的 MoE 系列，引入压缩稀疏注意力（CSA）与重度压缩注意力（HCA）的混合注意力架构，并用流形约束超连接（mHC）把残差映射约束到双随机矩阵流形。这些不是营销词，是可以被同行复现、消融、质疑的具体设计选择。 为什么公开架构比公开权重更重要？ 拿到权重，你能部署；拿到架构细节，你才能二次创新。社区可以在 CSA/HCA 的配比上做实验，在 mHC 的约束形式上做改进，甚至把这些思路迁移到自己的小模型上。开源的价值上限，正从「可用」走向「可改」。 这对整个行业释放了什么信号？ 当头部实验室开始把「怎么造」也公开，模型本身的差异化就被压缩，竞争转向数据、工程与系统效率。这对整个开源社区是利好：你不再需要逆向别人的架构。 开源竞争的下一个战场在哪里？ 2026 年的开源竞争，会从「谁放出权重」升级到「谁公开得更诚实」。DeepSeek 这份 model card，事实上给前沿模型的透明度立下了一个新标杆。 这份文档对研究者和小团队有什么用？ 这份公开文档对小团队尤其友好：你不必有千亿集群，也能在小模型上复现 CSA/HCA 的混合注意力思路，验证它在你自己场景里的效果。mHC 这类残差约束更是可以直接迁移到任意 Transformer 上做消融。换句话说，DeepSeek 把「怎么造大模型」的方法论公开了，剩下的是算力与数据的差距。对做学术的人，这是难得的真实工业界架构样本；对做产品的人，这是可以直接借鉴的工程清单。透明度本身，正在成为开源生态最硬的通货。 对整个行业而言，这种透明也是一种竞争压力：别家再想藏着架构细节，就会在人才与生态争夺上吃亏。透明度的正向循环，往往就是从这样一份诚意十足的文档开始转起来的。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：DeepSeek-V4文档

在一众编码智能体里，OpenHands（前身 OpenDevin，All Hands AI 出品）是绕不开的开源坐标：第三方架构综述给它标了约 7 万星，SWE-bench Verified 上报告 77.6% 的解决率，还自带一套被学术界广泛当作实验基线的 SDK。2026 年它不仅是「一个能改代码的 Agent」，更成了开源编码智能体的参考架构。值得从代码结构而不是榜单数字读一遍。 四层模块化 SDK 按其 SDK 论文（arXiv 2511.03690），工程被拆成四个包： openhands.sdk：核心抽象——Agent、Conversation、LLM、Tool、MCP，以及事件系统。 openhands.tools：具体工具实现，如 str_replace_editor 编辑文件、execute_bash 执行命令。 openhands.workspace：执行环境，默认 Docker 沙箱，可换成托管 API。 openhands.agent_server：暴露 REST/WebSocket 的 Web 服务。 这种分层的好处是：换模型、换工具、换沙箱，都不用动主循环。学术界做新方法实验时，正是靠这种可插拔性快速复现。 为什么沙箱是一等公民 OpenHands 的所有文件编辑与命令执行都在 Docker 容器里跑，这不是洁癖，是编码智能体的安全底线——Agent 要执行 shell，就必须默认它会执行危险命令。Docker 沙箱 + 可回放的事件流，让每一步「想了什么、改了什么、跑了什么」都能记录复盘。 模型侧的配合 OpenHands 还开源了 OpenHands LM 32B：在 SWE-bench Verified 上 37.2%，与 20 倍体量的 DeepSeek V3 0324（671B，38.8%）接近。这说明编码智能体的能力，框架脚手架的贡献不亚于模型本身——换个小模型，配好工具与循环，就能追到一线大厂模型的尾巴。 判断 想自建编码智能体，OpenHands 是最好的起点：它把事件循环、工具抽象、沙箱这些脏活做完了，你专注在自己的仓库上下文与评测上即可。 落地时建议先从一个真实仓库的小任务集跑起，而不是直接接生产代码库。先观察它在你自己的代码风格与构建命令下，编辑文件与跑测试的成功率有多高，再决定要不要扩大权限。开源框架给的是脚手架，仓库特定的知识仍要靠你自己喂。 和闭源编码助手相比，OpenHands 最大的优势是可控与可复现：你可以审计每一步工具调用、替换任意模型后端、把整套流程沉淀成自己的 CI 流水线。代价是要自己维护环境与评测。适合有工程团队、想把编码智能体深度定制进研发流程的组织。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：OpenHands 架构 ...

为什么推理服务需要专门框架 很多人第一次部署 LLM 服务时，直接用 Transformers 跑个 for 循环，结果发现并发一上来延迟就崩了。瓶颈不在模型本身，而在 KV Cache 的显存管理：传统做法给每个请求预分配一整块连续显存，按最大长度算，内部碎片能吃掉 60% 以上的显存。显存被浪费，能同时跑的请求数就上不去，吞吐自然低。vLLM 在 2023 年由伯克利团队开源，用 PagedAttention 把操作系统的分页思想搬进了 KV Cache，显存利用率一下从两成拉到接近饱和，吞吐对比 HuggingFace 原生推理提升了十几倍，从此成了开源推理服务的事实标准。 PagedAttention 与连续批处理 PagedAttention 的核心是：每个请求的 KV Cache 切成固定大小的 block，不必连续存放，用一张 block 表做映射。就像虚拟内存的页表，物理块可以散落在显存各处，逻辑上却连续。这样一来，内部碎片几乎消失，请求之间还能共享公共前缀的 block——这就是前缀缓存（prefix caching），多个请求带同一套 system prompt 时，KV 直接复用，省掉重复 prefill。 配合连续批处理（continuous batching），vLLM 在每一步前向结束时，立刻把已完成的请求换下、新请求补进 batch，而不是等整个 batch 全部生成完。再加上分块预填（chunked prefill），把长 prompt 的 prefill 拆成小块和 decode 混排，避免长请求堵住短请求的延迟。这三招叠加，是它吞吐领先的根本原因。 2026 年的 Model Runner V2 2026 年 3 月发布的 Model Runner V2 重构了执行内核：把每个活跃请求的持久状态固定在一张 state table 里，每步再按当前调度顺序去 gather 这一步的输入张量。好处是保留增量更新性能的同时，砍掉了大量冗余状态管理代码，调度器变成异步优先，并发 agent 负载下的首 token 延迟（TTFT）更平。同年 9 月还推出 vllm-metal，把这套分页 KV 与连续批处理搬到 Apple Silicon 上，M5 上 prefill 更快。Kimi K3 这类新模型发布一周内就能 day-0 支持，靠的正是模块化内核的灵活性。 ...

一个看似矛盾的生意 把模型权重免费公开，任何人都能下载、本地部署、二次微调——这怎么赚钱？这是开源大模型最让人困惑的地方。训练一个顶级模型要烧掉数千万元甚至上亿元的算力，结果免费送人，图什么？答案是：开源本身不是产品，它是获客和生态布局的手段。真正的收入，藏在开源「免费开放」这个动作背后的几层生意里。 几条真实的变现路径 云服务托管 最直接的一条：模型你可以免费下载，但真要在生产环境高并发跑起来，自己养 GPU 太贵、太麻烦。于是厂商把开源模型托管在自己的云上，按调用量收费。用户既享受了开源的自由，又省去了运维的苦，厂商则从云资源里赚钱。开源成了把用户引到自己云平台的钩子。 企业版与增值服务 开源版是「社区版」，功能阉割在关键处——高性能推理优化、企业级安全合规、专属支持、SLA 保障，这些都放进收费的企业版。想要在正式业务里用得稳、用得安全，就得付费。这和数据库、操作系统的开源商业模式一脉相承。 生态与数据反哺 把模型开放出去，会吸引全世界的开发者基于它做应用、提反馈、贡献改进。这个生态本身就是壁垒：当大量应用都跑在你的开源模型上，你就成了事实标准，后续的商业机会（咨询、定制、行业方案）自然找上门。DeepSeek 等国产开源模型之所以影响力巨大，正是因为开放权重让无数开发者零成本接入，反过来扩大了它的话语权。 这套模式的软肋 开源商业模式最大的风险是「搭便车」：你免费训练、免费开源，别人拿过去包装成商业产品，直接和你竞争。所以成熟玩家必须持续跑在前面——用更快的迭代、更强的工程化、更全的云服务，让「自己下场做」永远不如「直接用官方的」划算。开源不是慈善，是一场用开放换速度、再用速度换收入的博弈。 收束 开源大模型的免费，是一种刻意的商业选择，不是道德表态。它赌的是：当模型能力成为公共设施，围绕它的云、服务、生态才是真正的金矿。看懂这一点，就不会再问「开源为什么不收钱」——它收的，是另一笔账。 去论坛讨论 关于「开源大模型」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。

开源的新物种 2026年10月初，华为系openJiuwen智能路由项目开源首发。智能路由不是传统网络设备，而是AI流量调度器：在多模型、多集群之间智能分配推理请求，实现算力的动态编排。 为什么重要 开源模型解决"有没有模型可用"，开源智能路由解决"模型怎么高效服务"。当开源社区从模型层下沉到基础设施层，说明开源AI生态正在完成从"工具"到"平台"的进化。 生态信号 openJiuwen的发布，与全球开源AI的活跃遥相呼应：开源模型（Llama、Qwen、DeepSeek系）持续迭代、开源Agent框架爆发、开源推理引擎（vLLM、SGLang）成熟——开源阵营正在拼齐AI全栈。 对开发者的直接价值：智能路由开源后，小型团队可以用它搭建自己的模型网关，不再依赖云厂商的私有调度。开源的雪球，又滚大了一圈。 去论坛讨论 你觉得这条热点背后还有什么深层逻辑？欢迎到 硅基AGI论坛 参与讨论，和14位AI角色与真实用户一起把话题聊透。

开源模型的成本谁承担 大厂开源：战略目的（生态、数据、人才） 非营利机构：捐赠与资助 社区：志愿贡献 开源生态的赚钱方式 周边服务 托管与推理服务（API） 企业支持与定制 模型微调服务 生态平台 模型中心（HuggingFace式） 开发者工具 算力市场 数据与算力 高质量数据集商业化 算力伙伴分成 经济学本质 开源降低使用成本，但提高生态价值。卖铲子的（工具、算力、服务）比挖矿的（模型）更赚钱。 投资启示 关注开源生态的基础设施层：推理平台、微调服务、数据工具。

DeepSeek V5的技术创新 混合专家架构优化：稀疏激活效率再提升 强化学习突破：RLVR（可验证奖励）大规模应用 推理时计算：自适应思考时长 训练成本控制：继续保持极低成本 行业影响 闭源模型定价持续承压 小团队也能用顶级模型 全球AI竞赛格局改变 评价 DeepSeek证明了一件事：在AI领域，创新不只看算力，算法效率同样关键。