⼤家好，Weekly Gradient第 121 期已送达，本期内容围绕应用、模型与运行系统相互塑造，梳理 AI 基础设施、智能体平台、云服务、推理优化、持久执行环境与成本评估等新变化，并关注真实任务中的工程实践。
AI 商业
聚焦 AI 行业的商业化路径、市场竞争格局和商业模式创新，包含投资趋势、GTM 策略、SaaS 转型等商业话题。
1.张阔：用真实商业任务检验 AI 系统（硅谷101）
张阔把 AI 的进步拉回到商家每天真会碰到的活儿：比报价、识别钓鱼邮件、订船期、处理纠纷。他和团队整理了 107 个商业任务，不是刷榜题，而是拿来检验系统能不能在没人盯着的时候把事办完。按他的说法，在特定评测里，最前沿模型的无人干预通过率大约 61%。这个数字不算漂亮，但它提醒我们，模型、运行框架、上下文和多模型路由得一起调，单靠换更强模型解决不了全部问题。关注垂直 AI 产品和商业落地的人，可以借这场对话分清榜单能力和真实任务交付之间的差距。
AI 产品
探索 AI 原生产品的设计范式与用户体验革新，强调产品哲学、交互模式、Agent 产品设计等。
1.GPT-6：让回答变成可交互界面（OpenAI News）
OpenAI 这次把 GPT-6 的回答从一段文字变成了图表、按钮和可交互组件，聊天框里直接冒出能点能玩的小工具。模型训练开始负责挑选合适的表达方式，流式组件和编译器则让界面随着回答一点点长出来。更值得琢磨的是，模型、交互设计和运行系统一起改写了产品体验：同一个问题，用户不只看答案，还能上手探索。这次更新落在 ChatGPT 的聊天体验上，关注 AI 产品形态和界面设计的人会很感兴趣。
2.Dynamo：让推理系统理解智能体会话（PyTorch）
一次智能体任务往往包含多轮模型调用、工具等待和并行子任务，逐请求优化容易错过这些联系。Dynamo 用稳定的会话标识连接应用、路由、追踪与上下文缓存，让系统可以按整个任务考虑资源安排。文章既解释缓存反复失效的机制，也提供回放与调度思路；部分共享缓存接口仍在实验或提案阶段。适合把长任务智能体接入自托管推理服务的团队。
3.ClawLabs：从个人编码走向共享智能体（OpenAI）
Peter Steinberger 和 Kevin Lin 这次演示了一个很实在的转变：团队不再各写各的，而是把编码会话变成共享、长期运行的智能体。任务意图、讨论过程和产出物放在一起看，谁在做什么、为什么这么做都清楚；会话结束后，维护和后续推进也不会断。部署和权限控制接住了更长的运行周期，这恰恰是个人工具走向团队基础设施时最关键的一环。对关注团队 AI 工具和开源协作的人来说，值得看看当工作持续存在、多人一起参与后，执行环境和管理方式会怎么被重新设计。
4.Airbnb：从内部 AI 平台走向用户产品（Latent.Space）
Airbnb 的 CTO Ahmad Al-Dahle 讲了一条挺实在的路线：先把 AI 用在自家工程师和内部流程上，跑顺了再把这套能力交给用户。内部工具 Everest 负责组织工程上下文，让模型真正理解代码库和项目背景；客服这类场景则拿来检验真实部署到底靠不靠谱，用户可不会容忍答非所问。据他透露，团队同比多交付了将近 80% 的功能和改进，这个数字比任何演示都更有说服力。想从员工效率工具再往前走一步、把模型能力放进核心业务的团队，值得看看这条路上还得补哪些功课：上下文怎么喂进去、组织怎么真正用起来、用户体验怎么兜底。
AI 工程
涵盖 AI 工程技术实现与场景化开发的全流程，包含 Agent 工程架构、工具实践、上下文工程等核心技术话题。
1.EmbeddingGemma 2：把多模态检索带到端侧（Google DeepMind News）
Google 把文字、代码、图像、视频和音频塞进同一个检索空间，这个方向很实用：以后本地搜东西不再只认文本。更妙的是，EmbeddingGemma 2 用模块化编码器给端侧减负，完整模型 7.4 亿参数，纯文本任务只启用 2.7 亿参数，向量维度还能按存储预算拧一拧。模型设计和设备资源一起决定离线搜索能走多远，个人资料检索、隐私敏感应用和本地知识库都值得动手试试。
2.DatologyAI：12 万亿词元合成数据的工程实践（AI Engineer）
DatologyAI 的 Bogdan Gaza 把 12 万亿词元合成数据这个项目复盘了一遍，讲的重点其实不在模型多强，而在数据是怎么被造出来、运起来的。他们的做法是先筛出高质量文档，再做改写和重组，生成、训练、评估全部接进同一条流水线，中间没有断点。真正让训练慢下来的往往不是 GPU 数量不够，而是元数据存储、任务崩了之后怎么恢复、CPU 和 GPU 之间怎么排班，这些环节一卡，昂贵的算力就在那儿空转等数据。所以看大规模数据生产，光盯集群规模没什么用，瓶颈常常藏在数据和调度这几层。文中的效果数字是团队自己的案例，参考价值更多在于工程思路本身。
3.Google Interactions API：连接会话状态与持久执行（AI Engineer）
Google DeepMind 的 Ivan Leo 拿出一场演示，把 Interactions API 的用法讲得很实在：多模态输出、工具调用、托管智能体，都能在同一套接口里组织起来。真正有意思的是会话标识和环境标识这两个设计——会话标识把上下文一路承接下去，环境标识让后续调用重新回到同一个执行空间，之前放进去的文件和装好的依赖还原封不动地摆在那儿，不用重新传一遍、也不用重新搭一遍环境。这就意味着接口不再只是收发一次请求的通道，它开始替应用扛下更多运行时该干的活，开发者能腾出手来盯任务本身。要做长任务执行、要调远端工具、要在多种模态之间来回切换的产品团队，值得把这场演示里的基础能力拆开看看，组合起来的空间比想象中大得多。
4.GitHub：为智能体规模开发重建 Git 基础设施（The GitHub Blog）
智能体、开发者和 CI 同时在一个仓库里跑，写入量会变成什么样子？GitHub 的 Brian Celenza 给出的答案是：后台架构得跟着改。他们把这套系统重新拆了一遍，把持久存储和请求处理分开，写入时需要共同协调的步骤被压缩得更短，压缩和清理这类重活也挪出了在线服务路径，尽量不占用用户请求的响应时间。真正有意思的地方在于，这不是拍脑袋的设计，而是负载倒逼出来的选择——生成的代码越多，写入、读取和维护的工作量就越夸张，架构只能往这个方向走。不过得提醒一句，新架构还在建设过程中，那些设计目标不等于已经全面落地，看的时候别把蓝图当成现状。
5.DoorDash：从模型网关走向智能体平台（InfoQ）
DoorDash 两位平台工程师复盘了从模型接入一路走到工作流和智能体的过程。起点是一个统一模型网关，把模型切换、回退、日志和成本归属集中处理；后来又把开源模型托管和新的智能体服务接了进来。用户也从机器学习工程师扩展到全公司，平台设计因此不断调整。对正在搭企业 AI 平台的人来说，这场分享比工具清单更有用：公共能力得围绕准确性、延迟和成本持续打磨。
6.Spotify：AI 广告平台的多智能体架构（InfoQ）
Spotify 的工程师 Pratik Rasam 把多智能体直接塞进了真实的广告创建流程里——脚本、受众、投放这几段共用同一份上下文，但每个智能体都有独立模块和明确的负责人，不是一锅乱炖。比较克制的一点是，凡是关键数据，他们仍然交给确定性工具去算，没让模型硬扛。评估这条路也没偷懒，靠标准追踪配合生产环境回放来验证效果。读下来最值得琢磨的，是架构怎么被三方一起拉扯出来的：模型能力、运行框架、业务需求，缺一个都长不成现在这个样子。另外提醒一句，广告效果的反馈确实能让系统变好，但别顺手推断成基础模型在持续在线学习，这是两码事。
7.OpenAI：按成功任务优化 AI 成本（OpenAI）
挑模型别只盯着单次调用的价格，OpenAI 部署工程团队给的思路是先把任务和可接受准确率定清楚，再看完成它总共花多少钱。便宜模型不一定省钱，它可能要多跑几轮，或者最后还得人来补救。缓存、程序化工具调用、推理强度、延后处理这些运行方式，也会让同一个模型的经济账完全不同。把模型选择和怎么跑放进同一套评估里，做 AI 产品的成本预算、实验设计和服务配置会更靠谱；客户效果数据别当通用承诺，具体案例具体看。
8.Helion：用自动调优改进 vLLM 推理（PyTorch）
想让推理跑得更快，很多时候不必换硬件，而是把现有 GPU 榨得更干。Sean Chen 和 Shangdi Yu 做了件事：把 Helion 接进 vLLM，用一份高层内核实现去试不同算法和配置，再按实际负载自动调优。思路挺清晰——模型辅助搜索负责出候选方案，性能基准负责验收，谁快谁上；混合调度还会根据输入规模挑合适的后端，短序列长序列各走各的路。在文中的 H100 测试条件下，部分负载吞吐提升超过 10%，这个数字放在已经很成熟的推理栈里并不算小。当然代价也有，离线调优要花时间，后续维护也得跟上，不是一键就完事的银弹。如果你关心推理软件怎么把硬件性能真正释放出来，以及自动调优这套玩法在工程上到底要付出什么，这篇值得细读。
9.NVIDIA GPUNetIO：让 GPU 直接发起网络通信（NVIDIA Technical Blog）
NVIDIA 在 GPUNetIO 里做的事很硬核：把 GPU 直接发起网络通信的能力做成共享底座，NCCL、NVSHMEM 这些通信库都能复用同一套机制。结果就是 CUDA 内核能直接管一部分网络操作，关键数据路径上少绕 CPU 几圈，延迟和 GPU 空转都有机会压下来；但控制与初始化仍交给 CPU，不是让 CPU 彻底下岗。对做分布式 AI 的人来说，这提醒很直接：模型训练和推理效率不只取决于算力堆得多高，也取决于数据怎么在 GPU、网卡和节点之间流动。关心通信延迟、GPU 利用率、系统集成和软硬件联合优化的话，值得细看。
10.VS Code：AI 怎样推动每周发布（AI Engineer）
VS Code 从每月发一版改成每周发一版，听起来只是把节奏调快，背后其实是把整套交付系统重做了一遍。Harald Kirschner 讲的就是这个过程：构建得更快，界面要能让智能体直接操作，截图自动生成，代码审查跟着提速，发布拆成小批次推出去，新写的代码才能尽快拿到反馈。麻烦的地方在后半段——生成速度上来了，测试、审查和产品判断能不能接住突然多出来的工作量。大家都在说 AI 让写代码变快，可整条链条上最先撑不住的，往往不是生成环节，而是那些还靠人一个个盯的地方。想把 AI 开发真正变成稳定交付、又想知道自己下一步该往哪优化的团队，这篇值得细看。
11.Amin Vahdat：AI 基础设施的物理与经济约束（Sequoia Capital）
Amin Vahdat 是 Google AI 基础设施负责人，他聊 AI 的方式很像在拆一台巨型机器：模型、芯片、网络、存储、数据中心不能各管各的，得放进同一个设计问题里一起算。系统好不好，不看纸面峰值，而看真实负载下到底产出多少有效结果。更有意思的是，连续运行的智能体会把压力传导到 CPU、状态读取和通信上，基础设施的账本一下子变了。他还讲了 Google 和 DeepMind 怎么做联合设计，以及供电为什么直接卡住容量扩张。放到产业视角里看，AI 服务的速度、价格和可用规模，从来不是单个模型的事，而是整个系统在背后撑着。
12.Richard Ho：OpenAI 如何联合设计芯片与系统（TechTechPotato）
Richard Ho 从 Google TPU 走到 OpenAI 硬件团队，这次聊的重点不是单纯造一颗更快的芯片。芯片得和内存、封装、网络、供应链一起设计，任何一环跟不上，定制加速器都很难接住模型需求的快速变化。OpenAI 想走自研方向，但不代表要和 GPU 告别，两条路线可以同时存在，前提是长期投入，还要和专业供应商深度协作。关心 AI 硬件路线和产业协作的人，可以从这里看到架构选择背后的真实约束；同时别把公开计划直接当成已经验证的量产成绩单。
其他
行业前沿与开源生态，整合行业深度洞察与开源技术动态的复合型主题，技术哲学、AGI 讨论、领袖观点。
1.Matt Garman：为 AI 智能体重建云服务（a16z）
Matt Garman 这次聊得很实在：云服务正在为 AI 智能体重新设计，不是把原来的资源直接丢给 Agent 就完事。智能体会快速创建和销毁资源，执行环境得隔离，权限要短时又细粒度，这些都跟人类操作云的方式很不一样。他还谈了自研芯片、容量分配和企业落地时的现实取舍，AWS 对投资规模和增长预期也有自己的判断。最值得琢磨的是，应用负载正在倒逼云平台改产品设计，关注 AI 基础设施和企业采用的人会很有收获。
2.Walter Goodwin：内存带宽如何影响模型架构（No Priors）
Fractile 创始人 Walter Goodwin 把一件常被含糊带过的事讲清楚了：要跑长上下文、要跑那些一开就是几小时甚至几天的智能体，卡住你的不只是算力，而是内存带宽、容量和成本这三样东西互相拉扯。他也没藏着，直接说了自己为什么从看起来更快的 SRAM 路线上退下来，转向容量更大的存储方案——不够酷，但更贴近真实负载。访谈里最带劲的是他顺着带宽变好之后会怎样往下推：稀疏模型和注意力机制的经济账会被重算，哪些设计还站得住、哪些只是权宜之计，答案都会变。他还提醒别把技术方向、供应商想卖的东西和真正交付出来的结果混成一件事，在芯片行业里这三者经常被讲成同一个故事。想看懂推理芯片下一轮怎么打的人，值得从头读到尾。
3.ASML CEO：计算扩张的制造与供应链约束（TechTechPotato）
ASML 的 Christophe Fouquet 这次聊的不是某款芯片跑得多快，而是算力扩张背后最硬的那层：制造和供应链。EUV 是长期研发出来的设备，光做出来还不够，还得能反复制造、运到全球各地、长期稳定运行，而且专业合作伙伴必须提前把规划摊开来对齐。听起来不炫，但算力能不能持续供给，很大程度就卡在这里。另一头，他解释和 Mistral 的合作，把工业现场的数据和模型能力接在一起。工业 AI 不是拿通用模型套一下就完事，它需要业务里的独特数据，也需要上下游愿意一起排期、一起解决问题。想理解 AI 基础设施为什么有自己的节奏，以及工业 AI 为什么不能只靠通用能力，这段访谈值得看。