Posts

计算量的另一维度的稀疏化 MoE在"宽度"维度上实现了稀疏激活——不同token使用不同的专家。而Mixture-of-Depth（MoD）在"深度"维度上实现稀疏化——不同token经过不同数量的Transformer层。 这个想法直指一个核心观察：不是所有token都需要同等深度的计算。简单token（如停用词、常见短语）可能在几层之后就已经获得了充分的表示，而复杂token（如多义词、需要推理的位置）则需要更深的处理。 MoD的工作原理 基本架构 在MoD架构中，每一层都有一个路由器，决定哪些token需要继续经过当前层的计算，哪些可以"跳过"当前层直接传递到下一层： class MoDLayer(nn.Module): def __init__(self, d_model, n_heads, d_ff, capacity_ratio=0.5): super().__init__() self.router = nn.Linear(d_model, 1) # 输出一个标量路由分数 self.self_attn = MultiHeadAttention(d_model, n_heads) self.ffn = FFN(d_model, d_ff) self.norm1 = nn.RMSNorm(d_model) self.norm2 = nn.RMSNorm(d_model) self.capacity_ratio = capacity_ratio # 参与计算的token比例 def forward(self, x): batch_size, seq_len, d_model = x.shape # 路由决策 router_scores = self.router(x).squeeze(-1) # [batch, seq_len] n_process = int(seq_len * self.capacity_ratio) # 选择top-k个token参与计算 _, process_indices = torch.topk(router_scores, n_process, dim=-1) process_mask = torch.zeros_like(router_scores, dtype=torch.bool) process_mask.scatter_(1, process_indices, True) # 只有被选中的token经过注意力计算 processed = x.clone() if process_mask.any(): selected = x[process_mask].unsqueeze(0) attn_out = self.self_attn(self.norm1(selected)) ffn_out = self.ffn(self.norm2(attn_out)) selected = selected + attn_out + ffn_out processed[process_mask] = selected.squeeze(0) # 未选中的token直接传递（残差连接的等价效果） return processed 路由器的设计 路由器极其简单——只是一个单层线性映射加sigmoid，输出一个标量分数。这个分数表示"这个token需要当前层处理的程度"。 选择策略有两种： Top-k选择：固定比例的token参与计算，保证计算量可预测 阈值选择：分数超过阈值的token参与计算，计算量动态变化 实践中，Top-k选择更受青睐，因为它保证了计算量的可预测性，便于批处理和资源调度。 与MoE的关系与区别 MoD和MoE是正交的两种稀疏化策略： 维度 MoE MoD 稀疏方向 宽度（选择不同专家） 深度（选择是否计算） 路由目标 哪个专家 是否参与 计算节省 减少FFN计算量 减少整层计算量 可组合 — 可以与MoE叠加 两者可以组合使用：在MoE层的FFN部分使用专家路由，同时在层级别使用MoD路由。这种"双重稀疏"可以进一步降低计算量。 ...

引言 嵌入模型是RAG系统、语义搜索和推荐系统的基石。虽然不如生成模型那样引人注目，但嵌入模型的质量直接决定了上游应用的效果上限。2026年，嵌入模型在多语言、长文本和领域特化方面取得了显著进步。本文将为你提供全面的选型指南。 为什么嵌入模型很重要 嵌入模型将文本转化为高维向量，使得语义相似的文本在向量空间中距离更近。这个看似简单的操作是以下应用的核心： RAG系统：通过向量检索找到相关文档 语义搜索：理解用户查询的真实意图 推荐系统：基于内容相似度推荐 聚类分析：发现文本集合中的主题结构 去重与匹配：识别语义重复内容 嵌入模型的质量提升10%，可能带来RAG系统端到端效果提升20-30%。 主流嵌入模型 商业API OpenAI text-embedding-4-large — 3072维，综合最强 Voyage AI voyage-3 — 2048维，检索特化 Cohere Embed v4 — 1536维，多语言强 Google text-gecko-3 — 768维，速度快 开源模型 BGE-large-zh-v2 (智源) — 1024维，中文最强 E5-mistral-7b (微软) — 4096维，英文最强 GTE-large-zh (阿里) — 1024维，中文优秀 Jina embeddings v3 (Jina AI) — 1024维，长文本强 Nomic embed v2 (Nomic) — 768维，开源可复现 BGE-M3 (智源) — 1024维，多语言+多功能 核心基准对比 MTEB 2026 MTEB（Massive Text Embedding Benchmark）是最权威的嵌入模型评估基准： 英文检索 模型 维度 得分 特点 voyage-3 2048 72.8 检索之王 text-embedding-4-large 3072 71.5 综合最佳 E5-mistral-7b 4096 70.3 开源英文最佳 Cohere Embed v4 1536 69.7 多语言均衡 Jina embeddings v3 1024 68.5 长文本强 Nomic embed v2 768 66.2 轻量高效 中文检索 模型 维度 得分 特点 BGE-large-zh-v2 1024 74.5 中文之王 GTE-large-zh 1024 72.8 中文优秀 BGE-M3 1024 71.3 多语言兼中文 text-embedding-4-large 3072 70.2 商业中文最佳 Cohere Embed v4 1536 68.7 长文本检索 在处理长文档（>8K tokens）的检索任务上： ...

