152. 领读Kimi K3技术报告:从架构创新聊起,注意力美学、多教师蒸馏和开源MoE

[3.5s -> 5.5s] Hello 大家好,我是小俊。 [5.5s -> 12.5s] 今天的节目是一集学习播客,学习Kimi K3的技术报告,希望和大家一起领略技术之美。 [12.5s -> 18.5s] K3是有效扩展到2.8T总参数并全量开源的MOE模型。 [18.5s -> 24.5s] 大家可能注意到这集技术报告的领度播客能距离模型发布已经过去了一段时间。 [24.5s -> 27.5s] 期间我们试图寻找一位合适的嘉宾。 [27.5s -> 32.5s] 我们希望这位嘉宾他的工作和学术背景非常适合的来讲K3, [32.5s -> 34.5s] 最后找到了孙宇涛。 [34.5s -> 40.5s] 宇涛目前是清华大学计算机系博士候选人上海创制学院普瑞学者。 [40.5s -> 45.5s] 他从博士开始的研究方向是LLM架构预训练。 [45.5s -> 49.5s] 架构创新一直都是他的兴趣所在,这正好是K3的亮点之一。 [49.5s -> 55.5s] 宇涛透过领读K3的论文也串联讲解了十多篇相关的论文, [55.5s -> 59.5s] 他的语速非常快,所以前方语速高能预警。 [59.5s -> 63.5s] 期待2026年,我们和AI共同进步。 [63.5s -> 67.5s] 当然了,这关我觉得可能还有一些别的concern,比如说我们发现, [67.5s -> 70.5s] 其实如果用LLM的话,它其实会更容易出现LLM的, [70.5s -> 74.5s] 进行控制中间的计划值,总不是一个比较错的一个现象。 [74.5s -> 78.5s] 当然,如果我说LLM更容易来LLM,这个苏建磊一定会反对, [78.5s -> 81.5s] 他肯定会说,对于任何优化器来说,他都一定会出现LLM, [81.5s -> 83.5s] 因为你从模型架构上是控制不了的, [83.5s -> 87.5s] 所以说如果想严格控制的方法,他一定是直接从模型架构下手。 [88.5s -> 91.5s] 这个哲学上还有一个对应的概念,就是太修四只船嘛, [91.5s -> 95.5s] 就是你刚开始的,2017年这个船刚开始行驶的时候,是穿苏门, [95.5s -> 98.5s] 对,但是这个船刚开始是怎么拼起来的, [98.5s -> 100.5s] 它是Tension,加瑞C軸,行驶的过程中, [100.5s -> 103.5s] 我们可能会把慢慢的把某些部分换了, [103.5s -> 105.5s] 某些部分换了,其实跟穿苏门已经, [105.5s -> 107.5s] 我觉得相处已经很厉害了, [107.5s -> 109.5s] 你是不是还把这个东西叫做穿苏门? [110.5s -> 112.5s] 我说一下我的判断,我的判断比较暴论, [112.5s -> 115.5s] 我的暴论就是大模型可能没有太被认的上线, [115.5s -> 117.5s] 后面都是一些改良性的进行定步。 [117.5s -> 122.3s] 好的,那我们的论文学习播客又来了, [122.3s -> 126.3s] 这次我要请了清华大学的PhD Candidate, [126.3s -> 130.3s] 上海创治学院朴瑞学者孙宇涛, [130.3s -> 133.3s] 将由他带领大家一起来学习和阅读, [133.3s -> 137.3s] 最近大家关注度非常高的Kimi K3的论文, [137.3s -> 140.3s] 但是宇涛会带领大家读一系列的论文, [140.3s -> 143.3s] 那宇涛,你能不能先给大家做一个自我介绍, [143.3s -> 145.3s] 并且介绍一下你的研究方向? [146.3s -> 149.3s] 好的,各位观众朋友,大家下午好, [149.3s -> 151.3s] 然后我是来自清华大学的孙宇涛, [151.3s -> 156.3s] 我在博士期间的主要的研究方向是大模型的架构和预讯链, [156.3s -> 158.3s] 然后这个博士课题呢, [158.3s -> 160.3s] 我是从23年从那个时候开始, [160.3s -> 164.3s] 我们主要去研究大模型的模型架构的一系列的工作, [164.3s -> 165.3s] 然后在那个时间点, [165.3s -> 168.3s] 应该是拆的GBT刚刚发布一段时间吧, [168.3s -> 170.3s] 但是我们的架构研究, [170.3s -> 173.3s] 其实从拆的GBT发布之前就开始, [174.3s -> 175.3s] 差不多就开始了, [175.3s -> 177.3s] 然后我这两三年的, [177.3s -> 179.3s] 主要的一个研究方向, [179.3s -> 181.3s] 主要是去尝试解决, [181.3s -> 185.3s] 然后大模型在推理这个环节的一些低效性吧, [185.3s -> 187.3s] 所以说我们主要的一些研究方向, [187.3s -> 190.3s] 都是围绕着推理高效性来去展开的, [190.3s -> 192.3s] 然后其实大家也可以注意到说, [192.3s -> 194.3s] 就是在模型架构这个方面呢, [194.3s -> 197.3s] 整个业界的研究方向也是逐渐从, [197.3s -> 201.3s] 偏性能围导向逐渐的变得是以效率围导向, [201.3s -> 203.3s] 然后在这个方面, [203.3s -> 205.3s] 其实是有一些办事上的变化的, [205.3s -> 206.3s] 因为可能在Vision时代, [206.3s -> 207.3s] 或者说在ImageNet时代, [207.3s -> 211.3s] 大家还是尝试去做到更精妙的一些架构, [211.3s -> 213.3s] 然后去提升模型本身的一个表现, [213.3s -> 215.3s] 但是在大模型时代呢, [215.3s -> 216.3s] 然后我们其实逐渐发现, [216.3s -> 218.3s] 对于模型的性能而言, [218.3s -> 221.3s] 模型的参数量以外是一个最主要的一个因素, [221.3s -> 222.3s] 然后在这个, [222.3s -> 225.3s] 在模型架构本身的一些改进性的变化呢, [225.3s -> 227.3s] 其实相对于模型参数本身的提升, [227.3s -> 230.3s] 对带来的这个性能提升是相当微小的, [230.3s -> 233.3s] 但是其实不同的架构在这个模型的推理方面, [233.3s -> 234.3s] 然后性能差异是巨大的, [234.3s -> 237.3s] 而且这个也是主要决定了模型最后的一个部署的价格, [237.3s -> 241.3s] 然后其实这两年大家主要在这个方向去努力, [241.3s -> 242.3s] 然后对于我而言的话, [242.3s -> 244.3s] 其实我们是在23年开始, [244.3s -> 246.3s] 然后探索这个现役助理, [246.3s -> 248.3s] 这样一个方向的一个工作, [248.3s -> 249.3s] 然后我们GPiDriveNet的工作, [249.3s -> 251.3s] 刚开始主要是解决了两个问题的, [251.3s -> 253.3s] 我觉得从现在这个解决, [253.3s -> 254.3s] 主要解决两个问题, [254.3s -> 255.3s] 第一个问题就是, [255.3s -> 257.3s] 现役助理怎么能尽量的去, [257.3s -> 259.3s] 在一些比较general的场景下, [259.3s -> 262.3s] 我们毕竟这个权助于这样的一个性能, [262.3s -> 264.3s] 因为linear从刚开始提出, [264.3s -> 267.3s] 主要是为了去用一个比较linear kernel, [267.3s -> 269.3s] 然后去一个kernalized方式去拟合, [269.3s -> 272.3s] 然后二次复杂度的权助于这样的一个pattern的, [272.3s -> 274.3s] 所以在之前那个时代, [274.3s -> 276.3s] 其实对于linear tension而言, [276.3s -> 278.3s] 它的位置信息它其实是不够sensitive的, [278.3s -> 280.3s] 然后其实当在那个时代, [280.3s -> 283.3s] linear tension和RN只是在形式上比较相似, [283.3s -> 285.3s] 但是从这个建模的特性上来讲, [285.3s -> 287.3s] RN其实还是比较强调, [287.3s -> 289.3s] 就是一些locality的一些表示, [289.3s -> 290.3s] 所以说在那个时代, [290.3s -> 293.3s] 我们在RNtension是比较早的引入了一个 [293.3s -> 294.3s] 揣点的一个记者这样的话, [294.3s -> 297.3s] 可以让这个现役助理在一个有限的这个 [297.3s -> 298.3s] 状态空间里, [298.3s -> 300.3s] 然后尽量的去研磨这一些, [300.3s -> 303.3s] 对最后的结果贡献足够大的一些信息, [303.3s -> 305.3s] 然后这个其实刚开始的一个multiply, [305.3s -> 307.3s] 除了这个模型性能以外呢, [307.3s -> 310.3s] 我们当时也是主要比较先的提出了这种 [310.3s -> 311.3s] trunkwise recurrent, [311.3s -> 312.3s] 就是trunkwise recurrent这样的一个, [312.3s -> 314.3s] 现行助理力的一个kernalized, [314.3s -> 316.3s] 就是kernal的这个计算形式, [316.3s -> 318.3s] 因为对于这个现行助理力来说呢, [318.3s -> 320.3s] 如果把这个整个的状态都展开了, [320.3s -> 323.3s] 然后在token这个维度去做这个, [323.3s -> 324.3s] 去做地规的计算的话,
[324.3s -> 326.3s] 它其实从从效率上并不是最优的, [326.3s -> 328.3s] 但是如果用仿照助理力这种这个, [328.3s -> 329.3s] 计算方式去建谋的, [329.3s -> 333.3s] 它又享受不到这个整体计算复杂度带来的优势。 [333.3s -> 336.3s] 所以说我们当时就是在这种primeral representation, [336.3s -> 337.3s] 从一些并形的, [337.3s -> 339.3s] 就是像全助理这样的一个计算形式, [339.3s -> 341.3s] 和就是全地规的这个计算形式之间, [341.3s -> 342.3s] 然后找到了一个shade off, [342.3s -> 344.3s] 也就是这个块地规的这样的一个计算形式, [344.3s -> 346.3s] 然后这个trunkwise requirement呢, [346.3s -> 347.3s] 我们既可以拿到这个整体的, [347.3s -> 349.3s] 一个计算复杂度上的一个手里, [349.3s -> 351.3s] 同时我们能在curnalize 层面, [351.3s -> 353.3s] 然后我们可以尽量多的去调用tensical, [353.3s -> 356.3s] 然后把这个local 的一些计算密度都拿满, [356.3s -> 359.3s] 这个是我们提出的一个比较有效的一个计算方式, [359.3s -> 361.3s] 然后大家其实如果可以关注到, [361.3s -> 362.3s] 就是之后的一些, [362.3s -> 363.3s] 其实所有的一些, [363.3s -> 364.3s] 现行助理的改进功能, [364.3s -> 368.3s] 都是基于这样trunkwise 的计算形式去计算的, [368.3s -> 369.3s] 对吧,包括manba2, [369.3s -> 370.3s] 然后gatedel3.net, [370.3s -> 371.3s] 包括, [371.3s -> 373.3s] 然后来到今天的这个cumin linear, [373.3s -> 374.3s] KDA 这样的一个计算模式, [374.3s -> 375.3s] 然后在这个计算, [375.3s -> 376.3s] 大的计算模式, [376.3s -> 377.3s] 这上能, [377.3s -> 379.3s] 然后又带来一些新的, [379.3s -> 380.3s] 比较细节上的变化, [380.3s -> 381.3s] 然后这个可能之后, [381.3s -> 382.3s] 对今天的后面会, [382.3s -> 384.3s] 就更详细的来继续进行讨论, [384.3s -> 387.3s] 然后当然从现在这个视角的, [387.3s -> 388.3s] 纯现役助理力, [388.3s -> 390.3s] 就作为纯现役助理力的一个模型, [390.3s -> 392.3s] 而来无疑是一个比较失败的一个尝试, [392.3s -> 393.3s] 因为无论如何, [393.3s -> 395.3s] 这个比较有限的一个contest, [395.3s -> 396.3s] 它都难以带来, [396.3s -> 399.3s] 就是在尝试文中和这个传助力力比较, [399.3s -> 400.3s] 完全相懂的一个性能, [400.3s -> 401.3s] 这个其实在这个, [401.3s -> 402.3s] 今天这个时间点, [402.3s -> 403.3s] 我们都知道是不可能的。 [403.3s -> 404.3s] 所以说, [404.3s -> 406.3s] 这个当时我们在23年吧, [406.3s -> 407.3s] 也是注意到了这个现象, [407.3s -> 408.3s] 所以说, [408.3s -> 409.3s] 我们就会尝试说, [409.3s -> 410.3s] 就是从这个全线役助理力, [410.3s -> 411.3s] 然后转到一个, [411.3s -> 414.3s] 这个hybrid的腾认的这样一个, [414.3s -> 415.3s] 架构的形式, [415.3s -> 416.3s] 对hybrid的腾认, [416.3s -> 417.3s] 就是其实大家顾名思义, [417.3s -> 418.3s] 就是很简单, [418.3s -> 419.3s] 包括CMK3, [419.3s -> 420.3s] 其实也是这样的嘛, [420.3s -> 421.3s] 就是用一些线役助理力, [421.3s -> 422.3s] 和一些这个全助理力, [422.3s -> 423.3s] 然后组合起来, [423.3s -> 425.3s] 然后作为一个模型的架构, [425.3s -> 427.3s] 然后这个本质上听起来就是, [427.3s -> 429.3s] 像是一个工程上的吹道夫, [429.3s -> 431.3s] 然后也是一个比较工程的解法, [431.3s -> 432.3s] 但是虽然如此呢, [432.3s -> 433.3s] 我们当时就发现一个现象, [433.3s -> 435.3s] 不过这个也是目前所大家公认的, [435.3s -> 436.3s] 就是混合助理力, [436.3s -> 438.3s] 它其实虽然从架构上来讲, [438.3s -> 439.3s] 是一种吹道夫, [439.3s -> 440.3s] 但是从最后模型, [440.3s -> 441.3s] 本身的表现来说, [441.3s -> 442.3s] 并不是一个吹道夫, [442.3s -> 443.3s] 包括大家其实发现, [443.3s -> 446.3s] 在保持一定的全助力力比例的基础上, [446.3s -> 447.3s] 整个模型, [447.3s -> 448.3s] 其实是可以获得无损甚至, [448.3s -> 450.3s] 更好的一个常常上差人表现的, [450.3s -> 451.3s] 也就是说, [451.3s -> 453.3s] 混合助理力模型的架构中, [453.3s -> 454.3s] 我们并没有牺牲一定的, [454.3s -> 456.3s] 这个全助力力的这个模型能力, [456.3s -> 457.3s] 从而带来工程上的, [457.3s -> 459.3s] 所以从这个角度上来讲, [459.3s -> 462.3s] 也是因为这个实验上的一个结论, [462.3s -> 464.3s] 然后从而导致这个混合助理力, [464.3s -> 466.3s] 现在被大规模的利用起来。 [466.3s -> 468.3s] 这是你的第一片工作是吧? [468.3s -> 469.3s] 对对对,是的。 [469.3s -> 470.3s] 然后后来的话, [470.3s -> 472.3s] 就是当时我们会发现说, [472.3s -> 473.3s] 这个混合助力, [473.3s -> 475.3s] 其实在工程上是一个百分之二work的方法, [475.3s -> 477.3s] 我觉得其实没有问题, [477.3s -> 478.3s] 其实直到今天work的, [478.3s -> 479.3s] 也还是不错嘛。 [479.3s -> 480.3s] 当然了, [480.3s -> 481.3s] 这个博士上来讲, [481.3s -> 482.3s] 就是这个东西, [482.3s -> 483.3s] 就是虽然他比较work, [483.3s -> 484.3s] 大家也愿意去说, [484.3s -> 485.3s] 但是那这个东西, [485.3s -> 486.3s] 从导致上, [486.3s -> 487.3s] 其实感觉就差点意思, [487.3s -> 488.3s] 而且感觉也不够有趣, [488.3s -> 489.3s] 因为那是我们觉得, [489.3s -> 492.3s] 就是如果只是把这两种混合助力力模型, [492.3s -> 493.3s] 结合起来的话, [493.3s -> 494.3s] 它有这么几个问题, [494.3s -> 495.3s] 我觉得最大的问题就是, [495.3s -> 497.3s] 它在推理的架构比, [497.3s -> 500.3s] 它永远是和这个混合比是正交的, [500.3s -> 501.3s] 或者说也不是正交, [501.3s -> 502.3s] 就是完全成正比例的, [502.3s -> 504.3s] 因为现在比如大家比较常用的是, [504.3s -> 506.3s] 这个混合助力力比全助力力,
[506.3s -> 507.3s] 大概是三比一, [507.3s -> 508.3s] 这样的一个比例, [508.3s -> 509.3s] 也就是全助力力, [509.3s -> 510.3s] 然后在整个模型里, [510.3s -> 512.3s] 大概是四分之一这样的一个比例, [512.3s -> 513.3s] 所以说, [513.3s -> 514.3s] 如果说我们认为, [514.3s -> 516.3s] 就四分之一是一个比较无损的, [516.3s -> 518.3s] 也是一个比较极限的比例的话, [518.3s -> 520.3s] 其实我们很拿到更大的加速比, [520.3s -> 521.3s] 也就是说, [521.3s -> 522.3s] 我们无论是profile还是做抵扣的, [522.3s -> 524.3s] 我们最多的加速比, [524.3s -> 525.3s] 也就是四倍, [525.3s -> 527.3s] 当然我们在做纯限性助力力的时候, [527.3s -> 528.3s] 我们希望是更高的, [528.3s -> 529.3s] 我们希望最后, [529.3s -> 530.3s] 如果混合助力力, [530.3s -> 532.3s] 它其实是一个这个常数级别的改进, [532.3s -> 533.3s] 所以当时觉得, [533.3s -> 534.3s] 可能不是很有意思, [534.3s -> 536.3s] 所以我们后来就做了优扣这样的一个工作, [536.3s -> 538.3s] 对,当时我们的一个multipension, [538.3s -> 540.3s] 就是我们从第一性原理去思考, [540.3s -> 541.3s] 为什么纯限性助力, [541.3s -> 545.3s] 没有办法获得和纯权助力一样的性能, [545.3s -> 546.3s] 原业很简单, [546.3s -> 548.3s] 我们至少希望模型有一些比较基本能力, [548.3s -> 549.3s] 比如说, [549.3s -> 551.3s] 我们至少有一个可以获取钱, [551.3s -> 552.3s] 那么全文信息的能力, [552.3s -> 553.3s] 所以说, [553.3s -> 554.3s] 在这个场景下, [554.3s -> 556.3s] 其实全上下一文的KV开始, [556.3s -> 558.3s] 这一点是没有办法去省掉的, [558.3s -> 559.3s] 所以说, [559.3s -> 560.3s] KV开始既然没有省掉, [560.3s -> 562.3s] 我们能不能从另一个维度去省掉, [562.3s -> 563.3s] 所以当时我们就觉得, [563.3s -> 564.3s] 既然说, [564.3s -> 566.3s] 从token长度这个维度没有办法去节省, [566.3s -> 567.3s] 所以说, [567.3s -> 569.3s] 我们找到了另外一条节省的方向, [569.3s -> 571.3s] 就是从这个层间这样去节省, [571.3s -> 573.3s] 所以优扣当时做的是一个, [573.3s -> 575.3s] 就是所有层共用一份KV开始, [575.3s -> 577.3s] 这样的一个架构的方式, [577.3s -> 578.3s] 然后另外一个就是, [578.3s -> 579.3s] 从模型的计算角度, [579.3s -> 581.3s] 就每一个token在decode的过程当中, [581.3s -> 583.3s] 对它的计算密度是没有办法去减少的, [583.3s -> 585.3s] 因为我们希望它保持一定的, [585.3s -> 587.3s] 这个权注意力的计算能力, [587.3s -> 588.3s] 然后这样它才能达到 [588.3s -> 590.3s] 我们希望的常常差弯能力, [590.3s -> 591.3s] 所以说, [591.3s -> 592.3s] 我们提出的另一个东西就是, [593.3s -> 595.3s] 模型的计算和存储结果开来, [595.3s -> 596.3s] 所以说, [596.3s -> 597.3s] 我们当时可以看到, [597.3s -> 598.3s] 虽然我们只有一份的KV开始, [598.3s -> 600.3s] 但是我们可以保持一个多层的, [600.3s -> 602.3s] 复合层身的这样的一个计算结构, [602.3s -> 603.3s] 所以说, [603.3s -> 604.3s] 在这个技术上, [604.3s -> 605.3s] 我们当时的优扣架构, [605.3s -> 607.3s] 我们只保留一份的KV开始, [607.3s -> 609.3s] 但是可以获得和权注意力, [609.3s -> 610.3s] 或者混合注意力, [610.3s -> 611.3s] 基本上可以等价的一个, [611.3s -> 613.3s] 模型的一个计算结果, [613.3s -> 614.3s] 然后这个架构, [614.3s -> 615.3s] 还有另外一个优势, [615.3s -> 616.3s] 就是我们在profile的时候, [616.3s -> 618.3s] 可以直接跳过权注意力的计算, [618.3s -> 619.3s] 因为profile, [619.3s -> 621.3s] 也就是模型, [621.3s -> 623.3s] 可以处理这个用户输入的, [623.3s -> 624.3s] 这样的一个阶段, [624.3s -> 625.3s] 我们本质上只是希望, [625.3s -> 627.3s] 我们可以拿到模型的KV开始, [627.3s -> 628.3s] 然后这个KV开始, [628.3s -> 629.3s] 是用于后续的这个, [629.3s -> 631.3s] 底后的一系列的Heat State, [631.3s -> 632.3s] 所以说, [632.3s -> 633.3s] 这个profile的唯一目的, [633.3s -> 635.3s] 就是去达到这个模型的KV开始, [635.3s -> 636.3s] 所以说,在这个, [636.3s -> 637.3s] 这种架构上, [637.3s -> 638.3s] 我们经过前面的一些, [638.3s -> 639.3s] Linear Tension的一个, [639.3s -> 640.3s] 计算, [640.3s -> 641.3s] 然后拿到了KV开始, [641.3s -> 642.3s] 这个就够了, [642.3s -> 643.3s] 因为profile阶段, [643.3s -> 644.3s] 我们是没有必要, [644.3s -> 645.3s] 就是解码出, [645.3s -> 646.3s] 每一个位置的, [646.3s -> 647.3s] 后续的next token prediction, [647.3s -> 648.3s] 所以在profile阶段, [648.3s -> 649.3s] 我们就可以直接, [649.3s -> 650.3s] 不过cross certain, [650.3s -> 651.3s] 但是在底后的阶段, [651.3s -> 652.3s] 我们可以保持, [652.3s -> 653.3s] 和这个传统模型, [653.3s -> 654.3s] 一样的一个计算能力, [654.3s -> 655.3s] 对,然后这个是我, [655.3s -> 656.3s] 相关的一些第二片工作, [656.3s -> 658.3s] 这个标题也挺有意思的, [658.3s -> 659.3s] 对,这个也是致敬嘛, [659.3s -> 660.3s] 有only look once, [660.3s -> 661.3s] 当然后来也有, [661.3s -> 663.3s] 后面一系列的致敬的工作, [663.3s -> 665.3s] 你只能缓存一次是吧? [665.3s -> 666.3s] 对,是的, [666.3s -> 668.3s] 对,这个其实在这个, [668.3s -> 669.3s] 从KV开始的存储角度, [669.3s -> 671.3s] 基本上已经达到极致了, [671.3s -> 672.3s] 因为我们都同意, [672.3s -> 673.3s] 如果从token wise,
[673.3s -> 674.3s] 角度我们必须, [674.3s -> 675.3s] 的话, [675.3s -> 676.3s] 一份其实就是最少了, [676.3s -> 677.3s] 不可能再少了, [677.3s -> 678.3s] 所以这个从KV开始角度, [678.3s -> 679.3s] 是一个比较极限的一个结构, [679.3s -> 680.3s] 对,然后我讲, [680.3s -> 681.3s] 我对personally, [681.3s -> 682.3s] 我的一个第三片工作, [682.3s -> 683.3s] 就是在这个工作里, [683.3s -> 684.3s] 我们其实解决了, [684.3s -> 686.3s] 就是从一个更通用的角度, [686.3s -> 687.3s] 来去考虑问题的话, [687.3s -> 688.3s] 就是模型的推理, [688.3s -> 689.3s] 开销主要就分为三个部分, [689.3s -> 691.3s] 就是prefile的这个时间开销, [691.3s -> 692.3s] 然后decode的开销, [692.3s -> 693.3s] 然后和KV开始的存储开销, [693.3s -> 695.3s] 这三个是最主要的, [695.3s -> 696.3s] 跟模型的推理平仪, [696.3s -> 697.3s] 不可能有第四个, [697.3s -> 698.3s] 然后用后这个工作呢, [698.3s -> 699.3s] 我们主要解决的是prefile, [699.3s -> 701.3s] 和解决了KV开始, [701.3s -> 702.3s] 但是我们没有解决decode, [702.3s -> 703.3s] 然后decode的话, [703.3s -> 704.3s] 我们后续是, [704.3s -> 705.3s] 或者大家会尝试, [705.3s -> 707.3s] 用这个sparse-tension的方式去解决, [707.3s -> 708.3s] 然后, [708.3s -> 709.3s] 但是K3, [709.3s -> 710.3s] 它其实目前是没有用sparse-tension, [710.3s -> 711.3s] 所以这块, [711.3s -> 712.3s] 对,今天就, [712.3s -> 713.3s] 对,今天就先不讲了, [713.3s -> 714.3s] 对, [714.3s -> 715.3s] 然后我们后面的一个工作, [715.3s -> 716.3s] 是一个和另一个, [716.3s -> 718.3s] 赛道是一个比较相似的工作, [718.3s -> 720.3s] 也就是loop-language model, [720.3s -> 721.3s] loop-language model, [721.3s -> 722.3s] 这个顾名思义, [722.3s -> 723.3s] 也就是我们在保持, [723.3s -> 724.3s] 一个固定的, [724.3s -> 725.3s] 模型参数大小的情况下, [725.3s -> 726.3s] 去, [726.3s -> 727.3s] 通过多次迭代, [727.3s -> 729.3s] 来去提升模型的flops, [729.3s -> 731.3s] 从而去提升模型的, [731.3s -> 732.3s] 总的一个, [732.3s -> 733.3s] 这个能力, [733.3s -> 734.3s] 所以loop, [734.3s -> 735.3s] 这一系列的工作, [735.3s -> 736.3s] 主要目的就是, [736.3s -> 737.3s] 可以再保持一个比较小的, [737.3s -> 738.3s] 模型参数的技术上, [738.3s -> 739.3s] 然后, [739.3s -> 740.3s] 取得比同参数的模型好, [740.3s -> 741.3s] 更多的一个效果, [741.3s -> 742.3s] 但是其实, [742.3s -> 744.3s] 传统的这个loop-language model, [744.3s -> 745.3s] 它, [745.3s -> 746.3s] 在decode的情况下, [746.3s -> 747.3s] 它的这个成本, [747.3s -> 748.3s] 其实是难以忍受的, [748.3s -> 749.3s] 因为它只是省了, [749.3s -> 750.3s] 模型参数, [750.3s -> 751.3s] 它其实并没有省计算, [751.3s -> 752.3s] 而且, [752.3s -> 753.3s] 在相同计算下的话, [753.3s -> 754.3s] 它其实是并不如, [754.3s -> 755.3s] 把参数展开, [755.3s -> 756.3s] 或者说, [756.3s -> 757.3s] 用一个更大的, [757.3s -> 758.3s] 但是不去loop的模型, [758.3s -> 759.3s] 它最后总的效果好的, [759.3s -> 760.3s] 比较传统的loop-language model, [760.3s -> 761.3s] 其实还有一个问题, [761.3s -> 762.3s] 就是, [762.3s -> 763.3s] 它的这个推理, [763.3s -> 764.3s] 它的这个carry catch, [764.3s -> 765.3s] 它的存储, [765.3s -> 766.3s] 它会随着这个模型推理的 [766.3s -> 767.3s] 深度而增加, [767.3s -> 768.3s] 所以说, [768.3s -> 769.3s] 最后总的算起来的loop-language model, [769.3s -> 771.3s] 所带来的总的carry catch, [771.3s -> 772.3s] 其实是相当大的, [772.3s -> 774.3s] 然后youco universal的这个工作, [774.3s -> 776.3s] 其实就是在这个youco价格的基础上, [776.3s -> 777.3s] 然后去做一个位置上的改变, [777.3s -> 778.3s] 也就是我们把loop的单元, [778.3s -> 780.3s] 然后变成一个很efficient的一个单元, [780.3s -> 781.3s] 然后从而去避免, [781.3s -> 782.3s] 就是推理的时候, [782.3s -> 783.3s] 一些额外的一些, [783.3s -> 784.3s] 或者比较大的成本, [784.3s -> 786.3s] 但是能保持它模型的一个, [786.3s -> 788.3s] 效果比较稳定的一个增长, [788.3s -> 789.3s] 结法也很简单, [789.3s -> 790.3s] 因为对于youco而言, [790.3s -> 791.3s] 毫无疑问, [791.3s -> 792.3s] 它是一个, [792.3s -> 793.3s] 这个混合注意力架构, [793.3s -> 794.3s] 但是我们混合注意力方式, [794.3s -> 796.3s] 它不是一个交错式的一个结构, [796.3s -> 797.3s] 它是一个, [797.3s -> 798.3s] 两端的一个结构, [798.3s -> 799.3s] 也就是说, [799.3s -> 800.3s] 我们模型推理的前期, [800.3s -> 801.3s] 它是一个全线性注意力, [801.3s -> 802.3s] 但是模型的后期, [802.3s -> 804.3s] 是一个全注意力这样的一个架构, [804.3s -> 806.3s] 所以说我们的选择是把这个, [806.3s -> 808.3s] 把loop这样的一个架构, [808.3s -> 810.3s] 集中在这个线性注意力, [810.3s -> 811.3s] 这样的一个位置, [811.3s -> 812.3s] 然后这样的话, [812.3s -> 814.3s] 我们对整体的kv开始增长, [814.3s -> 815.3s] 是比较小的,
[815.3s -> 816.3s] 因为linear-tension, [816.3s -> 817.3s] 它本身的kv开始, [817.3s -> 818.3s] 它其实是微乎其位的, [818.3s -> 819.3s] 然后第二个就是, [819.3s -> 820.3s] 线性注意力, [820.3s -> 821.3s] 它不仅省存储, [821.3s -> 822.3s] 它其实也是省了计算, [822.3s -> 824.3s] 就在常上下文这样的一个场景下, [824.3s -> 825.3s] 它其实带来的额外的计算, [825.3s -> 826.3s] 是相当小的, [826.3s -> 828.3s] 但是虽然它linear-tension, [828.3s -> 829.3s] 所带来的tension, [829.3s -> 830.3s] 的decode的计算, [830.3s -> 831.3s] 它是相当小的, [831.3s -> 833.3s] 但是从in-general的模型能力上的话, [833.3s -> 834.3s] 它, [834.3s -> 835.3s] 比如说模型的perplexity, [835.3s -> 836.3s] 或者说, [836.3s -> 837.3s] 从模型的skilling behavior, [837.3s -> 838.3s] 它是可以获得, [838.3s -> 839.3s] 足够接近全注意力, [839.3s -> 841.3s] 的这样的一个模型能力, [841.3s -> 842.3s] 所以说我们, [842.3s -> 843.3s] 我们这个架构, [843.3s -> 845.3s] 它其实可以达到的一个效果, [845.3s -> 846.3s] 就是从, [846.3s -> 847.3s] 用差不多这个, [847.3s -> 848.3s] 比如说我们用两倍, [848.3s -> 850.3s] 于原模型的这样一个, [850.3s -> 851.3s] 计算强度, [851.3s -> 852.3s] 我们基本上就会, [852.3s -> 854.3s] 可以获得两倍左右的一个性能提升, [854.3s -> 855.3s] 但是我们的模型存储, [855.3s -> 856.3s] 和这个模型的kv开始, [856.3s -> 858.3s] 还是保持和原模型, [858.3s -> 860.3s] 一个差不多这样的一个, [860.3s -> 861.3s] 这个推理开枪, [861.3s -> 862.3s] 对, [862.3s -> 863.3s] 这个是我自己参与的工作, [863.3s -> 864.3s] 而这篇工作, [864.3s -> 865.3s] 因为去年, [865.3s -> 866.3s] 开始这个loop language model, [866.3s -> 867.3s] 是一个大家比较, [867.3s -> 868.3s] 热议的一个话题嘛, [868.3s -> 869.3s] 然后我们在这方面, [869.3s -> 870.3s] 然后做了一些探索, [870.3s -> 872.3s] 所以你从23年一开始读博, [872.3s -> 873.3s] 你的研究方向, [873.3s -> 874.3s] 就一直在, [874.3s -> 876.3s] 架构创新上,对吧? [876.3s -> 877.3s] 对,是的, [877.3s -> 878.3s] 而这次k3, [878.3s -> 880.3s] 它在11m的架构, [880.3s -> 881.3s] 和预讯栈上, [881.3s -> 882.3s] 也做了很多工作, [882.3s -> 883.3s] 这是我们今天来找你, [883.3s -> 885.3s] 来带我们读论文的原因, [885.3s -> 886.3s] 对,是的, [887.3s -> 888.3s] 当时我们其实之间, [888.3s -> 889.3s] 也有一些讨论, [889.3s -> 890.3s] 然后其实, [890.3s -> 891.3s] 工作的这个连续性, [891.3s -> 892.3s] 其实还是比较强的, [892.3s -> 894.3s] 包括k3, [894.3s -> 895.3s] 它其实也是比较远风, [895.3s -> 896.3s] 不动地搬到了k3的一个, [896.3s -> 898.3s] 总的一个合板的里面的嘛, [898.3s -> 899.3s] 你为什么一直对架构创新, [899.3s -> 900.3s] 比较感兴趣? [900.3s -> 901.3s] 我觉得两方面吧, [901.3s -> 902.3s] 从个人角度, [902.3s -> 903.3s] 我觉得, [903.3s -> 904.3s] 架构创新, [904.3s -> 905.3s] 比较有意思, [905.3s -> 906.3s] 就是比较好玩, [906.3s -> 907.3s] 对, [907.3s -> 908.3s] 因为别的层面的工作的话, [908.3s -> 909.3s] 它其实, [909.3s -> 910.3s] 也有工程性的因素, [910.3s -> 911.3s] 会更强一些, [911.3s -> 912.3s] 当然,架构创新, [912.3s -> 913.3s] 它也有一些, [913.3s -> 914.3s] 工程性主要来源于, [914.3s -> 915.3s] 就是你需要做一些, [915.3s -> 916.3s] infra上的口底赞, [916.3s -> 918.3s] 但即使是infra上的口底赞, [918.3s -> 919.3s] 其实我们, [919.3s -> 920.3s] 之前也提到了, [920.3s -> 921.3s] 比如说我们提出, [921.3s -> 922.3s] 就是唱歌recon, [922.3s -> 923.3s] 这样的一几段结果, [923.3s -> 924.3s] 它本身其实也是, [924.3s -> 925.3s] infra层面的一个创新, [925.3s -> 926.3s] 所以我觉得这个事情, [926.3s -> 927.3s] 比较有意思, [927.3s -> 928.3s] 而且它比较能起到, [928.3s -> 929.3s] 一个, [929.3s -> 930.3s] 四两不前进的效果吧, [930.3s -> 931.3s] 我觉得对于一个博士商人, [931.3s -> 932.3s] 这块是一个, [932.3s -> 933.3s] 相当好的一个, [933.3s -> 934.3s] 这个研究领域, [934.3s -> 935.3s] 当然在, [935.3s -> 936.3s] 在2023年是这样的, [936.3s -> 937.3s] 2026年的话, [937.3s -> 938.3s] 可能, [938.3s -> 939.3s] 其实是越来越少了, [939.3s -> 940.3s] 这个是, [940.3s -> 941.3s] 其实从个人层面, [941.3s -> 942.3s] 带来的一个考虑, [942.3s -> 943.3s] 然后整个这个, [943.3s -> 944.3s] 领域的角度而言呢, [944.3s -> 945.3s] 我觉得, [945.3s -> 946.3s] 其实全注意力的话, [946.3s -> 947.3s] 它当时是一个, [947.3s -> 948.3s] 非常大的一个平底, [948.3s -> 949.3s] 如果说在这个大规模的, [949.3s -> 950.3s] 这个, [950.3s -> 951.3s] 如果大模型推理, [951.3s -> 952.3s] 是大规模的应用的话,
[952.3s -> 953.3s] 就是, [953.3s -> 954.3s] 这个东西, [954.3s -> 955.3s] 是一定可以解决, [955.3s -> 956.3s] 就是, [956.3s -> 957.3s] 是一定需要解决, [957.3s -> 958.3s] 而且我们相信, [958.3s -> 959.3s] 是一定可以解决的, [959.3s -> 960.3s] 所以说, [960.3s -> 961.3s] 在那个时间, [961.3s -> 962.3s] 我们觉得, [962.3s -> 963.3s] 从整个行业来讲, [963.3s -> 964.3s] 架构创新, [964.3s -> 965.3s] 是对于模型部手而言, [965.3s -> 966.3s] 那我们这次的主题, [966.3s -> 967.3s] 其实是, [967.3s -> 968.3s] 一起来读PIMI K3论文, [968.3s -> 969.3s] 但是, [969.3s -> 970.3s] 你对于这篇论文, [970.3s -> 971.3s] 有很多自己的想法, [971.3s -> 972.3s] 所以你也做了一个, [972.3s -> 973.3s] 不一样的, [973.3s -> 974.3s] 一个分享的结构, [974.3s -> 975.3s] 并不是, [975.3s -> 976.3s] 完全是, [976.3s -> 977.3s] 根据这篇论文展开, [977.3s -> 978.3s] 能不能介绍一下, [978.3s -> 979.3s] 你整体的分享的, [979.3s -> 980.3s] 一个结构和逻辑? [980.3s -> 981.3s] 我一般, [981.3s -> 982.3s] 讲talk的主要的逻辑, [982.3s -> 983.3s] 就是, [983.3s -> 984.3s] 从它, [984.3s -> 985.3s] 模型本身, [985.3s -> 986.3s] 比如说, [986.3s -> 987.3s] 从一个论文本身出发, [987.3s -> 988.3s] 当然, [988.3s -> 989.3s] 所有论文都是建立, [989.3s -> 990.3s] 在这些之前, [990.3s -> 991.3s] 无数个这个, [991.3s -> 992.3s] 所以我会选一些, [992.3s -> 993.3s] 比如说, [993.3s -> 994.3s] 它一个论文, [994.3s -> 995.3s] 它有, [995.3s -> 996.3s] 几方面的贡献, [996.3s -> 997.3s] 然后, [997.3s -> 998.3s] 它可能一个论文贡献, [998.3s -> 999.3s] 它在背后, [999.3s -> 1000.3s] 有一个历史研究室的, [1000.3s -> 1001.3s] 一个脉络, [1001.3s -> 1002.3s] 对, [1002.3s -> 1003.3s] 我一般的风格是, [1003.3s -> 1004.3s] 会把这个脉络打开, [1004.3s -> 1005.3s] 然后, [1005.3s -> 1006.3s] 这样会达到一个效果, [1006.3s -> 1007.3s] 就是, [1007.3s -> 1008.3s] 如果只看这篇论文, [1008.3s -> 1009.3s] 你会知道, [1009.3s -> 1010.3s] 它是这样做的, [1010.3s -> 1011.3s] 但你可能会不太清楚, [1011.3s -> 1012.3s] 它为什么这样做, [1012.3s -> 1013.3s] 或者说, [1013.3s -> 1014.3s] 历史上, [1014.3s -> 1015.3s] 大家是怎么做的, [1015.3s -> 1016.3s] 为什么, [1016.3s -> 1017.3s] 最后达到这个结构, [1017.3s -> 1018.3s] 我觉得, [1018.3s -> 1019.3s] 比如说, [1019.3s -> 1020.3s] 这篇论文的话, [1020.3s -> 1021.3s] 也会讨论的更, [1021.3s -> 1022.3s] 综合一些, [1022.3s -> 1023.3s] 因为, [1023.3s -> 1024.3s] 如果只是一个点的话, [1024.3s -> 1025.3s] 它其实, [1025.3s -> 1026.3s] 我觉得意义是不够大的, [1026.3s -> 1027.3s] 当然这块可能, [1027.3s -> 1028.3s] 这个, [1028.3s -> 1029.3s] 模型架构是一个, [1029.3s -> 1030.3s] 比较多的一个篇幅, [1030.3s -> 1031.3s] 主要也是因为, [1031.3s -> 1032.3s] 一个是KIMI Q3, [1032.3s -> 1033.3s] 它也做的, [1033.3s -> 1034.3s] 比较多的一个, [1034.3s -> 1035.3s] 模型架构, [1035.3s -> 1036.3s] 本身的创新做的, [1036.3s -> 1037.3s] 另一个就是, [1037.3s -> 1038.3s] 模型架构, [1038.3s -> 1039.3s] 这一块, [1039.3s -> 1040.3s] 它的研究的脉络, [1040.3s -> 1041.3s] 它其实是相当清晰的, [1041.3s -> 1042.3s] 而且它每一个部分, [1042.3s -> 1043.3s] 它其实都有一些, [1043.3s -> 1044.3s] 比较固定的一个credit, [1044.3s -> 1045.3s] 就是拆成一个一个点, [1045.3s -> 1047.3s] 然后把大家去讲出来, [1047.3s -> 1048.3s] 当然后面也会有一些, [1048.3s -> 1049.3s] 关于info的那种, [1049.3s -> 1050.3s] 因为现在其实, [1050.3s -> 1051.3s] 都是比较依赖这个, [1051.3s -> 1052.3s] info和模型架构的, [1052.3s -> 1053.3s] 和credit站嘛, [1053.3s -> 1054.3s] 所以这两块, [1054.3s -> 1055.3s] 它其实是密不可分的, [1055.3s -> 1056.3s] 别的一些, [1056.3s -> 1057.3s] 比如说这个play train data的话, [1057.3s -> 1058.3s] 大家肯定都是一个, [1058.3s -> 1059.3s] 比较密密的状态, [1059.3s -> 1060.3s] paper里也没有写, [1060.3s -> 1061.3s] 对,我也不会讲这个, [1061.3s -> 1062.3s] paper除了公开内容, [1062.3s -> 1063.3s] 以外的一些东西, [1063.3s -> 1064.3s] 所以这块可能, [1064.3s -> 1065.3s] 就会设列的少一些。 [1065.3s -> 1066.3s] 你的罗链结构, [1066.3s -> 1067.3s] 让我感觉到, [1067.3s -> 1069.3s] 其实我们最后看到的是, [1069.3s -> 1070.3s] k3的一个呈现, [1070.3s -> 1071.3s] 但是其实它是, [1071.3s -> 1072.3s] 有很多人的credit, [1072.3s -> 1074.3s] 它不只是kimi一家公司, [1074.3s -> 1075.3s] 对吧,
[1075.3s -> 1077.3s] 这也是现在做frontier, [1077.3s -> 1078.3s] 这些模型的, [1078.3s -> 1080.3s] 一个有意思的地方, [1080.3s -> 1081.3s] 它要吸收很多, [1081.3s -> 1082.3s] 之前其他人的工作, [1082.3s -> 1083.3s] 然后我们也把credit, [1083.3s -> 1085.3s] 都给到大家, [1085.3s -> 1086.3s] 我们这篇讲解, [1086.3s -> 1087.3s] 就是除了, [1087.3s -> 1088.3s] 你能理解k3, [1088.3s -> 1089.3s] 也能理解, [1089.3s -> 1090.3s] 它是怎么来的, [1090.3s -> 1091.3s] 对吧? [1091.3s -> 1092.3s] 对,是的, [1092.3s -> 1093.3s] 我觉得, [1093.3s -> 1094.3s] 做一个公司, [1094.3s -> 1095.3s] 比较科学的方式, [1095.3s -> 1096.3s] 就如果你最后想把, [1096.3s -> 1097.3s] 这个模型做好, [1097.3s -> 1098.3s] 你肯定是, [1098.3s -> 1099.3s] 当然是, [1099.3s -> 1100.3s] 如果说, [1100.3s -> 1101.3s] 比如说, [1101.3s -> 1102.3s] 你只想用自己的工作, [1102.3s -> 1103.3s] 那这样可能就是, [1103.3s -> 1104.3s] 没有必要了, [1104.3s -> 1105.3s] 如果是, [1105.3s -> 1106.3s] 基于这样的目的, [1106.3s -> 1107.3s] 去做工作, [1107.3s -> 1108.3s] 那可能你就会, [1108.3s -> 1109.3s] 错过一些, [1109.3s -> 1110.3s] 别人一些, [1110.3s -> 1111.3s] 做的比较好的工作, [1111.3s -> 1112.3s] 因为无论如何, [1112.3s -> 1113.3s] 整个行业, [1113.3s -> 1114.3s] 都是由大家集体推动的, [1114.3s -> 1115.3s] 所以我觉得, [1115.3s -> 1116.3s] 这个也是, [1116.3s -> 1117.3s] kimi k3, [1117.3s -> 1118.3s] 一个比较好的一个点, [1118.3s -> 1119.3s] 它其实, [1119.3s -> 1120.3s] 我觉得包括, [1120.3s -> 1121.3s] 它之前的一些paper, [1121.3s -> 1122.3s] 也是这样的, [1122.3s -> 1123.3s] 我觉得比较客观, [1123.3s -> 1124.3s] 或者比较真实的, [1124.3s -> 1125.3s] 把之前的一些工作, [1125.3s -> 1126.3s] 用一个比较, [1126.3s -> 1127.3s] 可靠的方式, [1127.3s -> 1128.3s] 比较好的一个点, [1128.3s -> 1129.3s] 对, [1129.3s -> 1130.3s] 我们这次是, [1130.3s -> 1131.3s] 从k3出发, [1131.3s -> 1132.3s] 然后其实串联起了, [1132.3s -> 1133.3s] 不管是, [1133.3s -> 1134.3s] 十几篇论文也好, [1134.3s -> 1135.3s] 还是, [1135.3s -> 1136.3s] 技术报告也好, [1136.3s -> 1137.3s] 还是, [1137.3s -> 1138.3s] 比如说, [1138.3s -> 1139.3s] 苏建宁老师的, [1139.3s -> 1140.3s] 国课也好, [1140.3s -> 1141.3s] 就是, [1141.3s -> 1142.3s] 是有很多的那种, [1142.3s -> 1143.3s] 那我很期待, [1143.3s -> 1144.3s] 我们开始吧, [1144.3s -> 1145.3s] 好, [1145.3s -> 1146.3s] kimi k3, [1146.3s -> 1147.3s] 从前面, [1147.3s -> 1148.3s] 它的一个, [1148.3s -> 1149.3s] 主要的卖点, [1149.3s -> 1150.3s] 来说的话, [1150.3s -> 1151.3s] 它其实, [1151.3s -> 1152.3s] 主打的是一些, [1152.3s -> 1153.3s] 我觉得从几个方面, [1153.3s -> 1154.3s] 它有一个, [1154.3s -> 1155.3s] 比较大的一个难过, [1155.3s -> 1156.3s] 首先, [1156.3s -> 1157.3s] 在这里, [1157.3s -> 1158.3s] 其实也没有太多, [1158.3s -> 1159.3s] 可以解读的, [1159.3s -> 1160.3s] 然后为什么, [1160.3s -> 1161.3s] 能达到这样的一个结果, [1161.3s -> 1162.3s] 然后kimi k3, [1162.3s -> 1163.3s] 主要claim的是, [1163.3s -> 1164.3s] 三个维度的一个scaling, [1164.3s -> 1165.3s] 然后, [1165.3s -> 1166.3s] 当我觉得最重要的, [1166.3s -> 1167.3s] 还是说, [1167.3s -> 1168.3s] 模型大小的一个scaling, [1168.3s -> 1169.3s] 就是, [1169.3s -> 1170.3s] 它做到了一个2.8T, [1170.3s -> 1171.3s] 这样的一个, [1171.3s -> 1172.3s] 模型大小, [1172.3s -> 1173.3s] 而且它是一个, [1173.3s -> 1174.3s] 比较有效的, [1174.3s -> 1175.3s] 一个scaling的结果, [1175.3s -> 1176.3s] 什么叫无效呢? [1176.3s -> 1177.3s] 无效的scaling, [1177.3s -> 1178.3s] 我今天就可以给你, [1178.3s -> 1179.3s] 我晚上回去, [1179.3s -> 1180.3s] 起一个这个, [1180.3s -> 1181.3s] 2.8T的模型unit, [1181.3s -> 1182.3s] 我跑个100P的token, [1182.3s -> 1183.3s] 然后我就可以放出来, [1183.3s -> 1184.3s] 无效的, [1184.3s -> 1185.3s] 所以说这个scaling, [1185.3s -> 1186.3s] 当然是要, [1186.3s -> 1187.3s] 永远是建立在, [1187.3s -> 1188.3s] 有效的基础上, [1188.3s -> 1189.3s] kimi k3, [1189.3s -> 1190.3s] 就是在这个2.8T, [1190.3s -> 1191.3s] 这个scaling, [1191.3s -> 1192.3s] 做了一个有效的scaling, [1192.3s -> 1193.3s] 然后这个, [1193.3s -> 1194.3s] 模型参数大小, [1194.3s -> 1195.3s] 包括, [1195.3s -> 1196.3s] 模型的一个激活, [1196.3s -> 1197.3s] 它来到了100B, [1197.3s -> 1198.3s] 左右这样的一个量级,
[1198.3s -> 1199.3s] 其实在kimi k3, [1199.3s -> 1200.3s] 发布的时间点, [1200.3s -> 1201.3s] 其实是比, [1201.3s -> 1202.3s] 国内开源模型的, [1202.3s -> 1203.3s] 其他几家, [1203.3s -> 1204.3s] 要大很多的, [1204.3s -> 1205.3s] 这样一个, [1205.3s -> 1206.3s] 情况的, [1206.3s -> 1207.3s] 然后它另一个, [1207.3s -> 1208.3s] 扩展是在, [1208.3s -> 1209.3s] 模型上下文长度的, [1209.3s -> 1210.3s] 这样一个扩展, [1210.3s -> 1211.3s] 这样一个为动的, [1211.3s -> 1212.3s] 它做到了one million, [1212.3s -> 1213.3s] 这样的一个量级, [1213.3s -> 1214.3s] 然后one million的话, [1214.3s -> 1215.3s] 它自然是可以, [1215.3s -> 1216.3s] 获得更大的, [1216.3s -> 1217.3s] 一个上下文的窗口, [1217.3s -> 1218.3s] 然后去解决, [1218.3s -> 1219.3s] 更复杂的一个任务, [1219.3s -> 1220.3s] 所以说, [1220.3s -> 1221.3s] 就是从, [1221.3s -> 1222.3s] 模型总的, [1222.3s -> 1223.3s] 来看的话, [1223.3s -> 1224.3s] 我觉得还是, [1224.3s -> 1225.3s] 遵循一个, [1225.3s -> 1226.3s] 第一期原理, [1226.3s -> 1227.3s] 就是更大的模型, [1227.3s -> 1228.3s] 才有更大的, [1228.3s -> 1229.3s] 一个智能上限, [1229.3s -> 1230.3s] 如果别的东西, [1230.3s -> 1231.3s] 没有做太错的话, [1231.3s -> 1232.3s] 其实大家可以看到, [1232.3s -> 1233.3s] 这个模型的参数大小, [1233.3s -> 1234.3s] 还是解决, [1234.3s -> 1235.3s] 模型智能最本质的, [1235.3s -> 1236.3s] 一个参数量, [1236.3s -> 1237.3s] 当然, [1237.3s -> 1238.3s] 你有无数种方式, [1238.3s -> 1239.3s] 去达到一个, [1239.3s -> 1240.3s] 对内, [1240.3s -> 1241.3s] 或者对外, [1241.3s -> 1242.3s] 一个满意的结果, [1242.3s -> 1243.3s] 但是, [1243.3s -> 1244.3s] 从模型的能力本质上, [1244.3s -> 1245.3s] 模型的参数大小, [1245.3s -> 1246.3s] 还是最有效的一个方式, [1246.3s -> 1247.3s] 而Kimi确认, [1247.3s -> 1248.3s] 是一个, [1248.3s -> 1249.3s] 相当早期, [1249.3s -> 1250.3s] 或者说, [1250.3s -> 1251.3s] 相当成功的, [1251.3s -> 1252.3s] 达到了这样的一个量, [1252.3s -> 1253.3s] 对, [1253.3s -> 1254.3s] 然后到这个, [1254.3s -> 1255.3s] 模型结构, [1255.3s -> 1256.3s] 过长节, [1256.3s -> 1257.3s] 模型结构, [1257.3s -> 1258.3s] 过长节的话, [1258.3s -> 1259.3s] 就是Kimi K3, [1259.3s -> 1260.3s] 其实是, [1260.3s -> 1261.3s] 综合了, [1261.3s -> 1262.3s] 就是Kimi整个团队, [1262.3s -> 1263.3s] 包括这个, [1263.3s -> 1264.3s] 整个业界, [1264.3s -> 1265.3s] 然后过去一年以来, [1265.3s -> 1266.3s] 我想主要是, [1266.3s -> 1267.3s] 这个模型skilling本身, [1267.3s -> 1268.3s] 或者说, [1268.3s -> 1269.3s] 一些非模型架构的, [1269.3s -> 1270.3s] 一些创新, [1270.3s -> 1271.3s] 所以说, [1271.3s -> 1272.3s] Kimi K2, [1272.3s -> 1273.3s] 当时, [1273.3s -> 1274.3s] 主要沿用的就是, [1274.3s -> 1275.3s] DBC的一个结构嘛, [1275.3s -> 1276.3s] 但是K3, [1276.3s -> 1277.3s] 这块的话, [1277.3s -> 1278.3s] 它其实就跟K2, [1278.3s -> 1279.3s] 大不一样的, [1279.3s -> 1280.3s] Kimi K3, [1280.3s -> 1281.3s] 它本身引入了, [1281.3s -> 1282.3s] 很多, [1282.3s -> 1283.3s] 比较新的, [1283.3s -> 1284.3s] 或者说, [1284.3s -> 1285.3s] 比较创新的, [1285.3s -> 1286.3s] 一些设计元素, [1286.3s -> 1287.3s] 对, [1287.3s -> 1288.3s] 包括对外, [1288.3s -> 1289.3s] 自己的也好, [1289.3s -> 1290.3s] 别人的也好, [1290.3s -> 1291.3s] 有些比较创新的, [1291.3s -> 1292.3s] 一些赛品也好, [1292.3s -> 1293.3s] 或者说, [1293.3s -> 1294.3s] 比较细节的, [1295.3s -> 1296.3s] 首先的话, [1296.3s -> 1297.3s] 是hybrid attention, [1297.3s -> 1298.3s] hybrid attention, [1298.3s -> 1299.3s] 我刚刚也, [1299.3s -> 1300.3s] 讨论过一些, [1300.3s -> 1301.3s] 好的, [1301.3s -> 1302.3s] 我们可以重新, [1302.3s -> 1303.3s] 翻回头来, [1303.3s -> 1304.3s] 然后再从Kimi 本身, [1304.3s -> 1305.3s] 它的一个, [1305.3s -> 1306.3s] 写作的writing, [1306.3s -> 1307.3s] 来去看起, [1307.3s -> 1308.3s] 然后这块的话, [1308.3s -> 1309.3s] 我会先讲一下, [1309.3s -> 1310.3s] 这个先行注意力的, [1310.3s -> 1311.3s] 一个在过去三四年, [1311.3s -> 1312.3s] 以来的一个, [1312.3s -> 1313.3s] 历史的发展状态, [1313.3s -> 1314.3s] 因为你如果, [1314.3s -> 1315.3s] 直接读这个, [1315.3s -> 1316.3s] Kimi Delta attention的话, [1316.3s -> 1317.3s] 你会发现, [1317.3s -> 1318.3s] 它的这个, [1318.3s -> 1319.3s] 公式相当复杂,
[1319.3s -> 1320.3s] 而且说, [1320.3s -> 1321.3s] 对不同的像, [1321.3s -> 1322.3s] 然后具体是怎么来的, [1322.3s -> 1323.3s] 它具体承担, [1323.3s -> 1324.3s] 什么样的一个作用, [1325.3s -> 1326.3s] 公式的话, [1326.3s -> 1327.3s] 它会,你会发现, [1327.3s -> 1328.3s] 它特别特别长, [1328.3s -> 1329.3s] 比如说, [1329.3s -> 1330.3s] 比近代的诚审, [1330.3s -> 1331.3s] 它其实是要复杂很多的, [1331.3s -> 1332.3s] 它其实每一项, [1332.3s -> 1333.3s] 它背后都有一个, [1333.3s -> 1334.3s] 历史性的一些因素, [1334.3s -> 1335.3s] 或者说, [1335.3s -> 1336.3s] 大家从, [1336.3s -> 1337.3s] 对整个模型结构, [1337.3s -> 1338.3s] 探索, [1338.3s -> 1339.3s] 最后得到的, [1339.3s -> 1340.3s] 这样的一个结果, [1340.3s -> 1341.3s] 所以说, [1341.3s -> 1342.3s] 所以说, [1342.3s -> 1343.3s] 如果想了解, [1343.3s -> 1344.3s] 这个Kimi Delta 诚审, [1344.3s -> 1345.3s] 对这个最后, [1345.3s -> 1346.3s] 是怎么设计出来的, [1346.3s -> 1347.3s] 我们还是有必要, [1347.3s -> 1348.3s] 去探索之前的, [1348.3s -> 1349.3s] 一些先行注意力, [1349.3s -> 1350.3s] 经过了, [1350.3s -> 1351.3s] 怎样的一个发展阶段, [1352.3s -> 1353.3s] 对,这个其实是, [1353.3s -> 1354.3s] 刚开始, [1354.3s -> 1355.3s] 我们必不可少的一个, [1355.3s -> 1356.3s] 这个先行注意力的一个, [1356.3s -> 1357.3s] 发展的阶段吧, [1357.3s -> 1358.3s] 因为刚开始, [1358.3s -> 1359.3s] 这个先行注意力, [1359.3s -> 1360.3s] 非常非常简单, [1360.3s -> 1361.3s] 我们就是这个, [1361.3s -> 1362.3s] Kimi 成出来, [1362.3s -> 1363.3s] 得到一个外籍, [1363.3s -> 1364.3s] 然后把它加起来, [1364.3s -> 1365.3s] 对,刚开始的先行注意力, [1365.3s -> 1366.3s] 其实比Refnet, [1366.3s -> 1367.3s] 还要更简单, [1367.3s -> 1368.3s] 然后Refnet, [1368.3s -> 1369.3s] 在这个先行注意力的, [1369.3s -> 1370.3s] 基础上的, [1370.3s -> 1371.3s] 然后我们引入了, [1371.3s -> 1372.3s] 一个衰减像, [1372.3s -> 1373.3s] 然后这个衰减, [1373.3s -> 1374.3s] 是跟token 的位置, [1374.3s -> 1375.3s] 是有关的, [1375.3s -> 1376.3s] 然后这样的话, [1376.3s -> 1377.3s] 就把这个linear, [1377.3s -> 1378.3s] 它是从一个比较, [1378.3s -> 1379.3s] plation, [1379.3s -> 1380.3s] 从位置无关, [1380.3s -> 1381.3s] 然后不让它变上的, [1381.3s -> 1382.3s] 一个位置有关, [1382.3s -> 1383.3s] 然后位置有关, [1383.3s -> 1384.3s] 最主要的方式, [1384.3s -> 1385.3s] 一个就是, [1385.3s -> 1386.3s] 我们可以加rope, [1386.3s -> 1387.3s] 另一个就是, [1387.3s -> 1388.3s] 我们可以引入衰减像, [1388.3s -> 1389.3s] 因为无论如何, [1389.3s -> 1390.3s] 语言的特性, [1390.3s -> 1391.3s] 它就是更近的位置, [1391.3s -> 1392.3s] 它有更高的一个前众, [1392.3s -> 1393.3s] 所以说, [1393.3s -> 1394.3s] 如果我们在一个有限的, [1394.3s -> 1395.3s] 上下方理想, [1395.3s -> 1396.3s] 达到更好的结果, [1396.3s -> 1397.3s] 衰减这项, [1397.3s -> 1398.3s] 其实是必不可少的, [1398.3s -> 1399.3s] 对, [1399.3s -> 1400.3s] 所以说, [1400.3s -> 1401.3s] 这块是这个先行注意力, [1401.3s -> 1402.3s] 比较前期的一个, [1402.3s -> 1403.3s] 一个经验吧, [1403.3s -> 1404.3s] 然后这个, [1404.3s -> 1405.3s] 然后这个衰减像, [1405.3s -> 1406.3s] 这个影响就是, [1406.3s -> 1407.3s] 穿克瑞康的, [1407.3s -> 1408.3s] 这样的一个计算形式, [1408.3s -> 1409.3s] 对, [1409.3s -> 1410.3s] 因为如果我们只是, [1410.3s -> 1411.3s] 这个做一些偏学术性的, [1411.3s -> 1412.3s] 就或者说, [1412.3s -> 1413.3s] 只是发paper的话, [1413.3s -> 1414.3s] 其实从这个, [1414.3s -> 1415.3s] Colonize的一个, [1415.3s -> 1416.3s] 足够高的一个有效率, [1416.3s -> 1417.3s] 其实是大家不会, [1417.3s -> 1419.3s] 从一个比较刚开始, [1419.3s -> 1420.3s] 就比较强调, [1420.3s -> 1421.3s] 一个是, [1421.3s -> 1422.3s] 我们主要发现的, [1422.3s -> 1423.3s] 我们完全使用这个, [1423.3s -> 1424.3s] 地规的这样的一个, [1424.3s -> 1425.3s] 形式计算, [1425.3s -> 1426.3s] 它其实特别满, [1426.3s -> 1427.3s] 甚至比, [1427.3s -> 1428.3s] 就是在训练广中, [1428.3s -> 1429.3s] 甚至直接要比这个, [1429.3s -> 1430.3s] Parallel Remplitation, [1430.3s -> 1431.3s] 就类似全数一厘, [1431.3s -> 1432.3s] 计算方式, [1432.3s -> 1433.3s] 它还要满, [1433.3s -> 1434.3s] 但如果我们直接用, [1434.3s -> 1435.3s] 这种Parallel Remplitation, [1435.3s -> 1436.3s] 有感觉, [1436.3s -> 1437.3s] 有感觉, [1437.3s -> 1438.3s] 十分傻逼,对, [1438.3s -> 1439.3s] 因为, [1439.3s -> 1440.3s] 对, [1440.3s -> 1441.3s] 因为我们在训练之后, [1441.3s -> 1442.3s] 相当于完全没有,
[1442.3s -> 1443.3s] 享受到这个, [1443.3s -> 1444.3s] 现行注意力的手艺, [1444.3s -> 1445.3s] 它跟全注意力的, [1445.3s -> 1446.3s] 这个, [1446.3s -> 1447.3s] 计算强度是一模一样的, [1447.3s -> 1448.3s] 甚至还要更高的, [1448.3s -> 1449.3s] 因为它可能有一些, [1449.3s -> 1450.3s] 对, [1450.3s -> 1451.3s] 有别的处理, [1451.3s -> 1452.3s] 或者说, [1452.3s -> 1453.3s] 我们的这个, [1453.3s -> 1454.3s] 颗豆写的, [1454.3s -> 1455.3s] 写的没有Flash, [1455.3s -> 1456.3s] 很认好, [1456.3s -> 1457.3s] 这些都是有可能的, [1457.3s -> 1458.3s] 所以说, [1458.3s -> 1459.3s] 我们当时觉得, [1459.3s -> 1460.3s] 能够享受到, [1460.3s -> 1461.3s] 一个复杂度的, [1461.3s -> 1462.3s] 一个加速, [1462.3s -> 1463.3s] 所以当时, [1463.3s -> 1464.3s] 我们就做了, [1464.3s -> 1465.3s] 这样的一个事情, [1465.3s -> 1466.3s] 然后Restnet之后呢, [1466.3s -> 1467.3s] 有两个, [1467.3s -> 1468.3s] 比较重要的, [1468.3s -> 1469.3s] 一个节点, [1469.3s -> 1470.3s] 在这, [1470.3s -> 1471.3s] 对, [1471.3s -> 1472.3s] 我觉得一个是Mamba, [1472.3s -> 1473.3s] Mamba, [1473.3s -> 1474.3s] 当时是把这个, [1474.3s -> 1475.3s] 位置无关的, [1475.3s -> 1476.3s] 衰减, [1476.3s -> 1477.3s] 变成了这个, [1477.3s -> 1478.3s] 位置有关的, [1478.3s -> 1479.3s] 是一个衰减, [1479.3s -> 1480.3s] 然后, [1480.3s -> 1481.3s] 接下来就是DeltaNet, [1481.3s -> 1482.3s] DeltaNet的话, [1482.3s -> 1483.3s] 当然这个概念, [1483.3s -> 1484.3s] 不是宋林去提的, [1484.3s -> 1485.3s] 当时是这个, [1485.3s -> 1486.3s] DeltaNet, [1486.3s -> 1487.3s] 是之前的一个工作, [1487.3s -> 1488.3s] 然后, [1488.3s -> 1489.3s] 拖浪动作锐的, [1489.3s -> 1490.3s] 其实就一句话, [1490.3s -> 1492.3s] 就是如何能让这个DeltaNet, [1492.3s -> 1493.3s] 转化为一个, [1493.3s -> 1494.3s] GPU可计算的一个, [1494.3s -> 1495.3s] 这个Chunk Recurrent, [1495.3s -> 1496.3s] 这样的一个计算模式, [1496.3s -> 1497.3s] 对, [1497.3s -> 1498.3s] 当时宋林去做, [1498.3s -> 1499.3s] 这方面工作的时候, [1499.3s -> 1500.3s] 我还稍微有点疑惑, [1500.3s -> 1501.3s] 我说, [1501.3s -> 1502.3s] 看上去好像, [1502.3s -> 1503.3s] 就是DeltaNet, [1503.3s -> 1504.3s] 不太可以并行, [1504.3s -> 1505.3s] 他说可以并行, [1505.3s -> 1506.3s] 并且他已经搞定了, [1506.3s -> 1507.3s] 所以说, [1507.3s -> 1508.3s] 从这个GPU, [1508.3s -> 1509.3s] GPU efficiency的角度, [1509.3s -> 1510.3s] 就是DeltaNet, [1510.3s -> 1511.3s] 主要是解决, [1511.3s -> 1512.3s] 这是infra上的一个困难, [1512.3s -> 1513.3s] 而且这个解决方式, [1513.3s -> 1514.3s] 我觉得还是一个, [1514.3s -> 1515.3s] 然后DeltaNet, [1515.3s -> 1516.3s] 刚出来的时候, [1516.3s -> 1517.3s] 我们当时尝试去解决, [1517.3s -> 1518.3s] 就因为当时, [1518.3s -> 1519.3s] 我们知道, [1519.3s -> 1520.3s] 就是线性注意力, [1520.3s -> 1522.3s] 它在处理全上摄像文的, [1522.3s -> 1523.3s] 这样的一个能力场, [1523.3s -> 1524.3s] 它其实是不如, [1524.3s -> 1525.3s] 对,不如全注意力的, [1525.3s -> 1527.3s] 所以当时就有两个方案, [1527.3s -> 1528.3s] 第一个方案就是, [1528.3s -> 1529.3s] 我直接认输, [1529.3s -> 1530.3s] 我就去认定, [1530.3s -> 1532.3s] 现在注意力是这个, [1532.3s -> 1533.3s] 不可能匹敌全注意力的, [1533.3s -> 1534.3s] 当然, [1534.3s -> 1535.3s] 可能当时, [1535.3s -> 1536.3s] 我是这种心态, [1536.3s -> 1537.3s] 我当时意识到, [1537.3s -> 1538.3s] 可能从这个, [1538.3s -> 1539.3s] 线性注意力的这个视角出发, [1539.3s -> 1540.3s] 是很难去匹敌全注意力的, [1540.3s -> 1541.3s] 我当然是这个想法, [1541.3s -> 1542.3s] 当然宋丽是另一个想法, [1542.3s -> 1543.3s] 她当然觉得, [1543.3s -> 1544.3s] 我还可以再努力吧, [1544.3s -> 1546.3s] 我们可以努力的去提升, [1546.3s -> 1547.3s] 这个线性注意力, [1547.3s -> 1548.3s] 本身的一个, [1548.3s -> 1549.3s] 尝试一下文的一个容量, [1549.3s -> 1551.3s] 从而获得更好的一个节奏, [1551.3s -> 1552.3s] 然后DeltaNet, [1552.3s -> 1553.3s] 当时就是这样的一个目的, [1553.3s -> 1554.3s] 通过这种方式, [1554.3s -> 1555.3s] 我们可以获得, [1555.3s -> 1556.3s] 比之前的这个RatNet, [1556.3s -> 1557.3s] 很满满的, [1557.3s -> 1558.3s] 更好的一个, [1558.3s -> 1560.3s] 尝试一下文的一个容量的能力, [1560.3s -> 1561.3s] 本质上, [1561.3s -> 1562.3s] 其实也就是, [1562.3s -> 1563.3s] 在相同的这个, [1563.3s -> 1564.3s] KV开始大小的情况下, [1564.3s -> 1566.3s] 就是从上网上提高了, [1566.3s -> 1567.3s] 这个线注意力的, [1567.3s -> 1568.3s] 一个上下文的容量, [1568.3s -> 1569.3s] 当时DeltaNet, [1569.3s -> 1571.3s] 是没有做这个位置衰减的,
[1571.3s -> 1572.3s] 当时从这个, [1572.3s -> 1573.3s] 从Properlastic, [1573.3s -> 1574.3s] 或者说, [1574.3s -> 1575.3s] 从这个Bunchmark上, [1575.3s -> 1576.3s] 它的结果不是特别好, [1576.3s -> 1577.3s] 所以说, [1577.3s -> 1578.3s] 一个比较显然的事情, [1578.3s -> 1579.3s] 就是, [1579.3s -> 1580.3s] 既然我们知道, [1580.3s -> 1581.3s] 这个位置衰减, [1581.3s -> 1582.3s] 这个事情, [1582.3s -> 1583.3s] 本身是可以帮助, [1583.3s -> 1584.3s] 这个模型总的一个能力的, [1584.3s -> 1585.3s] 那我为什么不把, [1585.3s -> 1586.3s] 这个模型衰减, [1586.3s -> 1587.3s] 然后和这个DeltaNet, [1587.3s -> 1588.3s] 这样一个更高容量的, [1588.3s -> 1589.3s] Linear, [1589.3s -> 1590.3s] 谈认结合起来, [1590.3s -> 1591.3s] Gate的DeltaNet, [1591.3s -> 1592.3s] 正是这么做的, [1592.3s -> 1593.3s] 我们可以去, [1593.3s -> 1594.3s] 结合DeltaRoot, [1594.3s -> 1595.3s] 这样的一个, [1595.3s -> 1596.3s] 更高的一个, [1596.3s -> 1597.3s] 线性注意力的计算容量, [1597.3s -> 1598.3s] 然后同时, [1598.3s -> 1600.3s] 我们给它带来一个衰减, [1600.3s -> 1601.3s] 然后同时融合这两个, [1601.3s -> 1602.3s] 我们就可以得到一个, [1602.3s -> 1603.3s] 更优的, [1603.3s -> 1605.3s] 线性注意力的一个表达形式, [1605.3s -> 1606.3s] 然后, [1606.3s -> 1607.3s] 这里就可以看到, [1607.3s -> 1608.3s] 如果没有AlphaT, [1608.3s -> 1609.3s] 这一项的话, [1609.3s -> 1610.3s] 它其实就是一个, [1610.3s -> 1611.3s] 比较经典的DeltaNet, [1611.3s -> 1612.3s] 然后引入衰减的, [1612.3s -> 1613.3s] 引入衰减之后的话, [1613.3s -> 1614.3s] 我们就可以得到, [1614.3s -> 1615.3s] Gate的DeltaNet, [1615.3s -> 1616.3s] 这样的一个形式, [1616.3s -> 1618.3s] 然后大家就可以注意到, [1618.3s -> 1619.3s] 这个表达形式, [1619.3s -> 1620.3s] 其实可以, [1620.3s -> 1621.3s] 其实已经比, [1621.3s -> 1622.3s] 刚开始的线性注意力, [1622.3s -> 1623.3s] 要复杂很多了, [1623.3s -> 1624.3s] 对, [1624.3s -> 1625.3s] 因为如果把, [1625.3s -> 1626.3s] 这项, [1626.3s -> 1627.3s] 如果把这个, [1627.3s -> 1628.3s] ST-1, [1628.3s -> 1629.3s] 后面的一个, [1629.3s -> 1630.3s] 系数完全消掉的话, [1630.3s -> 1631.3s] 其实就是, [1631.3s -> 1632.3s] 最紧点的, [1632.3s -> 1633.3s] Linear Tension, [1633.3s -> 1634.3s] 然后, [1634.3s -> 1635.3s] RestNet和Memba, [1635.3s -> 1636.3s] 是把这项消掉的, [1636.3s -> 1637.3s] 得到一个结果, [1637.3s -> 1638.3s] 就是我对这个, [1638.3s -> 1639.3s] 上一个时间点的, [1639.3s -> 1640.3s] 历史状态, [1640.3s -> 1641.3s] 然后进行一个衰减, [1641.3s -> 1642.3s] 然后这样的话, [1642.3s -> 1643.3s] 是之前的RestNet和Memba, [1643.3s -> 1644.3s] 这样的一个结果, [1644.3s -> 1645.3s] 然后DeltaNet, [1645.3s -> 1646.3s] 它是引入了一个, [1646.3s -> 1648.3s] Gate的DeltaRoot, [1648.3s -> 1649.3s] 这样的一个方案, [1650.3s -> 1651.3s] 然后写成, [1651.3s -> 1652.3s] 地位形式的话, [1652.3s -> 1653.3s] 它其实就额外, [1653.3s -> 1654.3s] 再增加了一下, [1654.3s -> 1655.3s] 然后这样的复杂度, [1655.3s -> 1656.3s] 其实就慢慢的, [1656.3s -> 1657.3s] 去结架了上去, [1657.3s -> 1658.3s] 我们再回到Kimili, [1658.3s -> 1659.3s] 它其实在这个, [1659.3s -> 1660.3s] Gate的DeltaNet, [1660.3s -> 1661.3s] 基本上, [1661.3s -> 1662.3s] 又变了一个东西, [1662.3s -> 1663.3s] 然后大家可以, [1663.3s -> 1664.3s] 去对比一下, [1664.3s -> 1665.3s] 这个是怎么引入的, [1665.3s -> 1666.3s] 主要的区别, [1666.3s -> 1667.3s] 它其实就在这个, [1667.3s -> 1668.3s] 传简项上, [1668.3s -> 1669.3s] 比如说, [1669.3s -> 1670.3s] 在RestNet, [1670.3s -> 1671.3s] 然后Memba2, [1671.3s -> 1672.3s] 和Gate的DeltaRoot的, [1672.3s -> 1673.3s] 情况下的, [1673.3s -> 1674.3s] 当然了, [1674.3s -> 1675.3s] 就是线性这个, [1675.3s -> 1676.3s] 注意力是分害的, [1676.3s -> 1677.3s] 所以说, [1677.3s -> 1678.3s] 是分害的, [1678.3s -> 1679.3s] 但我们一般写, [1679.3s -> 1680.3s] 但我们一般写公设的话, [1680.3s -> 1681.3s] 我们会考虑, [1681.3s -> 1682.3s] 只有一个害的的情况, [1682.3s -> 1683.3s] 所以说, [1683.3s -> 1685.3s] 如果只有一个害的的话, [1685.3s -> 1686.3s] Gate的DeltaNet也好, [1686.3s -> 1687.3s] 然后, [1687.3s -> 1688.3s] 之前的工作也好, [1688.3s -> 1689.3s] 它其实这个, [1689.3s -> 1690.3s] 衰减上, [1690.3s -> 1691.3s] 它其实是一个标辆, [1691.3s -> 1692.3s] 对,它是一个标辆, [1692.3s -> 1693.3s] 也就是说, [1693.3s -> 1694.3s] 我整个一个害的, [1694.3s -> 1695.3s] 它遵循的这个, [1695.3s -> 1696.3s] 衰减系数是一致的, [1696.3s -> 1697.3s] 然后这样的好处是,
[1697.3s -> 1698.3s] 它在Colonel上, [1698.3s -> 1699.3s] 比较容易, [1699.3s -> 1700.3s] 就是写Colonel比较方便, [1700.3s -> 1701.3s] 因为衰减上, [1701.3s -> 1702.3s] 它本身想, [1702.3s -> 1703.3s] 比较好的一个, [1703.3s -> 1704.3s] 对,如果说, [1704.3s -> 1705.3s] 如果把这个, [1705.3s -> 1706.3s] 你可以拆成, [1706.3s -> 1707.3s] 个Refine的形式的话, [1707.3s -> 1708.3s] 我们再去写Colonel的话, [1708.3s -> 1709.3s] 它其实是一个, [1709.3s -> 1710.3s] 不太好处理的一个项, [1710.3s -> 1711.3s] 这个是, [1711.3s -> 1712.3s] 出于写的, [1712.3s -> 1713.3s] 写Colonel方面, [1713.3s -> 1714.3s] 然后从这个, [1714.3s -> 1715.3s] 模型能力方面, [1715.3s -> 1716.3s] 当然我们污用以问, [1716.3s -> 1717.3s] 就是我们把一个, [1717.3s -> 1718.3s] 标辆的衰减, [1718.3s -> 1719.3s] 然后变成Channelized衰减, [1719.3s -> 1720.3s] 它严格的, [1720.3s -> 1721.3s] 来说是能力更强的, [1721.3s -> 1722.3s] 对,然后, [1722.3s -> 1723.3s] KimiDeltaNet, [1723.3s -> 1724.3s] 它其实就是, [1724.3s -> 1725.3s] 把这个Gate的DeltaNet, [1725.3s -> 1726.3s] 这个衰减上, [1726.3s -> 1727.3s] 然后从一个标辆, [1727.3s -> 1728.3s] 变成了一个, [1728.3s -> 1729.3s] 更Fan Green Control, [1729.3s -> 1730.3s] 这样的一个量, [1730.3s -> 1731.3s] 然后这样的话, [1731.3s -> 1732.3s] 它就可以带来, [1732.3s -> 1733.3s] 就是每个Channel, [1733.3s -> 1734.3s] 可以的衰减系数, [1734.3s -> 1735.3s] 是不一样的, [1735.3s -> 1736.3s] 这样的话, [1736.3s -> 1737.3s] 我们这样, [1737.3s -> 1738.3s] 可以带来一个, [1738.3s -> 1739.3s] 严格更好的, [1739.3s -> 1740.3s] 一个能力的上限,对吧, [1740.3s -> 1741.3s] 因为从工质上来讲, [1741.3s -> 1742.3s] 它是严格更好的, [1742.3s -> 1743.3s] 无论如何, [1743.3s -> 1744.3s] 这个Channelized的Decay, [1744.3s -> 1745.3s] 它是, [1745.3s -> 1746.3s] 可以退化到一个, [1746.3s -> 1747.3s] 比较均匀的Decay的, [1747.3s -> 1748.3s] 这样一个, [1748.3s -> 1749.3s] 严格更强的, [1749.3s -> 1750.3s] 一个模型能力, [1750.3s -> 1751.3s] 它会带来一些, [1751.3s -> 1752.3s] 更好的效果, [1752.3s -> 1753.3s] 当然了,就是, [1753.3s -> 1754.3s] 它其实是有一些代价的, [1754.3s -> 1755.3s] 它的代价就是, [1755.3s -> 1756.3s] 它写Kernel, [1756.3s -> 1757.3s] 会更麻烦一些, [1757.3s -> 1758.3s] 它的麻烦的点, [1758.3s -> 1759.3s] 就在于说, [1759.3s -> 1760.3s] 我们不能说, [1760.3s -> 1761.3s] 我们作为一个Decay, [1761.3s -> 1762.3s] 我们其他部分, [1762.3s -> 1763.3s] 可以用一个, [1763.3s -> 1764.3s] 比较方便的方式, [1764.3s -> 1765.3s] 去做这个, [1765.3s -> 1767.3s] 去利用探测号来进行计算, [1767.3s -> 1768.3s] 如果是一个, [1768.3s -> 1769.3s] 标辆的衰减项的话, [1769.3s -> 1770.3s] 它的处理会特别特别容易, [1770.3s -> 1771.3s] 它其实一个Tile, [1771.3s -> 1773.3s] 就只有一个变量就完事, [1773.3s -> 1774.3s] 但是如果, [1774.3s -> 1775.3s] 把它从标辆, [1775.3s -> 1776.3s] 变成一个Channelized的话, [1776.3s -> 1777.3s] 对它的这个处理难度, [1777.3s -> 1778.3s] 就会, [1778.3s -> 1779.3s] 就会增加很多, [1779.3s -> 1780.3s] 然后这样的一个处理难度, [1780.3s -> 1781.3s] 也会带来这个, [1781.3s -> 1783.3s] 在Kimi K3里边, [1783.3s -> 1785.3s] 一个更, [1785.3s -> 1786.3s] 更细节的, [1786.3s -> 1787.3s] 一个Code Design的一个处理, [1787.3s -> 1788.3s] 这样的话, [1788.3s -> 1789.3s] 我们就来到了这个, [1789.3s -> 1790.3s] Lower Bundy的Decay, [1790.3s -> 1791.3s] 就为什么有这个东西, [1791.3s -> 1792.3s] 两方面的原因, [1792.3s -> 1793.3s] 一方面就是, [1793.3s -> 1794.3s] 我们可以认为, [1794.3s -> 1795.3s] 从算法层面, [1795.3s -> 1797.3s] 我们希望它不要Decay的太快, [1797.3s -> 1798.3s] 但是, [1798.3s -> 1799.3s] 从Paper本身而言的话, [1799.3s -> 1801.3s] 它其实是为了和Kernel, [1801.3s -> 1802.3s] 来进行一个Code Design, [1802.3s -> 1803.3s] 原因在于说, [1803.3s -> 1804.3s] 就是, [1804.3s -> 1805.3s] 我们想去处理, [1805.3s -> 1806.3s] 更Find Grand Decay的话, [1806.3s -> 1807.3s] 我们需要在这个数值上, [1807.3s -> 1808.3s] 做一个比较小卖的处理, [1808.3s -> 1809.3s] 也就是, [1809.3s -> 1810.3s] 对于Q和Kernel也, [1810.3s -> 1812.3s] 我们会做一个Decay的, [1812.3s -> 1813.3s] 倒数的一个变换, [1813.3s -> 1814.3s] 我可以举个例子吧, [1814.3s -> 1815.3s] 最简单的例子就是, [1815.3s -> 1817.3s] -2可以表示为这个3.5嘛, [1817.3s -> 1818.3s] 这个其实也, [1818.3s -> 1820.3s] 跟Rope的思想是比较一致的, [1820.3s -> 1821.3s] Rope的其实, [1821.3s -> 1823.3s] 在这个infollow上, [1823.3s -> 1824.3s] 一个特别方便的地方, [1824.3s -> 1825.3s] 就是, [1825.3s -> 1826.3s] 它可以通过这个, [1826.3s -> 1827.3s] 绝对位置变换,
[1827.3s -> 1828.3s] 来去表示相对位置变换, [1828.3s -> 1829.3s] 所以, [1829.3s -> 1830.3s] 如果在这个情况下, [1830.3s -> 1831.3s] 它整个的一个计算, [1831.3s -> 1832.3s] 会容易很多, [1832.3s -> 1834.3s] 然后Rope它的思路, [1834.3s -> 1835.3s] 它的思路, [1835.3s -> 1836.3s] 其实就是用绝对位置, [1836.3s -> 1837.3s] 来去表示相对位置, [1837.3s -> 1838.3s] 所以说, [1838.3s -> 1839.3s] 对于衰减而言, [1839.3s -> 1840.3s] 它其实也可以用绝对位置, [1840.3s -> 1842.3s] 来去表示相对位置, [1842.3s -> 1843.3s] 也就是说, [1843.3s -> 1844.3s] 比如说, [1844.3s -> 1845.3s] 我们有一个衰减像, [1845.3s -> 1846.3s] 比如说, [1846.3s -> 1847.3s] 它是一个alpha的平方, [1847.3s -> 1848.3s] 对吧, [1848.3s -> 1849.3s] alpha的平方, [1849.3s -> 1850.3s] 这样的一个衰减像, [1850.3s -> 1851.3s] 当然这个衰减像, [1851.3s -> 1852.3s] 可能是第10个token, [1852.3s -> 1853.3s] 对第2个token, [1853.3s -> 1854.3s] 或者说, [1854.3s -> 1855.3s] 第100个token, [1855.3s -> 1856.3s] 对102个token, [1856.3s -> 1857.3s] 所以说, [1857.3s -> 1858.3s] 我们如果想用绝对位置的话, [1858.3s -> 1859.3s] 我们就会选择, [1859.3s -> 1860.3s] 让Q先做一个, [1860.3s -> 1861.3s] 比如说, [1861.3s -> 1862.3s] 我让K的, [1862.3s -> 1863.3s] 又做一个, [1863.3s -> 1865.3s] 三四方的一个衰减的提升, [1865.3s -> 1866.3s] 然后让K的话, [1866.3s -> 1867.3s] 做一个,比如说, [1867.3s -> 1868.3s] 五四方的一个反衰减, [1868.3s -> 1869.3s] 然后这样的话, [1869.3s -> 1870.3s] 我通过这个惩罚结合率, [1870.3s -> 1871.3s] 我们就可以得出, [1871.3s -> 1872.3s] 和原来的地规, [1872.3s -> 1874.3s] 一个比较等价的形式, [1874.3s -> 1875.3s] 然后这样就带来一个问题, [1875.3s -> 1876.3s] 对于这个kime delta, [1876.3s -> 1877.3s] tension来说的话, [1877.3s -> 1878.3s] 它会对QK, [1878.3s -> 1879.3s] 它有一边, [1879.3s -> 1881.3s] 它会除一个很小的数, [1881.3s -> 1882.3s] 对成一个很小的数, [1882.3s -> 1883.3s] 可能没有关系, [1883.3s -> 1884.3s] 它无非就是dk到0, [1884.3s -> 1886.3s] 它并不会带来这个, [1886.3s -> 1888.3s] 当然我们也不希望它dk到0, [1888.3s -> 1889.3s] 当然从, [1889.3s -> 1890.3s] 数值精度上来讲的话, [1890.3s -> 1891.3s] 我们希望让它, [1891.3s -> 1893.3s] 控制在这个bf16的精度范围内, [1893.3s -> 1895.3s] 这样利用Rope那种, [1895.3s -> 1896.3s] 绝对位置来表示, [1896.3s -> 1897.3s] 相对位置编码的, [1897.3s -> 1898.3s] 这样的一个方式, [1898.3s -> 1899.3s] 它才是有效的, [1899.3s -> 1900.3s] 所以说为了, [1900.3s -> 1901.3s] 让衰减在一定的, [1901.3s -> 1902.3s] 唱歌范围内, [1902.3s -> 1903.3s] 然后控制在bf16的, [1903.3s -> 1905.3s] 就在一个固定的唱歌内部, [1905.3s -> 1906.3s] 让它控制在这个, [1906.3s -> 1907.3s] 一定的精度范围内的话, [1907.3s -> 1908.3s] 我们是需要, [1908.3s -> 1909.3s] 从数学上, [1909.3s -> 1910.3s] 把它控制住的, [1910.3s -> 1911.3s] 比如说, [1911.3s -> 1912.3s] kime linear, [1912.3s -> 1913.3s] 它这一块是一个, [1913.3s -> 1914.3s] 它这个是一个16个token tile, [1914.3s -> 1916.3s] 或者我们就希望这个衰减, [1916.3s -> 1917.3s] 在这16个token的Range里边, [1917.3s -> 1919.3s] 不要超出这个bf16的, [1919.3s -> 1920.3s] 这样的一个范围, [1920.3s -> 1921.3s] 当然, [1921.3s -> 1922.3s] bf16的精度范围, [1922.3s -> 1923.3s] 这个是我们已知的, [1923.3s -> 1924.3s] 我们可以通过这个, [1924.3s -> 1925.3s] bf16的精度范围, [1925.3s -> 1926.3s] 然后反解出来, [1926.3s -> 1927.3s] 在16个token, [1927.3s -> 1928.3s] 这样的一个区间内, [1928.3s -> 1929.3s] 然后我们最多, [1929.3s -> 1931.3s] 可以衰减到多大的量, [1931.3s -> 1932.3s] 然后kime delta, [1932.3s -> 1934.3s] 它就大概选择这样的一个量, [1934.3s -> 1935.3s] 然后, [1935.3s -> 1936.3s] 这块我们可以去证明说, [1936.3s -> 1937.3s] 就在16个token的tile里, [1937.3s -> 1938.3s] 我们是可以, [1938.3s -> 1939.3s] 这个衰减, [1939.3s -> 1940.3s] 像是不超出, [1940.3s -> 1941.3s] bf16 dynamic range, [1941.3s -> 1943.3s] 这块的这个loader body的dk, [1943.3s -> 1945.3s] 它更像是一种code design, [1945.3s -> 1946.3s] 我们通过这个, [1946.3s -> 1948.3s] 模型算法层面的一些控制, [1948.3s -> 1949.3s] 对, [1949.3s -> 1950.3s] 然后让它获得, [1950.3s -> 1951.3s] 就是在一定tile的内部, [1951.3s -> 1953.3s] 然后不要让它有数值方面的问题, [1953.3s -> 1954.3s] 这样的话, [1954.3s -> 1955.3s] 整个kernelize的一个方式, [1955.3s -> 1956.3s] 会更加的去通上, [1956.3s -> 1957.3s] 当然了, [1957.3s -> 1958.3s] 如果不去限制, [1958.3s -> 1960.3s] kernel肯定也有自己的写法, [1960.3s -> 1961.3s] 当然了, [1961.3s -> 1962.3s] 那种写法可能就会低效一些, [1962.3s -> 1963.3s] 所以说, [1963.3s -> 1964.3s] 为了保证一个高效的实现, [1964.3s -> 1965.3s] kime delta, [1965.3s -> 1967.3s] 才用了在一定的这个tile trunk,
[1967.3s -> 1969.3s] 然后控制它最大的一个, [1970.3s -> 1971.3s] 这样的一个方式, [1971.3s -> 1972.3s] 对, [1972.3s -> 1973.3s] 然后kime delta, [1973.3s -> 1974.3s] 调整大概就是这样的, [1974.3s -> 1975.3s] 其实拖到东瑞的, [1975.3s -> 1976.3s] 也很简单, [1976.3s -> 1977.3s] 第一个就是, [1977.3s -> 1978.3s] 我们kime delta, [1978.3s -> 1979.3s] 把JDN, [1979.3s -> 1980.3s] 这样的一个, [1980.3s -> 1981.3s] 对计算方式, [1981.3s -> 1982.3s] 扩展了一下, [1982.3s -> 1983.3s] 它的计算能力, [1983.3s -> 1984.3s] 然后为了扩展的计算能力, [1984.3s -> 1986.3s] 带来的一些额外的音符上的麻烦, [1986.3s -> 1988.3s] 然后他们在模型的表达范围内, [1988.3s -> 1989.3s] 采取了一些阵子, [1989.3s -> 1990.3s] 然后让它满足 [1990.3s -> 1991.3s] kernelize的一个方式, [1991.3s -> 1992.3s] 然后最后得到了, [1992.3s -> 1993.3s] 这个kime k3, [1993.3s -> 1995.3s] 采用的最后的一个形式, [1995.3s -> 1996.3s] OK, [1996.3s -> 1998.3s] 这个环节是gate的MLA, [1998.3s -> 1999.3s] 顾名思义, [1999.3s -> 2000.3s] 它就是把两个, [2000.3s -> 2001.3s] 对, [2001.3s -> 2002.3s] 把两块的模型, [2002.3s -> 2003.3s] 结合了起来, [2003.3s -> 2004.3s] MLA, [2004.3s -> 2005.3s] 可能大家都很熟悉了, [2005.3s -> 2006.3s] 对, [2006.3s -> 2007.3s] 是dpsk v2, [2007.3s -> 2008.3s] 刚开始去用的, [2008.3s -> 2009.3s] 主要目的是, [2009.3s -> 2010.3s] 对, [2010.3s -> 2011.3s] 主要目的是, [2011.3s -> 2012.3s] 减少一些k开始的一个开销, [2012.3s -> 2013.3s] 然后MLA的这个配置呢, [2013.3s -> 2015.3s] 后面主要是被这个dpsk v3, [2015.3s -> 2016.3s] 和kime k2的时候, [2016.3s -> 2017.3s] 去采用的, [2017.3s -> 2018.3s] 当然dpsk v4没有用, [2018.3s -> 2020.3s] 因为kime k2也用了, [2020.3s -> 2022.3s] 然后kime的同学们认为呢, [2022.3s -> 2023.3s] 就是MLA, [2023.3s -> 2024.3s] 如果在这个全注意力, [2024.3s -> 2025.3s] 这样的一个scope内部, [2025.3s -> 2026.3s] 大家觉得, [2026.3s -> 2027.3s] 至少还是一个, [2027.3s -> 2028.3s] 可以接受的一个形式, [2028.3s -> 2029.3s] 或者说, [2029.3s -> 2030.3s] 没有必要去大动的一个形式, [2030.3s -> 2031.3s] 所以说, [2031.3s -> 2032.3s] 这个k3还是采用了, [2032.3s -> 2033.3s] 跟k2一样的, [2033.3s -> 2034.3s] 这样的一个形式, [2034.3s -> 2036.3s] 然后在这个MLA的基础上呢, [2036.3s -> 2037.3s] 增加了一个gate的, [2037.3s -> 2038.3s] 这样的一个操作, [2038.3s -> 2040.3s] 然后gate的tension呢, [2040.3s -> 2041.3s] 最早应该是, [2041.3s -> 2043.3s] 千万团队刚开始去用的, [2043.3s -> 2044.3s] 对, [2044.3s -> 2046.3s] 然后从千万这个团队的标题, [2046.3s -> 2047.3s] 也可以看出来, [2047.3s -> 2048.3s] gate的tension, [2048.3s -> 2049.3s] 它当时主要是, [2049.3s -> 2050.3s] 解决的哪些问题, [2050.3s -> 2052.3s] 比如说这个long linearality, [2052.3s -> 2053.3s] 然后gate的tension, [2053.3s -> 2054.3s] 可以带来额外的, [2054.3s -> 2055.3s] 一个计算的一个强度, [2055.3s -> 2056.3s] 然后sparsity, [2056.3s -> 2057.3s] 和tension think free, [2057.3s -> 2058.3s] 然后这个东西, [2058.3s -> 2059.3s] 可能并不是那么显然, [2059.3s -> 2060.3s] 这个就得具体看, [2060.3s -> 2061.3s] 它的一个paper, [2061.3s -> 2062.3s] 但是whatever, [2062.3s -> 2063.3s] 我觉得, [2063.3s -> 2064.3s] delta的tension, [2064.3s -> 2065.3s] 大家最bite硬的一个点, [2065.3s -> 2066.3s] 就是它的一个, [2066.3s -> 2067.3s] 训练美丽性, [2067.3s -> 2068.3s] 而且这个训练美丽性, [2068.3s -> 2069.3s] 它是一个, [2069.3s -> 2070.3s] 我觉得是一个, [2070.3s -> 2072.3s] 被广泛人认过的, [2072.3s -> 2074.3s] 这样的一个形式, [2074.3s -> 2075.3s] 大家可以从, [2075.3s -> 2076.3s] 千万这个, [2076.3s -> 2077.3s] 进来图里, [2077.3s -> 2078.3s] 可以去看到, [2078.3s -> 2080.3s] 对于一个pre-train的round而言, [2080.3s -> 2081.3s] 我们还是希望它, [2081.3s -> 2083.3s] 从模型能力上, [2083.3s -> 2084.3s] 如果不是最有, [2084.3s -> 2085.3s] 但也没有关系, [2085.3s -> 2086.3s] 对吧, [2086.3s -> 2087.3s] 因为模型的能力, [2087.3s -> 2088.3s] 其实本质上, [2088.3s -> 2089.3s] 最主要的因素, [2089.3s -> 2090.3s] 是模型的参数大小, [2090.3s -> 2091.3s] 所以说好一点, [2091.3s -> 2092.3s] 差一点, [2092.3s -> 2093.3s] 它都不如稳定性, [2093.3s -> 2094.3s] 要重要, [2094.3s -> 2095.3s] 因为如果稳定性不好的话, [2095.3s -> 2096.3s] 它会带来很多, [2096.3s -> 2097.3s] 麻烦的问题, [2097.3s -> 2098.3s] 甚至比较, [2098.3s -> 2099.3s] 对,比较, [2099.3s -> 2100.3s] 比较大的问题, [2100.3s -> 2101.3s] 就是你整个round的讯, [2101.3s -> 2102.3s] 不敢来, [2102.3s -> 2103.3s] 然后你前边整个的, [2103.3s -> 2104.3s] 这个, [2104.3s -> 2105.3s] 前边整个的time point,
[2105.3s -> 2106.3s] 都废掉了, [2106.3s -> 2107.3s] 这个其实对于这个, [2107.3s -> 2108.3s] 对, [2108.3s -> 2109.3s] 我觉得对于任何团队而言, [2111.3s -> 2112.3s] 要不要的去提升, [2112.3s -> 2113.3s] 模型的美内性, [2113.3s -> 2114.3s] 这个还是一个, [2114.3s -> 2115.3s] 大家不要愿意采用的, [2115.3s -> 2116.3s] 一个技术吧, [2116.3s -> 2117.3s] 然后前面的, [2117.3s -> 2118.3s] getting的, [2118.3s -> 2119.3s] 这个前面三, [2119.3s -> 2120.3s] 应该是, [2120.3s -> 2121.3s] 对, [2121.3s -> 2122.3s] 前面三, [2122.3s -> 2123.3s] 应该是没有用, [2123.3s -> 2124.3s] 后来的这个, [2124.3s -> 2125.3s] 后来的前面next, [2125.3s -> 2126.3s] 包括前面3.5, [2126.3s -> 2127.3s] 3.6, [2127.3s -> 2128.3s] 应该都采用了, [2128.3s -> 2129.3s] 这样的一个架构, [2129.3s -> 2130.3s] 虽然它会带来, [2130.3s -> 2131.3s] 这个一定的, [2131.3s -> 2132.3s] 这个额外的, [2132.3s -> 2133.3s] 这个计算开要, [2133.3s -> 2134.3s] 但是它会对, [2134.3s -> 2135.3s] 这个模型的美内性, [2135.3s -> 2136.3s] 会带来特别大的一个好处, [2136.3s -> 2137.3s] 然后这个是, [2137.3s -> 2138.3s] 对, [2138.3s -> 2139.3s] 是在这个, [2139.3s -> 2140.3s] 这块上引入的吗? [2140.3s -> 2141.3s] 对, [2141.3s -> 2142.3s] 但这个设计, [2142.3s -> 2143.3s] 它其实无论是, [2143.3s -> 2144.3s] 你跟, [2144.3s -> 2145.3s] 这个东西是跟, [2145.3s -> 2146.3s] JQA或者说MLA, [2146.3s -> 2147.3s] 它本身是一个, [2147.3s -> 2148.3s] 对, [2148.3s -> 2149.3s] 正交的一个设计方式, [2149.3s -> 2150.3s] 所以说, [2150.3s -> 2151.3s] 这QMK3, [2151.3s -> 2152.3s] 把这块, [2152.3s -> 2153.3s] 对, [2153.3s -> 2154.3s] 这块做了一个结合, [2154.3s -> 2155.3s] 就把getting的, [2155.3s -> 2156.3s] 谈认的这样的一个, [2156.3s -> 2157.3s] 这个, [2157.3s -> 2158.3s] 稳定性的一个方式, [2158.3s -> 2159.3s] 引入到MLA当中, [2159.3s -> 2160.3s] 然后这样的话, [2160.3s -> 2161.3s] 它本身也不会破坏, [2161.3s -> 2162.3s] 这个MLA本身的一个, [2162.3s -> 2163.3s] 推理性的同时, [2163.3s -> 2164.3s] 可以提升, [2164.3s -> 2165.3s] 这个模型的一个, [2165.3s -> 2166.3s] 对, [2166.3s -> 2167.3s] 这个模型的一个, [2167.3s -> 2168.3s] 推理性的一个, [2168.3s -> 2170.3s] 为什么V4, [2170.3s -> 2172.3s] 没有再继续沿用MLA? [2172.3s -> 2173.3s] 对, [2173.3s -> 2175.3s] 因为他们有别的东西了吗? [2175.3s -> 2176.3s] 你觉得MLA, [2176.3s -> 2178.3s] 在未来还会成为一个共识吗? [2178.3s -> 2179.3s] 因为我记得, [2179.3s -> 2181.3s] 鲁夫利之前跟我说过, [2181.3s -> 2183.3s] 他觉得在A正时代, [2183.3s -> 2185.3s] MLA应该会被替代, [2185.3s -> 2186.3s] 你觉得MLA, [2186.3s -> 2187.3s] 在未来会成为共识吗? [2187.3s -> 2189.3s] 我们相同技术上讲, [2189.3s -> 2190.3s] MLA, [2190.3s -> 2191.3s] 它本身就是MQA的一个, [2191.3s -> 2193.3s] 等价的一个形式, [2193.3s -> 2194.3s] 所以说MLA, [2194.3s -> 2195.3s] 其实本质上, [2195.3s -> 2196.3s] 在未来行的东西, [2196.3s -> 2197.3s] 它只是一个更好的随道。 [2197.3s -> 2198.3s] 大家其实没有发现的一点, [2198.3s -> 2199.3s] 就是, [2199.3s -> 2200.3s] 如果大家想把MLA, [2200.3s -> 2201.3s] 用好的话, [2201.3s -> 2202.3s] 它其实想达到, [2202.3s -> 2203.3s] 相同的一个计算效果, [2203.3s -> 2204.3s] 它其实会增加, [2204.3s -> 2205.3s] 更多的, [2205.3s -> 2206.3s] 腾认的计算, [2206.3s -> 2207.3s] 去弥补这方面的一个损失。 [2207.3s -> 2208.3s] 所以说, [2208.3s -> 2209.3s] 我个人认为, [2209.3s -> 2210.3s] 就是MLA, [2210.3s -> 2211.3s] 主要拿到的手艺, [2211.3s -> 2213.3s] 其实是可以被更好的, [2213.3s -> 2214.3s] 这个GQA的, [2214.3s -> 2215.3s] 这个, [2215.3s -> 2216.3s] 参数设计, [2216.3s -> 2217.3s] 基本上是, [2217.3s -> 2218.3s] 可以拿到绝大多数的手艺的。 [2218.3s -> 2219.3s] 为什么DPSc, [2219.3s -> 2220.3s] 没有继续沿用MLA? [2220.3s -> 2221.3s] 对, [2221.3s -> 2222.3s] 这样的一个, [2222.3s -> 2223.3s] 转化形式, [2223.3s -> 2224.3s] 因为DPSc V4, [2224.3s -> 2225.3s] 它主要, [2225.3s -> 2226.3s] 后面主要推Sparse, [2226.3s -> 2227.3s] 对, [2227.3s -> 2228.3s] Sparse跟MLA, [2228.3s -> 2229.3s] 它其实不是一个, [2229.3s -> 2230.3s] 百分百兼容的东西, [2230.3s -> 2231.3s] 尤其是在这个, [2231.3s -> 2232.3s] 在Profile阶段, [2232.3s -> 2233.3s] 对, [2233.3s -> 2234.3s] 而且, [2234.3s -> 2235.3s] 它们其实, [2235.3s -> 2236.3s] 是用了这个, [2236.3s -> 2237.3s] MLA的等价的MQA形式,
[2237.3s -> 2238.3s] 因为从, [2238.3s -> 2239.3s] 从数学上来讲, [2239.3s -> 2240.3s] MLA, [2240.3s -> 2241.3s] 它本质上, [2241.3s -> 2242.3s] 就是一个大号的MQA, [2242.3s -> 2243.3s] 所以DPSc V4, [2243.3s -> 2244.3s] 用的是一个大号的MQA, [2244.3s -> 2245.3s] 我觉得, [2245.3s -> 2246.3s] 本质上区别, [2246.3s -> 2247.3s] 不是很大的。 [2247.3s -> 2248.3s] 罗福利, [2248.3s -> 2249.3s] 当时是, [2249.3s -> 2250.3s] 它觉得, [2250.3s -> 2251.3s] MLA对CHAT来说, [2251.3s -> 2252.3s] 是一个, [2252.3s -> 2253.3s] 优秀的模型结构, [2253.3s -> 2254.3s] 但是, [2254.3s -> 2255.3s] 它觉得不那么适合, [2255.3s -> 2256.3s] Asian的方式, [2256.3s -> 2258.3s] MLA在设计之初, [2258.3s -> 2259.3s] 为了达到很好的, [2259.3s -> 2261.3s] 仿存和计算的比例, [2261.3s -> 2262.3s] 在, [2262.3s -> 2263.3s] 当时的H系列芯片上, [2263.3s -> 2264.3s] 实现级不浪费, [2264.3s -> 2265.3s] 算力又打破, [2265.3s -> 2266.3s] 仿存平仅, [2266.3s -> 2267.3s] 是在这个价构, [2267.3s -> 2269.3s] 是按设计的, [2269.3s -> 2270.3s] 又发现, [2270.3s -> 2271.3s] 计算剩余的, [2271.3s -> 2272.3s] 实在太多了, [2272.3s -> 2273.3s] 它觉得MTP, [2273.3s -> 2274.3s] 能够更有效的, [2274.3s -> 2275.3s] 能够利用起来。 [2275.3s -> 2276.3s] 对, [2276.3s -> 2277.3s] 这个其实, [2277.3s -> 2278.3s] 是一个, [2279.3s -> 2280.3s] 在推理就当, [2280.3s -> 2281.3s] 它的计算, [2281.3s -> 2282.3s] 其实是大大浪费, [2282.3s -> 2283.3s] 它其实, [2283.3s -> 2284.3s] 从它的计算, [2284.3s -> 2285.3s] 是远大于它, [2285.3s -> 2286.3s] 实际的这个架部能力的, [2286.3s -> 2287.3s] 对, [2287.3s -> 2288.3s] 所以说, [2288.3s -> 2289.3s] 对于计算而言的话, [2289.3s -> 2290.3s] 它这块, [2290.3s -> 2291.3s] 是有一定的浪费, [2291.3s -> 2292.3s] Rofli, [2292.3s -> 2293.3s] 可能主要讨论点, [2293.3s -> 2294.3s] 就是, [2294.3s -> 2295.3s] 就是这种, [2295.3s -> 2296.3s] 计算模式, [2296.3s -> 2297.3s] 它跟MTP的收益, [2297.3s -> 2298.3s] 它不是正调的, [2298.3s -> 2299.3s] 甚至它可能是, [2299.3s -> 2300.3s] 互相缓冲的, [2300.3s -> 2301.3s] 因为MTP, [2301.3s -> 2302.3s] 本质上, [2302.3s -> 2303.3s] 就是用更多的token, [2303.3s -> 2304.3s] 同时去计算, [2304.3s -> 2305.3s] 然后, [2305.3s -> 2306.3s] 在memory bound, [2306.3s -> 2307.3s] 去推, [2307.3s -> 2308.3s] 所以说, [2308.3s -> 2309.3s] 对于MLA, [2309.3s -> 2310.3s] MTP的这个, [2310.3s -> 2311.3s] 对加速比会, [2311.3s -> 2312.3s] 大大减小, [2312.3s -> 2313.3s] 我觉得它, [2313.3s -> 2314.3s] 从来也没有失控, [2314.3s -> 2315.3s] 它只是一个选择, [2315.3s -> 2316.3s] ok, [2316.3s -> 2317.3s] 但k3, [2317.3s -> 2318.3s] 起码, [2318.3s -> 2319.3s] 还选择继续, [2319.3s -> 2320.3s] 沿用的是MLA, [2320.3s -> 2321.3s] 我觉得k3, [2321.3s -> 2322.3s] 是reasonable的, [2322.3s -> 2323.3s] 因为k2, [2323.3s -> 2324.3s] 当时主要是follow deep seek, [2324.3s -> 2325.3s] 他们当时的选择, [2325.3s -> 2326.3s] 是先不做, [2326.3s -> 2327.3s] 模型价格的创新, [2327.3s -> 2328.3s] 先把结果跑出来, [2328.3s -> 2329.3s] 对,然后, [2329.3s -> 2330.3s] 然后如果, [2330.3s -> 2331.3s] 从k2到k3的话, [2331.3s -> 2332.3s] 这块, [2332.3s -> 2333.3s] 我就对一个, [2333.3s -> 2334.3s] 从工程或者说, [2334.3s -> 2335.3s] 从组织管理上, [2336.3s -> 2337.3s] 因为它不是一个, [2337.3s -> 2338.3s] 特别大的问题, [2338.3s -> 2339.3s] 可能就暂时不会动, [2339.3s -> 2340.3s] 但我觉得, [2340.3s -> 2341.3s] 未来也不一定, [2341.3s -> 2342.3s] 我觉得这块, [2342.3s -> 2343.3s] 我觉得是一个, [2343.3s -> 2344.3s] 比较赞态的一个状态, [2344.3s -> 2345.3s] 当然, [2345.3s -> 2346.3s] MLA也不是这个, [2346.3s -> 2347.3s] 没有好处嘛, [2347.3s -> 2348.3s] 所以说, [2348.3s -> 2349.3s] 我觉得, [2349.3s -> 2350.3s] 这个都快好, [2350.3s -> 2351.3s] 所以它是加强了, [2351.3s -> 2352.3s] MLA的可控性, [2352.3s -> 2353.3s] 对, [2353.3s -> 2354.3s] Gate它主要是, [2354.3s -> 2355.3s] 提升了MLA, [2355.3s -> 2356.3s] 本身的训练稳定性, [2356.3s -> 2357.3s] 这块跟MLA是正雕的, [2357.3s -> 2358.3s] 就是任何, [2358.3s -> 2359.3s] 任何错诞证, [2359.3s -> 2360.3s] 其实都可以用, [2360.3s -> 2361.3s] 我们现在讲到, [2361.3s -> 2362.3s] 2.2对吧,
[2362.3s -> 2363.3s] 对, [2363.3s -> 2364.3s] 2.2, [2364.3s -> 2365.3s] 这样的一个, [2365.3s -> 2366.3s] 研究MLA来讲的话, [2366.3s -> 2367.3s] 我反而会认为, [2367.3s -> 2368.3s] Hyper-Connection, [2368.3s -> 2369.3s] 我觉得是一个, [2369.3s -> 2370.3s] 相当好的一个工作, [2370.3s -> 2371.3s] 对, [2371.3s -> 2372.3s] Hyper-Connection, [2372.3s -> 2373.3s] 是很早以前, [2373.3s -> 2374.3s] ZID团队去提出的, [2374.3s -> 2375.3s] 对, [2375.3s -> 2376.3s] 这块主要讨论的, [2376.3s -> 2377.3s] 就是, [2377.3s -> 2378.3s] 在一个比较深度的, [2378.3s -> 2379.3s] 模型当中的, [2379.3s -> 2380.3s] 一个深层到浅层的, [2380.3s -> 2381.3s] 一个连接方式, [2381.3s -> 2382.3s] 对, [2382.3s -> 2383.3s] 如果我们再仔细, [2383.3s -> 2384.3s] 去考虑问题的话, [2384.3s -> 2385.3s] 对吧, [2385.3s -> 2386.3s] 因为它叫attention-recedon, [2386.3s -> 2387.3s] 对吧, [2387.3s -> 2388.3s] 这个本质上跟Restnet, [2388.3s -> 2389.3s] 其实都有一个, [2389.3s -> 2390.3s] 比较深刻的, [2390.3s -> 2391.3s] 就是这个模型能力, [2391.3s -> 2393.3s] 在这个模型参入增长的情况, [2393.3s -> 2394.3s] 它至少可以, [2394.3s -> 2395.3s] 达到一个不退化的, [2395.3s -> 2396.3s] 一个效果,对吧, [2396.3s -> 2397.3s] 包括从稳定性角度, [2397.3s -> 2398.3s] 它其实也是, [2398.3s -> 2399.3s] 对,或者, [2399.3s -> 2400.3s] 它其实, [2400.3s -> 2401.3s] 无论是从模型稳定性, [2401.3s -> 2402.3s] 和模型能力上, [2402.3s -> 2403.3s] 它就是Restnet, [2403.3s -> 2404.3s] 本质上都会比, [2404.3s -> 2405.3s] 之前的一些工作, [2405.3s -> 2406.3s] 有本质性的提升吧, [2406.3s -> 2407.3s] 不过这个, [2407.3s -> 2408.3s] 大家都很熟悉了, [2408.3s -> 2409.3s] 然后大家其实, [2409.3s -> 2410.3s] 没有注意到的是, [2410.3s -> 2411.3s] Restnet, [2411.3s -> 2412.3s] 它其实是有两个版本的, [2412.3s -> 2413.3s] 它一个是CVPR的版本, [2413.3s -> 2414.3s] 然后一个是, [2414.3s -> 2415.3s] 这个ICCV的版本, [2415.3s -> 2416.3s] Restnet那个时代, [2416.3s -> 2417.3s] 凯明就已经讨论过, [2417.3s -> 2418.3s] 就是Player Nom, [2418.3s -> 2419.3s] 和Post Learn Nom, [2419.3s -> 2420.3s] 和训练稳定性的, [2420.3s -> 2421.3s] 这样的一个关系了, [2421.3s -> 2422.3s] 然后其实, [2422.3s -> 2423.3s] 而这个其实, [2423.3s -> 2424.3s] 也可以追溯到这个, [2424.3s -> 2425.3s] 比如说在Burnt时代, [2425.3s -> 2426.3s] 就是Burnt时代, [2426.3s -> 2427.3s] 它其实, [2427.3s -> 2429.3s] 大家还是会更常用Post Learn Nom, [2429.3s -> 2430.3s] 大家在Burnt时代, [2430.3s -> 2431.3s] 会觉得Post Learn Nom, [2431.3s -> 2432.3s] 它的结果, [2432.3s -> 2433.3s] 可能会稍微好一些, [2433.3s -> 2435.3s] 但是在模型增大的, [2435.3s -> 2436.3s] 效果, [2436.3s -> 2437.3s] 在模型逐渐增大的, [2437.3s -> 2438.3s] 这个, [2438.3s -> 2439.3s] 情况下呢, [2439.3s -> 2440.3s] 大家会发现Post Learn Nom, [2440.3s -> 2441.3s] 它有这个, [2441.3s -> 2442.3s] 提出消失的问题, [2442.3s -> 2443.3s] 不够稳定的问题, [2443.3s -> 2444.3s] 所以大家后面, [2444.3s -> 2445.3s] 就会逐渐的, [2445.3s -> 2446.3s] 去采取Player Nom, [2446.3s -> 2447.3s] 对这样的一个, [2447.3s -> 2448.3s] 残差连接的手段, [2448.3s -> 2449.3s] 然后, [2449.3s -> 2450.3s] 它其实, [2450.3s -> 2451.3s] 苏建林, [2451.3s -> 2452.3s] 讨论过这样的观点, [2452.3s -> 2453.3s] 就是, [2453.3s -> 2454.3s] 它绝对不是, [2454.3s -> 2455.3s] Player Nom, [2455.3s -> 2456.3s] 到这个, [2456.3s -> 2457.3s] 到另外一个, [2457.3s -> 2458.3s] Player Nom, [2458.3s -> 2459.3s] 摆放方式的一个区别, [2459.3s -> 2460.3s] 这样的话, [2460.3s -> 2461.3s] 它其实这个, [2461.3s -> 2462.3s] 风险是很大的, [2462.3s -> 2463.3s] 因为它会有, [2463.3s -> 2464.3s] 如果说, [2464.3s -> 2465.3s] 你一旦触及了Post Learn Nom, [2465.3s -> 2466.3s] 之前的问题的话, [2466.3s -> 2467.3s] 对, [2467.3s -> 2468.3s] 整个大drun, [2468.3s -> 2469.3s] 大家肯定是不敢上的, [2469.3s -> 2470.3s] 所以说, [2470.3s -> 2471.3s] 一定是Player Nom, [2471.3s -> 2472.3s] 一个超级, [2472.3s -> 2473.3s] 就是, [2473.3s -> 2474.3s] 它至少是可以, [2474.3s -> 2475.3s] 退化到Player Nom, [2475.3s -> 2476.3s] 它是, [2476.3s -> 2477.3s] 严格的是, [2477.3s -> 2478.3s] 比Player Nom, [2478.3s -> 2479.3s] 更强的一个结果, [2479.3s -> 2480.3s] 然后, [2480.3s -> 2481.3s] 这块, [2481.3s -> 2482.3s] 主要就是, [2482.3s -> 2483.3s] 简单讨论一下, [2483.3s -> 2484.3s] Residual这条研究线, [2484.3s -> 2485.3s] 之前大概是怎么来的,
[2485.3s -> 2486.3s] 对, [2486.3s -> 2487.3s] 然后Hip Connection, [2487.3s -> 2488.3s] 我觉得这个工作, [2488.3s -> 2489.3s] 是相当有意思的, [2489.3s -> 2490.3s] 其实, [2490.3s -> 2491.3s] 我觉得, [2491.3s -> 2492.3s] 无论是这个, [2492.3s -> 2493.3s] TBC, [2493.3s -> 2494.3s] 后来做的改进, [2494.3s -> 2495.3s] 也好, [2495.3s -> 2496.3s] 也好, [2496.3s -> 2497.3s] 本账都是, [2497.3s -> 2498.3s] 其实都是, [2498.3s -> 2499.3s] 从这篇工作来的, [2499.3s -> 2500.3s] 这个Player Nom, [2500.3s -> 2501.3s] 的基础上, [2501.3s -> 2502.3s] 如何去增加, [2502.3s -> 2503.3s] 模型残杀的容量, [2503.3s -> 2504.3s] 从而去提升, [2504.3s -> 2505.3s] 模型能力的, [2505.3s -> 2506.3s] 一个表达能力, [2506.3s -> 2507.3s] 当然了, [2507.3s -> 2508.3s] 这个, [2508.3s -> 2509.3s] 我之前也跟这个, [2509.3s -> 2510.3s] Hip Connection, [2510.3s -> 2511.3s] 这个, [2511.3s -> 2512.3s] 一座的同学交流过, [2512.3s -> 2513.3s] 我说, [2513.3s -> 2514.3s] 我觉得, [2514.3s -> 2515.3s] 这个工作, [2515.3s -> 2516.3s] 本身, [2516.3s -> 2517.3s] 从技术上, [2517.3s -> 2518.3s] 还是很好的, [2518.3s -> 2519.3s] 但是, [2519.3s -> 2520.3s] 它一个最大问题, [2520.3s -> 2521.3s] 就是, [2521.3s -> 2522.3s] 它Paper写的, [2522.3s -> 2523.3s] 太抽象了, [2523.3s -> 2524.3s] 不太容易读, [2524.3s -> 2525.3s] Hip Connection, [2525.3s -> 2526.3s] 我觉得, [2526.3s -> 2527.3s] 本质上就可以说, [2527.3s -> 2528.3s] 一句话, [2528.3s -> 2529.3s] 所以说, [2529.3s -> 2530.3s] 如果我们有更大的容量, [2530.3s -> 2531.3s] 它一定是有更好的, [2531.3s -> 2532.3s] 一个效果的, [2532.3s -> 2533.3s] 我觉得Hip Connection, [2533.3s -> 2534.3s] 它其实, [2534.3s -> 2535.3s] 我觉得从, [2535.3s -> 2536.3s] 我觉得从思想上, [2536.3s -> 2537.3s] 是相当简洁的, [2537.3s -> 2538.3s] 对, [2538.3s -> 2539.3s] 但是这个Paper存在, [2539.3s -> 2540.3s] 显示可能相对复杂的一点, [2540.3s -> 2541.3s] 所以说, [2541.3s -> 2542.3s] 当时这个工作, [2542.3s -> 2543.3s] 其实没有出圈, [2543.3s -> 2544.3s] 可能只是一个比较, [2544.3s -> 2545.3s] 对, [2545.3s -> 2546.3s] 大家做架构, [2546.3s -> 2547.3s] 或者说, [2547.3s -> 2548.3s] 技术层面的, [2548.3s -> 2549.3s] 一些同学, [2549.3s -> 2550.3s] 去了解的, [2550.3s -> 2551.3s] 但是后来, [2551.3s -> 2552.3s] 这个MHC, [2552.3s -> 2553.3s] 可能就比, [2553.3s -> 2554.3s] HC本身, [2554.3s -> 2555.3s] 要活了很多, [2555.3s -> 2556.3s] 但是我觉得, [2556.3s -> 2557.3s] 最重要的一言一, [2557.3s -> 2558.3s] 大家会尝试, [2558.3s -> 2559.3s] 去从模型, [2559.3s -> 2560.3s] 本身的一个, [2560.3s -> 2561.3s] 连接方式来讲, [2561.3s -> 2562.3s] 去提升模型的能力, [2562.3s -> 2563.3s] 因为, [2563.3s -> 2564.3s] 从Hip Connection, [2564.3s -> 2565.3s] 包括, [2565.3s -> 2566.3s] Racid, [2566.3s -> 2567.3s] 它一个比较好的点, [2567.3s -> 2568.3s] 就是, [2568.3s -> 2569.3s] 它对于推理来说, [2569.3s -> 2570.3s] 基本是免费的, [2570.3s -> 2571.3s] 也就是说, [2571.3s -> 2572.3s] 在模型的influence, [2572.3s -> 2573.3s] 它其实, [2573.3s -> 2574.3s] 几乎不会增加, [2574.3s -> 2575.3s] 任何的推理, [2575.3s -> 2576.3s] 它就可以拿到, [2576.3s -> 2577.3s] 对, [2577.3s -> 2578.3s] 更好的一个模型结果, [2578.3s -> 2579.3s] 这个其实, [2579.3s -> 2580.3s] 是大家这个, [2580.3s -> 2581.3s] 喜闻乐见的, [2581.3s -> 2582.3s] 对, [2582.3s -> 2583.3s] 因为如果, [2583.3s -> 2584.3s] 一旦涉及到, [2584.3s -> 2585.3s] 对, [2585.3s -> 2586.3s] 一旦涉及到, [2586.3s -> 2587.3s] 模型更好的表现, [2587.3s -> 2588.3s] 那这块, [2588.3s -> 2589.3s] 就带来一个, [2589.3s -> 2590.3s] 自然的水道火, [2590.3s -> 2591.3s] 就是, [2591.3s -> 2592.3s] 我为什么不能去, [2592.3s -> 2593.3s] 扩大的size, [2593.3s -> 2594.3s] 这样, [2594.3s -> 2595.3s] 还这个简单一些, [2595.3s -> 2596.3s] 所以说, [2596.3s -> 2597.3s] 一切, [2597.3s -> 2598.3s] 比如说, [2598.3s -> 2599.3s] 通过这个更慢的, [2599.3s -> 2600.3s] 模型实现的, [2600.3s -> 2601.3s] 去提升模型效果的方法, [2601.3s -> 2602.3s] 其实都是会被, [2602.3s -> 2603.3s] Fully question的, [2603.3s -> 2604.3s] 或者甚至说, [2604.3s -> 2605.3s] 对于一些,
[2605.3s -> 2606.3s] 保守的或者说, [2606.3s -> 2607.3s] 不是自己提的, [2607.3s -> 2608.3s] 就是说, [2608.3s -> 2609.3s] 可能大家就, [2609.3s -> 2610.3s] 会愿意去用, [2610.3s -> 2611.3s] 对于这种模型设计, [2611.3s -> 2612.3s] 它可能在推理, [2612.3s -> 2613.3s] 阶段是, [2613.3s -> 2614.3s] 几乎免费的, [2614.3s -> 2615.3s] 这样的话, [2615.3s -> 2616.3s] 然后, [2616.3s -> 2617.3s] 最后维度的话, [2617.3s -> 2618.3s] 其实还有一个, [2618.3s -> 2619.3s] 比较绕不过的, [2619.3s -> 2620.3s] 就是Desnete, [2620.3s -> 2621.3s] desnete, [2621.3s -> 2622.3s] 这个是一个, [2622.3s -> 2623.3s] 更早的一个工作了, [2623.3s -> 2624.3s] 就是, [2624.3s -> 2625.3s] 它是, [2625.3s -> 2626.3s] 对, [2626.3s -> 2627.3s] 它是, [2627.3s -> 2628.3s] 黄高老师在那个, [2628.3s -> 2629.3s] resonate之后, [2629.3s -> 2630.3s] 他其实是一个, [2630.3s -> 2631.3s] 连接方式, [2631.3s -> 2632.3s] desnete, [2632.3s -> 2633.3s] 其实和Tenri, [2633.3s -> 2634.3s] 它其实在, [2634.3s -> 2635.3s] 思想上, [2635.3s -> 2636.3s] 是一个, [2636.3s -> 2637.3s] 相当密切的一个方式, [2637.3s -> 2638.3s] 对, [2638.3s -> 2639.3s] 只不过, [2639.3s -> 2640.3s] 在desnete时代, [2640.3s -> 2641.3s] 它其实是, [2641.3s -> 2642.3s] 因为resonate, [2642.3s -> 2643.3s] 它其实只是, [2643.3s -> 2644.3s] 层和层之间的, [2644.3s -> 2645.3s] 其实在desnete时代, [2645.3s -> 2646.3s] 因为那个时代, [2646.3s -> 2647.3s] 其实没有Tenri, [2647.3s -> 2648.3s] 或者说, [2648.3s -> 2649.3s] 大家也没有过度重视, [2649.3s -> 2650.3s] Tenri本身的一个, [2650.3s -> 2651.3s] 很安能力, [2651.3s -> 2652.3s] 所以desnete里边主要, [2652.3s -> 2653.3s] 是一个大的linear, [2653.3s -> 2654.3s] 来去把, [2654.3s -> 2655.3s] 这之前所有的这个, [2655.3s -> 2656.3s] 对, [2656.3s -> 2657.3s] 之前所有的黑能性的, [2657.3s -> 2658.3s] 然后聚合到一起的, [2658.3s -> 2659.3s] 对, [2659.3s -> 2660.3s] 然后到desnete时代, [2660.3s -> 2661.3s] 其实desnete, [2661.3s -> 2662.3s] 它的那个, [2662.3s -> 2663.3s] 对, [2663.3s -> 2664.3s] 它那个实现, [2664.3s -> 2665.3s] 其实本身是不快的, [2665.3s -> 2666.3s] 对, [2666.3s -> 2667.3s] 因为它的这中间, [2667.3s -> 2668.3s] 对于这个连接方面的, [2668.3s -> 2669.3s] 它会带来一些, [2669.3s -> 2670.3s] 大量的额外的计算, [2670.3s -> 2671.3s] 但是到了这个, [2671.3s -> 2672.3s] Tenri时代的话, [2672.3s -> 2673.3s] desnete里边, [2673.3s -> 2675.3s] 一些比较high-weight的部件, [2675.3s -> 2676.3s] 然后, [2676.3s -> 2677.3s] 变成更lightweight的部件, [2677.3s -> 2678.3s] 然后这样的话, [2678.3s -> 2679.3s] 就诞生了Tenri Seedle, [2679.3s -> 2680.3s] 这样的一个工作, [2680.3s -> 2681.3s] Tenri Seedle, [2681.3s -> 2682.3s] 它最大的优势就是, [2682.3s -> 2683.3s] 它其实比desnete, [2683.3s -> 2684.3s] 它是一个更, [2684.3s -> 2685.3s] 对, [2685.3s -> 2686.3s] 它其实是一个更efficient的架构, [2686.3s -> 2687.3s] 我们可以通过一些, [2687.3s -> 2688.3s] 这个更深, [2688.3s -> 2690.3s] 更深层次的infrared code design, [2690.3s -> 2691.3s] 对, [2691.3s -> 2692.3s] 比如说用block, [2692.3s -> 2693.3s] Tenri的方式, [2693.3s -> 2694.3s] 去节偶掉这个模型的深度, [2694.3s -> 2695.3s] 对, [2695.3s -> 2696.3s] 因为如果只是, [2696.3s -> 2697.3s] 全数一厘的话, [2697.3s -> 2698.3s] 它上层会跟, [2698.3s -> 2699.3s] 底下所有层, [2699.3s -> 2700.3s] 之前的一个, [2700.3s -> 2701.3s] 比较大的问题, [2701.3s -> 2702.3s] 就是模型越深, [2702.3s -> 2703.3s] 它这块的overhead, [2703.3s -> 2704.3s] 其实越不厚烈, [2704.3s -> 2705.3s] 然后block tension的话, [2705.3s -> 2706.3s] 在这块做了一个节偶, [2706.3s -> 2707.3s] 所以说, [2707.3s -> 2708.3s] 它整体, [2708.3s -> 2709.3s] 一方面是, [2709.3s -> 2710.3s] Tenri它本身的, [2710.3s -> 2711.3s] 这个计算比较lightweight, [2711.3s -> 2712.3s] 然后第二方面, [2712.3s -> 2713.3s] 就是它节偶的深度, [2713.3s -> 2714.3s] 所以最后, [2714.3s -> 2715.3s] 总的看起来, [2715.3s -> 2716.3s] 它其实就一个, [2716.3s -> 2717.3s] 比较零巧, [2717.3s -> 2718.3s] 但是一个, [2718.3s -> 2719.3s] 能接视的, [2719.3s -> 2720.3s] 去提升模型能力, [2720.3s -> 2721.3s] 这样的一个组件, [2721.3s -> 2722.3s] 然后这块他们, [2722.3s -> 2723.3s] 对, [2723.3s -> 2724.3s] 这块可以看一些, [2724.3s -> 2725.3s] 这个skilling的一个结果, [2725.3s -> 2726.3s] 就block, [2726.3s -> 2727.3s] 对,
[2727.3s -> 2728.3s] 这个来说, [2728.3s -> 2729.3s] 表达能力, [2729.3s -> 2730.3s] 肯定是不如负我Tenri C6好的, [2730.3s -> 2731.3s] 对, [2731.3s -> 2732.3s] 但是这块大家claim的点, [2732.3s -> 2733.3s] 就是, [2733.3s -> 2734.3s] 它其实并没有损失, [2734.3s -> 2735.3s] 太多能力, [2735.3s -> 2736.3s] 而且对于bassline来说, [2736.3s -> 2737.3s] 它是一个, [2737.3s -> 2738.3s] 比较显著的一个状态, [2738.3s -> 2739.3s] 对, [2739.3s -> 2740.3s] 然后Tenri C6这块, [2740.3s -> 2741.3s] 应该, [2741.3s -> 2742.3s] 主要就是, [2742.3s -> 2743.3s] 上一个技术陪陪里讲的, [2743.3s -> 2744.3s] 然后k3这块, [2744.3s -> 2745.3s] 应该没有做太多特殊的处理, [2745.3s -> 2746.3s] 对, [2746.3s -> 2747.3s] 然后这块, [2747.3s -> 2748.3s] 大家就是这样的一个情况, [2748.3s -> 2749.3s] 你刚才讲的这几个, [2749.3s -> 2750.3s] 你觉得, [2750.3s -> 2751.3s] 哪个创新性是最强烈, [2751.3s -> 2753.3s] 你喜欢DanceNet和Kyber Connection? [2753.3s -> 2754.3s] 为什么? [2755.3s -> 2756.3s] 因为DanceNet, [2756.3s -> 2757.3s] 它是一个相当早的工作, [2757.3s -> 2758.3s] 就是, [2758.3s -> 2759.3s] 因为在那个时代, [2759.3s -> 2760.3s] 其实大家考虑这个连接的问题, [2760.3s -> 2761.3s] 我觉得, [2761.3s -> 2762.3s] 本质上, [2762.3s -> 2763.3s] Tenri C6考虑的问题, [2763.3s -> 2764.3s] 其实DanceNet, [2764.3s -> 2765.3s] 都考虑到的, [2765.3s -> 2766.3s] 只不过当时, [2766.3s -> 2767.3s] 没有Tenri C6而已, [2767.3s -> 2768.3s] 然后Kyber Connection的话, [2768.3s -> 2769.3s] 其实它相当于, [2769.3s -> 2770.3s] 是在传从本时代, [2770.3s -> 2771.3s] 重新把这个东西, [2771.3s -> 2772.3s] 带了回来, [2772.3s -> 2773.3s] 然后让大家在这个连接方式上, [2773.3s -> 2774.3s] 重新去讨论, [2774.3s -> 2775.3s] 如何有一个更强的连接方式, [2775.3s -> 2776.3s] 然后从而去, [2776.3s -> 2777.3s] 提升模型的性能, [2781.3s -> 2782.3s] 其实是之前的工作, [2782.3s -> 2783.3s] 已经定好的, [2783.3s -> 2784.3s] OK, [2784.3s -> 2786.3s] 然后Moe应该是年初, [2786.3s -> 2787.3s] 因为达, [2787.3s -> 2789.3s] 他们一个团队去提出的, [2789.3s -> 2790.3s] 我觉得这块, [2790.3s -> 2791.3s] 我觉得一个比较大的, [2791.3s -> 2792.3s] 一个, [2792.3s -> 2793.3s] 我觉得一个比较大的好处, [2793.3s -> 2794.3s] 就是, [2794.3s -> 2795.3s] 包括大家如果熟悉, [2795.3s -> 2796.3s] 这个Deep Sticker V3的, [2796.3s -> 2797.3s] 同学其实都知道, [2797.3s -> 2798.3s] 训练Moe, [2798.3s -> 2799.3s] 其实无论从, [2799.3s -> 2800.3s] 这个模型的本质性, [2800.3s -> 2801.3s] 或者训练方式, [2801.3s -> 2802.3s] 包括从一方上, [2802.3s -> 2803.3s] 它其实就是一个很大的挑战, [2803.3s -> 2804.3s] 然后最大的挑战, [2804.3s -> 2807.3s] 就是这个Moe的AutoDispatch, [2807.3s -> 2808.3s] 其实在EP的情况下, [2808.3s -> 2809.3s] 它的这个Overhead, [2809.3s -> 2810.3s] 是相当大的, [2810.3s -> 2812.3s] 也就是为了解决这个问题, [2812.3s -> 2813.3s] 然后我们不得不引入, [2813.3s -> 2814.3s] DPP这样一个, [2814.3s -> 2815.3s] 比较高优化的一个, [2815.3s -> 2816.3s] 同性的, [2816.3s -> 2817.3s] 同性固的方式, [2817.3s -> 2818.3s] 从而去降低, [2818.3s -> 2819.3s] 这个Auto out的, [2819.3s -> 2820.3s] 这样的一个开销, [2820.3s -> 2821.3s] 包括其实不同的, [2821.3s -> 2822.3s] Auto out的, [2822.3s -> 2823.3s] 不同的Moe的, [2823.3s -> 2824.3s] 设计价格方式, [2824.3s -> 2825.3s] 它不仅影响了, [2825.3s -> 2826.3s] 模型价格本人, [2826.3s -> 2827.3s] 它甚至影响了, [2827.3s -> 2828.3s] 第一层, [2828.3s -> 2829.3s] 不同的Infra的, [2829.3s -> 2830.3s] 一些设计选型, [2830.3s -> 2831.3s] 这个之后, [2831.3s -> 2832.3s] 后面会在这个Infra, [2832.3s -> 2833.3s] 那块会做一个, [2833.3s -> 2834.3s] 更多的讨论, [2834.3s -> 2835.3s] 但是Latina Moe这个, [2835.3s -> 2836.3s] 它其实本质上的东西, [2836.3s -> 2837.3s] 就在于说, [2837.3s -> 2838.3s] 我们是否可以把, [2838.3s -> 2839.3s] 这个Auto out Dispatch, [2839.3s -> 2840.3s] 这块的开销, [2840.3s -> 2841.3s] 来去减小, [2841.3s -> 2842.3s] 因为Auto out Dispatch, [2842.3s -> 2843.3s] 这块的话, [2843.3s -> 2844.3s] 我们需要把这个, [2844.3s -> 2845.3s] Hit and Set, [2845.3s -> 2846.3s] 分发到各个专家卡上, [2846.3s -> 2847.3s] 而且这个通信量, [2847.3s -> 2849.3s] 它是会随着这个Expert, [2849.3s -> 2850.3s] 激活的数量和, [2850.3s -> 2851.3s] 这个, [2851.3s -> 2852.3s] 模型Hit and Set的大小, [2852.3s -> 2854.3s] 来去并行的去增长的, [2854.3s -> 2855.3s] 对,然后Latina Moe, [2855.3s -> 2856.3s] 它的思想就是, [2856.3s -> 2858.3s] 我们是否可以把这个, [2858.3s -> 2859.3s] 把通信量减少的同时, [2859.3s -> 2860.3s] 来去保持, [2860.3s -> 2861.3s] 模型的,
[2861.3s -> 2862.3s] 这样的一个表达能力, [2862.3s -> 2863.3s] 然后Latina Moe的方式, [2863.3s -> 2864.3s] 就是我们把, [2864.3s -> 2865.3s] Dispatch的这样的, [2865.3s -> 2866.3s] 一个Hit and Set的减小, [2866.3s -> 2867.3s] 它可能减小, [2867.3s -> 2868.3s] 两倍减少四倍, [2868.3s -> 2869.3s] 这样的一个量, [2869.3s -> 2870.3s] 当然了, [2870.3s -> 2871.3s] 如果我们直接去减小, [2871.3s -> 2872.3s] 它的Hit and Set, [2872.3s -> 2873.3s] 它后面的模型的, [2873.3s -> 2874.3s] 这个Moe的材质量, [2874.3s -> 2875.3s] 可能就会随之争奖, [2875.3s -> 2876.3s] 为了去弥补, [2876.3s -> 2877.3s] 这个Latina Dimension, [2877.3s -> 2878.3s] 减小的一个材质量的话, [2878.3s -> 2879.3s] 这样, [2879.3s -> 2880.3s] 然后这里边, [2880.3s -> 2881.3s] 就有两种方式, [2881.3s -> 2882.3s] 第一种方式, [2882.3s -> 2883.3s] 就是提升, [2883.3s -> 2884.3s] Amp, [2884.3s -> 2885.3s] Intermediate Dimension, [2885.3s -> 2886.3s] 就是通过, [2886.3s -> 2887.3s] 这个提升, [2887.3s -> 2888.3s] Amp, [2888.3s -> 2889.3s] 然后把之前, [2889.3s -> 2890.3s] 这样的那一部分, [2890.3s -> 2891.3s] 弥补回来, [2891.3s -> 2892.3s] 这是一种方式, [2892.3s -> 2893.3s] 另一种方式, [2893.3s -> 2894.3s] 就是, [2894.3s -> 2895.3s] 我们去进一步, [2895.3s -> 2896.3s] 去把模型拆碎, [2896.3s -> 2897.3s] 这样的话, [2897.3s -> 2898.3s] 我们去用, [2898.3s -> 2899.3s] 对, [2899.3s -> 2900.3s] 我们去用更多Dexper的, [2900.3s -> 2901.3s] 和更多的激活, [2901.3s -> 2902.3s] 然后来去弥补, [2902.3s -> 2903.3s] 这个材质量的, [2903.3s -> 2904.3s] 这样的一个减少, [2904.3s -> 2905.3s] 然后最后, [2905.3s -> 2906.3s] 其实我们可以看下来, [2906.3s -> 2907.3s] 当然, [2907.3s -> 2908.3s] 在英文达这个Paper里, [2908.3s -> 2909.3s] 它其实结果是更好的, [2909.3s -> 2910.3s] 其实总的来说, [2910.3s -> 2911.3s] 就是一句话, [2911.3s -> 2912.3s] 就是, [2912.3s -> 2913.3s] 如果一个恰当, [2913.3s -> 2914.3s] 设计的Latina Moe的, [2914.3s -> 2915.3s] 一个Configuration, [2915.3s -> 2916.3s] 这个Standard Moe的, [2916.3s -> 2917.3s] 这样的一个结果的, [2917.3s -> 2918.3s] 就是, [2918.3s -> 2919.3s] 也就是说, [2919.3s -> 2920.3s] 我们可以在这个模型能力, [2920.3s -> 2921.3s] 完全相懂, [2921.3s -> 2922.3s] 甚至还能好一点, [2922.3s -> 2923.3s] 在一个Countess底下, [2923.3s -> 2924.3s] 然后来去, [2924.3s -> 2926.3s] 就是减小模型的Latint, [2926.3s -> 2929.3s] 去减少模型的一个通信开销, [2929.3s -> 2930.3s] 而且, [2930.3s -> 2931.3s] 通信开销, [2931.3s -> 2932.3s] 其实在这个, [2932.3s -> 2933.3s] 在通信和, [2933.3s -> 2934.3s] 在训练和这个推理中, [2934.3s -> 2935.3s] 是不一样的, [2935.3s -> 2936.3s] 训练, [2936.3s -> 2937.3s] 因为我们主要优化的是, [2937.3s -> 2938.3s] 我们可以用一些, [2938.3s -> 2939.3s] 这个Overlap的手段, [2939.3s -> 2940.3s] 然后来去, [2940.3s -> 2941.3s] 把通信这一部分, [2941.3s -> 2942.3s] 去弥补掉, [2942.3s -> 2944.3s] 对于Inference Latency来讲, [2944.3s -> 2945.3s] 尽管我们可以, [2945.3s -> 2946.3s] 用一些手段, [2946.3s -> 2947.3s] 来去掩盖, [2947.3s -> 2948.3s] 来去掩盖通信开销, [2948.3s -> 2949.3s] 但是这个时间, [2949.3s -> 2950.3s] 它是避免不了的, [2950.3s -> 2951.3s] 因为它整体, [2951.3s -> 2952.3s] 是在这个Critical Path上, [2952.3s -> 2953.3s] 所以说, [2953.3s -> 2954.3s] 对于模型推理, [2954.3s -> 2955.3s] 跟这个Latency来说, [2955.3s -> 2956.3s] 通信开销, [2956.3s -> 2957.3s] 它还是一个, [2957.3s -> 2958.3s] 相当不可忽略的一个点, [2958.3s -> 2959.3s] 所以说, [2959.3s -> 2960.3s] 其实从模型的, [2960.3s -> 2961.3s] 这个Inference Latency上来讲, [2961.3s -> 2962.3s] 这个推理的手艺, [2962.3s -> 2963.3s] 其实是比训练的手艺要大的, [2963.3s -> 2965.3s] 当然训练也有一定的手艺, [2965.3s -> 2966.3s] 所以说, [2966.3s -> 2967.3s] 如果说, [2967.3s -> 2968.3s] Latint Moe, [2968.3s -> 2969.3s] 不是一个推到复, [2969.3s -> 2970.3s] 我们不需要去, [2970.3s -> 2971.3s] 3号牺牲模型的, [2971.3s -> 2972.3s] 这个表达能力, [2972.3s -> 2973.3s] 来去, [2973.3s -> 2974.3s] 来去降低通信了, [2974.3s -> 2975.3s] 它其实还是一个, [2975.3s -> 2976.3s] 这个Free Launch, [2976.3s -> 2977.3s] 或者Lace Free Launch, [2977.3s -> 2978.3s] 的这样的一个结构, [2978.3s -> 2979.3s] 对, [2979.3s -> 2980.3s] 所以说, [2980.3s -> 2981.3s] KIMIKI3, [2981.3s -> 2982.3s] 其实是follow的, [2982.3s -> 2983.3s] 这样的一个结构, [2983.3s -> 2984.3s] 当然了, [2984.3s -> 2985.3s] 在Latency Moe, [2985.3s -> 2986.3s] 以上的话,
[2986.3s -> 2987.3s] 还有一些比较细节的一个改进, [2987.3s -> 2988.3s] 然后针对, [2988.3s -> 2989.3s] 这样的一个比较细节的改进呢, [2989.3s -> 2990.3s] 我们可以讨论一个, [2990.3s -> 2991.3s] 比较经典的问题, [2991.3s -> 2992.3s] 就是说起来也很简单, [2992.3s -> 2993.3s] 就是两个矩阵连成, [2993.3s -> 2995.3s] 这是一个非常非常基本的单元, [2995.3s -> 2996.3s] 就是两个矩阵连成, [2996.3s -> 2997.3s] 其实在模型表达能力上, [2997.3s -> 2998.3s] 是Table的, [2998.3s -> 2999.3s] 对吧, [2999.3s -> 3000.3s] 因为两个矩阵连成, [3000.3s -> 3001.3s] 严格的是可以, [3001.3s -> 3002.3s] 是可以和别脑一个的, [3002.3s -> 3003.3s] 但是优化性这上, [3003.3s -> 3004.3s] 其实是并不是这样的, [3004.3s -> 3005.3s] 就是两个矩阵连成, [3005.3s -> 3006.3s] 经常会出现这个, [3006.3s -> 3007.3s] 模型训练不稳定的问题, [3007.3s -> 3008.3s] 所以说, [3008.3s -> 3009.3s] 两个矩阵连成, [3009.3s -> 3010.3s] 一般中间就会用一些, [3010.3s -> 3011.3s] 这个搭配一些, [3011.3s -> 3012.3s] 稳定性的手段, [3012.3s -> 3013.3s] 然后来去弥补, [3013.3s -> 3014.3s] 这样的一个事情, [3014.3s -> 3015.3s] 这个色相, [3015.3s -> 3016.3s] 其实在这个MLA里, [3016.3s -> 3017.3s] 因为MLA, [3017.3s -> 3018.3s] 本质上也是, [3018.3s -> 3019.3s] 就是先做一个 [3019.3s -> 3020.3s] Local Reaction的投影, [3020.3s -> 3021.3s] 然后再把它打回来, [3021.3s -> 3022.3s] 它其实, [3022.3s -> 3023.3s] 本质上也是, [3023.3s -> 3024.3s] 两个Linear连成的一个方式, [3024.3s -> 3025.3s] 然后, [3025.3s -> 3026.3s] 两个Linear连成中间的话, [3026.3s -> 3027.3s] 一般会采取一个 [3027.3s -> 3028.3s] Normalization的一个方式, [3028.3s -> 3029.3s] 然后, [3029.3s -> 3030.3s] 把中间的Headset的控制住, [3030.3s -> 3031.3s] 从而那个, [3031.3s -> 3032.3s] 提升模型整体训练的, [3032.3s -> 3033.3s] 一个问题, [3033.3s -> 3034.3s] 所以, [3034.3s -> 3035.3s] 这是突然Dontrade的, [3035.3s -> 3036.3s] 就是很简单, [3036.3s -> 3037.3s] 就是一般来说, [3037.3s -> 3038.3s] 就是模型, [3038.3s -> 3039.3s] 在模型价格的设计的, [3039.3s -> 3040.3s] 当中呢, [3040.3s -> 3041.3s] 如果你不得不, [3041.3s -> 3042.3s] 和平到一起的话, [3042.3s -> 3043.3s] 中间一定要, [3043.3s -> 3044.3s] 加一个类似Normalization的, [3044.3s -> 3045.3s] 一个手段, [3045.3s -> 3046.3s] 然后这个思想, [3046.3s -> 3047.3s] 其实在, [3047.3s -> 3048.3s] 一个是在MLA里, [3048.3s -> 3049.3s] 有个设计, [3049.3s -> 3050.3s] 然后其实, [3050.3s -> 3051.3s] 这块Linear MOE, [3051.3s -> 3052.3s] 其实也是类似的道理, [3052.3s -> 3053.3s] 归根结底, [3053.3s -> 3054.3s] 就是Linear MOE, [3054.3s -> 3055.3s] 我是先把, [3055.3s -> 3056.3s] 这个模型, [3056.3s -> 3057.3s] 模型的Headset, [3057.3s -> 3058.3s] 通过一个Linear Projection, [3058.3s -> 3059.3s] 把它压到一个, [3059.3s -> 3060.3s] 地位的状态, [3060.3s -> 3061.3s] 然后, [3061.3s -> 3062.3s] 我们在, [3062.3s -> 3063.3s] 这个Linear Projection的, [3063.3s -> 3064.3s] 基础上, [3064.3s -> 3065.3s] 然后来去进行, [3065.3s -> 3066.3s] 后面的一些计算, [3066.3s -> 3067.3s] 然后当然, [3067.3s -> 3068.3s] 对于FFN, [3068.3s -> 3069.3s] 来说, [3069.3s -> 3070.3s] 跟Linear Projection, [3070.3s -> 3071.3s] 连成的情况, [3071.3s -> 3072.3s] 所以这块, [3072.3s -> 3073.3s] 我们需要一个, [3073.3s -> 3074.3s] RMSNorm, [3074.3s -> 3075.3s] 来去控制它, [3075.3s -> 3076.3s] OK,然后, [3076.3s -> 3077.3s] 下边就是这个, [3077.3s -> 3078.3s] C2GLU, [3078.3s -> 3079.3s] 这个设计, [3079.3s -> 3080.3s] 其实也是一个, [3080.3s -> 3081.3s] 大家看起来, [3081.3s -> 3082.3s] 可能, [3082.3s -> 3083.3s] 对, [3083.3s -> 3084.3s] 没有那么直观的, [3084.3s -> 3085.3s] 一个东西, [3085.3s -> 3086.3s] 然后这个东西, [3086.3s -> 3087.3s] 其实也跟, [3087.3s -> 3088.3s] 之前的一些, [3088.3s -> 3089.3s] 设计是有关系的, [3089.3s -> 3090.3s] 因为大家其实, [3090.3s -> 3091.3s] 会发现, [3091.3s -> 3092.3s] 就是, [3092.3s -> 3093.3s] 对于大模型, [3093.3s -> 3094.3s] 训练来说的话, [3094.3s -> 3095.3s] 就FFN, [3095.3s -> 3096.3s] 这块的这个MLP, [3096.3s -> 3097.3s] 它其实, [3097.3s -> 3098.3s] 中间的Headset, [3098.3s -> 3099.3s] 一个状态, [3099.3s -> 3100.3s] 而且这个东西, [3100.3s -> 3101.3s] 一个是, [3101.3s -> 3102.3s] 跟优化器有关, [3102.3s -> 3103.3s] 另一个就是, [3103.3s -> 3104.3s] 跟模型的精度有关, [3104.3s -> 3105.3s] 就在模型精度, [3105.3s -> 3106.3s] 更低的情况下, [3106.3s -> 3107.3s] 中间的这个Headset,
[3107.3s -> 3108.3s] 更容易出现Outlier, [3108.3s -> 3109.3s] 然后, [3109.3s -> 3110.3s] 为了解决这个问题呢, [3110.3s -> 3111.3s] 然后GPTOS, [3111.3s -> 3112.3s] 其实刚开始, [3112.3s -> 3113.3s] 采用了一个, [3113.3s -> 3114.3s] 特别简单的状态, [3114.3s -> 3115.3s] 就是把, [3115.3s -> 3116.3s] 最简单的SVGLU, [3116.3s -> 3117.3s] 就是没有, [3117.3s -> 3118.3s] 没有邦地的那块, [3118.3s -> 3119.3s] 直接通过一个Clip, [3119.3s -> 3120.3s] 然后, [3120.3s -> 3121.3s] 比如说, [3121.3s -> 3122.3s] 我们设一个Clip的职, [3122.3s -> 3123.3s] 比如说, [3123.3s -> 3124.3s] 不到10, [3124.3s -> 3125.3s] 然后就把它Clip, [3125.3s -> 3126.3s] 就是可以从数学上, [3126.3s -> 3127.3s] 比较严格的, [3127.3s -> 3128.3s] 可以把这个, [3128.3s -> 3129.3s] 它的上限控制住, [3129.3s -> 3130.3s] 然后Clip, [3130.3s -> 3131.3s] 它是一个, [3131.3s -> 3132.3s] 比较粗暴的状态, [3132.3s -> 3133.3s] 然后, [3133.3s -> 3134.3s] 你如果把这个Hard Clip, [3134.3s -> 3135.3s] 而变成这个Soft Clip, [3135.3s -> 3136.3s] 然后你就会, [3136.3s -> 3137.3s] 比较自然的, [3137.3s -> 3138.3s] 到这个摊机打H, [3138.3s -> 3139.3s] 这样的一个算子, [3139.3s -> 3140.3s] 因为摊机打H, [3140.3s -> 3141.3s] 它3号, [3141.3s -> 3142.3s] 就是一个Soft Clip, [3142.3s -> 3143.3s] 如果你指定一个, [3143.3s -> 3144.3s] 下一个, [3144.3s -> 3145.3s] 指定一个上限, [3145.3s -> 3146.3s] 它可以用一个, [3146.3s -> 3147.3s] 比较平滑的方式, [3147.3s -> 3148.3s] 比较一个, [3148.3s -> 3149.3s] 比较平滑的方式, [3149.3s -> 3150.3s] 让它逼近, [3150.3s -> 3151.3s] 一个Clip的一个升级版, [3151.3s -> 3152.3s] 但这个升级版, [3152.3s -> 3153.3s] 具体在模型的, [3153.3s -> 3154.3s] 表达能力上有多大影响, [3154.3s -> 3155.3s] 我觉得这个是, [3155.3s -> 3156.3s] 另一回事, [3156.3s -> 3157.3s] 而且这个肯定是, [3157.3s -> 3158.3s] 需要具体的实验, [3158.3s -> 3159.3s] 来去证明的, [3159.3s -> 3160.3s] 但Whatever, [3160.3s -> 3161.3s] 我觉得Soft Clip, [3161.3s -> 3162.3s] 它还是一个, [3162.3s -> 3163.3s] 比较安全的一个做法, [3163.3s -> 3164.3s] 从Switch Glue开始, [3164.3s -> 3165.3s] 然后, [3165.3s -> 3166.3s] 首先把一个, [3166.3s -> 3167.3s] 比较自由的Linear Projection, [3167.3s -> 3168.3s] 然后, [3168.3s -> 3169.3s] 改成了一个, [3169.3s -> 3170.3s] 摊机打H, [3170.3s -> 3171.3s] 帮地的一个状态, [3171.3s -> 3172.3s] 然后另一块的话, [3172.3s -> 3173.3s] 就是Switch, [3173.3s -> 3174.3s] 因为Switch要有, [3174.3s -> 3175.3s] 它前面就是一个, [3175.3s -> 3176.3s] 一个Linear的一个结果, [3176.3s -> 3177.3s] Switch, [3177.3s -> 3178.3s] 我们又可以, [3178.3s -> 3179.3s] 拆成这个Sigmoid, [3179.3s -> 3180.3s] 和一个Linear Projection, [3180.3s -> 3181.3s] 当然, [3181.3s -> 3182.3s] 这块, [3182.3s -> 3183.3s] 它是一个, [3183.3s -> 3184.3s] 共享Wit的一个状态, [3184.3s -> 3185.3s] 所以, [3185.3s -> 3186.3s] Soft Clip, [3186.3s -> 3187.3s] 相当于是, [3187.3s -> 3188.3s] 你把我, [3188.3s -> 3189.3s] 把所有这个, [3189.3s -> 3190.3s] 中间可能出现, [3190.3s -> 3191.3s] 帮地的一个, [3191.3s -> 3192.3s] 环解, [3192.3s -> 3193.3s] 然后, [3193.3s -> 3194.3s] 把它通过, [3194.3s -> 3195.3s] 一个摊机打H, [3195.3s -> 3196.3s] 的上下界放缩, [3196.3s -> 3197.3s] 然后, [3197.3s -> 3198.3s] 来去帮得住, [3198.3s -> 3199.3s] 这样的话, [3199.3s -> 3200.3s] 就可以把, [3200.3s -> 3201.3s] 整个MLP, [3201.3s -> 3202.3s] 中间的一个, [3202.3s -> 3203.3s] 几乎得到一个, [3203.3s -> 3204.3s] 严格的数学上借, [3204.3s -> 3205.3s] 然后, [3205.3s -> 3206.3s] Linear的, [3206.3s -> 3207.3s] 进行控制, [3207.3s -> 3208.3s] 中间的计划值, [3208.3s -> 3209.3s] 总不是一个, [3209.3s -> 3210.3s] 比较错的, [3210.3s -> 3211.3s] 一个现象, [3211.3s -> 3212.3s] 当然, [3212.3s -> 3213.3s] 如果我说, [3213.3s -> 3214.3s] 就更容易, [3214.3s -> 3215.3s] 来Linear这个, [3215.3s -> 3216.3s] 苏建灵一定会反对, [3216.3s -> 3217.3s] 他肯定会说, [3217.3s -> 3218.3s] 对于任何优化器来说, [3218.3s -> 3219.3s] 他都一定会出现Linear, [3219.3s -> 3220.3s] 因为你从, [3220.3s -> 3221.3s] 模型架构上是, [3221.3s -> 3222.3s] 控制不了的, [3222.3s -> 3223.3s] 所以说, [3223.3s -> 3224.3s] 如果想严格, [3224.3s -> 3225.3s] 控制的方法, [3225.3s -> 3226.3s] 它一定是, [3226.3s -> 3227.3s] 直接从,
[3227.3s -> 3228.3s] 模型架构下手, [3228.3s -> 3229.3s] 什么苏建灵, [3229.3s -> 3230.3s] 跟你观点不要, [3230.3s -> 3231.3s] 这个他没有说, [3231.3s -> 3232.3s] 但我猜到, [3232.3s -> 3233.3s] 他会这么说, [3233.3s -> 3234.3s] 所以如果, [3234.3s -> 3235.3s] 之前对CMK2, [3235.3s -> 3236.3s] 或者Monlite, [3236.3s -> 3237.3s] 大家如果记得的话, [3237.3s -> 3238.3s] 但当时就会说, [3238.3s -> 3239.3s] 就是, [3239.3s -> 3240.3s] 因为用了, [3240.3s -> 3241.3s] 没有优化器, [3241.3s -> 3242.3s] 所以QK Logis, [3242.3s -> 3243.3s] 会更容易去爆炸, [3243.3s -> 3244.3s] 所以Monlite, [3244.3s -> 3245.3s] 他们采用了一种, [3245.3s -> 3246.3s] 对于QK的一个, [3246.3s -> 3247.3s] 比较特化的一个处理方式, [3247.3s -> 3248.3s] 然后来去, [3248.3s -> 3249.3s] 压制模型到Outlier, [3249.3s -> 3250.3s] 然后在那个时间点, [3250.3s -> 3251.3s] 大家就问嘛,说, [3251.3s -> 3252.3s] 为什么, [3252.3s -> 3253.3s] 为什么我们之前, [3253.3s -> 3254.3s] 因为Adams训练的, [3254.3s -> 3255.3s] 不需要加这个东西, [3255.3s -> 3256.3s] 然后为什么, [3256.3s -> 3257.3s] 对吧, [3257.3s -> 3258.3s] 之前的这个QK Logis, [3258.3s -> 3259.3s] 都很稳, [3259.3s -> 3260.3s] 就不需要额外的处理, [3261.3s -> 3262.3s] 也不是完全稳定的, [3262.3s -> 3263.3s] 然后, [3263.3s -> 3264.3s] 然后当时DF3, [3264.3s -> 3265.3s] 可能3号也有一些, [3265.3s -> 3266.3s] 不稳定的现象, [3266.3s -> 3267.3s] 当然这个, [3267.3s -> 3268.3s] 并没有影响模型, [3268.3s -> 3269.3s] 最终的结果, [3269.3s -> 3270.3s] 它当时在对Monlite Clip的, [3270.3s -> 3271.3s] 观点就是, [3271.3s -> 3272.3s] 如果说, [3272.3s -> 3273.3s] 在Monlite信号里, [3273.3s -> 3274.3s] 有可能出现了, [3274.3s -> 3275.3s] 出现了, [3275.3s -> 3276.3s] 它严格来说, [3276.3s -> 3277.3s] 就是容易出现的, [3277.3s -> 3278.3s] 只不过, [3278.3s -> 3279.3s] 你可能出现的早晚问题, [3279.3s -> 3280.3s] 所以说, [3280.3s -> 3281.3s] 为了严格的限制, [3281.3s -> 3282.3s] 这样那个模型的行为, [3282.3s -> 3283.3s] 还是从这个, [3283.3s -> 3284.3s] 从模型架构本身, [3284.3s -> 3285.3s] 去做限制, [3285.3s -> 3286.3s] 是一个更本质的方案, [3286.3s -> 3287.3s] 或者直接在architecture上, [3287.3s -> 3288.3s] 做一些改变, [3288.3s -> 3289.3s] 然后让它整体, [3289.3s -> 3290.3s] 把bundit的限制度, [3290.3s -> 3291.3s] 就完事了, [3291.3s -> 3292.3s] 也不需要去纠结, [3292.3s -> 3293.3s] 更复杂的优化的细节, [3293.3s -> 3294.3s] 其实, [3294.3s -> 3295.3s] 我觉得是一个道理, [3295.3s -> 3296.3s] 所以说, [3296.3s -> 3297.3s] 我觉得, [3297.3s -> 3298.3s] 它应该还会这么说, [3298.3s -> 3299.3s] 对, [3299.3s -> 3300.3s] 没有是对于K2的一个沿用,对吧? [3300.3s -> 3301.3s] 对,对,对,对, [3301.3s -> 3302.3s] 这块儿, [3302.3s -> 3303.3s] 该相比K2, [3303.3s -> 3304.3s] 没有做太多的改进, [3304.3s -> 3305.3s] 改变, [3305.3s -> 3306.3s] 没有当时比较严重的问题, [3306.3s -> 3307.3s] 就是, [3307.3s -> 3308.3s] 它其实控制不住, [3308.3s -> 3309.3s] 这个,对, [3309.3s -> 3310.3s] 控制不住, [3310.3s -> 3311.3s] 对, [3311.3s -> 3312.3s] 对, [3312.3s -> 3313.3s] 控制不住, [3313.3s -> 3314.3s] 对, [3314.3s -> 3315.3s] 这种light比较率先的, [3315.3s -> 3317.3s] 就是把WateDK这样的一个, [3317.3s -> 3318.3s] 对, [3318.3s -> 3319.3s] 这样的一个因素, [3319.3s -> 3320.3s] 然后是, [3320.3s -> 3321.3s] 首先已经是到, [3321.3s -> 3322.3s] 比较大规模的模型讯链里, [3322.3s -> 3323.3s] 然后这样的话, [3323.3s -> 3324.3s] 其实在这个更, [3324.3s -> 3325.3s] 更长的round里边, [3325.3s -> 3326.3s] 是可以保持的。 [3326.3s -> 3327.3s] 另外, [3327.3s -> 3328.3s] 就在Kmic2之后, [3328.3s -> 3329.3s] 它就在这个WateDK的, [3329.3s -> 3330.3s] 这个анalyne, [3330.3s -> 3331.3s] 就是个命技术上, [3331.3s -> 3332.3s] 正如, [3332.3s -> 3333.3s] 额外, [3333.3s -> 3334.3s] 对, [3334.3s -> 3335.3s] 额外搞了一个 [3335.3s -> 3336.3s] QQClip [3336.3s -> 3337.3s] 的一个方式, [3337.3s -> 3338.3s] 然后其实这两个加起来是一个, [3338.3s -> 3339.3s] 对, [3339.3s -> 3340.3s] 就是就Kmic团队在这个, [3340.3s -> 3341.3s] 这个优化器上一个, [3341.3s -> 3342.3s] 对, [3342.3s -> 3345.7s] 比如说你用MLA,你就没有办法去加QKNUM [3345.7s -> 3349.1s] 因为QKNUM它是严格可以限制QK这块的一个边界的 [3349.1s -> 3353.2s] 所以说为了去适配MLA和MU的一个结合 [3353.2s -> 3356.7s] 所以说当时KIMIKETO引入了QKCLIP这样的一个操作 [3356.7s -> 3360.5s] 当然大家可以注意到比如说DM4个V4 [3360.5s -> 3363.7s] 然后包括SAPFON那些,他们应该都是用了MU [3363.7s -> 3367.4s] 然后在MU的基础上,因为他们都是用的GKMU没有用MLA
[3367.4s -> 3370.9s] 所以直接用QKNUM,它其实是本账是一个更简单的办法 [3370.9s -> 3375.0s] 就是尝试去控制这个MU带来一个外置outlier [3375.0s -> 3377.1s] 这个outlier在QKNUM里更容易出现的 [3377.1s -> 3380.8s] 它也一定会在这个MLP这块出现,相当于采取了不同的方式 [3380.8s -> 3383.8s] 就QKNUM那块通过CLIP也好,然后NUMALIZATION也好 [3383.8s -> 3386.3s] 然后把它限制住,然后在底下MLP这块的话 [3386.3s -> 3388.5s] 当然会用一些比较更Lightweight的手段 [3388.5s -> 3392.7s] 然后KIMIKETO现在就是通过这个用设计的一个结构凡数把它放得住 [3392.7s -> 3394.7s] 就大概就是这样的一个思想 [3394.7s -> 3397.4s] 然后QuantalBalancing的话,这个没有发什么论文 [3397.4s -> 3400.3s] 是苏建宁在他自己的博客里去讲的 [3400.4s -> 3405.8s] 然后QuantalBalancing的话,它主要是可以follow到就是之前的这个LostFree的Routing的方式 [3405.8s -> 3408.7s] 它主要的控制方法就是它只通过一个BIOS [3408.7s -> 3414.4s] 而不是通过一个偏整体的LostFree控制方式来去解决模型Expert的负载均衡的问题 [3414.4s -> 3419.2s] 到LostFree大家比较奇怪的一个问题就是它这样的一个BIOS的变量 [3419.2s -> 3423.6s] 因为这个BIOS的变量它直接决定了每个token它选哪些Expert的嘛 [3423.6s -> 3426.2s] 但这个更新方式,3号是有下达浩克的 [3426.2s -> 3428.7s] 就是它采取了一个比较起发式的更新方案 [3429.2s -> 3431.1s] 来去做这个BIOS的更新 [3431.1s -> 3435.5s] 然后这块的话,一个问题就是它这个东西它其实没有一个比较严格的一个 [3435.5s -> 3439.9s] 数学的一个数点表软,另一个就是它其实容易和这个主模型的更新 [3439.9s -> 3442.3s] 对大家一个感觉就是可能没有那么这个偶和 [3442.3s -> 3445.7s] 当然这个形式还是本身还是可以有work的,还不错的 [3445.7s -> 3451.0s] 就是在整体work不错的情况下的话,其实当时LostFree有几个问题可能是没有完成解决的 [3451.0s -> 3454.7s] 最主要的问题就是如果在使用LostFree的时候呢 [3454.7s -> 3458.4s] 大家可能会采取这个模型最最底下几层的一层或者三层 [3458.4s -> 3460.3s] 然后都把MoE去了的一个方案 [3460.3s -> 3463.0s] 主要原因就在于说对LostFree这样的一个控制方案 [3463.0s -> 3466.2s] 对于底层的模型来说它做work的不是很好 [3466.2s -> 3468.7s] 正式为LostFree它整体没有做整体的一个coding [3468.7s -> 3470.6s] 所以它可能会采取一些别的方式 [3470.6s -> 3474.7s] 然后来去弥补这个模型在大规模训练中碰到的一些问题 [3474.7s -> 3479.9s] 对,然后Quantile Balancing其实是主要是尝试用一个更principle的一个思想 [3479.9s -> 3484.2s] 然后来去这个解决模型推理的一个模型MoE负载稳定性 [3484.2s -> 3485.2s] 这样的一个问题 [3485.2s -> 3487.9s] 它本身LostFree的这个update的方式它肯定是 [3487.9s -> 3490.3s] 就是经过大量的这个调整之后得到了一个 [3490.3s -> 3491.9s] 就work还不错的一个方案 [3491.9s -> 3493.1s] 所以它本质上也很简单吧 [3493.1s -> 3495.9s] 就是如果你某个张家的你计划的多了 [3495.9s -> 3497.4s] 然后就把BIOS往下砍一点 [3497.4s -> 3500.0s] 如果每个那个计划的少了就就往上加一点 [3500.0s -> 3503.1s] 然后之前的LostFree是一个比较齐发式的方案去做嘛 [3503.1s -> 3506.6s] 对,然后这个Kimmy团队呢用更principle的一个方案 [3506.6s -> 3509.8s] 就是我们能不能直接通过一个这个现归的方式 [3509.8s -> 3512.6s] 直接推倒出来就是这个BIOS它应该是长什么样 [3512.8s -> 3514.4s] 答案就是这个是可以被推出来的 [3514.4s -> 3517.7s] 而且推出来的具体的方式也跟之前的Experts的Choice [3517.7s -> 3519.0s] 有一定的关系 [3519.0s -> 3522.6s] 然后最后的话就是QuantelBIOS它经过一系列推倒 [3522.6s -> 3525.1s] 它最后就得到一个一步的一个这个形式 [3525.1s -> 3527.9s] 也就是说比如说我们对于一步对于一个step [3527.9s -> 3529.2s] 内部的一个整体的激活 [3529.2s -> 3530.5s] 我们是可以求一个BIOS [3530.5s -> 3533.1s] 然后这个BIOS它本身就是一个这个 [3533.1s -> 3536.7s] 它本身就是一个让模型可以这个负载均衡的这样的一个方案 [3536.7s -> 3538.2s] 然后它博客的又写到了 [3538.2s -> 3540.5s] 为了去避免这个信息泄漏 [3540.7s -> 3542.9s] 也就是说我们不能让就任意一个token [3542.9s -> 3545.9s] 然后来去获得其他token的这的一个信息 [3545.9s -> 3548.4s] 所以说这个beta并不会在这个当前step使用 [3548.4s -> 3550.7s] 而是会在下一步去使用 [3550.7s -> 3554.6s] 然后这个是中间的QuantelBIOS的这样的一个细节 [3554.6s -> 3558.0s] 苏天灵博客的其实就主要提到的一个有点就是 [3558.0s -> 3559.6s] 首先它其实它不需要调参数 [3559.6s -> 3563.5s] EmailOS Freight是有一个list-learning rate的一个更新的方式的 [3563.5s -> 3564.9s] 这样的话它其实少了一个参数 [3564.9s -> 3566.9s] 整体的看起来会更加principle一些 [3566.9s -> 3568.7s] 然后第二个有点就是它其实 [3568.7s -> 3570.6s] 对于负载均衡balance这样的一个能力 [3570.6s -> 3572.4s] 它其实是一个更有的一个能力 [3572.4s -> 3574.9s] 然后它这块的博客就会贴出一个图 [3574.9s -> 3575.7s] 对于第一层而言 [3575.7s -> 3577.4s] 就因为其实我刚刚也提到 [3577.4s -> 3580.0s] 为了这个兼容model loss-pray-balance [3580.0s -> 3582.1s] 之前大家会把前级层搞成dancers [3582.1s -> 3583.2s] 不用mv这样的方法 [3583.2s -> 3585.8s] 然后把这个东西去规避掉 [3585.8s -> 3587.9s] 然后如果说对于这种qb这种方式的话 [3587.9s -> 3590.3s] 其实就没有必要去规避这样的一个问题了 [3590.3s -> 3593.5s] 其实它其实就可以直接把第一层变的balance [3593.5s -> 3596.5s] 这个其实可以发现前底层用dancers它其实是一个 [3596.6s -> 3598.3s] 对 它其实并不是一个grounds数字上 [3598.3s -> 3600.2s] 一定要去这么去做的一个方式 [3600.2s -> 3602.7s] 而是它其实在loss-pray-balance的下 [3602.7s -> 3604.2s] 不得不去采用的一个方式 [3604.2s -> 3605.9s] 然后其实如果你不采用loss-pray [3605.9s -> 3607.8s] 你直接就采用加辅助loss的方案 [3607.8s -> 3609.5s] 比如说千万mv的工作 [3609.5s -> 3611.5s] 它其实就是采用直接求loss-pray-balance的 [3611.5s -> 3612.9s] 对第一层也会没有问题 [3612.9s -> 3614.0s] 所以说这个这块的话 [3614.0s -> 3615.4s] 它主要就是可以处理掉 [3615.4s -> 3619.1s] 就是之前loss-pray一些比较失效的一些情况 [3619.1s -> 3620.6s] 当然它不可以也提到 [3620.6s -> 3623.6s] 如果本来s3sjd就比较work的情况下 [3623.6s -> 3625.3s] 这个qb它也是比较work的 [3625.4s -> 3626.9s] 而且它博客里也可以证明 [3626.9s -> 3628.4s] 对比较正常的情况 [3628.4s -> 3629.5s] 它其实是可以推出来说 [3629.5s -> 3632.3s] 这个qb如果我们不采用直接去均衡 [3632.3s -> 3633.9s] 去采用一些t度更新的方案的话 [3633.9s -> 3635.5s] 它其实是可以和loss-pray [3635.5s -> 3637.9s] 做到一个相当等价的一个数学形式的 [3637.9s -> 3640.2s] 然后这块其实还有一个细节是之前的 [3640.2s -> 3642.3s] 那个博客里没有去提及的 [3642.3s -> 3645.8s] 简单来说就是我们为了去在整个一个batch [3645.8s -> 3647.3s] 也因为现在大家大蒙鞋训练 [3647.3s -> 3648.3s] 一个batch会特别大 [3648.3s -> 3650.4s] 比如说4mm可能都会比较小 [3650.4s -> 3652.4s] 可能到几十mg这样的一个量级 [3652.4s -> 3654.6s] 就qb需要在几十mg的投根之间 [3654.6s -> 3656.5s] 恰逃取到在一个比例的位数 [3656.5s -> 3658.4s] 也就是说如果对于一个精确的计算的话 [3658.4s -> 3659.7s] 我们需要把所有token的 [3659.7s -> 3662.3s] 所有token的这个激活情况都存下来 [3662.3s -> 3664.0s] 其实这个是相当havid的 [3664.0s -> 3665.8s] 甚至在工程上是不可能的 [3665.8s -> 3667.6s] 然后当时在博客里提出了一个方案 [3667.6s -> 3669.3s] 它采取的方案是每个gpu
[3669.3s -> 3671.3s] 都去做一个local的一个分位数计算 [3671.3s -> 3673.9s] 然后再把这个不同gpu的分位数计算 [3673.9s -> 3675.8s] 也不一定是不同gpu了 [3675.8s -> 3677.9s] 反正就是你得把一个大的batch切碎 [3677.9s -> 3679.2s] 然后在一个小的batch里 [3679.2s -> 3680.1s] 然后去求分位数 [3680.1s -> 3682.7s] 然后这个分位数最后再做一个pooling [3683.5s -> 3684.9s] 对 然后keep in mind这个payword [3684.9s -> 3687.6s] 它这个payword其实是有一些不太一样的一个变化 [3687.6s -> 3689.6s] 它并不是按token去切唱课的 [3689.6s -> 3690.8s] 当然也有可能是我理解错的 [3690.8s -> 3693.8s] 它其实是对这个模型的在直语切一个唱课 [3693.8s -> 3696.7s] 也就是说比如说对于Sigmoid的结合 [3696.7s -> 3698.4s] 它一定是0到1之间的 [3698.4s -> 3701.4s] 所以说我们就可以在0到1或者说附1到1 [3701.4s -> 3703.0s] 这样的一个区疆发源为内 [3703.0s -> 3704.5s] 然后切成n个统 [3704.5s -> 3705.4s] 然后在这个统里边 [3705.4s -> 3707.4s] 然后去进行histogram的一个统计 [3707.4s -> 3708.7s] 然后这样的一个统计值 [3708.7s -> 3709.8s] 这样它有个好处 [3709.8s -> 3711.7s] 它可以是一个常数范围 [3711.8s -> 3712.9s] 这个常数量 [3712.9s -> 3715.1s] 常数的这个存数大条的一个 [3715.1s -> 3717.5s] 这就可以做的一个计算 [3717.5s -> 3719.9s] 而且它的这个计算代价会比较不速的实现 [3719.9s -> 3720.7s] 也要高效很多 [3720.7s -> 3722.8s] 而且它可以比较好的去处理这个 [3722.8s -> 3727.0s] 就是在大规模的dpep的这样一个分布式的架构底下 [3727.0s -> 3729.0s] 是一个比较容易扩展的一个状态 [3729.0s -> 3730.7s] 然后这个其实是相当于k3 [3730.7s -> 3731.8s] 它后来放出来之前 [3731.8s -> 3734.3s] 在博客里没有去详细讨论的一个技术 [3734.3s -> 3737.9s] 这个是其实对客币的一个比较必要的一个时间方式 [3737.9s -> 3739.2s] 规刊解理就是哪一用的时间 [3739.2s -> 3740.4s] 它基本上是不可行的 [3740.4s -> 3743.0s] 所以必须是用一些比如工商可行的方式 [3743.0s -> 3744.9s] 要去把这个比较精确的解决出来 [3744.9s -> 3746.4s] 然后到2.4了 [3746.4s -> 3748.7s] Native Vision这块其实没啥好说的 [3748.7s -> 3749.9s] 它主要讨论的一个点 [3749.9s -> 3752.2s] 就是是否有必要就用一个 [3752.2s -> 3753.8s] 已有的Visual Encoder去做这个 [3753.8s -> 3755.6s] VITVisual Encoder的一个说实话 [3755.6s -> 3756.7s] 用已有的VIT的话 [3756.7s -> 3758.3s] 当然它对于已有的Visual Encoder [3758.3s -> 3759.5s] 比如说用seqlif2这样 [3759.5s -> 3761.2s] 也比较大规模训练的一个Visual Encoder [3761.2s -> 3763.2s] 它的好处就是它你说点的会比较快 [3763.8s -> 3765.9s] 但是这个k3它中间讨论的一个问题 [3765.9s -> 3768.6s] 就是如果说直接用这个seqlif1nx的话 [3768.6s -> 3769.6s] 它的这个模型的部分 [3769.6s -> 3771.4s] 不稳定性也会比直接Native Vision [3771.4s -> 3772.7s] 它是要来得大的 [3772.7s -> 3774.7s] 也不一定是模型不稳定性的 [3774.7s -> 3776.4s] 因为不稳定性它是一个比较相对 [3776.4s -> 3779.0s] 甚至它不是一个严格被定义的东西 [3779.0s -> 3781.2s] 只是大家可能会一般会去看 [3781.2s -> 3783.2s] Gradient Nom这样的一个分布 [3783.2s -> 3785.3s] 然后中间有一些东西是大家比较concert的 [3785.3s -> 3786.6s] 比如说它的坚持多不多 [3786.6s -> 3788.7s] 然后甚至说它本身Nom大不大 [3788.7s -> 3789.6s] 这个团队会发现 [3789.6s -> 3791.6s] 如果说我们直接Frontless Clash训练 [3791.6s -> 3793.1s] 可能会多用一些算力 [3793.1s -> 3795.5s] 但是至少第一个就是它的最后的结果 [3795.5s -> 3796.7s] 它是不会有损的 [3796.7s -> 3798.1s] 如果我们经过恰巧的训练 [3798.1s -> 3799.5s] 它不会带来更差的结果 [3799.5s -> 3800.7s] 甚至可能会带来 [3800.7s -> 3801.9s] 差不多甚至更好的结果 [3801.9s -> 3803.1s] 对 第二个它主要Climbing点 [3803.1s -> 3805.9s] 就是圆模型会带来一个更好的兼容性 [3805.9s -> 3808.7s] 那就会提下在Gradient Nom会更加稳定 [3808.7s -> 3811.2s] 我觉得其实可能有一个类似的观察 [3811.2s -> 3814.8s] 就是Siglib它其实是用Adm来去训练的 [3814.8s -> 3817.5s] 之前大家其实也讨论过一个比较相关的话题 [3817.5s -> 3820.5s] 就是用Adm训练的模型是否能用没有去反定 [3820.5s -> 3822.9s] 然后反过来就用没有去训练的模型 [3822.9s -> 3825.3s] 是否用Adm去可以是用Adm去反定 [3825.3s -> 3826.7s] 当然最后的结论就是肯定是 [3826.7s -> 3828.3s] 比较原生的方式它肯定是最好的 [3828.3s -> 3829.4s] 当然用别的方式的话 [3829.4s -> 3830.3s] 如果想达到一样 [3830.3s -> 3833.1s] 可能就得做一些处理或者说它是有一些限制 [3833.1s -> 3835.1s] 所以说可能对于Climbing K3二眼 [3835.1s -> 3838.4s] 他们是希望去采用一个全用的一个优化方式 [3838.4s -> 3841.5s] 这样的话对于模型整体的训练的 [3841.5s -> 3842.2s] 稳定性也好 [3842.2s -> 3843.1s] 它的兼容性也好 [3843.1s -> 3844.3s] 是一个更优的状态 [3844.3s -> 3845.0s] 说到这里 [3845.0s -> 3847.1s] 我们倒会去讲一下 [3847.1s -> 3849.5s] 最早那个线性注意力机制的问题吧 [3849.5s -> 3853.0s] 为什么K3它用的是线性注意力机制 [3853.0s -> 3855.1s] 它没有用任何的Sparse Tension [3855.1s -> 3856.0s] 就是线性注意力 [3856.0s -> 3858.1s] 全注意力和Sparse Tension [3858.1s -> 3859.9s] 你可以三选一和三选二 [3859.9s -> 3861.8s] 就是为什么不用Sparse Tension [3861.8s -> 3863.7s] 我们就会带来一点为什么要用 [3863.7s -> 3866.3s] 用了会有什么好处或者说会有什么问题 [3866.3s -> 3868.7s] 这个其实一方面是跟模型价格有关 [3868.7s -> 3870.3s] 另一方面其实也跟这个模型 [3870.3s -> 3873.0s] 它每带这个GPU硬件的一个feature有关 [3873.0s -> 3874.5s] 比如说这个Deepseq 3.2那种 [3874.5s -> 3876.8s] Deepseq Sparse Tension一个是这个3.2用的 [3876.8s -> 3877.9s] 一个是那个JRM [3877.9s -> 3882.2s] JRM5也用了Deepseq Sparse Tension这样一个价格 [3882.2s -> 3883.2s] 就Deepseq Sparse [3883.2s -> 3884.9s] 其实到最后在底扣的里边 [3884.9s -> 3886.3s] 其实加速是特别特别小的 [3886.3s -> 3887.3s] 原因就在于说 [3887.5s -> 3890.3s] Sparse求Index这一步它是相当昂贵的 [3890.3s -> 3892.8s] 而且在Blackwell的硬件的情况下 [3892.8s -> 3893.8s] 越迁进的硬件 [3893.8s -> 3895.2s] 它其实这个Orhead是越大的 [3895.2s -> 3896.8s] 甚至其实在底扣的当中 [3896.8s -> 3898.5s] 这种Sparse Tension的一个方案 [3898.5s -> 3900.7s] 它其实甚至跟Fort Tension
[3900.7s -> 3903.1s] 并不会带来一个显著的一个加速 [3903.1s -> 3904.1s] 为了解决这个问题的话 [3904.1s -> 3906.0s] 当时这个JRM团队做了一个工作 [3906.0s -> 3907.7s] 叫Index Cache [3907.7s -> 3910.0s] 它当时的做法就是把这个求解Index [3910.0s -> 3911.3s] 就是求解哪一部分 [3911.3s -> 3913.2s] 哪一些token需要算了Tension [3913.2s -> 3914.3s] 这样的一个竞产操作 [3914.3s -> 3916.5s] 然后把不同层次间共享了起来 [3916.5s -> 3917.8s] 比如说每四层每八层 [3917.8s -> 3919.1s] 然后做一个共享 [3919.1s -> 3920.1s] 只要有用这样的方法 [3920.1s -> 3922.4s] 它其实才可以比较有效的去减小 [3922.4s -> 3924.2s] 这个Sparse本身带来的开销 [3924.2s -> 3925.9s] 只有Sparse Tension [3925.9s -> 3927.4s] 本身开销足够小的情况下 [3927.4s -> 3929.3s] 其实才能带来一些比较客观的 [3929.3s -> 3931.2s] 一个算法上的一个手艺 [3931.2s -> 3932.5s] 然后Sparse Tension这块 [3932.5s -> 3933.9s] 我们也做了一些相关的工作 [3933.9s -> 3935.4s] 也大概是一个类似的阶段 [3935.4s -> 3936.5s] 当我们做的更极端了 [3936.5s -> 3937.9s] 我们在优口的价格上直接取 [3937.9s -> 3939.1s] Labry Sparse Tension的话 [3940.2s -> 3941.9s] 因为我们之前的KVcache是万次的 [3941.9s -> 3943.4s] 所以我们当时采取的方案就直接 [3943.4s -> 3945.1s] Sparse Intex这一步也做成万次 [3945.1s -> 3947.1s] 也就是我们把每层的Intex开销 [3947.1s -> 3948.7s] 直接分摊到这个所有层上 [3948.7s -> 3950.9s] 这样的话其实开销就会特别特别小 [3950.9s -> 3952.3s] 这样的话我们才能吃到 [3952.3s -> 3954.9s] Sparse Tension本身的一个计算收益 [3954.9s -> 3956.4s] 对 然后我们再回到KVcache 3 [3956.4s -> 3957.6s] 为什么它不去采用 [3957.6s -> 3958.7s] 第一个就是我们认为说 [3958.7s -> 3960.7s] 每层都用Sparse Tension [3960.7s -> 3961.7s] 这样一个比较简易的方案 [3961.7s -> 3963.0s] 它其实在Blackwell上 [3963.0s -> 3965.0s] 它的收益是特别特别小的 [3965.0s -> 3965.9s] 为了解决这个问题 [3965.9s -> 3968.6s] 无论是Intex Cache的解法和我们的解法 [3968.6s -> 3969.4s] 其实结论都一样 [3969.4s -> 3972.9s] 就是我们需要把多层的Sparse的一个结果 [3972.9s -> 3974.7s] 然后来去跨层来进行附用 [3974.7s -> 3977.0s] 然后跨层的方式其实比较简单的方式 [3977.0s -> 3978.6s] 就是相连的层去跨 [3978.6s -> 3980.2s] 然后相连的层去跨层的话 [3980.2s -> 3981.5s] 其实对于Hybrid Tension [3981.5s -> 3983.1s] 就对于现行注意力和全注意力 [3983.1s -> 3984.9s] 这样Interleave的方式的话 [3984.9s -> 3986.2s] 它其实并不是一个显然的 [3986.2s -> 3987.9s] 因为对于这种Hybrid Tension [3987.9s -> 3989.1s] 对 它不同附和Tension [3989.1s -> 3989.9s] 它并不是A者的 [3989.9s -> 3991.1s] 它每个附和Tension中间 [3991.1s -> 3993.2s] 它其实隔了很多个现行注意力的 [3993.2s -> 3995.9s] 所以说在隔很多层现行注意力的情况下 [3995.9s -> 3998.0s] 就是这种Intex Cache是否有效 [3998.0s -> 3999.8s] 加速比是否足够高 [3999.8s -> 4001.9s] 这个其实是相当Question的 [4001.9s -> 4004.0s] 然后其实前两个问题就是Sparse Tension [4004.1s -> 4007.2s] 它基本上是没有办法进行From Squares [4007.2s -> 4008.7s] Sparse Tension大家现在一般采用的 [4008.7s -> 4009.7s] 都是Post Tension [4009.7s -> 4012.0s] 然后从Fur Tension进行转化的一个方式 [4012.0s -> 4013.9s] 不排除 我觉得KMK3可能未来会把 [4013.9s -> 4015.5s] 一用的Fur Tension的部分 [4015.5s -> 4017.5s] 然后来去进行Sparse Tension转化 [4017.5s -> 4019.1s] 当然如果他们用来MLA的话 [4019.1s -> 4020.7s] 这个会更难一些 [4020.7s -> 4022.1s] 所以说我觉得主要就两个原因 [4022.1s -> 4023.8s] 一个是想拿到实际加速比 [4023.8s -> 4026.7s] 就是其实对于Hybrid Tension来说 [4026.7s -> 4028.2s] 是一个None Trigger的东西 [4028.2s -> 4029.6s] 就是如果想拿实际加速比的话 [4029.6s -> 4031.3s] 可能需要做更多的事情 [4031.3s -> 4032.8s] 第二个事情就是它跟Pretion [4032.8s -> 4034.4s] 它并不是一个比较兼容的状态 [4034.4s -> 4036.3s] 所以说这个其实留一个接口 [4036.3s -> 4037.6s] 之后再做也行 [4037.6s -> 4038.9s] 我刚才讲的这些 [4038.9s -> 4041.1s] 不管是架构创建还是训练 [4041.1s -> 4042.1s] 还是推理工程 [4042.1s -> 4044.2s] 你觉得它中间有哪些Trade Off [4044.2s -> 4045.3s] 你有哪些趋势 [4045.3s -> 4047.1s] 我觉得Hybrid Tension它主要的Trade Off [4047.1s -> 4048.4s] 就是你要去调节这个 [4048.4s -> 4050.3s] 线路里和全球一类的比例 [4050.3s -> 4051.9s] 就是你肯定比例越大 [4051.9s -> 4053.5s] 就是Fur Tension周里比例越大 [4053.5s -> 4054.6s] 它跟你加速比较高 [4054.6s -> 4056.7s] 但是如果你想达到一个 [4056.7s -> 4059.1s] 偏无损的一个加速状态 [4059.1s -> 4061.0s] 就是一个比较无损的状态的同时 [4061.0s -> 4061.6s] 想获得加速 [4061.6s -> 4063.5s] 然后3比1就是一个比较 [4063.5s -> 4065.7s] 实验上是一个比较无可的方案 [4065.7s -> 4067.1s] 这块其实就是一个 [4067.1s -> 4067.9s] 主要的一个Trade Off [4067.9s -> 4069.1s] Sports它严格来说 [4069.1s -> 4070.4s] 它肯定大格率是不会带来 [4070.4s -> 4071.3s] 更强的表现能力的 [4071.3s -> 4073.1s] 所以这块其实就是另一回事了 [4073.1s -> 4074.6s] 它其实跟Hybrid Tension架构 [4074.6s -> 4076.3s] 它其实是另一条线的 [4076.3s -> 4079.1s] 只不过说如果你坚持 [4079.1s -> 4081.1s] 不用Hybrid Tension什么 [4081.1s -> 4082.6s] 那你可能就不得不采取一些 [4082.6s -> 4083.5s] 别的方案来 [4083.5s -> 4085.5s] 我听到这里的感受是 [4085.5s -> 4086.4s] 就是现在的模型训练 [4086.4s -> 4087.7s] 好像没有一个巨大的 [4087.7s -> 4088.9s] 所谓的饭式创新 [4089.0s -> 4091.6s] 但是它把之前很多的工作 [4091.6s -> 4092.5s] 都融合起来 [4092.5s -> 4095.1s] 然后再寻找一个可能的更有节 [4095.1s -> 4096.6s] 我不知道这种感受对不对 [4096.6s -> 4098.5s] 对 我觉得其实问题不大 [4098.5s -> 4099.9s] 就是我觉得不完全是 [4099.9s -> 4101.1s] 基础的原因是为什么的
[4101.1s -> 4102.3s] 就是因为大家现在都叫 [4102.3s -> 4102.8s] 闯从门 [4102.8s -> 4103.8s] 但什么是闯从门 [4103.8s -> 4105.0s] 这个其实是 [4105.0s -> 4106.8s] 其实是没有办法清晰定义的 [4106.8s -> 4108.6s] 这个哲学上还有个对应的概念 [4108.6s -> 4110.1s] 就是太休斯之船嘛 [4110.1s -> 4111.1s] 就是你刚开始的 [4111.1s -> 4112.3s] 2017年这个船 [4112.3s -> 4113.5s] 刚开始行驶的时候 [4113.5s -> 4114.7s] 就把试穿从门 [4114.7s -> 4115.9s] 对 但是这个船刚开始 [4115.9s -> 4117.2s] 是怎么拼起来的 [4117.3s -> 4118.9s] 它是Tension 加瑞塞咒 [4118.9s -> 4120.0s] 这些东西或者说 [4120.0s -> 4120.9s] 对 这些东西拼起来 [4120.9s -> 4123.4s] 包括Stack Layer这种方式 [4123.4s -> 4125.0s] 它其实在船从门之前 [4125.0s -> 4127.0s] 它其实也并不是一个全新的概念 [4127.0s -> 4128.8s] 所以说这个船刚建起来的时候 [4128.8s -> 4131.0s] 我们认为这个船从门是Miles总 [4131.0s -> 4133.5s] 但是这个船已经行驶了 [4133.5s -> 4134.5s] 八年 九年了 [4134.5s -> 4136.5s] 就在这个船慢慢行驶的过程中 [4136.5s -> 4138.0s] 我们可能会把慢慢的 [4138.0s -> 4139.0s] 把某些部分换了 [4139.0s -> 4140.2s] 某些部分换了 [4140.2s -> 4141.3s] 然后其实我们现在看 [4141.3s -> 4142.3s] 到2020年 [4142.3s -> 4143.6s] 其实跟船从门已经 [4143.6s -> 4145.0s] 我觉得像素已经很厉害了 [4145.0s -> 4147.3s] 你是不是还把这个东西叫做船从门 [4147.3s -> 4149.1s] 当然这个是择协上的一个问题 [4149.1s -> 4151.2s] 但是其实从现在大家来看的话 [4151.2s -> 4152.2s] 大家还是会叫 [4152.2s -> 4153.9s] 但是我觉得如果说 [4153.9s -> 4155.3s] 历史的走向 [4155.3s -> 4156.4s] 如果有些不同的变化的话 [4156.4s -> 4157.6s] 可能也就不叫了 [4157.6s -> 4158.7s] 我们上面讲的这些 [4158.7s -> 4160.7s] 你觉得总体来说是一个什么样的工作 [4160.7s -> 4162.3s] 我觉得这个东西很难定义 [4162.3s -> 4163.8s] 因为首先它跟你有什么关系 [4163.8s -> 4165.6s] 它是一个偏综合性的工作 [4165.6s -> 4166.7s] 它严格来说 [4166.7s -> 4168.8s] 就是一般大家会把 [4168.8s -> 4170.5s] 比较有创意性的单点突破 [4170.5s -> 4172.0s] 会专门拿出来去 [4172.0s -> 4173.1s] 专门去做讨论 [4173.1s -> 4174.3s] 其实之前也考虑过 [4174.3s -> 4175.9s] 也之前也专门讨论过来 [4175.9s -> 4177.7s] 然后中间二其实比较大的就几点 [4177.7s -> 4179.4s] 第一个就是注意力怎么设计 [4179.4s -> 4181.0s] 这个是一个点 [4181.0s -> 4182.3s] 第二个就是MV这块 [4182.3s -> 4183.5s] 对吧 有没有一些更好的设计 [4183.5s -> 4184.7s] 然后第三个是优化器 [4184.7s -> 4185.8s] 然后第四个可能就是 [4185.8s -> 4187.1s] 中间二的一些连接方式 [4187.1s -> 4188.5s] 这个其实专门 [4188.5s -> 4189.9s] 这个其实比如说你放到 [4189.9s -> 4191.2s] 你放到Rusnets时代 [4191.2s -> 4192.7s] 其实这些单拿出来 [4192.7s -> 4194.5s] 它可能就是一个架构了 [4194.5s -> 4195.9s] 对 我觉得在Rusnets时代 [4195.9s -> 4196.9s] 它肯定是这样的 [4196.9s -> 4198.6s] 有但是其实在船从门的时代 [4198.6s -> 4199.6s] 它可能并不是这样的 [4199.6s -> 4200.6s] 但是你可能 [4200.6s -> 4201.7s] 你把这个东西综合起来 [4201.7s -> 4203.6s] 它可能你最后再把它跑出来 [4204.2s -> 4205.5s] 因为之前大家做架构 [4205.5s -> 4206.4s] 比如说大家在这个 [4206.4s -> 4208.1s] 因为Rusnets上跑这个足够高了 [4208.1s -> 4209.5s] 它其实就是一个Miles [4209.5s -> 4211.1s] 但是大家在这个时代 [4211.1s -> 4213.1s] 你想把这个实际的东西跑出来 [4213.1s -> 4214.9s] 你要做的东西就特别特别多了 [4214.9s -> 4216.3s] 你得做这个Scaling的验证 [4216.3s -> 4218.3s] 然后你得把这个各个工程东西搞定 [4218.3s -> 4219.5s] 你得把Data搞定 [4219.5s -> 4221.1s] 把这些东西都搞定 [4221.1s -> 4222.5s] 然后你把这个Paper或者说 [4222.5s -> 4223.5s] 你把这个架构卖出来 [4223.5s -> 4224.4s] 大家才会白影 [4224.4s -> 4225.7s] 当然我就从研究方面 [4225.7s -> 4226.7s] 我觉得我Person里 [4226.7s -> 4228.2s] 我是不会太去关注的 [4228.2s -> 4229.4s] 因为我觉得架构的验证 [4229.4s -> 4230.3s] 它是有一个 [4230.3s -> 4231.4s] 我觉得是有严格的标准的 [4231.4s -> 4233.1s] 或者说不需要把这些东西 [4233.8s -> 4235.4s] 但是我觉得从非技术角度 [4235.4s -> 4236.6s] 它现在是一个这样的状态 [4237.7s -> 4240.6s] 所以上面是拼命这篇论文的一些 [4240.6s -> 4241.9s] 亮点的突破对吧 [4241.9s -> 4243.1s] 然后接下来还开始讲 [4243.1s -> 4244.6s] 它的预训联合后训练的工作 [4245.8s -> 4246.8s] 对 我觉得架构方面 [4247.5s -> 4248.3s] 相比K2的吧 [4248.3s -> 4249.1s] 至少不一样的吧 [4249.1s -> 4250.2s] 也不一定叫创新的吧 [4250.2s -> 4250.8s] 有些叫创新 [4250.8s -> 4252.7s] 有些叫这个比较偏调调的部分 [4252.7s -> 4254.5s] 我觉得还是比之前大不一样的 [4255.0s -> 4257.0s] 你觉得为什么K2到K3变化这么大 [4257.5s -> 4258.7s] 我觉得是个战略的问题 [4258.7s -> 4259.9s] 其实K2在那个时间点 [4259.9s -> 4260.7s] 他们也可以不一样 [4260.7s -> 4262.2s] 只不过他们当时主要的重心 [4262.2s -> 4263.3s] 是把模型跑出来 [4263.3s -> 4264.9s] 所以在K2到K3这个中间 [4264.9s -> 4266.3s] 他们有更多的时间 [4266.3s -> 4268.5s] 去做了很多的优化调整 [4268.5s -> 4269.5s] 我觉得主要是K2 [4269.5s -> 4270.7s] 它本身是做得不错的 [4270.7s -> 4272.2s] 包括K2大家 [4272.2s -> 4273.6s] 当时他们主要考虑的问题 [4273.6s -> 4275.0s] 比如说怎么把命运迅速出来的 [4275.0s -> 4276.9s] 怎么有效的把模型Skill上去
[4277.3s -> 4278.9s] 因为当时K2就是one trillion [4278.9s -> 4280.2s] 其实当时one trillion的话 [4280.2s -> 4281.1s] 还是比之前的 [4281.1s -> 4283.1s] 比如说比Deep Sake V3还是要大一些的 [4283.1s -> 4283.8s] 其实在那个时间 [4283.8s -> 4285.5s] 应该也是一个比较相当大的一个模型的 [4285.5s -> 4287.5s] 所以当时他们解决的是这样的一个问题 [4287.5s -> 4291.4s] 先把Bass Model整体的一个排挂来做稳 [4291.5s -> 4292.9s] 然后在这个稳的基础上的话 [4292.9s -> 4294.3s] 然后后来K3 [4294.3s -> 4297.1s] 然后再去追求一些更因求金的一个优化 [4298.3s -> 4300.1s] 你从上面的这些亮点工作 [4300.1s -> 4301.7s] 就是这是最后的结果吗 [4301.7s -> 4302.9s] 你反推你能看出 [4302.9s -> 4305.1s] 这个团队的整体的状态是什么样的 [4305.1s -> 4306.9s] 我觉得看怎么去定义 [4306.9s -> 4308.5s] 对于不同团队定义是不一样的 [4308.5s -> 4311.3s] 如果只是KIMI的架构团队或者一训练团队 [4311.3s -> 4312.4s] 我觉得没什么变化 [4312.4s -> 4313.8s] 我觉得一直就是一个样子 [4313.8s -> 4314.9s] 但对于整体公司而言 [4314.9s -> 4316.4s] 还是有战略性的测重的 [4317.0s -> 4318.4s] 我觉得测重点就是K2 [4318.4s -> 4319.9s] 但是KIMI的团队主要的授权 [4319.9s -> 4321.0s] 还是把Bass Model [4321.0s -> 4321.7s] 这个东西做稳 [4321.7s -> 4323.3s] 就是先把能力做出来就行了 [4323.3s -> 4325.2s] 然后先不去考虑更高的 [4325.2s -> 4326.0s] 以分认识也好 [4326.0s -> 4327.5s] 更经济求金的创新也好 [4327.5s -> 4328.7s] 当然了他们团队内部 [4328.7s -> 4329.5s] 内部是一直在做的 [4329.5s -> 4332.6s] 只不过看是你什么时候亮出来的 [4332.6s -> 4334.6s] 就是研究工作是一个更长期的工作 [4334.6s -> 4336.5s] 它可能要看放在哪个模型里 [4336.5s -> 4337.5s] 跟它一起结合 [4338.2s -> 4338.8s] 对 [4339.2s -> 4341.1s] 好的 那接下来我们是预设内部 [4341.1s -> 4343.6s] 对 接下来后面其实就是一些 [4343.6s -> 4344.3s] 对 [4344.3s -> 4345.7s] 因为Protrime和Postrime的话说 [4345.7s -> 4347.7s] 因为Postrime它是一个偏工程 [4347.7s -> 4349.9s] 或者说偏具体的场景的一个东西 [4349.9s -> 4351.5s] 这块可能就不会讲太多 [4351.5s -> 4352.8s] 因为它也没有写太多 [4352.8s -> 4354.5s] 然后Protrime和Postrime的话 [4354.5s -> 4355.9s] 我觉得主要是一些经验性 [4355.9s -> 4357.1s] 或者说一些能耗的东西 [4357.1s -> 4359.5s] 主要的场景可能是前面多一些 [4360.3s -> 4362.1s] 对 然后中间会有一些比较 [4362.1s -> 4364.0s] 我觉得比较有意思可以讨论的点 [4364.0s -> 4364.8s] 我觉得可以 [4364.8s -> 4366.7s] 我会专门拿出来去讨论 [4366.7s -> 4369.1s] 就是后面主要的风格会是这样的 [4369.6s -> 4370.7s] 然后我们就一个一个来 [4370.7s -> 4371.9s] Skin ULOD的话 [4371.9s -> 4374.6s] 我觉得一个比较值得讨论的眼就是 [4374.6s -> 4376.5s] 用哪样的Learning Weights策略 [4376.7s -> 4377.9s] 因为Learning Weights策略的话 [4377.9s -> 4379.7s] 其实刚开始就是Mini-CPM [4379.7s -> 4381.8s] 当时那个paper提出的WSD [4381.8s -> 4382.7s] Mini-CPM之后 [4382.7s -> 4383.1s] 对吧 [4383.1s -> 4383.9s] Mini-CPM之前 [4383.9s -> 4385.2s] 我觉得几乎可能所有团队 [4385.2s -> 4388.0s] 都会都在用的WSD的一个优化器 [4388.4s -> 4389.9s] 因为这样的优化器 [4389.9s -> 4392.3s] 我们可以去学习Mini-CPM [4392.3s -> 4394.6s] 当时它们是怎么去考虑这个问题的 [4395.1s -> 4397.2s] 简单来说就是WSD考虑的一个问题 [4397.2s -> 4400.3s] 就是我们如何能把这个data schedule [4400.3s -> 4402.1s] 和这个Learning schedule结合起来 [4402.5s -> 4405.3s] 首先这个Mini-CPM刚开始讨论的问题就是 [4405.5s -> 4407.7s] WSD然后和这个考参的DK [4407.9s -> 4410.6s] 是可以取得一个比较相近的结果 [4410.6s -> 4412.3s] 比如说我们从一个更高的学期率 [4412.3s -> 4413.4s] 到一个更低的学期率 [4413.4s -> 4415.0s] 中间怎么去调配 [4415.0s -> 4416.0s] 它对最后的结果 [4416.0s -> 4417.9s] 其实是影响是没有那么大的 [4418.9s -> 4419.8s] 所以在这种情况下 [4419.8s -> 4422.0s] 这个Mini-CPM的团队这个工作的认为 [4422.0s -> 4424.5s] 就是中间具体的这个DK的方式 [4424.5s -> 4426.3s] 对结果不是影响特别大的 [4426.3s -> 4428.7s] 既然具体DK的方式 [4428.7s -> 4429.6s] 对于最后的结果 [4429.6s -> 4430.5s] 影响没有那么大 [4430.5s -> 4431.9s] 然后这块我们就可以跟data [4431.9s -> 4433.1s] 拍拍一些联络的方案 [4433.1s -> 4434.5s] 因为在实际训练中 [4434.5s -> 4435.5s] 我们还是会发现的吧 [4435.5s -> 4436.9s] 包括在这个图里我们可以看到 [4436.9s -> 4437.9s] 就是在DK阶段的话 [4437.9s -> 4440.1s] 这个模型loss的这个衰减速度 [4440.1s -> 4443.2s] 还是比这个大的这个学期率稳步去跑 [4443.2s -> 4444.6s] 它的这个learned rate的下 [4444.6s -> 4445.9s] 就是loss的这个下降速度 [4445.9s -> 4446.7s] 还是会大很多的 [4446.7s -> 4447.5s] 所以说就是之前 [4447.5s -> 4448.0s] 大家会认为 [4448.0s -> 4448.7s] cool down这个阶段 [4448.7s -> 4451.5s] 它其实是模型学习最快的一个阶段 [4451.5s -> 4453.5s] 所以说这个Mini-CPM [4453.5s -> 4454.3s] 当时采用的策略 [4454.3s -> 4456.3s] 就是既然cool down这个阶段 [4456.3s -> 4457.9s] 是模型学习最快的状态 [4457.9s -> 4460.1s] 那我们为什么不把更多的这个 [4460.1s -> 4460.9s] 更好的数据 [4460.9s -> 4462.7s] 然后去放在这个cool down这个阶段 [4462.7s -> 4463.9s] 然后来去做训练 [4463.9s -> 4465.5s] 这样的话可能会取得 [4465.5s -> 4467.3s] 比这个所有data均匀分布 [4467.3s -> 4468.6s] 然后所有learned rate schedule [4468.6s -> 4469.3s] 也均匀分布 [4469.3s -> 4472.2s] 然后可以取得一个更好的效果 [4472.2s -> 4473.9s] 然后这个是当时这个Mini-CPM [4473.9s -> 4477.1s] 包括WSD提出的这样的这样的一个背景 [4477.1s -> 4479.3s] 我觉得这个还是挺有意思 [4479.3s -> 4479.9s] 我觉得一方面 [4479.9s -> 4481.3s] 就是它讨论了一个
[4481.3s -> 4482.1s] 一个none travel的问题 [4482.1s -> 4483.3s] 就是为什么我们要采取 [4483.3s -> 4484.3s] 不同的这个learned rate [4484.3s -> 4485.3s] DK的方式 [4485.3s -> 4486.7s] 然后learned rate DK [4486.7s -> 4487.9s] 一个是为什么要这么去做的 [4487.9s -> 4488.6s] 而另一个就是它 [4488.6s -> 4489.7s] 就是DK的不同阶段 [4489.7s -> 4492.2s] 它具体承担什么样的一个肉 [4492.2s -> 4493.5s] 然后他们利用这个 [4493.5s -> 4494.7s] 利用这个不同learned rate [4494.7s -> 4495.8s] DK阶段的一个行为 [4495.8s -> 4497.5s] 然后跟这个data的具体策略 [4497.5s -> 4498.9s] 然后来去结合这样 [4498.9s -> 4501.8s] 最后可以取得一个更好的一个结果 [4501.8s -> 4503.1s] 然后kimmi k3这块的话 [4503.1s -> 4504.4s] 其实他们讨论了一个 [4504.4s -> 4505.5s] 不太一样的事情 [4505.5s -> 4506.4s] 就是我们为什么 [4506.4s -> 4507.8s] 他们为什么不去用 [4507.8s -> 4510.6s] WSD的这样一个结果 [4510.6s -> 4511.6s] 然后这个其实在 [4511.6s -> 4513.6s] WSD之后的一些paper里 [4513.6s -> 4516.1s] 也是可以去讨论到的 [4516.1s -> 4518.2s] 因为WSD它除了这个 [4518.2s -> 4519.9s] 可以用更好的data schedule [4519.9s -> 4522.2s] 它还有一个额外的好处就是 [4522.2s -> 4523.6s] 就因为前面的learned rate [4523.6s -> 4525.9s] 它其实是无变化的 [4525.9s -> 4526.8s] 既然它不去变化 [4526.8s -> 4528.7s] 就是它跟你整体要训练的 [4528.7s -> 4531.0s] tlops和token那是无关的 [4531.0s -> 4531.9s] 因为它是无关的 [4531.9s -> 4535.3s] 所以说我们可以更自由的去 [4535.3s -> 4537.2s] 在这个模型训练的过程中 [4537.2s -> 4539.7s] 去选取我们最后实际的config [4539.7s -> 4540.8s] 比如说我们刚开始 [4540.8s -> 4543.5s] 可能预定的是要跑实际token [4543.5s -> 4545.3s] 但如果我们跑了实际token [4545.3s -> 4546.1s] 跑到中间 [4546.1s -> 4547.8s] 比如说训练策略改变了 [4547.8s -> 4549.5s] 或者说公司的策略改变了 [4549.5s -> 4550.7s] 或者说我们要更早的发版 [4550.7s -> 4552.1s] 或者更晚发版 [4552.1s -> 4554.5s] 然后WSD这样的一个优化器 [4554.5s -> 4556.8s] 我们就可以更自由的在中间来进行切换 [4556.8s -> 4558.2s] 而不用在刚开始 [4558.2s -> 4560.7s] 就把整个模型要训的token量定死 [4560.7s -> 4562.6s] 对 然后这个它其实是这样的一个好处 [4562.6s -> 4564.2s] 但是它其实带来的一个问题 [4564.2s -> 4565.1s] 没有讨论就是 [4565.1s -> 4568.6s] 我们虽然可以去任意的去选择 [4568.6s -> 4570.5s] 这个你实际要跑的token数 [4570.5s -> 4572.1s] 但是你实际的learned rate [4572.1s -> 4574.0s] 身合适合你要跑的token数 [4574.0s -> 4575.1s] 是有关系的 [4575.1s -> 4576.4s] 比如说你要设6144 [4576.4s -> 4579.9s] 6144作为一个比较稳定的一个schedule [4579.9s -> 4581.0s] 你跑实际 [4581.0s -> 4582.5s] 可能6144是最优的 [4582.5s -> 4585.0s] 你跑实际可能就是3144是最优的 [4585.0s -> 4587.0s] 所以说从最优的角度考虑 [4587.0s -> 4588.2s] 对任意去扩展token的时候 [4588.2s -> 4591.6s] 它可能并没有大家想的那么有效 [4591.6s -> 4593.7s] 然后这块qmk3的paper [4593.7s -> 4595.3s] 其实就讨论这个问题 [4595.3s -> 4598.4s] 就是说WSD它实际的schedule [4598.4s -> 4599.8s] 它的这个调节的难度 [4599.8s -> 4602.0s] 其实和wtk是一样的 [4602.0s -> 4604.1s] 而且它可能并不一定的 [4604.1s -> 4605.9s] 并不一定好去调整 [4605.9s -> 4609.2s] 就任意去选取最后训练的token量 [4609.2s -> 4612.2s] 这个事情也不一定只有WSD才能做到 [4612.2s -> 4615.0s] 我们可以用别的方式也是可以做到的 [4615.0s -> 4616.0s] 这个paper可以写到 [4616.0s -> 4617.8s] 就这些原因其实他们可以 [4617.8s -> 4618.9s] 选择一个更简单的方案 [4618.9s -> 4622.6s] 然后考虑tk它的方案就是才更好调 [4622.6s -> 4623.8s] 就它只有两个辩量 [4623.8s -> 4625.5s] 就是一个就是你要跑多少token [4625.5s -> 4628.0s] 然后一个就是你的maximal [4628.0s -> 4629.7s] learned rate具体设多少 [4629.7s -> 4631.1s] 但是你如果WSD的话 [4631.1s -> 4632.5s] 它就其实就会多一个辩量 [4632.5s -> 4634.8s] 就是你要tk的比例具体是多少 [4634.8s -> 4636.4s] 所以说从调三的角度来讲的话 [4636.5s -> 4639.4s] 考虑tk是一个更容易去调三的一个方案 [4639.4s -> 4643.3s] 所以说kimi k3他们在paper里就写到 [4643.3s -> 4644.8s] 如果说他们是因为这个发现 [4644.8s -> 4646.7s] 这个考虑tk它是更好的去 [4646.7s -> 4649.1s] 能找到一个hyper parameter setting的话 [4649.1s -> 4650.3s] 他们最后会采取一些 [4650.3s -> 4651.7s] 也可以算是一个比较经典的 [4651.7s -> 4653.5s] 一个learned rate的方式吧 [4653.5s -> 4655.7s] 而且这个其实是大家都用 [4655.7s -> 4658.3s] 就是WSD的情况下一个不太一样的setting [4658.3s -> 4661.4s] 然后一个是基于一个不太一样的learned rate [4661.4s -> 4662.1s] scalable策略 [4662.1s -> 4664.6s] 然后当然了kimi团队被对比了 [4664.7s -> 4665.5s] 从k2到k3 [4665.5s -> 4667.4s] 然后整体的一个scaling efficiency [4667.4s -> 4668.7s] 首先k3比k2大了很多 [4668.7s -> 4670.5s] 从1T左右到了2.8T [4670.5s -> 4672.7s] 总参数就是从1T到2.8T [4672.7s -> 4673.9s] 到大了不到三倍吧 [4673.9s -> 4677.8s] 然后激活量是从32.6B到1.04B [4677.8s -> 4679.6s] 它其实是比三倍要更多的 [4679.6s -> 4681.9s] 它其实从模型参数上毫无event [4681.9s -> 4684.6s] 是比kimi k2强很多的一个模型 [4684.6s -> 4686.6s] 然后中间它有一些别的一些compere [4686.6s -> 4688.9s] 当然这个主要是上面表的一个总结 [4688.9s -> 4690.4s] 最后他们团队给出了一个 [4690.4s -> 4692.4s] scaling loud的这样一个结果 [4692.5s -> 4695.1s] k3比k2最后的在scaling efficiency上 [4695.1s -> 4697.0s] 是2.5倍的这样一个量 [4697.0s -> 4698.0s] 但是它从 [4698.0s -> 4700.1s] 对于一个简单的dance model [4700.1s -> 4702.3s] 它的scaling efficiency是一个比较经典 [4702.3s -> 4703.0s] 讨论的问题 [4703.0s -> 4705.5s] 它之前很多openight的scaling loud
[4705.5s -> 4706.7s] 程车拉的scaling loud [4706.7s -> 4708.1s] 包括一些比较新的scaling loud [4708.1s -> 4710.3s] 其实都讨论过这样的一个问题 [4710.3s -> 4711.8s] 当然这块其实比较注意的一点 [4711.8s -> 4713.2s] 就是大家其实也问过 [4713.2s -> 4716.5s] 说就是kimi k2k3的这样的一个scaling behavior [4716.5s -> 4717.6s] 是不是固定data的 [4717.6s -> 4719.2s] 我记得他们的回答是应该不是 [4719.2s -> 4721.7s] 而paper的意义应该没有直接写是不是 [4721.8s -> 4722.5s] 当然也可以理解 [4722.5s -> 4723.8s] k3和k2它用的data [4723.8s -> 4724.7s] 肯定不可能是一样的 [4724.7s -> 4725.9s] 所以我觉得这块大概的意义 [4725.9s -> 4728.3s] 应该是有一个不一样的data recipe [4728.3s -> 4730.1s] 这个整体的scaling efficiency [4730.1s -> 4732.1s] 它其实一个是综合的模型架构 [4732.1s -> 4733.8s] 也综合了一个模型的 recipe [4733.8s -> 4734.7s] train recipe [4734.7s -> 4737.7s] 然后再叠加上这个模型的数据测量 [4737.7s -> 4738.7s] 之后总的一个结构 [4738.7s -> 4740.3s] 然后总的结构作为一个大的一个 [4740.3s -> 4741.4s] 综合的一个结果 [4741.4s -> 4743.9s] 是比k2的要高了很多的 [4743.9s -> 4746.7s] ok 然后接下来是这个长上线文 [4746.7s -> 4747.9s] 长上线文的话 [4747.9s -> 4749.9s] 因为k3是一个原生 [4749.9s -> 4752.8s] 去支持一般面临长上线文的一个模型 [4752.8s -> 4755.1s] 然后这块其实比较有意思的点 [4755.1s -> 4757.3s] 就是位置编码如何去选取 [4757.3s -> 4759.1s] 我们从刚开始比较传统的 [4759.1s -> 4760.9s] 上层位的架构来去做的话 [4760.9s -> 4763.2s] 大家都会用rope来去做位置编码嘛 [4763.2s -> 4764.3s] 但是如果用rope的话 [4764.3s -> 4765.9s] 它在这个长文扩展的时候 [4765.9s -> 4767.4s] 它有个问题就是 [4767.4s -> 4769.1s] rope的这个具体的一个参数 [4769.1s -> 4770.0s] 是需要做调整的 [4770.0s -> 4771.4s] 如果不做调整的话 [4771.4s -> 4773.0s] 这个rope直接去扩长文 [4773.0s -> 4775.0s] 就会显得没有那么有效 [4775.0s -> 4776.9s] 然后这个是其实是这个rope [4776.9s -> 4778.4s] 时代大家一个经典的做法 [4778.5s -> 4779.5s] 当然说如果现在 [4779.5s -> 4781.0s] 如果你还是用一个权注意力 [4781.0s -> 4784.2s] 或者说如果你不引入现行注意力的话 [4784.2s -> 4786.6s] 这个策略不会有太大的改变 [4786.6s -> 4789.9s] 也就是说你还是得去在不同的长度的setting来 [4789.9s -> 4792.3s] 来去调调节不同rope的参数 [4792.3s -> 4794.5s] 但是这个事情在这个混合模型里 [4794.5s -> 4795.9s] 是可以改变的 [4795.9s -> 4797.9s] 最早是这个copair团队的一个工作 [4797.9s -> 4800.5s] 只要讲了这样的一个因素 [4800.5s -> 4801.8s] 他们的结论也很简单 [4801.8s -> 4804.9s] 简单来说就是因为这个hybrid Tension排布方式 [4804.9s -> 4806.0s] 对于linear Tension来说 [4806.0s -> 4808.9s] 它已经引入了这样的一个位置信息 [4808.9s -> 4810.8s] 无论说你用这个rope也好 [4810.8s -> 4812.3s] rope加斯莱尼温队也好 [4812.3s -> 4813.5s] linear Tension也好 [4813.5s -> 4815.5s] 就是在现行注意力的这样的一个阶段 [4815.5s -> 4818.4s] 其实位置信息是已经被引入到的 [4818.4s -> 4819.9s] 所以说如果在这个setting下 [4819.9s -> 4821.8s] 就是在hybrid Tension的setting下 [4821.8s -> 4823.5s] 如果我们可以把这个four Tension [4823.5s -> 4824.3s] 从rope改成nope [4824.3s -> 4826.9s] 也就是说在全注意力的情况下 [4826.9s -> 4828.0s] 把位置边马去掉 [4828.0s -> 4829.8s] 它其实是可以带来一个更好 [4829.8s -> 4832.4s] 一个是可以带来更好的一个模型的表现 [4832.4s -> 4835.4s] 第二个就是它在这个长上下半是更容易扩展的 [4835.4s -> 4838.4s] 也就是说nope它是在模型扩展的情况下 [4838.4s -> 4840.3s] 不需要调整任何模型架构的参数 [4840.3s -> 4843.7s] 就可以达到一个长上下半的这样的一个效果 [4843.7s -> 4845.1s] 这个效果无疑是很优雅的 [4845.1s -> 4847.6s] 因为我们会觉得模型架构的参数选择 [4847.6s -> 4849.6s] 当然是跟具体的长度是没有关系的 [4849.6s -> 4851.9s] 然后也没有任何的理论去支持说 [4851.9s -> 4855.1s] 就是我们具体我们为什么要去不同的长度resp一下 [4855.1s -> 4857.0s] 然后来去采取不一样的参数 [4857.0s -> 4860.3s] 然后这种架构其实就可以有效的避免了这一点 [4860.3s -> 4862.5s] 一个是刚开始我比较早的看到 [4862.5s -> 4864.3s] 然后我可能看到第二天我就去浮现了一下 [4864.3s -> 4866.5s] 因为我当时看到就觉得特别有道理 [4866.5s -> 4867.8s] 然后我第二天浮现了一下 [4867.8s -> 4869.1s] 然后也很work [4869.1s -> 4873.1s] 我当时觉得这个肯定在混合注意力的一个里面 [4873.1s -> 4875.1s] 比较好的一个方式 [4875.1s -> 4876.8s] 我在会议里边还省到了一篇文章 [4876.8s -> 4878.8s] 当时我直接给了一个strong accept [4878.8s -> 4881.5s] 我感觉我这几年可能也都没有给过几个strong accept [4881.5s -> 4883.1s] 因为我觉得这个确实是一个很有效 [4883.1s -> 4885.1s] 也是一个很优雅的解决方案 [4885.1s -> 4889.3s] 然后当然这个也可以讨论一个大家之前理解错误的一个问题 [4889.3s -> 4892.3s] 就是nope它本质上它带来的是resncy bias [4892.3s -> 4893.9s] 就是nope它work最有效的点 [4894.2s -> 4898.4s] 对它对short context的这个建模能力是特别有效的 [4898.4s -> 4900.3s] 但是它其实对厂门来说是没有帮助的 [4900.3s -> 4902.0s] 甚至是有负面影响的 [4902.0s -> 4904.2s] 对于某一些这个舆论观点会认为 [4904.2s -> 4906.6s] 这个是nope在引入了这个厂门的这个表现 [4906.6s -> 4907.5s] 这个其实是错误的 [4907.5s -> 4909.3s] 就是nope它并不带来任何的厂门能力 [4909.3s -> 4911.1s] 它甚至是损害厂门能力 [4911.1s -> 4913.8s] 所以说kimi k3会把这个nope在这个 [4913.8s -> 4916.3s] 在这个厂上台门的这个附和团阵这块直接下掉 [4916.3s -> 4918.3s] 然后直接下掉之后就会一个是 [4918.3s -> 4919.5s] 如果你直接侧外推 [4919.5s -> 4920.7s] 直接侧外推它都会好很多 [4920.7s -> 4921.9s] 如果用nope的话 [4922.0s -> 4923.5s] 你扩长度你需要调参数 [4923.5s -> 4925.3s] 如果如果你调了参数你不去训练 [4925.3s -> 4925.5s] 对吧 [4925.5s -> 4927.1s] 它那个结果其实是很差的 [4927.1s -> 4928.9s] 所以说如果有nope你不用调参数 [4928.9s -> 4930.2s] 它的外推效果也很好 [4930.2s -> 4931.8s] 然后成了厂门的这个效果 [4931.8s -> 4932.5s] 也没有任何问题 [4932.5s -> 4933.3s] 甚至还要更好 [4933.3s -> 4935.4s] 它其实是一个在混合注意力的一个 [4935.4s -> 4936.3s] contact
[4936.3s -> 4938.4s] 是一个相当优美的解决方案 [4938.4s -> 4941.0s] 所以说这个kimi k3也用了这样的一个解决方案 [4941.6s -> 4942.7s] 然后post training的话 [4942.7s -> 4944.9s] 首先其实可以讨论的一个问题就是 [4944.9s -> 4946.3s] 第一季度这个训练 [4946.3s -> 4948.3s] 应该在什么阶段去引入 [4948.3s -> 4951.7s] 然后这个其实大家采取的策略是不太一样的 [4952.1s -> 4953.1s] 比如说dbsc v3 [4953.1s -> 4955.9s] 他们是刚开始原刹fv8来去训练的 [4955.9s -> 4957.7s] 然后dbsc v4 [4957.7s -> 4960.7s] 他们就直接用w4a8来去做延伸训练的 [4960.7s -> 4962.9s] 但是kimi这块采取的策略不太一样 [4962.9s -> 4964.9s] 他们是首先用高进度去训练 [4964.9s -> 4966.3s] 然后在sft阶段 [4966.3s -> 4969.5s] 然后再把这个低进度的qat引入进来的 [4969.5s -> 4971.5s] 这样至少我就有两点则的讨论 [4971.5s -> 4973.0s] 第一个就是从项目而言 [4973.0s -> 4974.5s] 就抛开技术角度 [4974.5s -> 4976.2s] 从整个这个项目的管理而言 [4976.2s -> 4977.9s] 大规模的训练采取更高进度 [4977.9s -> 4979.8s] 肯定是一个更保险的方案 [4979.8s -> 4980.2s] 对吧 [4980.2s -> 4981.4s] 因为它无论如何也不会错 [4981.4s -> 4984.3s] 如果用高进度训练在大规模的skilling中 [4984.3s -> 4985.3s] 带来了其他问题的话 [4985.3s -> 4987.5s] 我觉得这个是一个相当不可控的一个因素 [4987.5s -> 4988.3s] 而且这个东西 [4989.5s -> 4991.3s] 更大规模的清单是很难 [4991.3s -> 4994.1s] 就是提前被充分验证的特别精确的 [4994.1s -> 4995.1s] 我觉得第一点就是 [4995.1s -> 4997.1s] 从项目管理的角度的一个优势 [4997.1s -> 4998.2s] 第二个就是 [4998.2s -> 4999.0s] 从技术角度 [4999.0s -> 4999.1s] 对吧 [4999.1s -> 5000.6s] 我们是否有必要 [5000.6s -> 5002.5s] 从刚开始就用低进度训练 [5002.5s -> 5003.8s] 起码从我的实验而言 [5003.8s -> 5005.1s] 应该也是没有必要的 [5005.1s -> 5007.3s] 然后kimi可能他们发现也是没有必要的 [5007.3s -> 5008.8s] 也就是说对于低进度推理而言 [5008.8s -> 5009.8s] 而言本身就是 [5009.9s -> 5011.4s] 从from scratch刚开始就引入 [5011.4s -> 5013.9s] 并不会带来任何模型能力的一个提升 [5013.9s -> 5014.4s] 也就是说你 [5015.0s -> 5016.7s] wc8你在什么时候引入 [5016.7s -> 5018.3s] 只要你过了一定量的训练 [5018.3s -> 5019.8s] 它最后的结果可能都差不多 [5019.8s -> 5022.3s] 所以在sapt阶段引入是一个更保险 [5022.3s -> 5025.5s] 在然后在技术上也也不会带来额外损失的一个方式 [5025.5s -> 5026.8s] 对然后rl这块的话 [5026.8s -> 5028.4s] 因为rl其实也是对 [5028.4s -> 5029.4s] 因为kimi刚开始 [5029.4s -> 5032.6s] 它其实对rl这块是一个比较充分的一个 [5032.6s -> 5035.2s] 比如说他们其实从很早以前就比较重视rl这块 [5035.2s -> 5035.9s] 所以说 [5035.9s -> 5038.2s] 从kimi k1.5到k2.5 [5038.2s -> 5040.7s] 他们其实一直在做一些比较实际的创新 [5040.7s -> 5042.3s] 然后其实在k3.5也会 [5043.1s -> 5044.8s] 对比较充分的引入进来 [5044.8s -> 5047.0s] 然后这些其实都是一些比较 [5047.0s -> 5049.3s] 对比较成熟的一些方案了 [5049.3s -> 5050.9s] 这块就不太展开去讨论了 [5051.5s -> 5052.7s] 然后4.1.3的话 [5052.7s -> 5054.0s] 这块可以讨论一下opt [5054.0s -> 5058.7s] opt刚开始也是董老师团队这边比较早去讨论的一个方式 [5058.7s -> 5059.8s] 就是厌医院的 [5059.8s -> 5061.6s] 对为了厌医院动力 [5061.6s -> 5063.5s] 对然后pnlm这个是预显做的 [5063.5s -> 5065.5s] 预显去年也是清华特奖的 [5065.5s -> 5068.3s] 这个是他在董老师在厌医院员这边去做的 [5068.3s -> 5069.9s] 然后其实opt从刚开始 [5069.9s -> 5071.2s] 就是刚开始大家用起来 [5071.2s -> 5075.5s] 和其实和后面大家实际在工程中用的方式不太一样 [5075.5s -> 5076.7s] 这个其实可以讨论一下 [5077.4s -> 5079.5s] 就是opt刚开始的multi-mode是什么 [5079.5s -> 5081.1s] 后来大家是又是怎么做的 [5081.1s -> 5084.1s] 当时这个opt讨论的contest是这个征流 [5084.1s -> 5084.9s] 征流有两种 [5084.9s -> 5085.9s] 一个是黑核征流 [5085.9s -> 5087.9s] 黑核征流就是大家现在比较采取的方式 [5087.9s -> 5088.7s] 就拿一个API [5088.7s -> 5091.0s] 然后我们不知道模型内部的状态 [5091.0s -> 5094.3s] 我们也拿不到这个模型就是推理的logit [5094.3s -> 5095.4s] 对于这个外界来说 [5095.4s -> 5096.9s] 这模型它完全只是一个黑核 [5096.9s -> 5099.1s] 我们只能拿到它的输入和输出 [5099.1s -> 5100.1s] 然后这个叫黑核征流 [5100.1s -> 5102.3s] 然后白核征流的话就是另一种征流方式 [5102.3s -> 5104.5s] 我们可以获取到这个模型本身 [5104.5s -> 5108.4s] 然后我们也可以任意的去拿到这个模型推理的过程中 [5108.4s -> 5110.6s] 我们想得到的任何的一个状态 [5110.6s -> 5111.6s] 然后在这个场景下 [5111.6s -> 5113.5s] 就我们如何去做这个征流 [5113.5s -> 5116.9s] 然后是我们是否可以在基于比黑核征流更好的一个表现 [5118.1s -> 5119.3s] 然后mini-lm [5119.3s -> 5121.1s] 当时采取方式就是反其他而行之 [5121.1s -> 5123.2s] 因为之前大家采取的方案就是让模型 [5123.2s -> 5125.1s] 就是让teacher去生成答案 [5125.1s -> 5127.5s] 然后再把这个生成答案用sft的 [5127.5s -> 5130.2s] 用forward kd的方式把它引入到silent的模型里 [5130.2s -> 5132.2s] 然后mini-lm是反过来做的 [5132.2s -> 5134.6s] 也就是让学生去生成答案 [5134.6s -> 5137.7s] 然后让teacher做一个每步的一个纠正 [5137.7s -> 5139.7s] 然后直观来讲的话其实就有两种 [5139.7s -> 5140.7s] 一个是老师讲课 [5140.7s -> 5141.4s] 老师讲课 [5141.4s -> 5143.9s] 然后你把这个老师讲课的结果学进来 [5143.9s -> 5145.8s] 然后第二个就是你自己去做答案 [5145.8s -> 5146.7s] 自己去做体 [5146.7s -> 5149.4s] 自己去写这个中央推理过程 [5149.4s -> 5152.5s] 然后老师会把你中央推理哪里做的不对 [5152.6s -> 5153.4s] 然后给你出来 [5153.4s -> 5155.1s] 然后然后告诉你怎么去做 [5155.1s -> 5156.3s] 这个叫reverse KL [5156.3s -> 5157.5s] 然后reverse KL的话 [5157.5s -> 5159.9s] 然后后来sintimus lab另一个名字 [5159.9s -> 5161.9s] 就叫onpolicy distillation [5161.9s -> 5163.1s] 就是大家都会意识到 [5163.1s -> 5164.4s] 这个是一个比较有效的一个 [5164.4s -> 5166.5s] 从征流的角度是一个比较有效的方式
[5166.5s -> 5169.9s] 就是说从就我们不直接去学习模型的答案 [5169.9s -> 5172.1s] 而是在student自己的推理过程中 [5172.1s -> 5176.0s] 让教室模型逐步的去verify或者说去纠正 [5176.0s -> 5178.4s] 学生模型的这样的一个推理的方式 [5178.4s -> 5180.0s] 然后这个饭式刚开始 [5180.0s -> 5182.4s] 其实是为了这个征流来去使用的 [5182.5s -> 5184.6s] 无论是你做白盒的一些实验性的 [5184.6s -> 5185.8s] 包括说从公司的角度 [5185.8s -> 5187.0s] 你可以有一个pro的版本 [5187.0s -> 5187.9s] 可以有一个flash的版本 [5187.9s -> 5190.2s] 然后flash的版本你可以用opd的方式 [5190.2s -> 5192.7s] 然后来去征流更大的模型的这样的一个 [5192.7s -> 5193.0s] 结果 [5193.0s -> 5195.0s] 然后从而去获得一个更好的一个表现 [5195.0s -> 5196.2s] 你如果fromflash [5196.2s -> 5197.1s] 新来一个flash的模型 [5197.1s -> 5199.7s] 你可以比flash的模型获得一个更好的表现 [5199.7s -> 5201.1s] 从而在这个比较 [5201.1s -> 5202.4s] 比较便宜的模型这档 [5202.4s -> 5204.3s] 然后获得一个更大的竞争力 [5205.5s -> 5208.7s] 这个是这个opd刚开始的一个multi-version [5208.7s -> 5210.3s] 但是其实后来大家 [5210.3s -> 5211.5s] 更常用的一个方式 [5211.5s -> 5212.4s] 不是去做征流 [5212.4s -> 5213.1s] 原因在于 [5213.1s -> 5214.3s] 其实原因在于 [5214.3s -> 5216.2s] 如果你想做征流的话 [5216.2s -> 5218.0s] 你至少得有一个大模型 [5218.0s -> 5219.9s] 然后你再去训练一个小模型 [5219.9s -> 5222.5s] 如果你自己训练自己的模型而言 [5222.5s -> 5224.3s] 但是如果说你想去征流这个 [5224.3s -> 5225.3s] 比如说 [5225.3s -> 5226.6s] 征流一些黑盒的模型 [5226.6s -> 5228.3s] 这套方案是完全不可用的 [5229.3s -> 5230.3s] 从公司或者说 [5230.3s -> 5231.7s] 从这个项目侧来讲 [5231.7s -> 5233.5s] 如果我们不去基于一个大模型 [5233.5s -> 5235.3s] 然后来去这个训练一个更快 [5235.3s -> 5236.6s] 更小的一个小模型 [5237.2s -> 5237.5s] 的话 [5237.5s -> 5239.1s] 因为现在大家都不是这个setting [5239.2s -> 5240.4s] 大家都一般都是这个 [5240.4s -> 5241.5s] 搞一个旗舰模型 [5241.5s -> 5242.5s] 然后就完事了 [5242.5s -> 5244.3s] 然后来去它作为influence服务 [5244.3s -> 5245.4s] 然后在这个场景下的话 [5245.4s -> 5248.4s] 就不存在大刀小征流的这样的一个行为了 [5248.4s -> 5250.7s] 然后大家逐渐去采用的征流的方式 [5250.7s -> 5252.1s] 就是自己征流自己 [5252.1s -> 5253.9s] 然后为什么要自己征流自己呢 [5253.9s -> 5255.2s] 我觉得还是两部分 [5255.2s -> 5256.4s] 一个是非技术层面的 [5256.4s -> 5257.5s] 一个是技术层面的 [5257.5s -> 5259.4s] 我觉得从非技术层面的原因的话 [5259.4s -> 5260.9s] 我觉得这个技术可以让这个 [5260.9s -> 5263.9s] 整个Post-tune team的管理变得更简单 [5263.9s -> 5265.5s] Post-tune合板它其实是一个 [5265.5s -> 5266.6s] 比较highway的一个东西 [5266.6s -> 5268.3s] 因为Post-tune它不跟 [5268.3s -> 5269.3s] 它跟Post-tune不一样的 [5269.3s -> 5270.7s] Post-tune我只要把数据合起来 [5270.7s -> 5272.2s] 然后一会去干就完事了 [5272.2s -> 5273.5s] 但大家一般Post-tune的话 [5273.5s -> 5275.1s] 会用一些更复杂或者一些 [5275.1s -> 5276.8s] 更先进的一些训练测量 [5276.8s -> 5279.7s] 而且这些测量可能会不太容易训练在场 [5279.7s -> 5280.5s] 可能会 [5280.5s -> 5281.9s] 如果再直接去做合板的话 [5281.9s -> 5283.1s] 可能会有一些难度 [5283.7s -> 5285.4s] 所以说基于项目管理的测量的话 [5285.4s -> 5287.1s] Unpolicy Distillation它其实就是一个 [5287.1s -> 5287.8s] 比较好的测量 [5287.8s -> 5291.0s] 能把整个Post-tune的team的管理变得简化一些 [5291.0s -> 5292.2s] 然后从技术角度的话 [5292.2s -> 5293.6s] 比如说大家训练LL [5293.6s -> 5294.9s] 它一般有不同的测量嘛 [5295.0s -> 5295.9s] 比如说你训Mass [5295.9s -> 5298.1s] 它可能就是一个Wirefile or Reward [5298.1s -> 5300.9s] 然后如果你有些Preference的一些需求 [5300.9s -> 5302.9s] 你可能就会有一些Reward Model来去做 [5302.9s -> 5303.5s] 然后 [5303.5s -> 5305.5s] 如果你再想扩展这个LL别的能力 [5305.5s -> 5307.5s] 你看你可能每个能力对于LL来说 [5307.5s -> 5309.6s] 它的Reward它都是一个独特Reward [5310.3s -> 5312.0s] 然后你如果想把所有的模型的 [5312.0s -> 5313.2s] 所有的能力都搞到一块 [5313.2s -> 5316.6s] 因为Post-tune一般大家都会这个专项突破嘛 [5316.6s -> 5319.3s] 然后你想把直接专项模型的不同这个Reward [5319.3s -> 5320.8s] 直接拿进来一召会 [5320.8s -> 5322.7s] 它其实是比Properation的难度要大 [5322.7s -> 5324.0s] 我也不是说完全不可能 [5324.0s -> 5325.1s] 还是有可能的 [5325.1s -> 5327.1s] 但是OPD的话它就会变得很简单 [5327.1s -> 5330.5s] 我们可以把这个不同的Reward Model或者说不同的LL饭式 [5330.5s -> 5332.0s] 然后减化成不同的模型 [5332.7s -> 5335.4s] 然后减化成不同的模型这个事情就容易很多了 [5335.4s -> 5337.5s] 因为对于LL测量或者说对于这个Data [5337.5s -> 5339.0s] 它是一个高度依购的一个状态 [5339.0s -> 5341.4s] 但是对于模型来说它是一个高度同格的状态 [5341.4s -> 5343.5s] 因为现在我们也不会为了不同的任务 [5343.5s -> 5345.1s] 去专门设计不同的模型架构的 [5345.1s -> 5346.3s] 如果模型都长这样的话 [5346.3s -> 5348.2s] 我们再做一个Multi-Tier的一个盒版 [5348.2s -> 5349.5s] 这个就会容易很多 [5349.5s -> 5351.7s] 不过这个也不是K3首先去用的 [5351.8s -> 5356.5s] 这个是一个大家现在比较widely accepted的一个做法 [5356.5s -> 5360.7s] 我印象的应该小米、Gelm应该大家现在都是这么去做的 [5360.7s -> 5363.2s] 对 然后Colonization刚刚讲过来 [5363.2s -> 5366.0s] 然后DraftModel这块其实我觉得还是挺有意思的 [5366.0s -> 5369.5s] 这块还是可以额外去有一些很延伸的工作的 [5369.5s -> 5372.4s] 对 因为我觉得这块K3目前优化的不是很完善 [5373.0s -> 5376.0s] 之前小米他们推出了一个能达到1000TPS的一个方案 [5376.0s -> 5377.6s] 那个主要是用了两个技术 [5377.6s -> 5378.7s] 第一个就TiO2团队 [5378.7s -> 5381.4s] 然后他们做的一个可以高度融合不同阶段的一个算子 [5381.4s -> 5384.5s] 然后这样的话其实它可以获得比这个传统的这个 [5385.5s -> 5388.0s] VLM推理方式强很多的这样的一个推理效率 [5388.0s -> 5390.0s] 然后那个可能达到300-400TPS [5390.0s -> 5393.2s] 然后小米是个基于TiO2团队的那个一个结果 [5393.2s -> 5395.7s] 然后再加上那个基于TiO2T的一个结果
[5395.7s -> 5397.9s] 然后再加上那个Deflash这个投机推理 [5397.9s -> 5401.9s] 带来的外的加速比最后能带来一个比原模型强很多的一个 [5401.9s -> 5404.2s] 对 强很多的这样的一个推理速度 [5404.2s -> 5407.8s] 然后这个其实主要的服务是对于一些成本可以付出更高的成本 [5407.9s -> 5411.5s] 但是想拿到更强的一个推理速度的这一波用户去做的 [5411.5s -> 5415.1s] 因为它本质上如果说你是为了整体的sroop的服务的话 [5415.1s -> 5416.7s] 这个其实它的收益会小很多 [5416.7s -> 5418.3s] 但是如果你是小bash size [5418.3s -> 5421.5s] 但是大的sroop的这套方案是会强很多的 [5421.5s -> 5424.3s] 然后这样的话就跑开POWRT那方面的贡献 [5424.3s -> 5427.1s] 然后最后就落到了如何去做更好的MTP [5427.1s -> 5430.1s] 或者说用做更好的DraftModel [5430.1s -> 5432.4s] 然后这块的话有一些有LeaseMilder的工作 [5432.4s -> 5434.4s] 然后刚开始就是Ego3和MTP [5434.4s -> 5437.1s] Ego3和MTP它其实它主要的方法就是 [5437.1s -> 5439.6s] 因为刚开始Spacklative decoding [5439.6s -> 5441.1s] 因为这个提出的时候呢 [5441.1s -> 5443.6s] 大家还是用一个没有关系的小模型 [5443.6s -> 5446.5s] 然后来去Spacklative比较大的模型 [5446.5s -> 5448.3s] 然后这样的话它其实有一个问题就是 [5448.3s -> 5452.7s] 你无法充分的去利用大模型中间的一些黑灵 state [5452.7s -> 5455.1s] 如果说你可以利用大模型中间的黑灵 state的话 [5455.1s -> 5456.8s] 你其实就可以把小模型做得更小 [5456.8s -> 5458.4s] 或者说你在枪桶的参数底下 [5458.4s -> 5460.3s] 然后接触率做得更高 [5460.3s -> 5463.3s] 最后可以带来总的更强的一个推理效率 [5463.3s -> 5464.7s] 然后MTP和Ego3 [5464.7s -> 5466.8s] 然后它其实都是这样的一个思想 [5466.8s -> 5468.9s] 当然MTP如果从from scratch的话 [5468.9s -> 5470.3s] 它还有一些别的好处 [5470.3s -> 5471.2s] 然后Deflash的话 [5471.2s -> 5472.6s] 它其实会更有意思一些 [5472.6s -> 5474.7s] 对因为它联系的传统的Language Model [5474.7s -> 5477.7s] 和训练比较火的Deflash Model这两条脉络 [5477.7s -> 5480.3s] 然后通过Deflash这条线结合了起来 [5480.3s -> 5483.1s] 对因为Deflash Model刚开始提出的时候 [5483.1s -> 5484.6s] 这个大家主要的claim就是 [5484.6s -> 5487.5s] Deflash Model在这个单用户或者说BatchSize [5487.5s -> 5488.9s] 比较小的情况下 [5488.9s -> 5490.4s] 可以获得比这个 [5490.4s -> 5492.0s] 可以获得比传统的Language Model [5492.0s -> 5494.7s] 快很多的这样的一个推理效率 [5494.7s -> 5497.0s] 对但是DeflashLanguage Model之前 [5497.0s -> 5498.0s] 最大有两个问题嘛 [5498.0s -> 5500.3s] 第一个问题就是它如果from scratch [5500.3s -> 5503.0s] 它的训练效率不够高 [5503.0s -> 5508.0s] 它的整体的结果很难和传统的AR的Language Model [5508.0s -> 5509.2s] 想去PD [5509.2s -> 5512.1s] 然后第二个问题就是它只能打sloopput [5512.1s -> 5514.2s] 就是它只能打小BatchSize的sloopput [5514.2s -> 5515.7s] 但是如果是多用户 [5515.7s -> 5518.0s] 最后追求总的sloopput的一个场景 [5518.0s -> 5520.8s] 它其实DeflashLanguage Model并没有优势 [5520.8s -> 5523.1s] 所以Deflash当时主要就是统一了这样者 [5523.1s -> 5524.7s] 试图去利用DeflashLanguage Model [5524.7s -> 5525.8s] 更快的一个推理方式 [5525.8s -> 5528.5s] 然后进一步去优化MTP [5528.5s -> 5531.0s] 或者DraftModel这块的一个加速笔 [5531.0s -> 5532.7s] 最后可以得到一个更优的 [5532.7s -> 5534.6s] 总的一个单用户的sloopput [5534.6s -> 5536.6s] 当然了MTP这块其实是 [5537.9s -> 5539.5s] 之前我跟陈建就是 [5539.5s -> 5542.0s] 就是Deflash那个同学也交流过 [5542.0s -> 5543.1s] 他当然提了一个点是 [5543.1s -> 5544.7s] 对于整个模型是很重要的 [5544.7s -> 5546.0s] 即使我们用Deflash [5546.0s -> 5548.7s] 这种更先进的DraftModel的侧点 [5548.7s -> 5551.5s] 它跟预讯链的关系仍然是很大的 [5551.6s -> 5553.4s] 也就是说对于DraftModel来说 [5553.4s -> 5555.7s] 我们它是需要利用大模型的 [5555.7s -> 5557.7s] 一定的推理能力的基础上 [5557.7s -> 5560.3s] 然后再去使用DraftModel进一步的去伙大 [5560.3s -> 5561.5s] 也就是说对于MTP来说 [5561.5s -> 5563.2s] MTP是需要给 [5563.2s -> 5564.9s] 就是在Pretion阶段 [5564.9s -> 5566.8s] 需要给MTP提供一个接口 [5566.8s -> 5568.0s] 然后这个接口 [5568.0s -> 5570.1s] 会对下游的DraftModel的提升 [5570.1s -> 5570.9s] 会特别的帮助 [5570.9s -> 5572.2s] 然后这部分其实是需要 [5572.2s -> 5574.8s] 在Pretion阶段就引入的 [5574.8s -> 5577.7s] 然后当然DraftModel也是需要做一些反车理 [5577.7s -> 5579.4s] 它是需要做一些自己特化的处理的 [5579.5s -> 5581.6s] 比如说我们可以用一个Carol Loss [5581.6s -> 5583.4s] 然后来去替代这个比较传统的 [5583.4s -> 5585.1s] Nastalcom Prediction的 [5585.1s -> 5585.9s] 这样的话 [5585.9s -> 5587.9s] 我可以在原ModelWirefile的过程中 [5587.9s -> 5589.1s] 它可以对得更齐 [5589.1s -> 5590.9s] 这样的话可以进一步的去提升 [5590.9s -> 5593.0s] DraftModel接收的一个效率 [5593.0s -> 5594.6s] 对 这块我觉得之后 [5594.6s -> 5596.7s] 还会有一些更深层次的工作 [5596.7s -> 5597.2s] 我猜哈 [5597.2s -> 5600.0s] 因为这个肯定不是对于MTP的一个重点 [5600.0s -> 5602.3s] 然后Homart这个Rltask的话 [5602.3s -> 5603.8s] 它是一个比较Specific [5603.8s -> 5605.5s] 对于不同的任务来说 [5605.5s -> 5607.1s] 它有不同的具体的一些测量 [5607.1s -> 5609.1s] 我觉得这块的话只要看原文就好了 [5609.5s -> 5611.8s] 对 然后接下来的一大块就是Infra [5611.8s -> 5612.8s] 对 Infra这块的话 [5612.8s -> 5615.4s] 首先现在其实对于模型架构的设计来说 [5615.4s -> 5616.1s] 关键的设计 [5616.1s -> 5618.8s] 它是需要和Infra进行一些Code Design的 [5618.8s -> 5619.7s] 一个是Code Design [5619.7s -> 5621.1s] 然后一个就是模型架构本身 [5621.1s -> 5623.9s] 它会影响整体的Infra团是它本身的一个设计 [5623.9s -> 5627.0s] 然后这块包括跟DF4系列的Infra [5627.0s -> 5628.9s] 它是有一些设计上的区别 [5628.9s -> 5631.9s] 这块我觉得也是一个比较有意思的一个点 [5631.9s -> 5632.9s] 然后水源就是KDA [5632.9s -> 5636.3s] KDA之前在在前面其实已经讨论过了 [5636.3s -> 5640.4s] 因为我们如果想去追求更高的一个Chunk的效率 [5640.4s -> 5643.7s] 然后我们是需要对KDA的穿简系数做出一定的限制的 [5643.7s -> 5646.2s] 这样的话我们可以用一个更好的Colonel的设计形式 [5646.2s -> 5650.0s] 然后来去带来更强的一个Colonel level的一个效率 [5650.0s -> 5652.9s] 然后这块其实多的一个点就是KDA的CP [5652.9s -> 5654.2s] KDA的CP是一个 [5654.2s -> 5655.6s] 我觉得这个Linear它的CP
[5655.6s -> 5658.7s] 其实是一个可以简单讨论一下的一个点 [5658.7s -> 5661.4s] 因为比如说对于Sliding Window或者说对于Fortense而已 [5661.4s -> 5664.6s] 其实CP它其实从概念上是相当容易的 [5664.7s -> 5666.6s] 因为比如说你对于Fortense来说 [5666.6s -> 5668.2s] 比如说现在有些比较经典的算法 [5668.2s -> 5671.6s] 比如说你可以用Rule Tension或者说用Jag Zag Tension [5671.6s -> 5674.3s] 因为Tension它本身的这个计算模式是够简单的 [5674.3s -> 5675.9s] 而且它很多地方是省不了的 [5675.9s -> 5678.9s] 我至少会得把这个快GPU的这个所有的QB開始 [5678.9s -> 5681.2s] 都拿到一个GPU上然后来去做计算 [5681.2s -> 5683.7s] 我在这块是一个相对来说比较简单的一个概念 [5683.7s -> 5685.5s] 但是对于Linear Tension的CP而言 [5685.5s -> 5687.7s] 它的概念其实是一个更复杂的 [5687.7s -> 5688.7s] 然后这个大的框架 [5688.7s -> 5692.3s] 其实我们还是可以回到最经典的一个Chunkwise Recurrent [5692.4s -> 5694.6s] Chunkwise Recurrent首先我们都同意说 [5694.6s -> 5698.1s] Chunkwise Recurrent对于Linear Tension来说是一个必备的算法 [5698.1s -> 5702.5s] 然后对于一个正常的单击的一个不开CP的一个训练场地来说 [5702.5s -> 5704.5s] Chunkwise Recurrent它其实就有两部分 [5704.5s -> 5708.4s] 一个就是你可以拆成比如说比较小的16Tile或者64Tile的一个上课 [5708.4s -> 5712.0s] 然后唱个之间然后使用这个定规的方式去计算 [5712.0s -> 5715.5s] 然后Chunk内部的话可以用一些比较Parallel的方式去计算 [5715.5s -> 5717.2s] 然后KDA也是这么做的 [5717.2s -> 5721.5s] 然后KDA的那个DK的限制主要是解决这个Chunk内部的一个 [5721.5s -> 5723.5s] 可以用Parallel计算的一些高效性 [5723.5s -> 5726.3s] 然后这样的话其实对于单击的Linear Tension来说 [5726.3s -> 5729.1s] 就是一个Chunk内部用并行的方式去计算 [5729.1s -> 5734.5s] 然后Chunk之间用串形的方式去计算这样的一个计算的pattern [5734.5s -> 5739.8s] 但是对于CP来说我们就需要讨论它的一个Linear Tension比较有意思的一个方式 [5739.8s -> 5743.4s] 就是它这个Chunk本身是可以任意去拆分的 [5743.4s -> 5745.5s] 也就是说不同的Chunk的数字 [5745.5s -> 5749.5s] 就比如说你想512个Token一个Chunk或者说8K token一个Chunk [5749.6s -> 5751.6s] 它在数学上是完全等价的 [5751.6s -> 5754.3s] 这个就跟早年一些比较拼接式的方案 [5754.3s -> 5759.3s] 比如说有一些工作会尝试这个Chunk之间都要用Linear Tension [5759.3s -> 5760.3s] Chunk内部用Fort Tension [5760.3s -> 5761.9s] 如果用这种策略的话 [5761.9s -> 5767.0s] 它的这个Chunk的大小就跟你具体的模型的这个Architecture Design是有关的了 [5767.0s -> 5769.5s] 但是纯Linear Tension其实是无关的 [5769.5s -> 5774.7s] 既然是无关的话我们就可以对这个Chunk的层次做出一个比较任意的处理 [5774.7s -> 5777.4s] 比如说对于单击来说它Chunk是一步去拆分的 [5777.4s -> 5778.9s] 我们就这个16Tile去拆分 [5778.9s -> 5782.2s] 然后16Tile内部用一个并行的方式去计算 [5782.2s -> 5784.7s] 但是它其实并没有限制说你Chunk只能拆一次 [5784.7s -> 5786.9s] 它的思想就是比如说我有一个One Million [5786.9s -> 5788.3s] 特别长的一个Chunk [5788.3s -> 5792.8s] 然后我们可以拆成8K放了一张卡8K放一张卡 [5792.8s -> 5795.9s] 这样的话我们就构建了一个以大Chunk为单元 [5795.9s -> 5797.2s] 然后不同这PU之间 [5797.2s -> 5800.1s] 然后采取定位计算这样的一个Chunk的拆分方式 [5800.1s -> 5802.7s] 然后我们拿到这个8K的这样的一个拆分方式之后 [5802.7s -> 5805.1s] 我们可以在这个内部进一步去拆分 [5805.1s -> 5806.4s] 最后在Linear Tension的时候 [5806.4s -> 5810.3s] 我们没有任何的限制说一个Chunk中间是如何去计算 [5810.3s -> 5812.3s] 因为对于一个比较小的Chunk而言 [5812.3s -> 5813.9s] 这个Parallel是一个比较优的实现 [5813.9s -> 5816.3s] 但是如果我们拆Chunk足够大的话 [5816.3s -> 5818.4s] 我们可以采取这个Chunk套Chunk的方式 [5818.4s -> 5819.3s] 然后来去进一计算 [5819.3s -> 5821.6s] 也就是说对于Linear Tension的CP而言的话 [5821.6s -> 5824.5s] 我们是做一个层次性的Chunk [5824.5s -> 5826.7s] 我们首先是在这个不同机器上做一个Chunk [5826.7s -> 5827.9s] 然后在一个机器内的话 [5827.9s -> 5829.6s] 我们再在Colonel来我然后做一个Chunk [5829.6s -> 5831.6s] 然后通过这样一个双层Chunk的解释 [5831.6s -> 5834.6s] 然后组成一个对于Linear Tension一个比较大的CP [5834.6s -> 5837.0s] 然后这个呢我可主要还是来源于说 [5837.0s -> 5839.9s] 就是ChunkLinear Tension的Chunk可以任意拆分的一个特性 [5839.9s -> 5843.2s] 然后这样的话可以带来Linear Tension的一个CP的一个方案 [5843.2s -> 5847.0s] 然后这个其实是对于这个Fortension不太一样的一个处理方式 [5847.0s -> 5848.3s] 这个是可以讨论一下那些 [5848.3s -> 5854.0s] 然后接下来是上面这个是CP或者说Colonelize的一个infra的方案 [5854.0s -> 5857.9s] 然后接下来的话其实就会讨论就是从这个分布式训练的一个角度 [5857.9s -> 5860.8s] 然后我们如何去优化它的分布式的这样的一个方案 [5860.8s -> 5862.7s] 然后这块的话我们后面就可以发现 [5862.7s -> 5864.9s] 其实它跟DLC的方案是稍微有些区别的 [5864.9s -> 5868.8s] 然后这个区别是主要是来源于不同Moe的一个架构的一个方式 [5868.8s -> 5870.7s] 然后首先的话5.2.1这部分 [5870.7s -> 5875.9s] KIMITUAN对带来了一个GDPP进一步延伸的一个G算方案 [5875.9s -> 5879.0s] 然后他们的主要的claimery一点就是对于传统的EP [5879.0s -> 5881.0s] 因为我们现在都用JoplessEP [5881.0s -> 5883.5s] JoplessEP就是对于每一个token而言 [5883.5s -> 5886.7s] 我选哪个专家它是不受整体的一个约束的 [5886.7s -> 5888.1s] 就是我想选哪个选哪个 [5888.1s -> 5889.4s] 然后这样带来一个方案 [5889.4s -> 5891.9s] 我们会总起来之后会发现不同的专家 [5891.9s -> 5893.6s] 它的负载是不一样的 [5893.6s -> 5896.4s] 然后既然它是不一样的它就会带来一些问题 [5896.4s -> 5898.4s] 第一个问题就是对于EP而言 [5898.4s -> 5901.0s] 因为每个GPU它分道的token数不一样 [5901.0s -> 5901.9s] token数不一样的话 [5901.9s -> 5904.8s] 它就会带来它的整体的执行时间不一样 [5904.8s -> 5906.3s] 然后执行时间如果一旦不一样 [5906.3s -> 5907.3s] 它就会互相等 [5907.3s -> 5909.4s] 互相等就会浪费这个模型的 [5909.4s -> 5911.5s] 会浪费GPU的这个算力 [5911.5s -> 5912.3s] 这是第一个问题 [5912.3s -> 5915.2s] 第二个问题就是如果我们不同的卡上的它的那个 [5915.2s -> 5916.1s] token数是不确定的 [5916.1s -> 5919.0s] 然后对于这个GPU的通信来说它会额外多一个阶段 [5919.1s -> 5921.6s] 就是我们首先是需要告诉所有GPU [5921.6s -> 5923.0s] 就是你要接受多少token [5923.0s -> 5924.2s] 它再把这个token发过去 [5924.2s -> 5926.0s] 所以至于这两个阶段的话 [5926.0s -> 5927.3s] 传统的EP它严格来说 [5927.3s -> 5929.5s] 当然不是一个最优的一个方案的 [5929.5s -> 5930.7s] 如果完全为了info [5930.7s -> 5932.6s] 它最优的方案就是这个戴照铺的EP [5933.8s -> 5935.0s] 也就是说我们每个token [5935.0s -> 5937.4s] 然后要去受到全局的一个影响 [5937.4s -> 5939.4s] 然后受到一个全局的影响的情况下 [5939.4s -> 5942.1s] 我们可以通过一系列的一个allocated的方式 [5942.1s -> 5942.9s] 从模型的角度 [5942.9s -> 5945.8s] 让每个expert都受到完全均匀的一个token [5945.8s -> 5947.2s] 然后通过模型的方式 [5947.2s -> 5948.9s] 然后让它达到完全的balance [5948.9s -> 5950.5s] 完全的影响的情况其实就是这样的 [5950.5s -> 5953.6s] 所以说如果在这个info的层面完全均衡 [5953.6s -> 5955.0s] 然后是一个最优的话 [5955.0s -> 5957.0s] 从info测的就是我们努力把info
[5957.0s -> 5958.9s] 从非最优导上一个最优 [5958.9s -> 5961.1s] 然后同时保持模型能力是不下降的 [5961.1s -> 5962.9s] 因为如果照铺token的话 [5962.9s -> 5963.9s] 大家现在都不会用 [5963.9s -> 5965.8s] 因为它那个对于模型损失 [5965.8s -> 5967.9s] 对于模型能力损失还是相当明显的 [5967.9s -> 5970.5s] 然后然后默应P它就采取了一个 [5970.5s -> 5972.1s] 我觉得是一个比较高端的一个方案 [5972.1s -> 5974.2s] 它把模型的这个EP的方式 [5974.2s -> 5976.3s] 所变成了一个更动态的一个方式 [5976.3s -> 5978.0s] 就是它是可以计算出来 [5978.0s -> 5980.3s] 比如说之前的一个经典的方式 [5980.3s -> 5982.3s] 就是我比如说我有128个专家 [5982.3s -> 5984.0s] 然后我如果一批 [5984.0s -> 5985.1s] 如果我们一批8的话 [5985.1s -> 5987.0s] 可能每张卡放16个专家的话 [5987.0s -> 5988.5s] 它是一个比较静态的一个方式 [5988.5s -> 5989.5s] 然后默应P的话 [5989.5s -> 5991.4s] 它采取的是一个动态型的方式 [5991.4s -> 5993.1s] 就是它又有一些荣誉的专家 [5993.1s -> 5995.1s] 然后通过这个额外荣誉专家的话 [5995.1s -> 5996.9s] 然后它从数学上是可以证明说 [5996.9s -> 5998.6s] 我存在一个测量 [5998.6s -> 6000.5s] 可以使得就是我们只需要增加一个 [6000.5s -> 6001.6s] 小比例的荣誉专家 [6001.6s -> 6003.5s] 就可以保证这个token数的完全对齐 [6003.5s -> 6005.5s] 然后我感觉像是一个比较经典的 [6005.5s -> 6007.1s] 数据结构与算法的一个问题 [6007.1s -> 6008.1s] 这个是可以证明到的 [6008.1s -> 6009.7s] 然后他们可以证明到这一点的话 [6009.7s -> 6011.1s] 它就可以得到一个结论 [6011.1s -> 6012.7s] 就是我们通过少量的荣誉专家 [6012.7s -> 6016.4s] 就可以达到就是所有卡上均存的这样的效果 [6016.4s -> 6017.9s] 然后具体如何去达到 [6017.9s -> 6019.9s] 他们采取了一个online planning的方式 [6019.9s -> 6020.7s] 然后这样的话 [6020.7s -> 6022.3s] 我们去提前去规划 [6022.3s -> 6024.2s] 就是哪些卡应该有哪些荣誉专家 [6024.2s -> 6026.6s] 然后在这种情况下可以达到不同的这个 [6026.6s -> 6027.8s] 对不同卡上这个 [6027.8s -> 6030.3s] 就从token数的一个完全的一个均衡 [6030.3s -> 6032.8s] 当然即使说你从卡的角度是均衡的 [6032.8s -> 6034.5s] 它并不代表专家层面是均衡的 [6034.5s -> 6036.7s] 因为这个算法它只是保证了所有每张卡 [6036.7s -> 6039.6s] 对吧每张卡的所有的token数是一定的 [6039.6s -> 6041.5s] 但是它并不保证每个专家是一定的 [6041.5s -> 6043.1s] 因为一张卡里有多个专家 [6043.1s -> 6046.7s] 如果说你还想保证每个专家的都是一定的 [6046.7s -> 6047.5s] 那就没有办法了 [6047.5s -> 6050.1s] 那你就只能采取这个有存的一个策略去优化 [6050.1s -> 6052.4s] 这个可能如果大家是不希望的话 [6052.4s -> 6054.1s] 这个上线可能就卡到这里 [6054.1s -> 6056.3s] 所以说我们在两个中间可以采取 [6056.3s -> 6058.5s] 就可以找一些更优的一个处理方式 [6059.5s -> 6061.7s] 这块是KIMI团队带来的一个 [6061.7s -> 6063.4s] 比较有意思的一个创新 [6063.5s -> 6065.8s] 接下来就是这块就Memory的一份吹领 [6065.8s -> 6066.8s] 我觉得这块比较有意思 [6066.8s -> 6068.2s] 就首先他们带来了一个 [6068.2s -> 6069.4s] 从软件工程的层面 [6069.4s -> 6070.5s] 这个比较简单的一个方案 [6070.5s -> 6073.1s] 就是我们可以去更细腻度的去控制 [6073.1s -> 6074.9s] 就是那个每个部件 [6074.9s -> 6076.9s] 就是应该去采取这个Activation [6076.9s -> 6079.0s] 还是去采取这个Offloading的一个策略 [6079.0s -> 6080.8s] 然后这块不一样的一点就是 [6080.8s -> 6083.9s] KIMI K3它采取了大规模的这个Offloading [6083.9s -> 6085.5s] 对吧 中间计算得到一个结果 [6085.5s -> 6087.1s] Offloading到CPU上 [6087.1s -> 6089.4s] 然后这个其实是一个None Travers的一个东西 [6089.4s -> 6092.2s] 因为理论上如果想满足这个Offloading [6092.2s -> 6093.7s] 不拖慢这个模型的讯解 [6093.7s -> 6095.2s] 它是有一定的条件的 [6095.2s -> 6097.4s] 你得保证CPU和CPU之前的同性 [6097.4s -> 6098.9s] 它满足的某个不等式 [6098.9s -> 6100.7s] 这样你才有完全用计算 [6100.7s -> 6102.5s] Overlap时候同性的一个可能 [6102.5s -> 6104.3s] 然后为了达到可以做Offloading的话 [6104.3s -> 6106.5s] 然后KIMI K3它把所有可以Offloading的东西 [6106.5s -> 6107.6s] 都用FP8去存 [6107.6s -> 6108.6s] 这样它可以省一倍 [6108.6s -> 6111.4s] 省一倍它可能才能从一个编辑 [6111.4s -> 6112.4s] 然后跨到另一个编辑 [6112.4s -> 6113.9s] 然后具体这个编辑怎么算 [6113.9s -> 6115.1s] 这个跟具体的卡 [6115.1s -> 6116.1s] 这个具体的具体玷体环境 [6116.1s -> 6117.7s] 集群环境也跟具体的模型 [6117.7s -> 6119.2s] config是有关系的 [6119.2s -> 6120.2s] 然后后面的话 [6120.2s -> 6121.9s] 它一方面它们是需要去优化 [6121.9s -> 6123.5s] 这个Attenture Residual [6123.5s -> 6125.3s] 它本身的一个运发的关系的 [6125.3s -> 6127.1s] 这个其实在Attenture Residual的paper [6127.1s -> 6129.1s] 其实也讨论过 [6129.1s -> 6131.0s] 然后我觉得PP这块其实它 [6131.0s -> 6131.9s] 我觉得一个是PP [6131.9s -> 6133.9s] 一个是那个同性的Overlap的手段 [6133.9s -> 6136.3s] 这个其实跟Deepsec是不太一样的 [6136.3s -> 6137.6s] 一个方案 [6137.6s -> 6140.0s] 因为首先比如从DeepsecV3的角度来讲 [6140.0s -> 6142.3s] 它采取了两个不太一样的 [6142.3s -> 6145.1s] 至少是能吹过的一个方式 [6145.1s -> 6146.9s] 一个就是这个比较细腻度的 [6146.9s -> 6148.6s] MOE角度的Overlap [6148.6s -> 6149.5s] MOE角度的Overlap [6149.6s -> 6151.9s] 因为首先就是MOE中间有两个同性 [6151.9s -> 6153.5s] 有两个同性它是一个是Dispatch [6153.5s -> 6154.5s] 一个是Combine [6154.5s -> 6155.5s] 然后这两个同性 [6155.5s -> 6157.0s] 它是Overlap是比较大的 [6157.0s -> 6158.5s] 其实在这个Blackwell上 [6158.5s -> 6159.7s] 它其实又不太一样 [6159.7s -> 6160.4s] 但是无论如何 [6160.4s -> 6162.5s] 它是一个比较大的一个开销 [6162.5s -> 6163.9s] 然后DeepsecV3的话 [6163.9s -> 6165.9s] 它一个是在MOE的Overlap这块 [6165.9s -> 6167.4s] 它会拆得特别细 [6167.4s -> 6168.3s] 然后具体的方式 [6168.3s -> 6171.5s] 它就是会把这个MOE上一个Batch的MOE的forward [6171.5s -> 6173.9s] 有backward和下一个MOE的forward
【嘉宾】把它俩融合起来,然后通过重排去计算的一个先后顺序,从而达到把所有的Dispatch和Combine的计算都藏起来。想达到这点的话,其实需要特别精细、也特别复杂的一些软件工程的优化。这个其实在MegaScale里边也讨论过类似的事情,因为这个事情如果想做得足够好的话,我们需要把所有的forward和backward的计算从原子计算的层面就拆开,然后手工进行重新排布,我觉得这个还是有一定难度的。
【嘉宾】另一个就是DeepSeek采用了一个DualPipe的策略,也就是为了缓解PP的气泡和不同expert负载不均匀的问题,他们采取了DualPipe的一个排布方式。当然除了DualPipe还有一个DualPipeV,它们达到的效果是一样的,对,它从逻辑上会更简单一些。起码从公开的论文里可以看到,Kimi K3是没有采用这两个优化方式的,它们采用的其实是一些别的方式。
【嘉宾】第一个就是如何去隐藏通信,这个就跟实际的模型架构的选型有关系。因为Kimi K3采用了Latent MoE(注:应为MoE架构相关),因为Latent MoE本身极大地降低了通信开销,所以它在整个计算开销里边其实减小了特别多。因为通信开销减小了特别多,所以如果想把它overlap掉,就会变得容易很多。就是我们没有必要再去跟另一个batch的计算来做overlap,我们可以采取一个batch内部更简单的overlap手段,就可以把这个通信很好地隐藏掉。
【嘉宾】Kimi K3具体采用的方式,是把MoE的前向和后向的通信跟Shared Expert的计算overlap在一起。因为Shared Expert现在绝大多数模型都有,而且Shared Expert是有一定的计算量的。正是因为通信开销减小了,所以说它才能被Shared Expert一个比较简单的方式去overlap掉。但是如果你用传统的MoE,它的通信开销就会特别大,特别大的话,你用Shared Expert去overlap就很难overlap掉。所以如果Shared Expert overlap不掉的话,你就必须把另一个batch拿进来,这样才能完美地把通信都隐藏掉。
【嘉宾】用不一样的MoE的架构,带来了不一样的overlap的策略。然后这个策略它带来一个好处就是,推理的Critical Path Latency它是免费的。从训练架构上的话,因为我们通信量更小了,就可以采取更简单的策略来排布通信的细粒度。其实还有另一个问题,就是我们即使通过更复杂的方法去完美地把通信藏掉,它其实也不是完全无损的。因为即使是完美的通信和计算隐藏,计算也会相对地慢一些,它不是完全可以无损的。针对这个问题,DeepSeek也做了类似的优化,DeepSeek的优化方式就是用一个足够少的SM的占用来获得更大的一个整体的通信的带宽,才能让这块的overlap跑得更快。所以说这是一个很不一样的设计方式。
【嘉宾】另一个设计方式就是PP的处理,其实是不太一样的。因为如果用DualPipe或者DualPipeV这样的PP排布方式的话,不同PP rank之间相对还是一个比较对称的状态。如果你用单向的PP的话,它其实就不太对称。不太对称的话就有两种解决方式嘛:第一种就是让它变得对称;第二个方法其实就是Kimi这个paper里讨论到的,我们可以把不均衡的问题转化掉。因为比较普通的PP的话,比如说前面的PP rank它进入得更早,它积累的batch就会更多,它的activation的压力就会越大。Kimi K3采用的方式是,它把Memory占用比较大的一些PP rank上的数据直接存到Memory比较小的一个PP rank上,通过这种比较lightweight的方式,去规避掉更复杂的DualPipe的一个设计方式。
【嘉宾】后面的话其实就是Memory的一些优化。因为Muon是需要按矩阵去做牛顿-舒尔茨迭代的嘛,所以如果用传统的Adam,因为Adam相当于把所有参数都摊平,之后再切分,又因为Adam是逐元素优化,所以你怎么切都不会影响模型优化的结果。但是对于Muon来说它是有影响的,因为我在某个rank上需要把一个矩阵所有的参数都保存下来,所以说这块需要做一些处理,才能让Muon比较好地在optimizer这个角度切起来。
【嘉宾】对,然后domain shift这个inference也是一个比较有意思的点。因为从inference的角度就是纯的规模的问题,当然大家想把它优化得足够好,也是需要相当多的effort,这刚刚也讨论了很多。但是其实对于domain shift而言,你每引入一项功能,它的inference难度其实都是直线提升的。这块的问题就是如何把Vision做做好。Vision做好的话,其实有两个问题。第一个就是我们对于现在的Vision来说,大家会对Vision做一定的压缩。比如说Vision最后输入到大模型里边的话,它可能是8K token,但是你输入之前它可能是32K token。就是说Vision接入模型的过程中,其实是有做一个压缩的,但是这个压缩在Vision内部是没有做的。
[6478.3s -> 6480.3s] 所以说它在vshinql内部计算的时候 [6480.3s -> 6481.8s] 它就会更长 [6481.8s -> 6483.3s] 所以为了解决更长的一个问题 [6483.3s -> 6486.7s] 可能你如果对于金蛋对于模型主干不需要KCP的话 [6486.7s -> 6489.9s] 你可能就对于vshinql它可能就需要KCP [6490.0s -> 6493.6s] 所以说这块它是需要做一些额外的infra的一个处理 [6494.7s -> 6496.2s] 然后PP这个就更有意思了 [6496.2s -> 6498.3s] PP这个大家其实注意到一个问题就是 [6498.3s -> 6500.3s] 我们做这个vl [6500.3s -> 6501.7s] Native Training的时候 [6501.7s -> 6503.9s] vl的tokern它其实只是有一个比例的 [6503.9s -> 6506.3s] 比如说你对于某些卡来说 [6506.3s -> 6507.9s] 它是一个纯温版的一个状态 [6507.9s -> 6510.7s] 然后你对于另一张卡它可能是一个全世界的一个 [6510.7s -> 6512.4s] vl的比例相当大的一个状态 [6512.4s -> 6513.4s] 如果这种情况的话 [6513.4s -> 6517.4s] 你还是会出现一个不同卡不均的一个现象 [6517.4s -> 6519.5s] 然后这个现象它不仅会影响DP [6519.5s -> 6521.9s] 它PP也是会去影响的 [6521.9s -> 6522.9s] 因为PP的话 [6522.9s -> 6525.6s] 我们是首先是要保证不同PP之间 [6525.6s -> 6527.3s] 它是一个比较均匀的一个状态 [6527.3s -> 6529.7s] 这样它的流水线才能打得足够满 [6529.7s -> 6530.7s] 不然的话 [6530.7s -> 6532.9s] 如果我们在这里引入的一个新代微信以后的 [6533.6s -> 6537.1s] 第一个PP它就它的这个计算强度就会显著去增强 [6537.1s -> 6540.3s] 它就会破坏整体这个流水线的一个打满的一个状态 [6540.3s -> 6541.9s] 然后为了去规避这个行为 [6541.9s -> 6544.0s] PPX3这块采用的一个方式 [6544.0s -> 6546.3s] 就是把PP不去放在这个PP的钢开头 [6546.3s -> 6548.2s] 它说会放在中间或者尾巴上 [6548.2s -> 6550.1s] 然后所以在前面的PP [6550.1s -> 6553.9s] 在前面的微信以后的或者说比较浅层的Language Model [6553.9s -> 6554.7s] 做的过程中呢 [6554.7s -> 6556.0s] 中间的PP它是显示的 [6556.0s -> 6557.9s] 它就会把中间显示这部分利用上 [6557.9s -> 6561.1s] 提前把微信以后的后面的一些步骤提前算出来 [6561.1s -> 6564.6s] 然后通过这种方式去规避掉第一个PP [6564.6s -> 6566.2s] 带来的足够大的一个气泡 [6566.2s -> 6569.9s] 然后这个是一个在PP的层面需要做的一个优化 [6569.9s -> 6571.9s] 它这篇论文真的写得好详细 [6571.9s -> 6573.0s] 是的 [6573.0s -> 6575.8s] 就是这些细节东西其实是需要去处理的 [6575.8s -> 6577.2s] 如果你不处理的话 [6577.3s -> 6580.3s] 就是你写出来大家就觉得这个事件肯定没有问题 [6580.3s -> 6581.4s] 可以去这么做 [6581.4s -> 6583.0s] 然后有一些没有写的部分呢 [6583.0s -> 6586.4s] 大家就会去追求如果有些团队的这个组织密度 [6586.4s -> 6589.1s] 没有那么足够说我自己就能把这个事情搞定了 [6589.1s -> 6591.6s] 大概一部分人就会沉迷小道消息嘛 [6591.6s -> 6594.9s] 大家就会思想一打听这些东西到底是怎么处理的 [6594.9s -> 6596.1s] 如果你写出来这个事情 [6596.1s -> 6599.5s] 其实就对大家就不需要去找小道消息了 [6599.5s -> 6603.1s] 你说他写出来在附近难吗 [6603.1s -> 6606.4s] 我觉得一发上的事情本质上没有什么难的 [6606.4s -> 6608.7s] 因为它本身就是个高度确定性的东西 [6608.7s -> 6611.4s] 我觉得所有一发上的事情都本质上它是确定性的东西 [6611.4s -> 6612.9s] 但是你如果想自己提出来的话 [6612.9s -> 6615.2s] 它就对你本身分析perfection的方式 [6615.2s -> 6617.1s] 或者说对于你本身的这个组织密度 [6617.1s -> 6620.6s] 或者说就是你团队氛围就是有比较高的一个要求 [6620.6s -> 6622.9s] 但是你如果整个infrared团队比较好 [6622.9s -> 6624.0s] 你还是可以自己搞出来的 [6624.0s -> 6625.0s] 但是你如果不行的话 [6625.0s -> 6628.3s] 你就尝试去follow一些比较好的一些工程时间的practice [6628.3s -> 6629.6s] 但如果这个事情都得搞定 [6629.6s -> 6631.3s] 那我觉得就可能就不太应该了 [6631.3s -> 6632.4s] 前面主要是 [6632.4s -> 6634.4s] 就infrared大家主要就翻三部分吧 [6634.4s -> 6635.4s] 一个是perfection [6635.4s -> 6637.7s] perfection的话前面主要是讨论了一些 [6637.7s -> 6641.3s] 大规模分布式的情况下一些比较复杂的一些用法方式 [6641.3s -> 6642.6s] 然后后面的话一个就是 [6642.6s -> 6645.2s] 后面的话就是两部分就把一个就rl [6645.2s -> 6646.9s] 然后还有一个就是influence [6646.9s -> 6650.0s] 然后rl的话因为它本身就是设计大量的influence的 [6650.0s -> 6651.1s] 所以在这两个中间呢 [6651.1s -> 6652.8s] 其实是有一些overlap的 [6652.8s -> 6655.7s] 然后l它本身一个对不太一样的点 [6655.7s -> 6658.3s] 就是它需要对三大规模三的box [6658.3s -> 6660.1s] 会有一些比较细的一个要求 [6660.1s -> 6662.5s] 对但这个其实就算是一个更工程的一个东西了 [6662.6s -> 6664.4s] 这块的话它其实就是一些比较细的处理 [6664.4s -> 6666.0s] 或者去处理不同的三大box [6666.0s -> 6667.4s] 对于rl的task来说 [6667.4s -> 6668.4s] 你每一个tractory [6668.4s -> 6671.0s] 它可能都对应一个它自己的dalker嘛 [6671.0s -> 6674.4s] 所以说就如何去管理大规模dalker [6674.4s -> 6676.3s] 其实是这块比较麻烦的一个问题 [6676.8s -> 6677.8s] 然后上面这块的话 [6677.8s -> 6679.4s] 我觉得这个chimiketide比较有意思 [6679.4s -> 6682.3s] 就是它会时不时给你蹦出来一些比较有意思的东西 [6683.0s -> 6684.6s] 对 我觉得这块比较有意思东西 [6684.6s -> 6686.7s] 但也不一定是刚才就是它提的了 [6686.7s -> 6688.5s] 这块可以省一个gradient buffer [6688.5s -> 6691.8s] 对 这块相当于是一个比较tricky的一个东西 [6691.9s -> 6693.2s] 因为对于一个晚上的rl来说 [6693.2s -> 6694.7s] 它有好几部分的model嘛 [6694.7s -> 6697.7s] 比如说你至少有一个种model [6697.7s -> 6699.3s] 然后你还有一个reference model [6699.3s -> 6702.3s] 然后你主model它还要对应的一个gradient和optimizer [6702.3s -> 6704.9s] 当然如果你还想做这个revolver model的话 [6704.9s -> 6706.5s] 它还会再多一个model [6706.5s -> 6707.5s] 然后其实这块的话 [6707.5s -> 6708.9s] 它就会多特别特别多的model [6708.9s -> 6711.9s] 然后这个chimiketide这块两个一个比较有意思的事情 [6712.6s -> 6714.5s] 就是它不同model之间 [6714.5s -> 6715.6s] 因为你放一个model [6715.6s -> 6718.8s] 它对于这片头来说它还是很大的一个memory嘛 [6718.8s -> 6720.4s] 所以说它这块相当于是 [6720.4s -> 6722.5s] 把两部分memory就托到一块了 [6722.5s -> 6723.9s] 就对于reference model而言 [6723.9s -> 6727.1s] 然后它们发现它可以跟gradient buffer来去合起来 [6727.1s -> 6729.6s] 因为首先reference model它是没有提肚的 [6729.6s -> 6731.8s] 然后在你求个objective的过程中 [6731.8s -> 6733.2s] 你是没有gradient的 [6733.2s -> 6734.6s] 等你有了gradient之后 [6734.6s -> 6736.9s] 然后你可能reference model就不会去用了 [6736.9s -> 6739.1s] 对 所以说它这块用了一个gradient buffer [6739.1s -> 6741.5s] use for non-policy model for forwarding
[6741.5s -> 6744.1s] 然后这块是一个比较有意思的一个东西 [6744.1s -> 6747.5s] 然后上下路就感觉是一些比较常规的处理方式 [6747.5s -> 6750.3s] 然后我觉得reference目前不会有太多的一个东西 [6750.3s -> 6752.2s] 因为主体的reference optimization [6752.2s -> 6755.1s] 它其实是VLM或者S这样的专门讨论的一些内容 [6755.1s -> 6757.7s] 然后这块它其实讲的就是对于qmx3架构 [6757.7s -> 6759.4s] 它所带来的增量 [6759.4s -> 6763.0s] 就是在现代的特定形中是如何去处理的 [6763.0s -> 6765.7s] 所以然后首先就是会带来 [6765.7s -> 6769.2s] 就linear tension它在现代的reference handling [6769.2s -> 6770.6s] 它有一个麻烦 [6770.6s -> 6772.4s] 它有一个麻烦就是它prefix caching [6772.4s -> 6774.3s] 它是一个比较麻烦的一个点 [6774.3s -> 6775.5s] 因为对于for tension来说 [6775.5s -> 6779.1s] 它相当于是每个位置它都有一个cache [6779.1s -> 6780.7s] 所以说你可以任意 [6780.7s -> 6782.0s] 就是你下一个位置的cache [6782.0s -> 6784.9s] 它一定是上一个cache的一个简单的一个增量 [6784.9s -> 6786.1s] 所以说在这种情况下 [6786.1s -> 6788.6s] 就prefix caching会对简单很多 [6788.6s -> 6790.0s] 但是对于linear tension来说 [6790.0s -> 6792.5s] 它会有一些它会有一个比较麻烦的特性 [6792.5s -> 6794.5s] 就是linear tension它每一步 [6794.5s -> 6795.3s] 它是需要 [6795.3s -> 6798.5s] 它是会在原来上一步的这个qvcache的基础上 [6798.5s -> 6799.9s] 它是做一个复写的 [6799.9s -> 6801.9s] 也就是说对于每一步而言 [6801.9s -> 6804.7s] 它的prefix state它其实都是不一样的 [6804.7s -> 6806.9s] 所以说如果我们把每一步都存起来 [6806.9s -> 6809.1s] 那其实linear tension的好处就完全没有了 [6809.1s -> 6810.8s] 但是你如果完全不存的话 [6810.8s -> 6813.8s] 你就完全没有办法去享受到这个prefix caching [6813.8s -> 6815.4s] 所带来的好处 [6815.4s -> 6817.1s] 对然后这块的话 [6817.1s -> 6818.7s] 就是对现代目前对于这个 [6818.7s -> 6820.3s] linear tension它的一个采用的策略 [6820.3s -> 6821.9s] 就是按照block聚期 [6821.9s -> 6823.6s] 就是我每个block去做一个 [6823.6s -> 6825.9s] 去做一个prefix caching [6825.9s -> 6826.6s] 然后同样的话 [6826.6s -> 6828.2s] 我们还是要另一个让它能够确认的点 [6828.2s -> 6830.7s] 就是VLM这样的一个page kv [6830.7s -> 6832.1s] 它的一个实现方式 [6832.1s -> 6833.7s] 从工程上或者从概念上 [6833.7s -> 6835.4s] 它最简单的一个分布方式 [6835.4s -> 6837.9s] 它是不考虑层和层之间的意志性的 [6837.9s -> 6840.2s] 所以说其实从去年还是前一年 [6840.2s -> 6842.0s] 就是如果想直接在这个VLM里 [6842.0s -> 6843.1s] 去引入捧合价格的话 [6843.1s -> 6845.7s] 它在infra上并不是一个容易的事情 [6845.7s -> 6847.9s] 而且因为现在infra3这越来越havvy了 [6847.9s -> 6849.5s] 所以说如果简单的一些改法的话 [6849.5s -> 6852.5s] 会把整个infra3这搞得特别特别的乱 [6852.5s -> 6854.0s] 当然现在这个infra3这可能 [6854.0s -> 6855.7s] 都有一些比较先进的管理方式 [6855.7s -> 6857.5s] 但是这个就是需要去透露处理一下 [6857.5s -> 6859.5s] 就是把这个一个就是把不同的 [6859.5s -> 6860.8s] tension pattern去结合起来 [6860.8s -> 6863.4s] 对于FOR的tension来说是按page管理的 [6863.5s -> 6865.5s] 但对于linear or slender 的话 [6865.5s -> 6867.1s] 它才是不按照page管理的 [6867.1s -> 6869.3s] 因为它并不似在一个长久的一个 [6869.3s -> 6871.1s] 对于token weather 原来的一个 [6871.1s -> 6872.7s] KVcache的一个产生方式 [6872.7s -> 6874.3s] 这个本身对于VLM的设计来说 [6874.3s -> 6877.0s] 它其实是需要做一些坚重性的处理的 [6877.0s -> 6879.4s] 然后我觉得后面就是一些 [6879.4s -> 6880.6s] 就是适配性的一些优化 [6880.6s -> 6881.5s] 因为底图定的优化 [6881.5s -> 6883.1s] 它其实跟prefile或者说跟 [6883.1s -> 6883.9s] trainin不太一样嘛 [6883.9s -> 6884.7s] 所以说这块的话 [6884.7s -> 6886.2s] 对于每个环节都需要做一些 [6886.2s -> 6888.1s] 外的一些carnals的一个page [6888.1s -> 6889.6s] 但我觉得这块应该对 [6889.6s -> 6891.3s] 我觉得这块都是可以去做的 [6891.3s -> 6893.1s] 而且我觉得应该是一个 [6893.1s -> 6895.1s] 确定性比较高的一个设计 [6895.1s -> 6896.8s] 然后后面就是evaluation [6896.8s -> 6899.0s] 我觉得evaluation这个没啥好讲的 [6899.5s -> 6900.8s] 就是好呗 特别好 [6900.8s -> 6902.6s] 就是在每个环节都好 [6902.6s -> 6905.4s] 然后后面主要就是这样的一个状态 [6905.4s -> 6907.3s] 然后应该就没啥了 [6907.3s -> 6910.2s] 觉得KVcache让你最impressive的地方是哪里啊 [6910.2s -> 6910.8s] 个人而言吧 [6910.8s -> 6911.8s] 我觉得impressive的一点 [6911.8s -> 6914.2s] 就是他们把这个计划搞得特别特别大 [6914.2s -> 6915.6s] 就是足足有100别领 [6915.6s -> 6917.3s] 比我预期的还是要大一些的 [6917.9s -> 6919.3s] 这个依赖的什么能力呢 [6920.3s -> 6921.8s] 这个不依赖任何能力 [6921.8s -> 6923.7s] 就是你具体定多少几乎这个本身 [6923.7s -> 6924.9s] 它不是一个技术性的东西 [6924.9s -> 6927.1s] 就看你想到达到什么阶段的一个效果 [6927.6s -> 6929.9s] 我觉得KVcache还是比较有破裂力 [6929.9s -> 6931.8s] 就是在以后的开研模型这个赛的基础上 [6931.8s -> 6933.1s] 他们要提升一个数量级 [6933.1s -> 6934.0s] 所以我刚刚就说 [6934.0s -> 6936.5s] 他们比上一代的激活其实是多了300多的 [6936.5s -> 6938.4s] 我觉得这个决定是一个非就型的一个决定 [6938.4s -> 6939.9s] 但是这个是要一定的负离的 [6941.1s -> 6943.6s] 因为杨志宁喜欢说有概率的非共识 [6943.6s -> 6945.1s] 你觉得在KVcache上能看到 [6945.1s -> 6948.0s] 他们的什么样的different bits或者说创新 [6948.0s -> 6948.8s] 我觉得也没啥 [6949.0s -> 6950.8s] 因为有价值的技术创新 [6950.8s -> 6952.1s] 他们都打写了一个paper了 [6952.1s -> 6953.5s] 所以这个KVcache刚出来的时候 [6953.5s -> 6955.1s] 我主要就surprise这个size [6955.1s -> 6956.2s] 别的我都不和我一起 [6957.1s -> 6958.8s] 就是你刚才给大家也展示了 [6958.8s -> 6960.1s] 好多他们历史的paper [6960.1s -> 6961.6s] 其实中间就已经发出来对吧 [6961.6s -> 6964.7s] 但是他把它优化到了一个更大的模型上 [6965.6s -> 6968.1s] 对 我其实的一个观点就是 [6968.1s -> 6971.2s] 科学研究是不存在阶约性的提升的 [6971.2s -> 6973.5s] 只是说大家习惯把这个技术的 [6974.3s -> 6977.4s] 建议性提升的某些节点会成为一个mouse stone [6977.5s -> 6979.1s] 我其实一直是这么认为的
【主持人】技术永远是慢慢去提升,然后靠这个公司里的所有人、项目里的所有人,包括整个业界的同学一块去推动的,所以我觉得从这个角度没有什么milestone(里程碑)。有人说Kimi的研究方式相对比较科学,你觉得这个你认同吗?怎么解释?
【嘉宾】首先我是认可的,但具体认可的方式的话,我觉得首先这个主要是来源于他们内部的一些管理方式。当然有些公开大家都知道的,就是Kimi其实是公开里边大家认可的最强调这个模型内测(模型internal)的一个团队,就Kimi他们一直尝试去让这个pre-training变得更加的科学,比如说让不同的行为的trace可以以一些更可靠的方式去获取到,然后让比如说模型的不稳定性、或者说模型collapse的现象,可以更明确地去归因。所以他们其实一直去强调这个模型内测这样的一个case,我觉得这个其实是他们科学化的一个体现吧,我觉得这个其实是没有任何问题的。我觉得科学对应的就是不科学嘛,就是什么是不科学的,我觉得这个事情讨论清楚,大家就知道什么是科学的、什么是不科学的。
我觉得不科学的方式就是,如果从整体项目的角度你想去推一个东西、你想证明某个东西是有效的,我觉得这个东西不存在任何疑问。因为从学术线上或者说你从学术论文的角度,我觉得这个大家都是有明确标准的:你得有明确的benchmark(基准测试),你得有足够的变量的控制,你得用更科学的方式去说明你这个东西是有效的,我觉得这个大家都是认可的。然后为什么不科学?不科学就是基于某些利益需求,把科学的方式都干掉了,这就是不科学,不特指任何技术。我一直强调的就是我觉得KV这个团队非常团结,然后非常能把劲往一处使,如果大家是这样的目的为先,你的判断方式自然而然就是科学。
【主持人】因为最近也是V4发布的时间嘛,K3和V4,你觉得他们的区别是什么?能不能做一些对比?
【嘉宾】我觉得是不同层面吧。我觉得从模型定位也好,然后从刚刚咱们比较详细讨论的在音乐上的一些区别,然后从模型角度层面的话,我觉得目前区别还是比较大的,我觉得完全也不是一个东西嘛。我觉得其实比较考虑KV,就是DeepSeek现在出了两档嘛,一档是这个1.2T的,然后另一个是一个更小的size。DeepSeek我觉得目前还是更强调一个性价比的,就是他们其实Flash那个模型做得还是挺好的。我觉得Kimi目前主要的精力还是尝试去提升开源模型的一个能力的上限,而不是去考虑这个模型的(性价比)——也不是完全不考虑嘛,至少说模型的性价比不是一个最主要的考虑条件。当然也可以看到,现在K3的API相当贵,比别的模型贵多了。
【主持人】照这个趋势发展下去,Kimi和DeepSeek又会分化吗?
【嘉宾】我觉得技术层面的东西只要大家不笨,都是知道什么是好、什么是不好。我觉得组织团队的走向取决于人的选择,我觉得就这么简单。我觉得技术上这个东西不存在太多分歧的,好就是好、不好就是不好,这个是有明确的客观标准的,但对于组织而言、对于人而言,这个是比较模糊的。
【主持人】你觉得K3相比之前的所有模型来说,不一样在哪里?它有过创新吗?它创新性更强?
【嘉宾】我觉得两方面。我觉得从技术的层面来说的话,我们可以讨论很多很多,就是它中间的有些创新也好、有些退化也好,这个对于技术同学而言是可以去讨论的。但这个东西是不是成为里程碑,它是个非技术的问题,所以它最大的变量是你最后的一个能力。DeepSeek的V3,我觉得比如说它那些比如MoE这些东西,我觉得就是简单划过。我觉得最大的问题就是它其实是国内第一个把模型scale(规模化)到一定程度、并且把链路全都打通的。因为在K3之前,可能最大的就是Qwen的72B,这个其实是从模型size上的一个表达的飞跃,因为有size他才有智能。所以说K3,你把激活多了三倍、把模型也扩大了三倍,它就是下一个Qwen(72B),我觉得这个就没有任何问题,这个核心是size。
[7198.1s -> 7199.1s] 有效的Scade [7199.1s -> 7199.9s] 对其实是这样 [7200.7s -> 7203.8s] 对这是个完全是一个靠团队来去做起来的东西 [7203.8s -> 7205.8s] 因为你把模型增大 [7205.8s -> 7206.4s] 最简单 [7206.5s -> 7207.3s] 如果吹尾尔来看 [7207.3s -> 7210.3s] 我就把模型就把几个数字调大一点 [7210.3s -> 7211.8s] 我就可以达到更大Size [7211.8s -> 7213.1s] 但这个不解决任何问题 [7213.1s -> 7214.3s] 从技术上来讲 [7214.3s -> 7215.9s] 它不是一个太大的创新 [7215.9s -> 7217.1s] 因为你扩大模型Size [7217.1s -> 7218.3s] 它本身不是创新 [7218.3s -> 7219.2s] 你把这个东西做Work [7219.2s -> 7220.3s] 它中间才有创新 [7221.8s -> 7224.3s] 你的新团队现在再去重做一个模型 [7225.0s -> 7227.1s] 还有时间窗口或人机会吗 [7227.6s -> 7229.1s] 我觉得如果这个团队足够好 [7229.1s -> 7230.9s] 这个团队的氛围足够好 [7230.9s -> 7232.5s] 然后单位作战能力足够强 [7232.5s -> 7233.2s] 是有机会的 [7233.8s -> 7235.8s] 但这个条件我觉得大概是不存在的 [7235.9s -> 7238.0s] 所以说后面的创业的事情也就不存在 [7239.3s -> 7240.1s] 为什么不存在 [7240.1s -> 7242.5s] 因为好的人其实已经进去了 [7242.5s -> 7243.8s] 还是怎么说 [7243.8s -> 7245.7s] 我觉得好的人和好的组织人的话 [7245.7s -> 7246.4s] 想达成 [7246.4s -> 7248.0s] 我觉得是有历史的局限的 [7248.0s -> 7250.2s] 你不是想达成就能达成的 [7251.3s -> 7253.3s] 动委这个事情真的是有点虚 [7253.3s -> 7254.4s] 很难去描述它 [7255.1s -> 7255.9s] 我觉得也不虚 [7255.9s -> 7258.0s] 我觉得就取决于Leader的Test [7258.0s -> 7259.4s] 或者说Leader的性格 [7259.4s -> 7261.6s] 是绝大多数影响到只能团队的氛围的 [7261.6s -> 7263.9s] 我觉得Kimi有一个特点是 [7263.9s -> 7265.3s] 所有人好像都不怕杨志玲吧 [7266.5s -> 7267.8s] 对 为什么要怕 [7267.8s -> 7269.1s] 有道理你就 [7269.1s -> 7270.3s] 谁有道理谁说了算 [7270.3s -> 7273.5s] 对 还是一个非常极体的一个工作 [7273.5s -> 7275.2s] 它不是一个个人的工作 [7275.2s -> 7276.7s] 它不依赖于个人英雄主义 [7279.4s -> 7282.2s] 你觉得未来的模型的发展方向 [7282.2s -> 7283.0s] 你有没有什么预测 [7283.8s -> 7285.8s] 比如说半年之后一年之后 [7285.8s -> 7288.0s] 模型size毫无以往还会继续扩大 [7289.0s -> 7290.1s] 我说一下我的判断 [7290.1s -> 7291.1s] 我的判断比较暴论 [7291.6s -> 7292.9s] 我的暴论就是 [7292.9s -> 7294.5s] 大模型可能没有太本人的创新 [7294.6s -> 7296.4s] 后面都是一些改良性的进步 [7296.4s -> 7298.7s] 然后它会做到一个什么样的水平呢 [7298.7s -> 7301.1s] 做多大size对应的是什么样的性能呢 [7302.0s -> 7303.4s] 我觉得这个最重要的就是 [7303.4s -> 7304.9s] 大家去定义什么能力 [7304.9s -> 7305.9s] 去定义一些 [7305.9s -> 7307.5s] 就是只要大家能定义一个能力 [7307.5s -> 7308.3s] 就能去达到 [7309.1s -> 7310.5s] 因为大家之前定义的方式 [7310.5s -> 7312.0s] 比如说就是强扣定AZ的扣定 [7312.0s -> 7313.3s] 这些东西是清晰定义出来 [7313.3s -> 7314.5s] 然后大家就可以去做到 [7314.5s -> 7316.4s] 这个取决于大家怎么去定义一些能力 [7316.4s -> 7317.6s] 或者说从商业化角度 [7317.6s -> 7318.7s] 大家注重什么能力 [7318.7s -> 7321.2s] 只要它能清晰定义这个任务本身 [7321.2s -> 7323.0s] 它的能力就能够达成 [7323.7s -> 7325.5s] 我觉得如果是纯蓝硅脂的 [7325.5s -> 7326.7s] 应该没有太大问题 [7326.7s -> 7328.0s] 它能达到所谓的AGI吗 [7328.6s -> 7329.7s] 我觉得AGI最大的问题 [7329.7s -> 7331.4s] 就是它没有被Weldified [7331.4s -> 7333.1s] 所以只要能够定义它就能达到 [7334.2s -> 7335.9s] 后面都是一系列的优化工作 [7336.5s -> 7338.4s] 对 当然如果说你定义AGI的 [7338.4s -> 7341.1s] 是去生的是真实物理世界交互 [7341.1s -> 7342.3s] 我觉得这个事情肯定还是 [7342.3s -> 7343.1s] 该不是更大的 [7343.1s -> 7344.2s] 但如果你还是在这个 [7344.2s -> 7345.7s] 蓝硅脂Model的scope里 [7345.7s -> 7346.2s] 讨论问题 [7346.2s -> 7347.1s] 我觉得有问题不大 [7347.6s -> 7349.9s] 你觉得它最后会是一个多大的模型呢 [7350.7s -> 7351.9s] 还是说它是无线大 [7352.3s -> 7353.6s] 无线往上叠上去 [7354.4s -> 7355.9s] 我觉得这个事情可能是不可能的 [7355.9s -> 7357.2s] 因为首先就是 [7358.3s -> 7359.6s] 对预讯量的这个数据量 [7359.6s -> 7361.5s] 包括说我们已知的吧 [7361.5s -> 7361.8s] 人类 [7362.3s -> 7363.4s] 我觉得从抽签来讲 [7363.4s -> 7365.0s] 就是人类互联网上能集结到的 [7365.0s -> 7365.6s] 所有的信息量 [7365.6s -> 7366.6s] 这个是有限的 [7366.6s -> 7368.0s] 这个事情是不可能无前提升的 [7368.9s -> 7369.9s] 基于这个case来讲 [7369.9s -> 7370.7s] 从数学理论上 [7370.7s -> 7371.0s] 对吧 [7371.0s -> 7372.4s] 你想吃掉一个错过大的数据量 [7372.4s -> 7374.1s] 你模型不可能是无限的 [7374.1s -> 7374.9s] 没有必要是无限的 [7374.9s -> 7377.1s] 所以说这个能带来一个更宽的棒子 [7377.6s -> 7379.9s] 然后这个宽的棒子可能上下会更高 [7379.9s -> 7380.8s] 然后更窄的棒子 [7380.8s -> 7381.9s] 就是在什么情况下 [7381.9s -> 7383.5s] 就是我们对于模型 [7383.5s -> 7384.8s] 聚集在任务上的一个感觉 [7384.8s -> 7385.8s] 可能会没有那么充分 [7385.8s -> 7387.4s] 然后这个是一个更窄的一个棒子 [7387.4s -> 7389.2s] 或者说如果未来有更难的任务 [7389.2s -> 7390.5s] 它必须有更大的size [7390.5s -> 7391.4s] 那可能就会 [7391.4s -> 7392.7s] 退化得更宽的那个棒子里 [7394.3s -> 7394.8s] 对 [7394.8s -> 7396.3s] 但是无论如何不可能是无限的 [7397.7s -> 7399.0s] 你觉得它会最后有多大 [7399.5s -> 7400.3s] 这个模型 [7400.3s -> 7401.6s] 现在是六到二两点八
[7401.6s -> 7402.4s] 以后呢 [7402.4s -> 7403.7s] 必然的肯定还是有更大的 [7403.7s -> 7404.3s] 不见 [7404.3s -> 7406.1s] 所以如果像完全Match必然的 [7406.1s -> 7407.3s] 肯定还是可以再打一些的 [7407.3s -> 7409.4s] 但是更大的话这个就不确定了 [7409.4s -> 7411.8s] 你现在为什么去探索世界模型了 [7411.8s -> 7413.3s] 我觉得这个主要是一个 [7413.3s -> 7414.5s] personal的一个东西 [7415.3s -> 7416.8s] 因为我觉得这个弹幕型 [7416.8s -> 7417.8s] 不存在太大的 [7418.5s -> 7419.8s] 太大的改良空间 [7419.8s -> 7420.5s] 改进空间 [7420.5s -> 7421.3s] 没有大的突破的话 [7421.3s -> 7422.3s] 就没有大的这个 [7423.1s -> 7423.9s] credit嘛 [7423.9s -> 7424.7s] 所以说我觉得 [7425.2s -> 7426.0s] 对于个人来说 [7426.0s -> 7427.5s] 可能从实验上来上来讲 [7427.5s -> 7429.0s] 不是一个能做出太大的一个 [7429.0s -> 7430.2s] 贡献的一个领域来 [7430.7s -> 7431.9s] 我是一个唯有底范的问题 [7431.9s -> 7432.7s] 这玩意问题更大 [7432.7s -> 7432.9s] 对吧 [7432.9s -> 7434.3s] 但我觉得至少是一个新的东西