技术原理

一次影响存储芯片股价的模型架构升级 9月第一周，DeepSeek扔出两颗炸弹：一颗技术，一颗资本。 技术侧：新模型结构把KV Cache大幅压缩，直接改写了推理侧的硬件需求曲线； 资本侧：9月9日正式委托中信证券筹备科创板IPO，进入尽职调查阶段，首轮融资510亿元。 两件事看似独立，实则是同一套叙事的两面——DeepSeek要证明自己不仅是"便宜的模型"，而是"重新定义推理经济学的公司"。 KV Cache压缩：到底压缩了什么 要理解这次升级的冲击力，先得搞清楚KV Cache在推理时的角色。 一、推理成本的大头在哪 大模型推理时，每生成一个Token都要重新计算注意力。为了不重复计算历史Token，系统会把Key和Value缓存下来——这就是KV Cache。 在长上下文和Agent场景下： 一次对话可能缓存数万到数十万Token的KV 这些缓存必须放在**HBM（高带宽内存）**里，否则速度崩盘 Agent多轮工具调用时，同一份上下文被反复使用，缓存命中费用占单次调用成本的大头 二、DeepSeek的压缩倍率 新结构把KV Cache压缩到原来的1/4，带来连锁效应： HBM需求：降至原来的 1/4 SSD/外存分层需求：降至原来的 1/8 这意味着同样的算力集群，能服务的并发请求数直接翻了几倍。对Agent这种"长会话+高频调用"的场景，单次使用成本会出现量级下降。 三、为什么SK海力士跌了3% 消息传出当天，SK海力士股价跌超3%。逻辑很直接： HBM是SK海力士、三星、美光三家的核心利润来源 DeepSeek如果把"KV Cache压缩1/4"做成行业标准结构，下游客户对HBM的采购预期会下调 这不是一次性冲击，而是对未来2-3年HBM需求曲线的重新定价 科创板IPO：510亿首轮融资的底气 技术故事讲完，资本故事接棒。 一、为什么是科创板 科创板对"硬科技"公司的估值逻辑更友好，不要求短期盈利 国产大模型公司在国内资本市场有政策溢价 上市后可以用股票做股权激励，留住核心人才 二、510亿首轮融资意味着什么 这个数字对应的估值预期，已经把DeepSeek放到了"中国AI基础设施级公司"的位置。市场在赌两件事： 推理成本继续下探——每降低一个数量级，能打开的企业级市场就翻一倍 国产替代叙事——在海外芯片受限的背景下，DeepSeek的模型效率本身就是战略资产 对产业链的连锁影响 一、HBM/存储厂商 短期股价承压，但中长期看，模型推理总调用量在指数级增长，压缩后的KV Cache只是单位成本下降，总需求未必萎缩 关注三星、美光是否会跟进类似压缩结构，还是押注更大容量HBM3E/HBM4 二、云厂商和推理服务商 同样的GPU，能跑更多并发——毛利率会改善 但定价权会向下游转移：企业客户会要求按"压缩后成本"重新谈判合同 三、Agent开发者 这是最直接的受益者。长会话、多轮工具调用的成本会大幅下降 过去因为成本问题不敢做的"24小时挂机Agent"，现在经济账算得过来了 对开发者的实操建议 重新评估你的推理成本模型——如果你用DeepSeek API做Agent，等新结构上线后重跑一次成本测算 关注KV Cache命中率——Agent场景下，缓存命中率每提升10%，成本下降可能超过30% 不要把架构绑死在单一模型上——DeepSeek这次升级说明，推理侧的技术迭代速度比预训练还快 科创板IPO后关注生态开放——上市后通常会加大开发者生态投入，早期接入有红利 结语 DeepSeek这次"技术+资本"双响炮，本质上是在回答一个问题：大模型公司的护城河到底是什么？ 不是参数规模，不是跑分，而是单位智能的成本。当KV Cache压缩到1/4、HBM需求降到1/4，DeepSeek证明了自己能在推理侧持续制造结构性成本优势。 科创板IPO只是开始——真正的战场，是把这套成本优势变成企业级市场的定价权。

