据新浪创智记报道，DeepSeek创始人梁文锋在内部沟通中透露，新一代旗舰大模型DeepSeek V4将于4月下旬正式发布。

然而比起新模型，我更关注DeepSeek的服务器。

3月29日晚上9点35分，DeepSeek又双叒叕崩了。

这一次不是小打小闹的“服务器繁忙”，而是史诗级的12小时58分钟全面瘫痪。网页端、APP双双失守，修复了又崩，崩了又修复，直到第二天上午10点才喘过气来。

DeepSeek-V4还没正式发布，冲击波已经如此强劲，一旦正式发布，目前DeepSeek的基础设施真的扛得住吗？

这就是为什么我们要关注代达劢，他是DeepSeek的基础设施负责人。

他负责的不是模型有多聪明，而是模型能不能在百万级用户同时涌入时不崩盘。

V4传闻四起，发布时间从2月推到3月，又推到4月，外界都在盯着性能跑分，但真正的压力测试，其实在代达劢这边。

服务器是DeepSeek的软肋，这已经不是秘密。问题是，留给代达劢的时间还有多少？

01

DeepSeek基础设施掌门人

圈内也有人管他叫“戴大麦”。2024年博士毕业于北京大学计算机学院计算语言所，师从穗志方教授。

在学术圈，他是个狠人。发表20余篇顶会论文，Google Scholar显示引用次数超过28000次。2023年，他作为第三核心作者，拿下了EMNLP最佳长论文奖，这也是中国大陆机构首次获得该奖项。

这篇获奖论文名为《Label Words are Anchors: An Information Flow Perspective for Understanding In-Context Learning》（标签词是锚点：从信息流视角理解上下文学习），研究的是上下文学习的工作机制，从信息流的视角揭示了大模型如何通过示例中的标签词进行预测。

在读博期间，代达劢还获得过国家奖学金、校长奖学金、微软学者提名奖、北京市优秀毕业生、北京大学三好学生标兵等一系列荣誉。

代达劢博士论文入选了中国中文信息学会“博士学位论文激励计划”，研究的是预训练语言模型的知识增强与推理能力对齐。

他的研究方向聚焦在大模型基础设施和系统优化。说白了，就是怎样让模型跑得更快、更稳、更省钱。

代达劢还参与了一篇综述类文章，在AI圈内也很火。标题是《A Survey on In-Context Learning》（上下文学习综述）。

文章讲的是In-Context Learning（上下文学习）这个方向的整体研究进展，也就是总结这个领域“大家都做了什么、怎么分类、有哪些解释、还有哪些问题没解决”。

从DeepSeek V1到V3，代达劢参与了全程。在DeepSeek，他负责的是整个推理系统的工程优化与规模化部署，包括多硬件平台的性能调优、分布式系统架构设计，以及那些用户看不见但至关重要的底层管道。

DeepSeek能在开源大模型领域实现弯道超车、以极低推理成本对标头部闭源模型的核心技术支撑，就是DeepSeekMoE。

DeepSeekMoE所解决的，是传统MoE架构的专家知识冗余、专业化不足的行业痛点，这才让DeepSeek能在同等计算成本下实现了模型性能的大幅跃升。

提出这个架构的论文，叫《DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models》，于2024年1月发表在ACL 2024。

而这篇论文的第一作者，正是本文的主角代达劢。

DeepSeekMoE架构提出了“细粒度专家分割”的创新思路，让每个token可以激活多个专家，提升知识融合能力。传统的MoE架构像GShard，激活top-K个专家。

但如何确保每个专家真正专业化，获取不重叠的、聚焦的知识？代达劢团队的方案是把专家细分成更细粒度的单元，从N个专家变成mN个，激活时从K个变成mK个，这样组合更灵活。

同时隔离出一些共享专家，专门捕获通用知识，减少路由专家之间的冗余。

这套架构后来成为DeepSeek-V2和V3的核心基础。

论文提出的MoE架构在145B参数规模上，只用28.5%的计算量就达到了DeepSeek 67B的性能。更关键的是，DeepSeekMoE 2B的表现接近同等总参数量的稠密模型，这为MoE模型设定了性能上限。这不是纸面数据，而是真刀真枪跑出来的工程成果。

从理论到工程，代达劢不只是提出创新架构，更要确保这套架构能在真实环境中稳定运行。这种“理论上好使，工程上也能跑”的能力，正是DeepSeek能用这么低的算力，跑出如此高性能的原因。

不过这些成就，都是在模型训练和架构设计层面。真正考验基础设施的，是当百万用户同时涌入时，系统能不能撑住。

3月29日那场12小时的崩溃，恰恰暴露了这个问题。

02

DeepSeek的崩溃与代达劢的硬仗

DeepSeek总是崩，跟代达劢有没有关系？

有，但不全是他的锅。

DeepSeek现在最大的问题，就出在它的交付系统上。

面对流量高峰，DeepSeek的交付系统不够稳定。模型再强，如果推理集群扛不住并发、负载均衡没做好、容错机制不够健壮，照样会崩。

算法团队可以把模型训练得再聪明，但如果基础设施撑不住，用户看到的就是“服务器繁忙”四个大字。

代达劢负责的基础设施，就是这条链路上的关键一环。推理集群的调度策略、请求的分发逻辑、GPU资源的动态分配、故障时的降级预案，这些看不见的管道，决定了系统能不能在压力下稳住。

