MoE 架构

核心摘要 通过将 Qwen3.6-35B-A3B 的 8 个 MoE 专家层策略性地卸载至 CPU，开发者在 RTX 3090 (24GB) 上成功释放显存，通过提升批处理大小使提示词处理速度（Prefill）从 564 tok/s 飙升至 1330 tok/s，增幅达 136%。 ▶ MoE 架构的非对称优势：由于 MoE 模型的稀疏激活特性，卸载部分专家层对生成（Decode）速度影响微乎其微，但释放的显存能显著提升 KV Cache 和批处理空间。 ▶ 吞吐量胜过纯速度：在长上下文（64K）场景下，VRAM 的瓶颈不在于计算力，而在于批处理容量。将 -b (batch size) 从 512 翻倍至 1024 是性能翻倍的核心驱动力。 八卦洞察 「八卦智库」认为，这一实验揭示了消费级 GPU 在大模型长上下文时代的生存法则：精细化内存管理（Tiered Memory Management）优于盲目追求全显存运行。Qwen3.6-35B 的 A3B（Active 3B）架构赋予了模型极高的推理灵活性。传统的 llama.cpp “自动匹配”往往倾向于保守的显存分配，而手动调优 MoE 专家分布，本质上是在利用 CPU 的大容量内存为 GPU 的高带宽计算“松绑”。在 RAG（检索增强生成）应用日益普及的今天，Prefill 速度直接决定了系统的响应延迟，这种通过牺牲极小部分专家响应时间来换取吞吐量爆发的策略，将成为单卡运行中型 MoE 模型的标准范式。 行动建议 针对 RAG 开发者：若使用 24GB 显卡处理长文本，应优先通过卸载部分专家层（Expert Offloading）来腾出显存，将批处理参数（-b 和 -ub）推至硬件极限，以换取更高的预处理吞吐量。 量化选择策略：在显存受限时，选择 Q6 等高精度量化并配合专家卸载，其效果往往优于强行压缩至 Q4 以适配全显存运行，前者能更好地保持模型逻辑能力。

核心摘要 G9v3-39A5B 是一款基于混合专家架构（MoE）的开源大模型，凭借极低的幻觉率和出色的通用任务处理能力，在 Hugging Face 的人工评估及 LocalLLaMA 社区中脱颖而出，成为构建 Agent 系统的理想选择。 ▶ 低幻觉即正义：在 RAG 和自动化 Agent 场景中，模型的可靠性权重已超越纯粹的逻辑推理。 ▶ MoE 架构的生产力化：39B 的总参数量通过 MoE 实现高效推理，平衡了本地部署的门槛与输出质量。 ▶ Qwen 的强力挑战者：除编程能力略逊于 Qwen 外，该模型在通用对话和指令遵循上表现出极强的竞争力。 八卦洞察 G9v3-39A5B 的出现标志着开源模型竞争进入了“垂直可靠性”阶段。过去一年，开发者往往陷入 Benchmark 高分的数字游戏，但在实际 Agent 编排中，模型常因微小的幻觉导致整个工作流崩溃。G9v3 通过优化 MoE 专家路由，显著降低了事实性错误，这对于需要处理长上下文和复杂工具调用的 Agent 开发者来说是重大利好。虽然 Qwen 在 Coding 领域依然保持霸主地位，但 G9v3 在通用语义理解上的平滑表现，使其成为企业级内部助手和知识库问答的首选本地模型。这种“Agentic Heavy”的设计思路，预示着未来模型评价体系将从“博学”转向“稳健”。 行动建议 针对开发者：若当前项目受困于 RAG 系统的“一本正经胡说八道”，建议立即在本地环境测试 G9v3-39A5B 的 FP16 或 4-bit 量化版本。 针对架构师：在构建多 Agent 协作系统（Multi-Agent Systems）时，可考虑将 G9v3 作为协调节点（Orchestrator），利用其低幻觉特性进行任务分发与结果校验。 关注点：持续观察该模型在 Function Calling 上的稳定性，这是衡量其“Agentic”属性是否名副其实的核心指标。