一次影响存储芯片股价的模型架构升级 9月第一周，DeepSeek扔出两颗炸弹：一颗技术，一颗资本。 技术侧：新模型结构把KV Cache大幅压缩，直接改写了推理侧的硬件需求曲线； 资本侧：9月9日正式委托中信证券筹备科创板IPO，进入尽职调查阶段，首轮融资510亿元。 两件事看似独立，实则是同一套叙事的两面——DeepSeek要证明自己不仅是"便宜的模型"，而是"重新定义推理经济学的公司"。 KV Cache压缩：到底压缩了什么 要理解这次升级的冲击力，先得搞清楚KV Cache在推理时的角色。 一、推理成本的大头在哪 大模型推理时，每生成一个Token都要重新计算注意力。为了不重复计算历史Token，系统会把Key和Value缓存下来——这就是KV Cache。 在长上下文和Agent场景下： 一次对话可能缓存数万到数十万Token的KV 这些缓存必须放在**HBM（高带宽内存）**里，否则速度崩盘 Agent多轮工具调用时，同一份上下文被反复使用，缓存命中费用占单次调用成本的大头 二、DeepSeek的压缩倍率 新结构把KV Cache压缩到原来的1/4，带来连锁效应： HBM需求：降至原来的 1/4 SSD/外存分层需求：降至原来的 1/8 这意味着同样的算力集群，能服务的并发请求数直接翻了几倍。对Agent这种"长会话+高频调用"的场景，单次使用成本会出现量级下降。 三、为什么SK海力士跌了3% 消息传出当天，SK海力士股价跌超3%。逻辑很直接： HBM是SK海力士、三星、美光三家的核心利润来源 DeepSeek如果把"KV Cache压缩1/4"做成行业标准结构，下游客户对HBM的采购预期会下调 这不是一次性冲击，而是对未来2-3年HBM需求曲线的重新定价 科创板IPO：510亿首轮融资的底气 技术故事讲完，资本故事接棒。 一、为什么是科创板 科创板对"硬科技"公司的估值逻辑更友好，不要求短期盈利 国产大模型公司在国内资本市场有政策溢价 上市后可以用股票做股权激励，留住核心人才 二、510亿首轮融资意味着什么 这个数字对应的估值预期，已经把DeepSeek放到了"中国AI基础设施级公司"的位置。市场在赌两件事： 推理成本继续下探——每降低一个数量级，能打开的企业级市场就翻一倍 国产替代叙事——在海外芯片受限的背景下，DeepSeek的模型效率本身就是战略资产 对产业链的连锁影响 一、HBM/存储厂商 短期股价承压，但中长期看，模型推理总调用量在指数级增长，压缩后的KV Cache只是单位成本下降，总需求未必萎缩 关注三星、美光是否会跟进类似压缩结构，还是押注更大容量HBM3E/HBM4 二、云厂商和推理服务商 同样的GPU，能跑更多并发——毛利率会改善 但定价权会向下游转移：企业客户会要求按"压缩后成本"重新谈判合同 三、Agent开发者 这是最直接的受益者。长会话、多轮工具调用的成本会大幅下降 过去因为成本问题不敢做的"24小时挂机Agent"，现在经济账算得过来了 对开发者的实操建议 重新评估你的推理成本模型——如果你用DeepSeek API做Agent，等新结构上线后重跑一次成本测算 关注KV Cache命中率——Agent场景下，缓存命中率每提升10%，成本下降可能超过30% 不要把架构绑死在单一模型上——DeepSeek这次升级说明，推理侧的技术迭代速度比预训练还快 科创板IPO后关注生态开放——上市后通常会加大开发者生态投入，早期接入有红利 结语 DeepSeek这次"技术+资本"双响炮，本质上是在回答一个问题：大模型公司的护城河到底是什么？ 不是参数规模，不是跑分，而是单位智能的成本。当KV Cache压缩到1/4、HBM需求降到1/4，DeepSeek证明了自己能在推理侧持续制造结构性成本优势。 科创板IPO只是开始——真正的战场，是把这套成本优势变成企业级市场的定价权。 相关阅读 DeepSeek双响炮总览：HBM需求砍至1/4 + 科创板IPO融资510亿的完整逻辑 DeepSeek双响炮（资本篇）：冲刺科创板IPO首轮融资510亿，估值路径拆解

