1.多人会议超过1h大多是没有意义的2.anything better should be defaultDeepSeek DSpark推理加速: 小模型试错、大模型把关① 投机解码原理通过草稿模型预生成候选token由目标模型批量验证将串行生成转为并行校验在不改变输出分布前提下大幅降低延迟和计算成本。② 半自回归生成创新引入串行模块建模token间依赖关系解决传统投机解码接受率衰减问题兼顾高吞吐与准确性。③ 硬件感知调度动态过滤低置信度内容避免尾部token浪费算力根据系统负载智能分配验证资源。④ 信念调度机制通过confidence scheduler转移训练压力使大模型专注关键token生成小模型处理次要内容。⑤ 性能突破数学推理领域接受长度提升26.7%-30%生成速度在Flash模型上提速60%-85%Pro模型提升57%-78%。祛魅old wine in new bottlesAI已经烂大街了但是AI Engineer的概念还相对新颖。 AI engineers ~ software engineers that work on AI application本质上还是写应用软件只不过面向的客体从白领变成了agent。同样的传统软件公司也调整了侧重点针对AI和agent的场景推出新的产品$AKAM 加码 inference cloud$DT 入局 agent observability。SaaS 依然存在只不过变成 Software as an agent Service。coding is solved当人们在谈论agent的时候人们在谈论coding agent。太多的startups围绕着闭源模型搭建高度类似的harness比如 automated code review。这些方向可以快速迭代但是也容易被快速迭代。neo cloud and infra新旧云厂商百花齐放虽然业务高度重合、缺少差异化但是目前来看供应端有 $NVDA 的布局支持需求端有个人和 startup 的开发以及中大厂 forward deployment 的 token 消耗好像行业还处在供不应求的阶段。同时针对 llm / agent serving and orchestration 还有优化和发展的空间。降噪panel discussion, demo presentation. As participants, those events are good to build personal connections, but hard to learn new insight from. As host or speaker, to get attentions is the main purpose for the event.btw AI engineer 市场需求在增加吗这个很难说 我感觉更多是传统SDE转型过来 如果 forward deployment engineer 也算的话 那可能在增加只要我还一直读书我就能够一直理解自己的痛苦一直与无知狭隘偏见见招拆招。 --加缪关于研究1.NanoChat Autoresearch固定预算内训练小语言模型任务是在单 GPU、五分钟预算内把小语言模型训练到尽可能低的验证 BPB。Recursive 的系统从同样的初始方案出发把此前 autoresearchhome 最佳方案的 0.9372 BPB 提升到 0.9109 BPB从另一个更弱的 vanilla Transformer 起点出发也能把 1.059 BPB 提升到 0.9344 BPB。技术上它不是靠单一 trick而是组合了架构、短上下文记忆、辅助损失、注意力、优化器、权重衰减、编译设置等多类改动。其中一个重要点是把 hashed bigram/trigram embedding 注入 attention value path让小模型以较低成本利用局部 n-gram 信息2. NanoGPT Speedrun尽快训练到目标 loss这个基准已经被社区优化了两年多公开最佳训练时间从约 45 分钟降到 79.7 秒。Recursive 的系统在此基础上进一步把时间降到 77.5 秒同时满足验证 loss 的显著性要求它的改进包括把 FP8 推进 attention projection、在优化器里加入退火探索噪声、对 embedding 表使用 sign-agreement 的 cautious Adam、重写 fused MLP kernel、调整训练 schedule 和 step 数等。文章强调77.5 秒不是一个单点优化而是多个建模、优化和系统层面的改动叠加3. SOL-ExecBench优化 GPU kernels这个基准包含 235 个来自真实工作负载的 GPU kernel 编写任务目标是在保持正确性的前提下尽可能接近硬件性能上限。Recursive 的系统平均 SOL 分数达到 0.754而此前 leaderboard 最好是 0.699相当于把距离理论上限 1.0 的差距缩小了 18%文章给了几个 kernel 优化例子比如融合 Linear → GELU → GRN → Linear、MoE routing、NVFP4 MoE expert等