核心事件 一名开发者通过自研 C99 推理引擎，利用 Kimi K3 模型的 MoE（混合专家）稀疏性，成功在仅配备 8GB 内存的单 CPU 设备上运行了参数量高达 1.56TB 的 Kimi K3，将推理瓶颈从显存容量转移到了 NVMe 存储带宽。 ▶ 极致稀疏性的胜利：Kimi K3 的 1.56TB 权重中，93% 为专家权重。由于每 token 仅需激活 896 个专家中的 16 个，开发者通过“按需从 NVMe 读取”而非“常驻内存”的策略，实现了超大规模模型的平民化运行。 ▶ 推理范式转移：该实验证明了在 MoE 架构下，高速 SSD 可以充当“二级显存”，预示着未来大模型推理将从单纯的算力竞争转向 I/O 效率的博弈。 八卦洞察 这并非简单的技术炫技，而是对当前“算力焦虑”的一次有力回击。Kimi K3 的架构设计（极多专家、极高稀疏度）天然契合这种“存储即计算”的模式。当下的 AI 工业界过度依赖 H100 集群的统一内存架构，但对于非实时、高吞吐或边缘端的应用场景，这种“动态加载”模式提供了极高的 ROI（投资回报率）。如果未来能结合 DirectStorage 等零拷贝技术，普通消费级 PC 运行万亿级模型将不再是幻想，这将彻底瓦解英伟达在显存容量上的定价溢价。 行动建议 针对企业端：在构建私有化 RAG 或离线批处理任务时，应评估“专家按需加载”方案，利用廉价的 NVMe 存储资源替代昂贵的 H100 节点，大幅降低 TCO（总拥有成本）。 针对开发者：关注 C99/Rust 等底层语言在 I/O 密集型推理中的应用，优化 NVMe 到 CPU 的数据路径，避开 Python 框架在内存管理上的性能损耗。 硬件选型：在边缘 AI 部署中，应优先提升高速存储接口（如 PCIe 5.0 NVMe）的优先级，而非盲目追求大容量显存。