两条新闻，一个方向 最近国内AI基础设施传来两条标志性消息： 粤港澳大湾区首个昇腾万卡智算集群在韶关上线，总算力达 9000P 我国首颗采用软件定义与三维近存计算技术的AI芯片在上海发布，在14纳米制程上实现每秒 520万亿次 浮点运算 两条新闻指向同一个趋势：国产算力正在从"能用"走向"好用"。 “换芯工程"的三重逻辑 当前国内大模型企业正稳步推进算力"换芯工程”，核心预训练算力加速从海外GPU向国产AI芯片迁移： 1. 集群规模上台阶 9000P的昇腾万卡集群意味着什么？它已经具备支撑超大规模模型训练的能力——万亿参数级别模型的预训练，从此可以在国产算力底座上完成。 2. 架构创新找突破 软件定义 + 三维近存计算，是针对AI访存瓶颈的定向优化： 三维近存：把存储堆叠到计算单元附近，缩短数据搬运距离 软件定义：通过软件灵活调度硬件资源，适配不同模型形态 14nm制程实现520万亿次/秒，证明了"架构创新可以部分对冲制程差距" 3. 产业闭环加速 从芯片设计、制造、集群部署到模型适配，国产AI算力的产业闭环正在成型。对模型企业而言，多一个可选的算力底座，就多一分供应链安全。 挑战依然存在 需要清醒认识的是，国产算力在软件生态、开发者工具链上仍与成熟生态有差距。“换芯工程"不只是硬件替换，更是软件栈的迁移与重构。 结语 9000P集群与三维近存芯片，是"换芯工程"从概念走向落地的注脚。这条路不轻松，但方向已经不可逆——自主可控的算力底座，是AI产业长期发展的压舱石。

MoE架构的本质思想 混合专家模型（Mixture of Experts, MoE）的核心思想非常直观：不要让每个Token都经过所有参数的计算，而是为每个Token选择最合适的"专家"子网络来处理。这类似于医院分诊——患者不会被所有医生同时看诊，而是根据症状被分配给对应科室的专家。 MoE vs Dense模型对比 特性 Dense模型 MoE模型 参数利用率 100%（每个Token激活所有参数） 5-20%（仅激活部分专家） 总参数量 固定 可扩展至更大规模 训练成本 与参数量成正比 与激活参数量成正比 推理成本 与参数量成正比 与激活参数量成正比 模型容量 受限于计算预算 可用更大容量模型 MoE架构演进史 第一代：经典MoE（2017-2020） 最早的MoE思想可追溯到1991年Jacobs等人提出的自适应混合模型。在现代深度学习中，Google的GShard（2020）首次将MoE引入Transformer架构： # GShard MoE 的核心逻辑（简化版） import torch import torch.nn as nn import torch.nn.functional as F class MoELayer(nn.Module): def __init__(self, d_model, num_experts, top_k=2): super().__init__() self.num_experts = num_experts self.top_k = top_k # 门控网络 self.gate = nn.Linear(d_model, num_experts) # 专家网络（每个专家是一个FFN） self.experts = nn.ModuleList([ nn.Sequential( nn.Linear(d_model, d_model * 4), nn.GELU(), nn.Linear(d_model * 4, d_model) ) for _ in range(num_experts) ]) def forward(self, x): # x shape: (batch_size, seq_len, d_model) gate_logits = self.gate(x) # (batch, seq, num_experts) # 选择Top-K专家 gate_scores = F.softmax(gate_logits, dim=-1) topk_scores, topk_indices = torch.topk(gate_scores, self.top_k, dim=-1) # 归一化专家权重 topk_scores = topk_scores / topk_scores.sum(dim=-1, keepdim=True) # 计算加权输出 output = torch.zeros_like(x) for i in range(self.top_k): expert_idx = topk_indices[..., i] # (batch, seq) weight = topk_scores[..., i:i+1] # (batch, seq, 1) for e in range(self.num_experts): mask = (expert_idx == e) if mask.any(): expert_input = x[mask] expert_output = self.experts[e](expert_input) output[mask] += expert_output * weight[mask] return output 第二代：Switch Transformer（2021） Google在2021年提出的Switch Transformer将Top-2简化为Top-1路由，大幅降低了通信开销： ...

