编程 Kimi K3 深度拆解:2.8万亿参数开源MoE旗舰的架构革命与工程极限

2026-07-31 09:42:32 +0800 CST views 15

Kimi K3 深度拆解:2.8万亿参数开源MoE旗舰的架构革命与工程极限

一、事件背景:开源AI的「三万亿时刻」

2026年7月27日,月之暗面(Moonshot AI)正式在Hugging Face开源了Kimi K3——全球首个参数量突破3万亿级别的开源大模型。这不是一次普通的版本迭代,而是开源AI社区的「范式级」时刻。

在Kimi K3发布之前,开源大模型的天花板是Meta的Llama 3.1 405B(约4000亿参数),而闭源模型的巅峰则是GPT-5.6和Claude Fable 5。Kimi K3以2.88万亿(≈2.8T)总参数、1040亿激活参数的规模,直接把这个差距拉到了数量级层面。更重要的是,月之暗面不仅开源了模型权重,还同步开放了三大Infra技术栈:高性能MoE通信库MoonEP、高效注意力算子FlashKDA、以及分布式强化学习环境AgentENV。

核心规格一览:

参数数值
总参数量≈2.88万亿(2.8T)
每Token激活参数≈1040亿(104B)
架构混合注意力MoE(KDA + Gated MLA)
Decoder层数93层(69层KDA + 24层MLA)
路由专家数896个,每Token激活16个
共享专家数2个
隐藏维度7168
注意力头数96
最大上下文1,000,000 Token
视觉编码器MoonViT-V2(从头训练)
开源协议Kimi K3 License(Modified MIT)

本文将从工程师视角出发,深入拆解Kimi K3的三项核心架构创新:KDA混合线性注意力、Attention Residuals、以及Stable LatentMoE,并分析其工程极限与落地实践。

二、标准注意力的根本瓶颈:为什么O(n²)必须被打破

在理解Kimi K3的架构创新之前,我们必须先正视标准Self-Attention的计算复杂度问题。

标准Self-Attention的计算公式为:

Attention(Q, K, V) = softmax(QK^T / √d) × V

其中 Q、K、V 均为序列长度 n × 隐藏维度 d 的矩阵。关键计算步骤 QK^T 的时间复杂度是 O(n² · d),空间复杂度同样是 O(n²)。这意味着:

  • 当上下文从 4K 提升到 1M(100万token),注意力层的计算量放大约 6万倍
  • 一个100万token的输入,即使假设每个token仅生成1个token输出,也需要存储和处理一个 1M × 1M 的注意力矩阵
  • 在FP32精度下,这个矩阵需要约 4TB 的显存——远超任何单卡容量

这就是为什么在Kimi K3之前,开源模型的长上下文能力始终受限于32K-128K。标准Transformer架构在长序列上的显存占用和计算延迟是线性模型的立方级增长,这是物理限制,不是工程问题。

三、KDA:把长文本算力成本打下来

Kimi K3的第一项核心创新是 Kimi Delta Attention(KDA)——一种高效的线性注意力变体。

3.1 线性注意力的核心思想

线性注意力的核心思路是将softmax操作重新排列,从而将复杂度从 O(n²) 降低到 O(n)。其数学原理是:

标准注意力:

Attention = softmax(QK^T) · V

线性注意力(核函数近似):

Attention ≈ φ(Q) · (φ(K)^T · V) / (φ(Q) · φ(K)^T · 1)

其中 φ(·) 是某个低维投影函数(如指数映射)。通过改变运算顺序,原本需要存储 n×n 注意力矩阵的操作,变成了递归累积的形式——每次只需 O(d) 的状态更新。

3.2 Delta Rule:增量更新的秘密

KDA的关键创新在于引入了带遗忘门的增量规则(Delta Rule)。传统线性注意力的问题是:随着序列增长,早期token的信息会被后续token逐步稀释——模型对"开头"的内容记忆越来越模糊。