3月29日晚上9点35分，DeepSeek开始出现大规模服务中断。网页端、手机APP均无法正常使用，大量用户反馈无法发起新对话、现有对话中断。技术团队立即启动紧急排查，于当日23时23分完成首次故障修复，部分用户反馈可短暂登录平台，但随后服务再次出现波动。

3月30日00时20分，技术团队再次针对服务性能异常问题展开调查，于01时24分实施二次修复方案，期间平台服务始终处于不稳定状态，直至30日上午10时左右，所有服务才完全恢复正常。从首次发现异常到彻底恢复，全程耗时超过12小时，创下DeepSeek成立以来单次服务中断时长的最长纪录。

其实咱们如果回顾DeepSeek的历史你就会发现，DeepSeek虽然也会偶尔卡顿，但网页端服务从未出现过超过2小时的中断。

虽然宕机对于目前的大模型而言属于正常现象，但这么长时间的宕机，以DeepSeek的技术能力而言，不应该发生。

现在的问题是，这套系统在V3时代已经显得吃力，V4来了怎么办？

不仅如此，根据最新的消息，V4不只是模型升级，它是一次底层硬件的全面切换。

DeepSeek V4将全面基于国产芯片完成适配和优化。

这可不是说像你打游戏换块显卡那么简单。大模型要从英伟达的CUDA生态迁移到国产芯片框架，意味着底层代码要大量重写，推理系统要重新调优，性能瓶颈要重新排查。

核心差异在于算子生态。

CUDA积累了15年，覆盖几乎所有场景。国内的框架到现在还在补课阶段，只不过从以前的网课，变成线下实体课程了。

尤其是Flash Attention、Triton自定义算子这类高性能优化层，适配工作量相当大。

GPU和NPU的计算是高度并行的，同一个矩阵乘法可能被分拆成几千个线程同时计算，最后求和。而浮点加法不满足结合律，不同芯片的并行分拆策略不同，导致累积误差的路径也不同。

对于那种几十亿参数量的小模型来说，这个误差的确是可以忽略不计的。

但V3就已经是百亿级模型了，V4只可能更大，尤其是在处理长上下文时，误差会随层数和序列长度累积，在输出层可能产生明显的误差。

实际部署时，如何让模型在新硬件上跑出接近甚至超越英伟达的性能？如何保证迁移过程中服务不中断？如何在多硬件平台之间做好资源调度？这些问题，都压在代达劢肩上。

V4成败，不只看模型跑分，更看发布时系统能不能稳住。

如果V4发布当天又崩好几个小时，再好的模型也会被喷成筛子。DeepSeek下一阶段要补的，已经不只是模型能力，而是把模型能力稳定送到用户面前的能力。

03

沉默的这几个月，代达劢在憋什么大招？

DeepSeek太久没更新了。

V4的发布时间从2月推到3月，又推到4月，外界都在猜测是不是模型出了问题。

但如果你仔细看DeepSeek这几个月发的论文，会发现他们在为一场更大的战役做准备。

2026年2月，DeepSeek联合清华、北大发布了DualPath论文。这篇论文的第一作者是北大博士生吴永彤，研究方向也是LLM Infrastructure，和代达劢是一个战壕里的人。

2025年7月，吴永彤加入DeepSeek系统组，参与下一代模型推理基础设施的建设工作。

他的核心职责之一，是对大规模内部软件系统进行系统级优化，使其能够在不同硬件平台上实现高效、稳定的运行。这类工作本质上属于大模型基础设施建设范畴，重点在于提升推理系统在复杂集群环境中的性能与资源利用效率。

说白了，就是把大模型的底层系统搭好，让它在复杂服务器集群里既跑得动，也跑得快，还不浪费机器

还有一点，agent这么火，如果V4要上agent能力，推理系统就必须跟上。即便像DeepSeek MLA这样已经过高度缓存优化的模型，其I/O压力依然巨大。

DualPath解决的是推理系统里的一个吞吐瓶颈，进而提高大规模服务时的承载能力。所以其实DeepSeek自己心里也明白，再好吃的菜，端不上桌，也是白扯。

戴大麦和吴永彤，他们这类工程师的压力更大。

做算法的人，成绩往往是看得见的。模型能力更强了，榜单分数更高了，论文发出来了，产品出了爆款功能，外界很快就能感知到变化。

可做基础设施的人不一样，他们最好的成绩，往往恰恰是“什么都没发生”。

服务器没崩，网页能打开，APP不卡顿。

但用户只会觉得“那你不是本来就该这样吗？”，没人会专门记住是谁把这件事做成的。

可一旦出了问题，所有压力又会在第一时间落到他们头上。

因为对绝大多数用户来说，系统不是由模型、调度、网关、缓存、数据库这些抽象模块组成的，系统只有一种最直观的体验——它能不能用。

普通用户就一个评判标准，“我打开你网页的时候转不转圈”。转圈就是你服务器不行，不转圈就是应该的。

用户是分不清楚到底哪层出了问题。对他们来说，任何原因都会被压缩成一句话：DeepSeek怎么又崩了？

这就是基础设施岗位最难的地方。

做好了，没人鼓掌，因为这是你该做的；做差了，你就等着被唾沫喷死吧！

对一家已经被推上风口浪尖的大模型公司来说，基础设施团队背负的东西很多。

如果V4发布时不崩，那才是真正的封神时刻。这场仗，代达劢必须赢。因为模型再强，崩了就是零。