多模态融合的核心问题 多模态模型要解决一个根本问题：如何让模型理解不同模态（文本、图像、音频、视频）之间的语义关联。这包含两个子问题： 表征对齐：将不同模态的输入映射到统一的语义空间 推理融合：在统一空间中进行跨模态的推理与生成 多模态融合的三个阶段 阶段 时间 代表模型 核心方法 对比学习 2021-2022 CLIP, ALIGN 双塔编码器 + 对比损失 桥接融合 2023 BLIP-2, LLaVA 视觉编码器 + Q-Former/投影层 + LLM 原生多模态 2024-2026 GPT-4V, Gemini 端到端训练的多模态Transformer 第一阶段：对比学习对齐（CLIP） CLIP的核心思想 CLIP（Contrastive Language-Image Pre-training）通过简单的对比学习，将图像和文本映射到同一语义空间： import torch import torch.nn as nn import torch.nn.functional as F class CLIPModel(nn.Module): def __init__(self, image_encoder, text_encoder, projection_dim=512): super().__init__() self.image_encoder = image_encoder # ViT self.text_encoder = text_encoder # Transformer self.image_projection = nn.Linear( image_encoder.dim, projection_dim ) self.text_projection = nn.Linear( text_encoder.dim, projection_dim ) self.logit_scale = nn.Parameter(torch.ones([]) * np.log(1/0.07)) def forward(self, images, texts): # 编码图像和文本 image_features = self.image_encoder(images) # (batch, img_dim) text_features = self.text_encoder(texts) # (batch, txt_dim) # 投影到共享空间 image_embeds = self.image_projection(image_features) # (batch, proj_dim) text_embeds = self.text_projection(text_features) # (batch, proj_dim) # L2归一化 image_embeds = F.normalize(image_embeds, dim=-1) text_embeds = F.normalize(text_embeds, dim=-1) # 对比损失：对角线为正样本，其余为负样本 logit_scale = self.logit_scale.exp() logits_per_image = logit_scale * image_embeds @ text_embeds.t() logits_per_text = logits_per_image.t() labels = torch.arange(len(images), device=images.device) loss_i2t = F.cross_entropy(logits_per_image, labels) loss_t2i = F.cross_entropy(logits_per_text, labels) loss = (loss_i2t + loss_t2i) / 2 return loss CLIP的局限 表征能力有限：对比学习只学了"相似/不相似"，无法做细粒度理解 无法生成：CLIP只能做检索和分类，无法生成图像描述 固定分辨率：ViT需要固定输入分辨率，处理高分辨率图像时信息丢失 第二阶段：桥接融合（BLIP-2 / LLaVA） BLIP-2：Q-Former桥接 BLIP-2引入了Q-Former（Querying Transformer），用一组可学习的Query从视觉特征中提取与语言相关的信息： ...

为什么标准注意力是瓶颈？ Transformer的核心——自注意力机制，其计算复杂度是序列长度的二次方 O(n²)。这个n²使得处理长序列时的计算和内存开销急剧增长。 标准注意力的计算过程 import torch import torch.nn.functional as F import math def standard_attention(Q, K, V): """ 标准自注意力 Q, K, V: (batch, num_heads, seq_len, d_head) """ d = Q.shape[-1] # 注意力分数: (batch, heads, seq, seq) scores = torch.matmul(Q, K.transpose(-2, -1)) / math.sqrt(d) # Softmax归一化 attn = F.softmax(scores, dim=-1) # 加权求和 output = torch.matmul(attn, V) # (batch, heads, seq, d_head) return output # 计算复杂度分析 # scores矩阵大小: seq_len × seq_len # 当 seq_len = 8192 时, 每个head的scores矩阵 = 8192² = 67M 个元素 # 当 seq_len = 32768 时, 每个head的scores矩阵 = 32768² = 1B 个元素 # 显存随序列长度平方增长！ 不同序列长度的开销对比 序列长度 注意力矩阵大小 显存(FP16, 32头) 计算量(FLOPs) 4K 16M 1GB 0.13T 8K 64M 4GB 0.52T 32K 1B 64GB 8.4T 128K 16B 1TB 134T 1M 1T 64TB 8.2PT 这个表格清楚地展示了为什么标准注意力无法扩展到超长序列。 ...