引言 AI辅助编程在2026年已经成为开发者的日常。从代码补全到Bug修复，从单元测试到架构设计，代码模型的能力边界不断扩展。本文将对当前主流代码模型进行全面对比，帮你找到最适合的AI编程伙伴。 参评模型 通用模型的代码能力 GPT-5 (OpenAI) — 代码综合能力最强 Claude 4 Opus (Anthropic) — 代码重构和审查最佳 Gemini 2.5 Ultra (Google) — 多语言覆盖广 DeepSeek-V4 (深度求索) — 开源代码之王 GLM-5 (智谱AI) — 中文编程文档强 代码专用模型 Codex 3 (OpenAI) — 专用代码模型 CodeLlama 4 (Meta) — 开源代码专用 DeepSeek-Coder V3 (深度求索) — 开源代码专用 StarCoder 3 (BigCode) — 开源多语言代码 Qwen 3 Coder (阿里) — 中文代码专用 核心基准对比 HumanEval 2026 HumanEval是最经典的代码生成基准，测试Python函数生成： 模型 pass@1 pass@10 语言 GPT-5 94.2% 98.7% 多语言 Codex 3 92.8% 97.3% 多语言 Claude 4 Opus 91.5% 96.8% 多语言 DeepSeek-Coder V3 89.3% 95.2% 多语言 Gemini 2.5 Ultra 88.7% 94.5% 多语言 Qwen 3 Coder 87.1% 93.8% 多语言 CodeLlama 4 82.5% 90.3% 多语言 StarCoder 3 80.2% 88.7% 多语言 GLM-5 86.5% 93.2% 多语言 SWE-Bench Verified SWE-Bench测试解决真实GitHub issue的能力： ...

自回归生成的根本瓶颈 LLM的自回归生成是一个严格串行的过程——每个token依赖前一个token的输出。在A100 GPU上，生成一个token的延迟约为15-30ms，其中计算只占一小部分，大部分时间花在权重加载上。这就是内存带宽限制：每生成一个token都要将整个模型权重从HBM读到计算单元，但只产生一个token的输出。 推测解码（Speculative Decoding）通过打破这一串行约束，实现了2-3倍的推理加速。 核心思想：Draft-Verify范式 推测解码的核心思想异常简洁： Draft阶段：用一个小而快的Draft模型快速生成一段候选序列 Verify阶段：用大模型一次性并行验证这整段候选序列 接受/拒绝：根据大模型的概率分布决定接受多少个候选token 关键洞察在于：大模型并行处理N个token的速度（一次前向传播）远快于串行生成N个token（N次前向传播）。即使候选序列有部分错误，只要平均接受率足够高，就能获得净加速。 数学基础：拒绝采样 推测解码使用拒绝采样确保输出分布与纯大模型生成完全一致。给定Draft模型的概率 q(x) 和大模型的概率 p(x)： 接受概率 = min(1, p(x) / q(x)) 如果 p(x) ≥ q(x)：总是接受（Draft模型低估了这个token的概率） 如果 p(x) < q(x)：以 p(x)/q(x) 的概率接受，否则拒绝并从调整后的分布中重新采样 def speculative_decoding_step(draft_model, target_model, prefix, n_draft=4): # 1. Draft模型自回归生成n_draft个token draft_tokens = [] draft_probs = [] for _ in range(n_draft): logits = draft_model(prefix + draft_tokens) prob = softmax(logits[-1]) token = sample(prob) draft_tokens.append(token) draft_probs.append(prob[token]) # 2. 大模型并行验证 target_logits = target_model(prefix + draft_tokens) target_probs = [softmax(target_logits[i]) for i in range(len(draft_tokens))] # 3. 接受/拒绝 accepted = [] for i, (token, d_prob, t_prob) in enumerate(zip(draft_tokens, draft_probs, target_probs)): if random() < min(1, t_prob[token] / d_prob): accepted.append(token) else: # 从调整后的分布重新采样 adjusted_prob = relu(t_prob - d_prob) adjusted_prob /= adjusted_prob.sum() accepted.append(sample(adjusted_prob)) break # 一旦拒绝，后续候选全部丢弃 return accepted 这个算法保证了输出分布与纯大模型采样的分布完全一致——无损加速。 ...