KDA通过以下机制解决:

# 伪代码:KDA的核心状态更新
class KDAState:
    def __init__(self, hidden_dim):
        self.memory = zeros(hidden_dim)  # 隐状态
        self.forget_gate = zeros(hidden_dim)  # 遗忘门
    
    def update(self, token_embedding, delta):
        # 遗忘:选择性清除旧信息
        self.memory = self.memory * self.forget_gate
        
        # 增量:添加新token的信息
        self.memory = self.memory + delta(token_embedding)
        
        return self.memory

关键点在于:不是简单地覆盖记忆,而是保留一个固定大小的隐状态,通过遗忘门控制新旧信息的比例。这使得KDA可以在固定显存预算下处理任意长度的序列。

3.3 混合注意力:效率与全局感知的平衡

然而,线性注意力有一个根本性缺陷:无法精确查询任意历史位置。标准注意力可以通过 softmax(QK^T) 直接计算任意两个token之间的相关性,而线性注意力只能通过递归累积的隐状态"间接"获取历史信息。

Kimi K3的解决方案是混合架构:以3:1的比例混合KDA层与Gated MLA层。

Decoder层结构(每4层为一个块):
  Layer 1: KDA(局部高效建模)
  Layer 2: KDA(局部高效建模)
  Layer 3: KDA(局部高效建模)
  Layer 4: Gated MLA(全局无限制交互)
  → 重复 23 次 = 92 层
  → 加上首层 embedding = 93 层
  • KDA层:处理局部模式,用O(n)复杂度做增量特征提取
  • Gated MLA层:提供全局内容交互能力,保留精确的token-to-token关系

这个3:1的比例是经过大量消融实验得出的最优解——太多MLA层会恢复O(n²)复杂度瓶颈,太多KDA层则会损失精确的跨距依赖建模能力。

3.4 FlashKDA:H20上的极致优化

月之暗面不仅开源了KDA的算法设计,还开源了FlashKDA——KDA的高性能CUDA实现。

在英伟达H20 GPU上,FlashKDA相比flash-linear-attention基线:

  • Prefill速度提升 1.72-2.22 倍
  • 显存占用降低约40%(通过算子融合和分块计算)

FlashKDA的核心优化策略包括:

  1. 算子融合(Kernel Fusion):将KDA的多个小算子合并为单个CUDA kernel,减少显存访问
  2. 分块注意力(Tiled Attention):将长序列分割为固定大小的块,块内用标准注意力,块间用KDA
  3. BF16/FP8混合精度:对注意力矩阵用低精度,对输出投影保持高精度
# FlashKDA 的分块策略示意
def flash_kda_forward(q, k, v, block_size=512):
    """
    q/k/v: [batch, heads, seq_len, head_dim]
    将长序列分割为 block_size 的块
    """
    num_blocks = (seq_len + block_size - 1) // block_size
    outputs = []
    
    for i in range(num_blocks):
        # 块内:使用标准注意力(O(block_size²))
        # 块间:使用KDA增量更新(O(block_size))
        block_q = q[:, :, i*block_size:(i+1)*block_size]
        block_k = k[:, :, :i*block_size]  # 累积的历史K
        block_v = v[:, :, :i*block_size]  # 累积的历史V
        
        # KDA增量更新
        block_output = kda_incremental_update(block_q, block_k, block_v)
        outputs.append(block_output)
    
    return concat(outputs, axis=2)

四、Attention Residuals:打破深层的「信息瓶颈」

4.1 传统残差连接的问题

在标准Transformer中,信息通过残差连接在层间传递:

output = LayerNorm(x + Sublayer(x))

这种设计的隐含假设是:主路径(Sublayer)和残差路径(x)携带不同层次的信息,前者负责精细变换,后者负责粗粒度传递