事件核心 俄罗斯科技巨头 Sberbank 正式发布了其最新旗舰模型 GigaChat 3.5-432B-A28B 及其基础版本。该模型采用混合专家模型（MoE）架构，总参数量高达 432B，而单次推理激活参数仅为 28B。最令社区振奋的是，官方在发布首日即同步推出了 GGUF 格式支持，并通过 Pull Request 积极推动其合并至 llama.cpp 主分支。 ▶ 架构优势：432B 的总参数量提供了极高的知识容量，而 28B 的激活参数确保了推理速度与 30B 级别模型相当，实现了性能与效率的平衡。 ▶ 生态策略：官方“Day-0”支持 GGUF 格式，标志着大模型厂商从“等待社区转换”转向“主动拥抱本地部署生态”，极大降低了超大规模模型的使用门槛。 ▶ 硬件兼容：通过 GGUF 量化，该模型有望在消费级多显卡环境或高配 Mac Studio 上运行，打破了 400B+ 模型仅能在企业级集群运行的迷思。 八卦洞察 Sberbank 此举不仅是技术实力的展示，更是一次精明的生态位抢占。在 Meta 和 Mistral 占据开源主流的当下，GigaChat 3.5 通过超大参数规模和极致的本地化适配（GGUF）来寻求差异化竞争。432B/28B 的配比暗示了其在处理复杂逻辑和多语言任务时的深厚潜力。更深层来看，这反映了非美系科技巨头在算力受限背景下，通过 MoE 架构和量化技术压榨硬件性能、实现“技术主权”的战略路径。对于开发者而言，这不仅是一个新模型，更是一个在私有化部署中替代 Llama 3 405B 的潜在强力竞争者。 行动建议 开发者应立即关注 llama.cpp 的相关 PR (#11585)，尝试在本地环境中构建并测试 Q4_K_M 等主流分位的量化版本。企业级用户若有俄语或特定欧洲语言的 RAG 需求，应重点评估该模型在长文本处理上的表现。同时，建议关注其推理成本与性能的实际曲线，评估其在私有化算力节点上的部署可行性。

事件核心 AI 开源社区迎来里程碑式进展。Longcat 2.0 模型权重已正式在 ModelScope 及相关平台发布，并采用极其宽松的 MIT 许可证。该模型采用混合专家（MoE）架构，总参数量达到惊人的 1.6 万亿（1.6T），而单次推理激活的参数约为 480 亿（48B）。这一发布不仅标志着开源模型在参数规模上正式跨入“万亿俱乐部”，更通过 MIT 协议彻底打破了商业应用的法律壁垒。 技术/商业细节 参数效率与架构：Longcat 2.0 的核心竞争力在于其极高的稀疏性。1.6T 的总参数量赋予了模型庞大的“知识库”，而 48B 的激活参数则将推理成本控制在可接受范围内。这意味着在拥有足够显存（存储总权重）的前提下，其推理速度可类比中型稠密模型。 MIT 许可证的杀伤力：相比 Meta Llama 系列带有附加限制的社区许可证，Longcat 2.0 选择 MIT 协议意味着企业可以无限制地进行商业化、修改和闭源二次开发。这对于追求底层技术自主权的科技巨头和初创公司具有极强的吸引力。 生态协同：此次发布由 elie 与 ModelScope 深度参与，展示了全球开发者社区与中国开源基础设施的紧密协作。模型权重的开放涵盖了完整的技术文档，为后续的微调（Fine-tuning）和量化（Quantization）铺平了道路。 八卦分析：全球影响 「八卦情报局」认为，Longcat 2.0 的出现是开源界对闭源巨头（如 OpenAI、Google）的一次强力“肌肉展示”。 首先，它验证了开源社区有能力驾驭万亿级参数模型的训练与分发。长期以来，1T+ 参数被认为是闭源巨头的护城河，Longcat 2.0 证明了通过 MoE 架构，开源力量可以实现“参数规模”的平权。其次，48B 的激活参数是一个精妙的平衡点。它既能提供远超 7B/8B 模型的逻辑推理能力，又避开了 1.6T 稠密模型无法落地的尴尬，直接瞄准了高端工作站和企业级服务器市场。 更深层的影响在于，这将迫使 Meta 等公司重新审视其开源策略。如果社区能够持续产出 MIT 协议的万亿级模型，那么带有“月活用户限制”的 Llama 协议将失去其作为事实标准的号召力。 战略建议 算力布局：企业应关注高显存、高带宽的硬件配置（如 H200 或多卡串联方案），以容纳 1.6T 的静态权重，利用其 MoE 特性实现高性能推理。 技术选型：对于需要构建垂直领域“专家系统”的团队，Longcat 2.0 的 MoE 架构提供了理想的底座。建议尝试针对特定专家层进行差异化微调。 合规优势：鉴于其 MIT 协议，建议对合规性要求极高的金融、政务类 AI 项目优先调研此模型，以规避未来潜在的授权风险。

核心摘要昇腾社区（Ascend-tribe）近期披露了 openPangu-2.0-Flash，这是一款原生基于华为昇腾平台训练的高性能混合专家（MoE）模型。该模型拥有 920 亿总参数，推理时仅激活 60 亿参数，并支持高达 512k 的超长上下文，其预训练数据量达到了惊人的 34T tokens。▶ 极致稀疏化架构：92B 总参数仅激活 6B，旨在实现极低延迟的“闪电级”推理响应，在吞吐量与模型深度之间取得了极佳平衡。▶ 认知进化：快慢思考融合：后训练阶段引入了具备“快慢思考”能力的统一 SFT 及多专家强化学习（RL），标志着国产开源模型开始深度探索类 o1 的逻辑推理范式。▶ 国产算力生态闭环：该模型的出现不仅是参数规模的堆砌，更是昇腾原生大模型从“可用”向“高性能原生优化”跨越的里程碑。八卦洞察openPangu-2.0-Flash 的核心竞争力在于其 34T Tokens 的海量数据集，这一数字已与 Meta 的 Llama 3 处于同一数量级，显示了其在知识密度上的野心。更值得关注的是其 512k 的上下文窗口，这直击当前企业级 RAG（检索增强生成）和长文档分析的痛点。从技术路径看，该模型试图通过高稀疏比的 MoE 架构，在非 H100/B200 集群上实现媲美顶级芯片的推理效率，这是对 NVIDIA 垄断地位的一次有力技术突围。行动建议对于开发者，建议密切关注 Hugging Face 的权重发布动态，第一时间测试其在非昇腾硬件上的兼容性与推理效率。对于企业决策者，应重新评估基于昇腾算力架构的国产 AI 基础设施方案，openPangu-2.0-Flash 的表现证明了国产软硬一体化优化已进入成熟期，可作为主线业务的备选方案进行预研。

LongCat 团队正式发布 LongCat-2.0，这是一个采用混合专家模型（MoE）架构的超大规模语言模型，拥有 1.6 万亿（1.6T）总参数量，但在推理时仅激活 480 亿（48B）参数，旨在解决长文本处理与复杂 RAG 场景下的效率瓶颈。 ▶ 稀疏化扩展的里程碑：LongCat-2.0 通过 1.6T 的海量参数空间实现了极高的知识容量，同时利用 MoE 机制将推理成本控制在 48B 级别，证明了“大而不臃”的架构在长上下文任务中的优越性。 ▶ 长文本与 RAG 的深度优化：该模型针对超长 Context Window 进行了专项调优，显著提升了在海量文档检索与合成任务中的准确率，直接对标行业顶尖的闭源长文本模型。 八卦洞察 LongCat-2.0 的出现标志着大模型竞争进入了“稀疏化扩展”的下半场。1.6T 的总参数量并非单纯的数字堆砌，而是为了在垂直领域专家化（Expert Specialization）上取得突破。对于全球 AI 产业而言，LongCat-2.0 的核心竞争力不在于其原始计算能力，而在于其对“长程注意力”与“动态路由”的极致优化。这种架构有效缓解了传统 Dense 模型在处理长文本时出现的“中间丢失（Lost in the Middle）”问题。我们认为，随着 RAG 架构向原生长文本（Native Long-Context）演进，LongCat 这种高容量、低激活的 MoE 模型将成为企业级知识库处理的首选底座。 行动建议 架构迁移评估：建议正在构建大规模 RAG 系统的企业，评估从传统 Dense 模型迁移至 LongCat-2.0 等 MoE 架构的可行性，以在不显著增加算力开销的前提下提升长文档处理精度。 基础设施对齐：开发者应关注针对 MoE 路由优化的推理后端（如 vLLM 或 TensorRT-LLM 的最新版本），以充分发挥 1.6T 模型在 48B 激活状态下的吞吐优势。 关注长文本评测：不要仅参考传统的 MMLU 等基准测试，应针对 LongCat-2.0 开展 Needle-in-a-Haystack（大海捞针）等长文本压力测试，以验证其在实际业务长文档中的召回表现。

事件核心MIT 衍生初创公司 Liquid AI 正式发布了其最新的 Liquid Foundation Models (LFM) 2.5 系列。其中最受瞩目的是 8B-A1B 模型，这是一个采用 Mixture-of-Experts (MoE) 架构的 80 亿参数模型，但在推理时仅需激活 10 亿参数。该模型最令人震撼的数据在于其训练规模：在高达 38 万亿 (38T) Token 的海量数据集上进行了训练。LFM 2.5 并非基于传统的 Transformer 架构，而是采用了 Liquid AI 独有的、基于动力系统（Dynamical Systems）的新型架构，旨在解决 Transformer 在长序列处理和推理成本上的固有缺陷。技术/商业细节LFM 2.5 的核心竞争力在于其极高的“数据参数比”。通常，Llama 3.1 8B 等模型使用约 15T Token 训练，而 Liquid AI 将这一数字推高到了 38T，这意味着模型对知识的压缩率和理解深度达到了新高度。在架构层面，LFM 避开了传统 Attention 机制的二次方复杂度，实现了线性缩放。这使得 8B-A1B 模型在拥有 128K 上下文窗口的同时，其内存占用远低于同级别的 Transformer 模型。在 Benchmark 测试中，LFM 2.5 8B 在多项指标上超越了 Meta 的 Llama 3.1 8B 和 Google 的 Gemma 2 9B，尤其是在编码（Coding）和长文本推理方面表现卓越。八卦分析：全球影响Liquid AI 的这次发布向业界释放了一个强烈信号：Transformer 可能并非 AI 的终局。长期以来，硅谷一直存在“架构焦虑”，即担心 Transformer 的推理成本会限制 AI 的大规模商业化。Liquid AI 证明了通过非 Transformer 架构（如状态空间模型 SSM 或其变体）配合极致的数据喂养，可以在更小的参数规模下实现更强的性能。这对于边缘计算（Edge AI）和端侧设备具有颠覆性意义。如果 1B 激活参数的模型能达到 8B 甚至更高参数模型的水平，那么智能手机和 IoT 设备将真正具备运行复杂逻辑的能力，而无需依赖昂贵的云端 GPU 集群。战略建议对于开发者： 重点关注非 Transformer 架构的适配。LFM 2.5 提供的推理效率优势，特别是在 KV Cache 压力巨大的长文本场景下，可能是降低 RAG 应用成本的关键。对于企业决策者： 重新评估“模型大小”与“模型能力”的关系。不要盲目追求千亿级参数模型，Liquid AI 的案例证明，经过超大规模数据精炼的小模型（SLM）在特定业务场景下具有更高的 ROI。对于硬件厂商： 关注非 Transformer 算子在芯片层面的优化。随着 Liquid AI、Mamba 等架构的兴起，单纯针对 Attention 优化的硬件架构可能面临兼容性挑战。