注意力计算的性能瓶颈 标准注意力计算的核心瓶颈不在于计算量，而在于显存访问。注意力矩阵 QK^T 的形状为 [n, n]，对于 n=8192 的序列，仅这个矩阵就需要256MB显存（FP32）。GPU的计算速度远超显存带宽——A100的计算能力为312 TFLOPS，而HBM带宽仅2TB/s。 这就是经典的"内存墙"问题：注意力计算大部分时间不是在算，而是在等数据搬运。 Flash Attention V1：分块计算的突破 Tri Dao在2022年提出的Flash Attention V1核心思想是：通过分块计算避免实例化完整的注意力矩阵。 在线Softmax Flash Attention的关键创新是在线Softmax算法。标准Softmax需要先遍历一次数据求最大值，再遍历一次计算指数和归一化。在线Softmax通过维护一个运行最大值和运行和，在单次遍历中完成Softmax计算： def online_softmax(blocks): """在线Softmax：逐块更新""" m = float('-inf') # 运行最大值 l = 0.0 # 运行和 result = None for block in blocks: block_max = block.max() # 更新全局最大值 new_m = max(m, block_max) # 修正之前的累积值 alpha = math.exp(m - new_m) beta = math.exp(block_max - new_m) l = alpha * l + beta * block.sum() if result is None: result = beta * block else: result = alpha * result + beta * block m = new_m return result / l 分块策略 将Q、K、V分别切分为块，每次只加载一小块到SRAM（GPU片上高速缓存）中计算。外层循环遍历K/V块，内层循环遍历Q块： for each K_j, V_j block: load K_j, V_j to SRAM for each Q_i block: load Q_i to SRAM compute S = Q_i @ K_j^T update online softmax statistics compute partial O = P @ V_j write O_i back to HBM 这种策略使得HBM访问量从O(n²)降低到O(n²d/M)，其中M是SRAM大小。对于典型配置，这相当于减少了10-20倍的显存访问。 Flash Attention V2：效率的进一步提升 V2在V1基础上做了几个关键优化： 减少非矩阵乘法运算 GPU上矩阵乘法（GEMM）的效率远高于其他运算（如rescale、softmax）。V2重新组织了计算顺序，将rescale操作推迟到最后，减少了中间的rescale次数。 并行化改进 V1主要沿序列维度并行化，V2增加了批次和头维度的并行化，使得在长序列场景下能更好地利用GPU的并行能力。 前向和后向的分配优化 V2重新分配了前向和后向传播中的工作负载，减少了线程块之间的同步开销。 Flash Attention V3：FP8与异步流水线 2024年发布的Flash Attention V3针对H100 GPU的FP8张量核心和异步执行特性进行了深度优化。 ...

引言 视觉语言模型（VLM）在2026年取得了突破性进展。从简单的图像描述到复杂的视觉推理，从单图理解到视频时序分析，视觉模型的能力边界正在快速扩展。本文将从实际应用场景出发，提供系统化的视觉模型选型指南。 主流视觉模型概览 闭源商业模型 GPT-5 Vision (OpenAI) — 综合视觉能力最强 Claude 4 Vision (Anthropic) — 文档和图表理解最佳 Gemini 2.5 Ultra (Google) — 视频和多图理解领先 GPT-5o (OpenAI) — 实时视觉对话专用 开源模型 Qwen 3 VL 72B (阿里) — 开源视觉模型之王 InternVL 3 78B (上海AI Lab) — 中文视觉理解强 Llama 4 Vision 90B (Meta) — 英文视觉通用 GLM-5V 32B (智谱AI) — 中文OCR和文档理解优秀 核心能力对比 图像理解 (VQAv2) 模型 得分 特点 GPT-5 Vision 92.3% 综合最佳，细粒度理解强 Gemini 2.5 Ultra 91.1% 多图对比能力强 Claude 4 Vision 89.7% 文档和图表最佳 Qwen 3 VL 72B 87.5% 开源最佳 InternVL 3 78B 86.2% 中文视觉强 Llama 4 Vision 90B 84.8% 通用能力均衡 GLM-5V 32B 83.5% OCR能力突出 OCR与文档理解 在OCR-Bench和DocVQA上： ...