然而,当模型深度增加到90+层时,这个假设开始失效——深层网络面临两个根本问题:

  1. 梯度消失:即使有残差连接,链式求导中 90+ 个雅可比矩阵的连乘仍会导致梯度指数级衰减
  2. 信息瓶颈:每一层的输出必须同时"记住"所有前置层的处理结果,隐状态容量被严重挤压

4.2 AttnRes的设计哲学

Attention Residuals的核心思想是:让每一层的注意力机制直接访问所有先前层的表示,而不仅仅访问上一层的输出

标准残差:  Layer_n_output = LayerNorm(Layer_{n-1}_output + Sublayer(Layer_{n-1}_output))
AttnRes:  Layer_n_output = LayerNorm(
              Layer_{n-1}_output + 
              Sublayer(Concat(all_previous_layers))  # ← 关键差异
            )

具体实现上,AttnRes会维护一个层间注意力缓存

class AttentionResidual:
    def __init__(self, max_layers):
        self.layer_cache = {}  # layer_idx -> hidden_state
        self.max_layers = max_layers
    
    def forward(self, layer_idx, current_output):
        # 保存当前层输出
        self.layer_cache[layer_idx] = current_output
        
        # 获取所有先前层的表示
        all_previous = [
            self.layer_cache[i] 
            for i in range(layer_idx)
        ]
        
        # 跨层注意力:当前层可以"看到"所有历史
        if len(all_previous) > 0:
            stacked = torch.stack(all_previous, dim=2)  # [B, H, n_layers, D]
            cross_layer_attn = self.cross_attention(current_output, stacked)
            return current_output + cross_layer_attn
        
        return current_output

这样做的好处是:

  • 改善梯度传播:梯度可以直接从深层回传到任意浅层,不再需要穿越90+个雅可比矩阵连乘
  • 缓解信息瓶颈:历史信息不再被逐层压缩,而是以"记忆库"形式存在
  • 提升训练稳定性:AttnRes相当于在深层网络中引入了多个"快捷通道"

根据月之暗面技术报告,AttnRes使Kimi K3的训练效率相比K2提升约25%,且在深层(60+层)的loss下降速度显著快于传统架构。

五、Stable LatentMoE:极端稀疏架构的工程实践

5.1 MoE的基本原理

Mixture of Experts(混合专家)是一种条件计算范式:不是所有参数都参与每个token的处理,而是根据输入动态选择"专家"(通常是FFN层)来处理。

标准Dense模型:  每个token经过所有参数计算
MoE模型:        每个token只经过选中的少数专家计算

以Kimi K3为例:

  • 总共896个专家(Expert)
  • 每个token只激活其中的16个
  • 激活比例 = 16/896 ≈ 1.8%

这意味着:2.88T参数中,实际参与每次推理的只有约1040亿参数,算力消耗与一个104B的Dense模型相当,但模型容量却是2.88T。

5.2 稀疏MoE的训练稳定性挑战

然而,896专家仅激活16个的极端稀疏度带来了严重的训练不稳定问题:

  1. 负载不均衡:随机初始化下,某些专家会被频繁选中,某些专家几乎不被选中("专家坍塌")
  2. 梯度冲突:被频繁选中的专家梯度更新快,未被选中的专家梯度几乎为零
  3. 通信瓶颈:专家并行(Expert Parallelism)需要All-to-All通信,稀疏度越高,通信模式越不规则

5.3 Stable LatentMoE的三项关键改进

月之暗面提出了Stable LatentMoE框架,通过三项关键改进解决了这些问题:

改进1:归一化LatentMoE(Normalized LatentMoE)

在专家聚合后加入 RMSNorm,抑制激活值爆炸:

class StableLatentMoE(nn.Module):
    def __init__(self, num_experts=896, top_k=16):
        self.experts = nn.ModuleList([FeedForward() for _ in range(num_experts)])
        self.gate = TopKRouter(top_k=top_k)
        self.norm = RMSNorm()  # ← 关键
    
    def forward(self, x):
        # 路由选择
        weights, indices = self.gate(x)  # weights: [B, top_k], indices: [B, top_k]
        
        # 专家计算
        expert_outputs = [self.experts[idx](x) for idx in indices.t()]
        
        # 加权聚合 + RMSNorm
        stacked = torch.stack(expert_outputs, dim=0)  # [top_k, B, D]
        weighted = (stacked * weights.unsqueeze(-1)).sum(dim=0)
        
        return self.norm(weighted)  # ← 抑制激活值爆炸

改进2:SiLU-Gated Linear Unit(SiTU-GLU)

使用Swish激活函数(SiLU)改造门控线性单元,提升门控信号的表达能力:

class SiTU_GLU(nn.Module):
    def forward(self, x):
        # 标准GLU: gate = sigmoid(Wg·x), output = W·x * gate
        # SiTU-GLU: gate = silu(Wg·x), output = W·x * silu(Wg·x)
        return self.up_proj(x) * silu(self.gate_proj(x))

SiLU相比Sigmoid的优势:SiLU(x) = x · sigmoid(x),其导数在x接近0时更大,有助于门控信号的快速调整。

改进3:Quantile Balancing(分位数均衡)

通过监控每个专家的激活频率,当发现某些专家的激活频率偏离中位数过大时,强制对其进行热启动(增加选中概率):

class QuantileBalancer:
    def __init__(self, num_experts, target_quantile=0.5):
        self.num_experts = num_experts
        self.target_quantile = target_quantile
        self.usage_counts = torch.zeros(num_experts)
    
    def adjust_routing(self, router_logits):
        """
        router_logits: [B, num_experts]
        返回调整后的路由分数
        """
        # 计算当前分位数
        usage_percentiles = self.usage_counts / self.usage_counts.sum()
        
        # 惩罚过载专家,奖励空闲专家
        adjustment = torch.where(
            usage_percentiles > self.target_quantile,
            -self.penalty_weight * (usage_percentiles - self.target_quantile),
            self.reward_weight * (self.target_quantile - usage_percentiles)
        )
        
        return router_logits + adjustment
    
    def update_usage(self, indices):
        # indices: [B, top_k],被选中的专家索引
        for idx in indices.flatten():
            self.usage_counts[idx.item()] += 1

5.4 MoonEP:超大规模MoE的高性能通信库

Kimi K3的896专家不可能全部放在同一台机器上,必须进行专家并行(Expert Parallelism)。这需要频繁的All-to-All通信:当一个token需要激活专家A(可能在GPU 1)和专家B(可能在GPU 8)时,必须先分发token到各GPU,再聚合各专家的输出。

MoonEP是月之暗面为超大稀疏MoE打造的高性能通信库,其核心设计:

  1. 细粒度流水线:将All-to-All通信与计算重叠,避免GPU空转
  2. 拓扑感知路由:利用NVLink的物理拓扑,选择最优通信路径
  3. 动态负载均衡:当某些GPU上的专家过载时,自动将流量重定向到空闲GPU
传统All-to-All(假设8 GPU):
  GPU0 → GPU1, GPU2, ..., GPU7
  GPU1 → GPU0, GPU2, ..., GPU7
  ...(全部并行,但无法处理不均衡)

MoonEP优化后:
  阶段1:先在节点内完成局部All-to-All
  阶段2:节点间通过NVLink全速通信
  阶段3:根据实时负载动态调整路由

六、MoonViT-V2:原生多模态的视觉编码器

Kimi K3的另一项重要能力是原生多模态——不是通过嫁接的视觉模块实现,而是从头训练了一个专门的视觉编码器 MoonViT-V2

6.1 从头训练的视觉编码器

传统多模态模型的视觉编码器通常基于以下范式之一:

  • 对比学习预训练(CLIP系列):图文配对训练,视觉和文本分别编码后对齐
  • 检测+描述:使用检测模型识别物体,再生成描述

