1.多人会议超过1h大多是没有意义的
2.anything better should be default
DeepSeek DSpark
推理加速: 小模型试错、大模型把关
① 投机解码原理
通过草稿模型预生成候选token，由目标模型批量验证，将串行生成转为并行校验，在不改变输出分布前提下大幅降低延迟和计算成本。
② 半自回归生成
创新引入串行模块建模token间依赖关系，解决传统投机解码接受率衰减问题，兼顾高吞吐与准确性。
③ 硬件感知调度
动态过滤低置信度内容，避免尾部token浪费算力，根据系统负载智能分配验证资源。
④ 信念调度机制
通过confidence scheduler转移训练压力，使大模型专注关键token生成，小模型处理次要内容。
⑤ 性能突破
数学推理领域接受长度提升26.7%-30%，生成速度在Flash模型上提速60%-85%，Pro模型提升57%-78%。
祛魅
old wine in new bottles
AI已经烂大街了，但是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 的系统从同样的初始方案出发，把此前 autoresearch@home 最佳方案的 0.9372 BPB 提升到 0.9109 BPB；从另一个更弱的 vanilla Transformer 起点出发，也能把 1.059 BPB 提升到 0.9344 BPB。技术上，它不是靠单一 trick，而是组合了架构、短上下文记忆、辅助损失、注意力、优化器、权重衰减、编译设置等多类改动。其中一个重要点是把 hashed bigram/trigram embedding 注入 attention value path，让小模型以较低成本利用局部 n-gram 信息
-
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 秒不是一个单点优化，而是多个建模、优化和系统层面的改动叠加
-
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等