为什么KV Cache如此重要？ 在自回归生成中，每生成一个新token都需要计算它与之前所有token的注意力。如果不缓存，生成第N个token需要重新计算前N-1个token的K和V，复杂度为O(N²)。KV Cache将已计算的K/V存储起来，使每步生成只需O(N)的计算。 但缓存本身带来了巨大的显存压力。以Llama-3-70B为例，FP16精度下单个token的KV Cache占用约320KB。在32K上下文、batch_size=32的场景下，KV Cache总量达到约320GB——远超模型本身的140GB。 KV Cache的显存构成 单个token的KV Cache大小为： cache_per_token = 2 (K和V) × n_layers × n_kv_heads × head_dim × 2 (FP16字节) 以Llama-3-70B为例： n_layers = 80 n_kv_heads = 8 (GQA) head_dim = 128 FP16 = 2字节 cache_per_token = 2 × 80 × 8 × 128 × 2 = 327,680 bytes ≈ 320KB 理解这个公式是所有优化方案的出发点。 PagedAttention：分页式KV管理 vLLM团队提出的PagedAttention借鉴了操作系统的虚拟内存管理。核心思想： 块式管理 将KV Cache分为固定大小的块（Block），每个块存储若干token的KV。块不需要在物理上连续，通过块表（Block Table）映射逻辑位置到物理位置。 class PagedKVCache: def __init__(self, n_blocks, block_size, n_layers, n_kv_heads, head_dim): self.block_size = block_size # 每块的token数 self.n_blocks = n_blocks # 预分配所有块的存储 self.k_blocks = torch.zeros(n_blocks, n_layers, block_size, n_kv_heads, head_dim) self.v_blocks = torch.zeros(n_blocks, n_layers, block_size, n_kv_heads, head_dim) self.free_blocks = list(range(n_blocks)) self.block_tables = {} # seq_id -> [block_indices] def allocate(self, seq_id, n_tokens): n_blocks_needed = (n_tokens + self.block_size - 1) // self.block_size blocks = [] for _ in range(n_blocks_needed): if not self.free_blocks: raise OOMError("No free KV cache blocks") blocks.append(self.free_blocks.pop()) self.block_tables[seq_id] = blocks def append(self, seq_id, token_idx, k, v): block_idx = token_idx // self.block_size offset = token_idx % self.block_size physical_block = self.block_tables[seq_id][block_idx] self.k_blocks[physical_block, :, offset] = k self.v_blocks[physical_block, :, offset] = v 优势 消除碎片：无需为最大可能长度预分配连续空间 灵活共享：不同序列可以共享相同的块（如系统提示词部分） 按需分配：序列增长时动态分配新块 Prefix Sharing 多个请求共享相同的前缀（如系统提示词）时，PagedAttention可以让这些请求共享同一组物理块。这在对话AI场景中可节省30-50%的显存。 ...

引言 “用开源还是商业模型？“这是每个AI应用开发者在项目初期都会面临的核心决策。2026年，开源模型与商业模型之间的差距已经大幅缩小，但在某些关键维度上仍有显著差异。本文将提供一个系统化的决策框架，帮助你做出明智选择。 当前格局 商业模型第一梯队 GPT-5 (OpenAI) — 综合能力最强 Claude 4 Opus (Anthropic) — 推理和安全最佳 Gemini 2.5 Ultra (Google) — 多模态和长上下文领先 开源模型第一梯队 DeepSeek-V4 (671B MoE) — 综合能力最强的开源模型 GLM-5 (智谱AI) — 中文能力最佳 Llama 4 405B (Meta) — 生态最成熟 Qwen 3 235B (阿里) — 性价比最高 维度一：能力上限 综合智能 商业模型在综合智能上仍有一定优势。在MMLU-Pro上，GPT-5得分91.3%，而最好的开源模型DeepSeek-V4为85.8%，差距约5个百分点。但在具体任务上，这个差距可能更小。 复杂推理 在GPQA Diamond等高难度推理基准上，Claude 4 Opus的78.4%远超开源最佳的68.5%。对于需要深度科学推理的场景，商业模型仍有明显优势。 代码生成 SWE-Bench Verified上，GPT-5的71.2%对比DeepSeek-V4的58.9%，差距约12个百分点。复杂软件工程任务上商业模型领先较多。 多模态 Gemini 2.5 Ultra在多模态理解上遥遥领先，开源模型在这一领域仍有较大差距。 结论：如果你的任务需要顶级能力（复杂推理、高级编程、多模态理解），商业模型仍是首选。 维度二：成本 API调用成本 以处理100万token为例： 模型类型 输入成本 输出成本 GPT-5 $10 $40 Claude 4 Opus $15 $75 Gemini 2.5 Ultra $7 $21 DeepSeek-V4 (API) $0.27 $1.1 GLM-5 (API) $0.5 $2.0 开源模型的API价格通常是商业模型的1/10到1/50。 ...