MoonViT-V2采用了一种新范式:Next-Token Prediction(下一个token预测)——和语言模型一样的训练目标,从零开始预测下一个视觉token。

class MoonViT_V2(nn.Module):
    """
    与语言模型统一的视觉编码器
    训练目标:预测下一个视觉token
    """
    def __init__(self, image_size=448, patch_size=14, vocab_size=8192):
        self.patch_embed = PatchEmbed(patch_size=patch_size)
        self.blocks = nn.ModuleList([ViTBlock() for _ in range(24)])
        self.lm_head = nn.Linear(hidden_dim, vocab_size)  # 视觉词汇表
    
    def forward(self, images):
        x = self.patch_embed(images)  # [B, num_patches, hidden]
        
        for block in self.blocks:
            x = block(x)
        
        # 预测下一个token的概率分布
        logits = self.lm_head(x)
        return logits  # 用于NTP训练

这种设计的优势:

  1. 优化目标一致:视觉编码器和语言模型都用NTP训练,收敛行为更一致
  2. 无需对比预训练:不需要大规模的图文配对数据集
  3. 更稳定的训练:避免了CLIP中常见的模式崩塌(mode collapse)问题

6.2 高分辨率图像处理

MoonViT-V2原生支持 448×448 输入分辨率(配合14×14的patch size,共1024个patch)。对于更高分辨率的图像,采用动态分块策略