长上下文窗口的现状 2026年，主流大模型的上下文窗口已经从2023年的32K扩展到百万甚至千万Token级别。Gemini 1.5 Pro支持2M Token，Claude 3.5支持200K，而实验性方案已验证10M Token的可行性。但上下文窗口的扩展远不止"加大序列长度"那么简单——它是一个涉及位置编码、显存管理、计算效率和模型质量的系统性工程挑战。 上下文窗口演进历程 时间 代表模型 上下文长度 关键突破 2023年初 GPT-4 8K-32K 标准Transformer 2023年中 Claude 2 100K 滑动窗口注意力 2024年初 Gemini 1.5 1M Ring Attention + 优化KV Cache 2024年中 Claude 3 200K Prompt Caching 2025年 Gemini 2.0 2M 分布式KV Cache 2026年 实验方案 10M 混合架构 + 压缩 四大核心技术挑战 挑战1：位置编码的外推问题 标准RoPE（旋转位置编码）在训练长度外推时性能急剧下降。从32K训练扩展到100K推理，模型在长序列上的困惑度可能翻倍。 RoPE外推的数学本质 import torch import math def rotary_position_embedding(seq_len, d_head, theta=10000.0): """ RoPE: 通过旋转矩阵编码相对位置 """ # 频率向量 freqs = 1.0 / (theta ** (torch.arange(0, d_head, 2).float() / d_head)) # 位置 × 频率 positions = torch.arange(seq_len).float() angles = torch.outer(positions, freqs) # (seq_len, d_head/2) # 构造旋转矩阵 cos = torch.cos(angles).repeat_interleave(2, dim=-1) # (seq_len, d_head) sin = torch.sin(angles).repeat_interleave(2, dim=-1) return cos, sin def apply_rope(x, cos, sin): """将RoPE应用到注意力输入""" # x: (batch, heads, seq, d_head) d_head = x.shape[-1] x1 = x[..., ::2] # 偶数维度 x2 = x[..., 1::2] # 奇数维度 # 旋转 rotated = torch.stack([-x2, x1], dim=-1).reshape_as(x) return x * cos + rotated * sin # 问题演示：训练长度32K，推理长度128K train_len = 32768 infer_len = 131072 # 在训练长度内，位置编码分布良好 cos_train, sin_train = rotary_position_embedding(train_len, 128) # 外推到4倍长度时，高频分量出现周期性混叠 cos_infer, sin_infer = rotary_position_embedding(infer_len, 128) # 高频维度在超出训练范围后，角度快速旋转，导致相似位置的编码差异巨大 # 这就是外推性能下降的根本原因 主流解决方案 1. NTK-aware Scaling： ...

记忆持久化的核心挑战 Agent的会话记忆在对话结束后就消失了。要让Agent"记住"用户偏好、历史交互和学到的知识，需要将记忆持久化到外部存储。如何存储、如何检索、如何遗忘——这是记忆持久化的三大问题。 存储方案对比 方案一：向量数据库 最主流的记忆存储方案： class VectorMemory: def __init__(self, vector_db): self.db = vector_db async def store(self, content, metadata=None): embedding = await self.embed(content) self.db.insert({ "content": content, "embedding": embedding, "metadata": metadata, "timestamp": datetime.now() }) async def retrieve(self, query, top_k=5): query_vec = await self.embed(query) results = self.db.search(query_vec, top_k=top_k) return results 优点： 语义检索、灵活查询 缺点： 缺乏结构化关系、时间感知弱 方案二：关系数据库+摘要 class RelationalMemory: def __init__(self, db): self.db = db async def store_interaction(self, user_id, session_data): # 存储完整交互 self.db.insert("interactions", { "user_id": user_id, "session_id": session_data.id, "summary": await self.summarize(session_data), "key_points": json.dumps(session_data.key_points), "timestamp": session_data.start_time }) async def get_user_context(self, user_id): """获取用户上下文""" interactions = self.db.query( "SELECT * FROM interactions WHERE user_id = ? ORDER BY timestamp DESC LIMIT 10", [user_id] ) return self.build_context(interactions) 优点： 结构化、可精确查询 缺点： 无法语义检索 方案三：知识图谱 class GraphMemory: def __init__(self, graph_db): self.db = graph_db async def store_fact(self, subject, predicate, obj): """存储三元组""" self.db.run( "MERGE (s:Entity {name: $subject}) " "MERGE (o:Entity {name: $object}) " "MERGE (s)-[r:RELATION {type: $predicate}]->(o)", subject=subject, predicate=predicate, object=obj ) async def query_relations(self, entity): """查询实体关系""" return self.db.run( "MATCH (e:Entity {name: $entity})-[r]->(related) " "RETURN e, r, related", entity=entity ) 优点： 关系推理能力强、结构化 缺点： 构建成本高、灵活性低 ...

