据相关报道，DeepSeek创始人梁文锋透露，该公司计划在四月下旬推出其最新的旗舰级大模型DeepSeek V4。
不过相较于新模型的发布，更值得关注的是DeepSeek的服务器稳定性问题。
在三月二十九日晚上九点三十五分，DeepSeek又一次遭遇了严重的服务中断。
此次故障并非轻微的技术瓶颈导致的小范围中断，而是长达十二小时五十八分钟的大规模全面瘫痪。无论是网页端还是手机应用，都出现了无法正常使用的情况，并且在修复后不久又再次崩溃，直到第二天上午十点才恢复正常运作。
在DeepSeek V4尚未正式上线前，这样的技术问题已显示出相当的冲击力，一旦该模型发布，现有的基础设施是否能够承受住巨大的访问压力？
为此，我们需要关注一位名叫代达劢的关键人物，他是负责公司基础架构的负责人。
其主要职责在于确保在百万级用户同时涌入的情况下，系统不会崩溃。
关于DeepSeek V4的传闻不断增多，原定发布日期从二月推迟到三月，再推至四月。外界纷纷关注其性能指标的表现，然而真正的挑战却落在了代达劢身上。
服务器稳定性一直是困扰DeepSeek的一大难题，这已是公开的秘密。问题是，留给基础设施团队进行改进的时间还有多久？
01
深度寻求基础设施主管
在业内，他还有一个昵称叫“戴大麦”。2024年获得北京大学计算机学院计算语言研究所博士学位，导师为穗志方教授。
他在学术界的贡献显著。已发表超过二十篇顶级会议论文，并在Google Scholar上获得了超过二万八千次的引用次数。作为第三核心作者之一，在2023年的EMNLP会议上荣获最佳长篇论文奖，这是中国大陆机构首次获得该奖项。
这项获奖的研究题目为《标签词是锚点：从信息流视角理解上下文学习》，探讨了大模型通过示例中的标签词进行预测的机制。
读博期间，代达劢还获得了包括国家奖学金、校长奖学金和微软学者提名奖等多项荣誉及认可。
其博士论文则聚焦于预训练语言模型的知识增强与推理能力对齐问题，并入选了中国中文信息学会“博士学位论文激励计划”。
他的研究方向集中在大模型基础设施和技术优化，核心目标在于提升模型的运行效率和稳定性的同时降低成本。
此外，他还参与撰写了一篇关于上下文学习领域的综述性文章，在人工智能圈内广受好评。
这篇文章总结了该领域迄今为止的研究进展、分类方式以及尚未解决的问题，并提出了未来研究方向。
自DeepSeek V1至V3的版本迭代中，代达劢全程参与。在公司内部，他负责整个推理系统的工程优化与大规模部署工作，包括多平台性能调优和分布式系统架构设计等关键环节。
DeepSeek能够在开源大模型领域实现弯道超车，并以极低的成本与头部闭源模型竞争的技术核心之一就是DeepSeekMoE架构。
这一创新解决了传统MoE架构中存在的专家知识冗余及专业化不足等问题，使得DeepSeek能够以更低的计算成本获得更高的性能表现。
提出该架构的研究论文《DeepSeekMoE: 向极致专家细分化迈进》，于2024年1月发表在ACL 2024会议上。
论文的第一作者正是代达劢博士本人。
DeepSeekMoE提出了“细粒度的专家分割”概念，使得每个token可以激活多个专家，从而增强了知识融合能力。传统的MoE架构如GShard，则仅激活top-K个专家。
为确保每位专家的专业化水平并避免知识重叠，代达劢团队将原有的N个专家拆分成了mN个更细粒度的单元，在激活时从K个增加到mK个。
同样地，他们还设计了一些专门捕捉通用信息的知识共享专家模块，减少了路由专家间的冗余性。
这一创新架构后来成为DeepSeek V2和V3版本的核心基础设施。
在145B参数规模下，论文提出的MoE架构仅需28.5%的计算资源即可达到与DeepSeek 67B性能相近的表现。此外，在同等总参数量的情况下，新硬件上的表现可以接近甚至超越英伟达设备。
DeepSeek V4的成功不仅取决于模型自身的跑分成绩，更重要的是系统能否稳定运行。
如果在发布当天再次出现长时间的服务中断问题，即使拥有再优秀的模型也会受到公众的严厉批评。因此，DeepSeek下一阶段的任务不仅是提升模型能力，还需要确保其平稳地交付给用户。
沉默了几个月后，代达劢团队究竟有何重大突破？
02
DeepSeek已经很久没有更新了。
关于V4的发布时间一再推迟，人们纷纷猜测是否遇到了技术上的难题。
有，但不全是他的锅。
但仔细分析DeepSeek最近发布的论文可以发现，他们正在为更大的挑战做准备。
在二零二六年二月，与清华大学和北京大学联合发布了一篇名为DualPath的研究成果。该文章的第一作者是来自北大博士生吴永彤，研究方向同样集中在LLM Infrastructure领域。
他在同年七月加入了DeepSeek系统组，参与下一代模型推理基础设施的设计工作。
其主要职责之一是对大规模内部软件进行系统的优化和改进，在各种硬件平台下实现高效且稳定的运行效果。
简单来说就是构建一个能够支持大模型在复杂集群环境中快速稳定工作的底层系统。
另外，考虑到代理技术（Agent）的流行趋势，如果V4计划引入新的代理能力，则推理系统的性能优化便显得尤为重要。即使像DeepSeek MLA这样的高度缓存优化模型，在处理大量数据时仍会面临巨大的I/O压力。
DualPath正是为了解决这种大规模服务环境下常见的吞吐瓶颈问题而提出的解决方案，从而提高系统的负载能力和响应速度。
代达劢和吴永彤等工程师所面临的压力非常巨大。
对于从事算法开发的人来说，成绩往往是显而易见的。一旦模型性能更强、榜单排名更高或论文发表成功时，外界很快就能感受到这些变化带来的影响。
然而对于负责基础设施建设的人来说，则正好相反。他们最好的成果往往就是“一切如常”。
服务器不崩溃、网页可以正常打开、手机应用也不卡顿等等看似平常的体验背后是无数辛勤工作的结果。
正是因为这种无形的努力，用户才会认为这些都是理所当然的事情。
然而一旦出现问题，则所有压力都会瞬间转移到基础设施团队身上。
对于大部分普通用户而言，他们不会区分系统是由哪些模块组成或具体哪个环节出现了故障。对他们来说，只要服务无法正常使用就会直接归咎为DeepSeek又出问题了。
这就是基础设施工程师面临的最大挑战之一：做好了没人会特别称赞；但如果做差了就可能面临来自各方面的批评与质疑。
对于像DeepSeek这样已经被广泛关注的大模型公司来说，其基础设施团队肩负的责任更加重大。
如果V4在发布时能够保持稳定运行，则将是真正意义上的“封神”时刻。这场战役中，代达劢必须取得胜利。因为再强大的模型一旦出现故障就等于零分。
但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发布时不崩，那才是真正的封神时刻。这场仗，代达劢必须赢。因为模型再强，崩了就是零。