def encode_high_res_image(image, max_patches=4096):
    """
    处理高分辨率图像(如PDF截图、架构图等)
    自动将图像分割为多个448×448块
    """
    h, w = image.shape[:2]
    
    # 计算需要的块数(不超过max_patches)
    blocks_per_row = min(w // 448, int(sqrt(max_patches * w / h)))
    blocks_per_col = min(h // 448, max_patches // blocks_per_row)
    
    patches = []
    positions = []  # 记录每个块的位置信息
    
    for i in range(blocks_per_col):
        for j in range(blocks_per_row):
            patch = image[i*448:(i+1)*448, j*448:(j+1)*448]
            patch_embedding = moonvit.encode(patch)
            patches.append(patch_embedding)
            positions.append([i, j, blocks_per_row, blocks_per_col])  # 位置编码
    
    # 全局注意力融合所有块
    return global_attention(torch.stack(patches), positions)

七、后训练:强化学习的三大领域

Kimi K3的后训练(Post-training)采用多推理级别强化学习(Multi-Level RL),在三大领域进行了大规模任务合成:

7.1 通用推理(General Reasoning)

涵盖数学、逻辑、常识等开放域推理任务,使用GRPO(Group Relative Policy Optimization)算法优化策略。

7.2 通用Agent(General Agent)

在AgentENV环境中训练模型的多步规划、工具使用能力。这是月之暗面开源的第三个Infra组件——一个用于分布式运行Agent环境的平台。

# AgentENV 环境交互示例
class AgentENV:
    def __init__(self, model):
        self.model = model
        self.tools = [
            browse_web,
            read_file,
            write_file,
            execute_bash
        ]
    
    def run_task(self, task_description):
        observation = "初始化环境"
        trajectory = []
        
        for step in range(max_steps):
            # 模型思考下一步
            thought = self.model.think(
                f"任务: {task_description}\n当前: {observation}",
                reasoning_level="deep"
            )
            
            # 执行动作
            if thought.action == "browse":
                result = self.tools["browse_web"](thought.url)
            elif thought.action == "read":
                result = self.tools["read_file"](thought.path)
            # ... 其他工具
            
            trajectory.append({
                "thought": thought,
                "observation": result
            })
            
            if thought.is_terminal:
                break
        
        return trajectory

7.3 编程Agent(Coding Agent)

针对代码生成、代码修复、代码审查等任务,专门训练了模型的长程推理和上下文保持能力。

Kimi K3在 Frontend Code Arena 基准测试中以 1679分 超越Claude Fable 5(1631分)和GPT-5.6 Sol(1618分),登顶全球第一。这是开源模型首次在编程专项评测中超越闭源顶级模型。

八、工程极限分析:2.8T参数的显存墙与通信墙

8.1 推理时的显存墙

即使采用FP8量化,2.8T参数也需要约 2.8TB 的显存来存放模型权重:

模型权重(FP8):
  2.88T 参数 × 1 byte/参数 = 2.88 TB

KV Cache(100万上下文,单精度FP16):
  2 × 序列长度 × 层数 × 注意力头 × 头维度 × batch_size
  = 2 × 1M × 93 × 96 × 64 × 1
  ≈ 1.14 TB

总计(单请求,无批量):
  ≈ 4 TB 显存需求

这远超单卡(A100 80GB / H100 80GB / H20 80GB)的容量上限。实际推理必须依赖:

  • 张量并行(Tensor Parallelism):将模型权重按维度切分到多卡
  • 流水线并行(Pipeline Parallelism):将不同层分配到不同节点
  • 专家并行(Expert Parallelism):将专家分布到多GPU/NUMA节点

8.2 训练时的通信瓶颈

MoE架构的专家并行需要在每次前向传播中进行两次All-to-All通信

前向传播:
  Token分发 → 专家计算 → Token聚合
  ↑_________ All-to-All #1
                        ↑_________ All-to-All #2

反向传播:
  梯度分发 → 专家梯度计算 → 梯度聚合
  ↑_________ All-to-All #3
                        ↑_________ All-to-All #4

896专家、16激活的极端稀疏性使得通信模式极其不规则——每个token只和1.8%的专家通信,但必须和所有GPU协调路由决策。

MoonEP通过以下策略优化:

class MoonEPLib:
    def alltoall_optimized(self, send_buf, recv_buf, expert_mapping):
        # 1. 按目标GPU分组
        batches = self.group_by_destination(expert_mapping)
        
        # 2. 节点内通信(高带宽NVLink)
        for node in self.nodes:
            local_batch = [t for t in batches if t.dst_gpu in node]
            self.nvlink_alltoall(send_buf, recv_buf, local_batch)
        
        # 3. 节点间通信(IB/RoCE)
        remote_batch = [t for t in batches if t.dst_gpu not in current_node]
        self.network_alltoall(send_buf, recv_buf, remote_batch)

九、本地部署实践:从HuggingFace到Ollama

9.1 获取模型权重

Kimi K3已发布至Hugging Face:

HuggingFace: https://huggingface.co/MoonshotAI/Kimi-K3
GitHub: https://github.com/MoonshotAI/kimi-k3

模型权重采用 Kimi K3 License(Modified MIT),允许商业使用,但需遵守以下限制:

  • 禁止用于违法内容生成
  • 禁止用于生物武器/化学武器开发
  • 禁止用于大规模监控

9.2 Ollama本地运行(需要多GPU)

由于2.8T参数的规模限制,Kimi K3无法在单卡上运行。最低配置建议:

推荐配置:
  - 8 × H100/H20 (80GB) 或等效显存
  - 512GB+ 系统内存
  - NVLink互联

Ollama部署步骤:
  # 1. 安装Ollama
  curl -fsSL https://ollama.com/install.sh | sh
  
  # 2. 配置多GPU张量并行
  OLLAMA.tensor_parallel=8 ollama serve &
  
  # 3. 拉取模型(需要HuggingFace账号授权)
  ollama pull moonshotai/kimi-k3
  
  # 4. 运行
  ollama run moonshotai/kimi-k3

9.3 API调用示例

import openai

client = openai.OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # Ollama不需要真实API Key
)

response = client.chat.completions.create(
    model="moonshotai/kimi-k3",
    messages=[
        {"role": "system", "content": "你是一位资深的Go语言工程师。"},
        {"role": "user", "content": "解释一下Go 1.24的泛型改进有哪些?"}
    ],
    temperature=0.7,
    max_tokens=4096
)

print(response.choices[0].message.content)

9.4 vLLM高性能推理

对于需要更高吞吐量的场景,建议使用 vLLM

# vLLM部署脚本
from vllm import LLM, SamplingParams

llm = LLM(
    model="MoonshotAI/Kimi-K3",
    tensor_parallel_size=8,  # 8卡并行
    trust_remote_code=True,
    dtype="float16",
    max_model_len=1000000   # 100万上下文
)

sampling_params = SamplingParams(
    temperature=0.7,
    max_tokens=4096,
    stop=["<stop>"]
)

outputs = llm.generate([
    "写一个Go语言的HTTP服务器",
    "用Rust实现一个简洁的二叉树",
    "解释Kubernetes的Pod调度机制"
], sampling_params)

for output in outputs:
    print(f"Prompt: {output.prompt}\nCompletion: {output.outputs[0].text}\n")

十、性能基准与竞品对比

10.1 核心基准测试结果

基准测试Kimi K3Claude Fable 5GPT-5.6 SolDeepSeek V4-Pro
MMLU92.493.192.889.5
HumanEval96.294.895.188.3
MATH88.791.290.582.1
Frontend Code Arena1679163116181420
长上下文(100K)98.3%97.1%96.8%91.2%

10.2 成本效率分析

指标Kimi K3GPT-5.6 SolClaude Fable 5
BrowseComp单次成本$0.52$1.04$5.87
相对成本11.3×
100万上下文支持
开源权重

Kimi K3在保持第一梯队性能的同时,BrowseComp基准单次任务成本仅为GPT-5.6 Sol的一半,Claude Fable 5的约九分之一。

十一、总结与展望

Kimi K3的意义远不止于刷新参数规模纪录。它的三项核心创新为未来大模型架构指明了方向:

  1. KDA混合线性注意力:首次在生产级模型中实现了O(n)长上下文建模,为百万级上下文提供了工程可行的解决方案
  2. Attention Residuals:打破了深层Transformer的信息瓶颈,使得90+层的大模型训练更加稳定
  3. Stable LatentMoE:证明了896专家/16激活的极端稀疏性是可以稳定训练的,为未来更大规模MoE模型奠定了工程基础

更值得关注的是,月之暗面选择同步开源Infra层(MoonEP、FlashKDA、AgentENV),而非仅开源模型权重。这相当于不仅给了你鱼,还给了你渔网——整个开源社区都可以基于这些基础设施构建自己的大模型训练和推理系统。

2026年7月27日之后,开源AI的天花板已经变成了另一个故事。而这个故事的主角,是中国团队写的。


Tags: Kimi K3 | Moonshot AI | MoE | 大模型 | 开源 | KDA | Attention Residuals | Stable LatentMoE | MoonViT | AI Agent | 深度学习 | 编程Agent

Keywords: Kimi K3 | Moonshot AI | 开源大模型 | MoE架构 | 混合专家 | 线性注意力 | 长上下文 | 100万token | 本地部署 | Ollama | vLLM | AgentENV | FlashKDA | MoonEP | 多模态 | 视觉编码器

推荐文章

JavaScript设计模式:组合模式
2024-11-18 11:14:46 +0800 CST
Vue3中的事件处理方式有何变化?
2024-11-17 17:10:29 +0800 CST
html折叠登陆表单
2024-11-18 19:51:14 +0800 CST
免费常用API接口分享
2024-11-19 09:25:07 +0800 CST
Golang Select 的使用及基本实现
2024-11-18 13:48:21 +0800 CST
批量导入scv数据库
2024-11-17 05:07:51 +0800 CST
Vue3中的Store模式有哪些改进?
2024-11-18 11:47:53 +0800 CST
mendeley2 一个Python管理文献的库
2024-11-19 02:56:20 +0800 CST
程序员茄子在线接单