推理：大模型的最后一块拼图 大模型在知识广度上已经超越人类，但在复杂推理上仍然薄弱。简单的数学题、多步逻辑推理——这些对人类不难的任务，对LLM却是挑战。思维链（Chain of Thought, CoT）技术的出现，正在改变这一局面。 CoT技术谱系 基础CoT 让模型在给出答案前生成推理过程： Prompt: "让我们一步步思考" Output: 1. 首先，我们需要... 2. 根据已知条件... 3. 所以答案是... 原理： LLM的自回归生成机制下，中间token作为"工作记忆"，帮助模型逐步组织推理。不生成中间token时，模型需要在一次前向传播中完成所有推理——负担太重。 Zero-shot CoT： 在prompt末尾加"Let’s think step by step"，无需示例。 Few-shot CoT： 提供带推理过程的示例，效果更好。 Self-Consistency 对抗LLM生成随机性的方法： 1. 用同一prompt生成K条CoT推理（temperature=0.7） 2. 提取每条推理的最终答案 3. 取多数票作为最终答案 适用：数学计算、逻辑推理等有明确答案的任务。 效果：通常比单次CoT提升5-15%准确率。 成本：推理成本变为K倍。 Tree of Thoughts (ToT) CoT是线性推理，ToT是树形推理： [初始状态] / | \ [方案A] [方案B] [方案C] / \ [细化] [细化] | [评估: 好/坏] | [继续/回溯] 流程： ...

Scaling Law：规则还是错觉？ 2020年OpenAI发表Scaling Law论文，揭示了一个惊人的规律：模型能力随参数量、数据量、计算量的幂律增长而可预测地提升。这个发现驱动了过去六年大模型的爆发式发展。但2026年，Scaling Law正在减速——这意味着什么？ 经典Scaling Law 三个维度 L(N, D, C) = 常数 × (N/N₀)^(-α_N) × (D/D₀)^(-α_D) × ... N: 模型参数量 D: 训练数据量（tokens） C: 计算量（FLOPs） 经验值： α_N ≈ 0.076（参数缩放指数） α_D ≈ 0.095（数据缩放指数） α_C ≈ 0.057（计算缩放指数） 关键洞察 可预测性：给定计算预算，可以预测模型loss 最优分配：给定计算量C，存在最优的N和D分配 没有饱和：在测试范围内，能力随规模持续提升 Chinchilla修正 DeepMind的Chinchilla论文修正了原始Scaling Law： 之前模型训练数据不足（过度参数化） 最优训练：每个参数约20个token 70B模型应该用1.4万亿token训练 减速信号 信号1：边际收益递减 模型规模增长10倍 → loss下降约0.05 模型规模再增长10倍 → loss下降约0.04 模型规模再增长10倍 → loss下降约0.03 （幂律仍在，但绝对增量越来越小） 信号2：数据墙 高质量训练数据正在枯竭： 互联网高质量文本约10万亿token 2024年训练的模型已用5-10万亿 2026年接近数据上限 低质量数据加入反而可能降低性能 信号3：成本爆炸 训练万亿参数模型： 计算量约10^25 FLOPs 需要约10万张H100运行数月 单次训练成本超过1亿美元 投资回报率递减 信号4：benchmark天花板 在MMLU、HumanEval等基准上： ...