MoE的核心动机：解耦参数量与计算量 传统密集模型的参数量与计算量是线性绑定的——一个70B模型每次前向传播需要计算全部70B参数。MoE（Mixture of Experts）打破了这一绑定：通过路由机制只激活部分专家，使得总参数量可以远大于单次计算量。 DeepSeek-V3以671B总参数量实现了仅37B的激活计算量，在保持顶级性能的同时将推理成本降低了5-10倍。这是MoE在2026年成为超大模型首选架构的直接原因。 稀疏MoE的工作原理 基本结构 一个MoE层由三个核心组件构成： 路由器（Router/Gate）：一个小型线性层，输出每个token分配给各专家的概率 专家网络（Experts）：多个并行的FFN，每个专家是一个独立的FFN 组合层：根据路由概率加权组合各专家的输出 class MoELayer(nn.Module): def __init__(self, d_model, d_ff, n_experts, top_k=2): super().__init__() self.router = nn.Linear(d_model, n_experts, bias=False) self.experts = nn.ModuleList([ FFN(d_model, d_ff) for _ in range(n_experts) ]) self.top_k = top_k def forward(self, x): batch_size, seq_len, d_model = x.shape x_flat = x.view(-1, d_model) # 路由 router_logits = self.router(x_flat) # [N, n_experts] router_probs = F.softmax(router_logits, dim=-1) # Top-K选择 topk_probs, topk_indices = torch.topk(router_probs, self.top_k, dim=-1) topk_probs = topk_probs / topk_probs.sum(dim=-1, keepdim=True) # 分发到专家 output = torch.zeros_like(x_flat) for i in range(self.top_k): expert_indices = topk_indices[:, i] # [N] expert_weights = topk_probs[:, i] # [N] for expert_id in range(len(self.experts)): mask = (expert_indices == expert_id) if mask.any(): expert_input = x_flat[mask] expert_output = self.experts[expert_id](expert_input) output[mask] += expert_weights[mask].unsqueeze(-1) * expert_output return output.view(batch_size, seq_len, d_model) Top-K路由 每个token只被路由到K个专家（通常K=1或2）。这实现了计算量的稀疏化——在N=256个专家的情况下，每次只激活约0.8%的参数。 负载均衡：MoE的关键难题 如果不加约束，路由器会倾向于将大部分token分配给少数"优秀"专家，导致其他专家得不到训练。这就是负载不均衡问题。 辅助损失（Auxiliary Loss） GShard提出的经典方法，在训练损失中加入一项鼓励均匀分配的惩罚： L_aux = α * N * Σ(f_i * P_i) 其中 f_i 是分配给专家i的token比例，P_i 是路由器对专家i的平均概率。当分配均匀时 L_aux 最小。 ...

引言 在大模型参数规模动辄千亿的时代，7B级别的小模型正在证明一个事实：大不是唯一解。2026年，7B级模型的能力已经达到了两年前70B模型的水平，成为边缘部署、本地推理和成本敏感场景的首选。本文将对当前主流的7B级模型进行全面横评。 参评模型 Llama 4 8B (Meta) — 2026年3月 Qwen 3 7B (阿里通义) — 2026年4月 GLM-5 Air 6B (智谱AI) — 2026年6月 Mistral 7B v0.4 (Mistral AI) — 2026年2月 DeepSeek 7B v3 (深度求索) — 2026年5月 Gemma 3 7B (Google) — 2026年3月 Phi-4 7B (微软) — 2026年1月 基础能力对比 MMLU-Pro 模型 得分 优势领域 Qwen 3 7B 72.3% 工程、数学 Llama 4 8B 70.8% 人文、社科 GLM-5 Air 6B 69.5% 中文、法律 Phi-4 7B 68.1% 数学、逻辑 DeepSeek 7B v3 67.7% 代码、推理 Mistral 7B v0.4 65.2% 欧洲语言 Gemma 3 7B 64.8% 通用知识 Qwen 3 7B在小模型中领先，已经达到了2024年Llama 3 70B的水平。 ...