读见

AI 精选周刊

NO.116Ginolujiaxian

BestBlogs.dev 第 116 期:相互塑造

上期谈「贴身的智能」,看到智能体开始进入日常。本周,镜头向产品背后移了一层:当它们持续工作、并行调用工具,围绕人类操作设计的云服务、代码仓库和推理缓存,也需要跟着改变。

应用提出新要求,模型与运行系统扩大应用的可能性,内存、通信和供电又影响模型的设计与部署。

20 条

本期内容已更正:上游成品更新 查看前一版

作者 OpenAI

GPT-6:让回答变成可交互界面(在新标签页打开)

推荐理由

OpenAI 把 GPT-6 的回答从文字扩展到图表、按钮和可交互组件。模型训练负责选择合适的表达方式,流式组件与编译器则让界面随回答逐步出现。这里值得关注的是模型、交互设计与运行系统共同改变了产品体验:同一个问题,可以直接变成供用户探索的小工具。这次更新面向 ChatGPT 的聊天体验,适合关注 AI 产品形态与界面设计的读者。

OpenAI 已在全球范围内为 ChatGPT Plus、Pro、Business 和 Enterprise 用户推出 GPT-6,并将在不久后逐步向 Free 和 Go 层级开放。此次发布的重心是「智能 UI」(Intelligent UI),这是一项新功能,允许模型根据具体用户查询生成动态、交互式的界面(如图表、表单和工具),而非静态文本。该功能旨在通过适应用户需求的界面来增强学习效果和任务完成度。此外,GPT-6 引入了改进的延迟处理机制,使其能够在继续处理复杂推理的同时开始回答,从而显著减少依赖网络搜索的查询等待时间。此次更新还强调了安全性改进,包括更强的越狱抵抗能力和更清晰的局限性沟通。

作者 Sahil Dua、Henrique Schechter Vera

EmbeddingGemma 2:把多模态检索带到端侧(在新标签页打开)

EmbeddingGemma 2 是 Google 推出的一款新型多模态嵌入模型,构建在 Gemma 4 架构上,采用 Apache 2.0 许可证发布。该模型拥有 7.4 亿参数,优化用于本地推理,支持最高 8K token 上下文,并采用 Matryoshka 表征学习实现存储高效的向量截断。在代码、视觉与音频基准测试中均取得顶级成绩,并与 Google AI Edge 工具集成,用于实时决策引擎与多媒体搜索应用。

推荐理由

Google 将文字、代码、图像、视频和音频映射到同一检索空间,并用模块化编码器降低端侧部署的负担。EmbeddingGemma 2 完整模型为 7.4 亿参数,纯文本任务只需启用其中的 2.7 亿参数;向量维度也可按存储预算调整。模型设计与设备资源共同决定了离线搜索的可行范围,为个人资料检索、隐私敏感应用和本地知识库提供了值得尝试的路径。

Gaza 介绍,BeyondWeb 先从原始数据中挑选高质量文档,再通过改写和重组生成预训练数据,而非让模型凭空编造样本。他引用内部对比称,这种方法能用更少 token 取得相近模型准确率,但转录中没有充分说明评测方法。演讲的重点是工程实践:团队把原先独立运行的 Slurm 研究任务接入 Kubernetes 工作流,串起 Spark 数据筛选、Ray 与 vLLM 生成、训练和评估。在万亿 token 规模下,逐项读取 S3 元数据预计需要 9 至 11 天;批量列举将估算时间缩短至约 2 小时。缩小分区并定期保存进度,则减少了 GPU 故障后的重复计算。跨集群协调 CPU 与 GPU 调度、系统性搜索推理参数,也分别改善了执行效率和吞吐量;后者据称带来约 40% 的提升。Gaza 称,最终生成了约 7 万亿 web token,以及 5 万亿数学与代码 token。这些数字来自团队的一手陈述,并非经过独立审计的基准结果。

推荐理由

DatologyAI 的 Bogdan Gaza 复盘 12 万亿词元合成数据项目,把模型训练背后的工程工作讲得很具体。团队先筛选高质量文档,再改写与重组,并把数据处理、生成、训练和评估接入统一流水线。存储元数据、故障恢复与 CPU、GPU 调度,都可能让昂贵的算力等待。理解大规模数据生产时,这些实际瓶颈比单看集群规模更有参考价值;效果数字属于团队案例。

作者 Ishan Dhanani、Jamie Li、Karen Chung

Dynamo:让推理系统理解智能体会话(在新标签页打开)

本文详细介绍了 NVIDIA Dynamo,该框架旨在处理智能体工作负载的独特流量模式。与标准单轮聊天机器人不同,智能体会话涉及大量初始预填充、重复的工具调用以及并行子代理。通过利用统一的“会话 ID”(或轨迹),Dynamo 将请求感知的基础设施转变为程序感知的基础设施。主要创新包括减少缓存抖动的会话感知调度、用于跨工作负载重复使用前缀的共享 KV 缓存索引,以及跨不同内存层(HBM 和 DRAM)的程序化缓存策略。

推荐理由

一次智能体任务往往包含多轮模型调用、工具等待和并行子任务,逐请求优化容易错过这些联系。Dynamo 用稳定的会话标识连接应用、路由、追踪与上下文缓存,让系统可以按整个任务考虑资源安排。文章既解释缓存反复失效的机制,也提供回放与调度思路;部分共享缓存接口仍在实验或提案阶段。适合把长任务智能体接入自托管推理服务的团队。

Ivan Leo 从单轮模型补全和函数调用讲起,说明智能体如何利用工具、执行环境和多轮推理完成任务。他将 Interactions API 介绍为连接模型、长时间运行的智能体和多模态生成的统一接口。interaction ID 能在多轮调用中保存服务端上下文与思维签名;类型化输出和 steps 数据模型则让音频、图像、工具调用及异步操作更容易辨认。演示包括把图像生成的上下文传递给视频生成,以及结合 Google Search、URL context 和自定义事件提交工具。托管智能体部分展示 Antigravity 在远端沙箱中分析 GitHub 仓库:environment ID 可将后续请求送回同一文件和依赖环境,资料也能从 GCS、GitHub 或内联文件导入。他还介绍了把本地技能迁移到云端、冻结具名智能体配置,以及通过代理注入凭证,使模型无需直接接触令牌。结尾涉及 Gemini API CLI 和迁移技能。功能演示较具体,但性能、安全、价格与扩展性主要仍是厂商陈述,缺少独立测量。

推荐理由

Google DeepMind 的 Ivan Leo 演示如何用 Interactions API 组织多模态输出、工具调用与托管智能体。会话标识承接上下文,环境标识让后续调用回到同一执行空间,文件和已安装依赖可以继续使用。接口因此开始承担更多应用运行工作,开发者可以把精力放回任务本身。对需要长任务执行、远端工具和多模态交互的产品团队,这场演示展示了可以组合使用的基础能力。

代理式软件开发的发展显著增加了对 Git 操作的需求,推动年均推量增长 4.9 倍。为此,GitHub 正在将架构设计转为将持久化存储(由 Azure Blob Storage 处理)与请求服务层分离,从而可以独立扩展读写容量。新设计通过并行化非关键任务并将在服务路径之外进行维护来最小化协调,目标是提供更高吞吐和韧性,而不会牺牲开发人员期待的可靠性和控制力。

推荐理由

GitHub 的 Brian Celenza 解释智能体、开发者与持续集成并行工作后,为什么代码仓库的后台也要改变。方案将持久存储与请求处理分开,缩短写入时需要共同协调的步骤,并把压缩与清理移出在线服务路径。本文尤其值得读的是负载如何推动架构选择:更多生成代码会带来更多写入、读取和维护工作。面向新架构的建设仍在推进,不能把设计目标都视作已全面落地。

作者 Siddharth Kodwani、Swaroop Chitlur

DoorDash:从模型网关走向智能体平台(在新标签页打开)

本文详细介绍了 DoorDash GenAI 平台团队自 2023 年初以来的平台演进。团队从服务机器学习工程师转向服务全公司用户,平台随行业经历了从模型到工作流、再到智能体的转变。关键策略包括实施 LLM 网关以处理多提供商路由、成本归因和可靠性回退。他们还讨论了从供应商优先策略转向托管开源权重模型(如 Qwen)以降低成本,以及向“智能体网关”(Agent Gateway)的新兴趋势,用于管理复杂的 AI 工作流和 MCP 服务器。

推荐理由

DoorDash 的两位平台工程师复盘从模型接入到工作流和智能体的演进。统一网关集中处理模型切换、回退、日志与成本归属,随后再引入开源模型托管和新的智能体服务。用户范围从机器学习工程师扩大到全公司,平台的设计也随之改变。对正在建设企业 AI 平台的团队,这场一手分享提供了比工具清单更实用的参考:围绕准确性、延迟和成本持续调整公共能力。

本次演讲实录介绍了 Spotify 构建「Ads AI」——一个用于生成广告创意的生产级多智能体系统的历程。团队最初依赖一个拥有大量指令的单一复杂智能体,但遭遇了脆弱性和幻觉问题。随后他们转向模块化架构,每个智能体(如脚本生成、护栏、受众解析)由特定团队负责,通过 Bazel 独立打包,并依据标准化的 OTel GenAI 规范进行监控。关键架构决策包括将 LLM 推理与确定性应用代码分离,利用工具为数据(如地理定位)提供支撑而非让 LLM 猜测,以及利用共享会话上下文在各步骤间累积信号。该演讲重点阐述了这种结构如何实现闭环度量,使性能数据能够反哺优化定向和创意生成策略。

推荐理由

Spotify 工程师 Pratik Rasam 把多智能体放进真实广告创建流程:脚本、受众与投放环节共享上下文,每个智能体都有独立模块和负责人,关键数据仍交给确定性工具处理。平台还用标准追踪与生产回放支持评估。内容的价值在于说明,模型、运行框架与业务需求如何一起决定架构;广告效果反馈可以改进系统,但不宜据此推断基础模型已经持续在线学习。

OpenAI 部署工程师 Mandeep 和 Sapto 解释,token 标价无法完整反映 AI 应用成本。便宜模型可能消耗更多 token、无法完成任务,或需要人工介入,因此应关注在达到准确率要求、延迟可接受时,成功完成一项任务的成本。他们建议建立代表性的评测集,将模型、运行框架与配置一起测试,在准确率与成本的 Pareto 前沿上选择合适方案,而不是假定最小模型总是最便宜。除模型选择之外,他们讨论四个杠杆:提示词缓存、程序化工具调用、推理强度,以及 Batch 或 Flex 处理。程序化工具调用将中间工具数据的协调、筛选和比较交给代码,只把有用的报告返回模型。推理强度则应独立于答案长度进行评测。缓存方面,他们建议保持提示词开头稳定,并介绍显式断点、仅显式缓存模式、保留缓存的推理强度和工具调整、缓存仪表盘,以及定位未命中的诊断工具。客户案例包括 Clio 自述减少 38% 的输入 token,以及 Blitzy 自述将缓存复用率从 24% 提升至 90%,还有其他由厂商转述的效率改善。这些数字展示可能的收益,不是受控对比基准。结尾建议追踪一项完整任务,每次只改变一个设置,保留经过验证的改进,并随应用演进持续评测。

推荐理由

OpenAI 部署工程团队建议先定义任务和可接受的准确性,再比较完成它的总成本。便宜的模型可能需要更多调用或人工补救,而缓存、程序化工具调用、推理强度与延后处理,也会改变同一模型的经济性。这场分享把模型选择和运行方式放进同一套评估,适合为 AI 产品确定成本预算、设计实验和选择服务配置;客户效果数据应理解为具体案例。

作者 Sean Chen、Shangdi Yu

Helion:用自动调优改进 vLLM 推理(在新标签页打开)

本文详细介绍了如何将硬件无关的内核 DSL Helion 集成到 vLLM 推理框架中,以优化 NVIDIA Hopper GPU 上的线性层(特别是 GEMM)。通过使用能够探索搜索空间的离线编译(AOT)自动调优器,Helion 在 FP8 和 INT8 量化上实现了顶尖性能,无需手动特化。论文引入了一种混合调度策略:针对较小的 Token 数使用 Helion(通过 CUDA Graphs 减少开销),较大负载则回退到 CUTLASS 等默认内核。它讨论了内核级优化中性能、易用性和可维护性之间的权衡。

推荐理由

Sean Chen 与 Shangdi Yu 将 Helion 接入 vLLM,用一份高层内核实现探索不同算法与配置,再按负载自动调优。模型辅助搜索提供候选,性能基准负责验证;混合调度则在不同输入规模下选择合适后端。在文中的 H100 测试条件下,部分负载吞吐提升超过 10%。文章同时讨论离线调优与维护成本,适合理解推理软件怎样把现有硬件的性能释放出来。

作者 Elena Agostini、Simon Schwitanski、Pak Markthub

NVIDIA GPUNetIO:让 GPU 直接发起网络通信(在新标签页打开)

该文章介绍了 NVIDIA DOCA GPUNetIO,这是一个用于在 NVIDIA 软件栈中统一 GPU 发起网络操作的框架。它详细说明了 GPUNetIO 如何通过集成 GDA-KI、RDMA 和 Ethernet 技术,让 CUDA 内核直接控制网络事务,从而绕过 CPU 瓶颈。文章强调了该项目的开源特性、与其他 NVIDIA 库(如 NCCL 和 NVSHMEM)的集成,并提供了编程模型和 API 结构的全面概述。

推荐理由

NVIDIA 将 GPU 发起网络通信的能力组织成共享基础,让 NCCL、NVSHMEM 等组件复用同一套机制。CUDA 内核可以直接管理部分网络操作,减少关键数据路径上对 CPU 的往返依赖,而 CPU 仍负责控制与设置。这篇工程文章提供了软硬件联合优化的具体例子:分布式 AI 的效率也取决于数据怎样移动。适合关注通信延迟、GPU 利用率与系统集成的读者。

作者 AI Engineer

VS Code:AI 怎样推动每周发布(在新标签页打开)

Harald Kirschner 从团队一线经验出发,讲述服务超过 5000 万用户的 VS Code 如何结束延续十年的每月发布节奏,改为每周发布。他强调,代码生成更快还不够,围绕代码的反馈系统也必须同步改善。团队追踪智能体所写代码最终进入提交的比例;据他所述,这个指标从 GPT-4.1 时的 55%,在新模型和更好的运行框架下升至 86%。精简的仓库指引与无障碍技能把专家知识带给更多人,而 TypeScript Go 据称让构建快了十倍。自动化组件截图和 Playwright 驱动的应用操作,让智能体能直接看到 UI 变化并自查;AI 审查意见必须先解决,才进入人工审查。问题分类、错误堆栈归并和部分修复提案也交给自动化处理,同时保留人工纠错。分批发布降低桌面软件发生故障时的回退成本,VSC-Bench 与线上实验则检验更快的交付是否真的改善产品。分享给出了少见的端到端工程实践,但关键数字仍是团队自报,转录没有提供受控的因果验证或详细故障率。

推荐理由

Harald Kirschner 分享 VS Code 从每月发布走向每周发布时,团队如何调整整套交付系统。更快的构建、可供智能体操作的界面、自动截图、代码审查和分批发布,让新增代码能够更快获得反馈。重点是看生成速度提高以后,测试、审查和产品判断怎样接住新的工作量。适合希望把 AI 开发转化为稳定交付、同时寻找下一个流程瓶颈的团队。

作者 Sequoia Capital

Amin Vahdat:AI 基础设施的物理与经济约束(在新标签页打开)

Amin Vahdat 将 AI 数据中心描述为需要联合设计供电、冷却、网络、加速器、CPU 和软件的专用系统。他更看重实际负载的有效产出,而不是理论 FLOPS,因为大型同步任务中一个组件故障就可能使整个系统停顿。Google 的目标是约每六个月将有效令牌服务能力翻倍,依靠模型、运行时与硬件上的持续改进,而非单纯增加芯片数量。他回顾 TPU 从 2013 年针对推理的押注扩展到训练和更广泛负载,并解释联合设计在灵活性与效率之间的取舍,以及团队如何在芯片设计阶段与 DeepMind 协作。长期运行的智能体消除了模型调用之间的人类等待,也提高了对 CPU 编排、网络和存储的需求。供电仍是长期最根本的约束;面向全球的服务还需要专门的推理容量。对谈也涉及光网络与轨道计算的潜力和挑战,并区分已部署实践与探索性设想。

推荐理由

Google AI 基础设施负责人 Amin Vahdat 把模型、芯片、网络、存储与数据中心放进同一个设计问题。评价系统要看实际负载的有效产出;连续运行的智能体还会增加 CPU、状态读取与通信需求。他进一步解释与 DeepMind 的联合设计,以及供电对容量扩张的约束。这场访谈为本期提供产业视角,适合理解 AI 服务的速度、价格与可用规模为何取决于整个系统。

作者 TechTechPotato

Richard Ho:OpenAI 如何联合设计芯片与系统(在新标签页打开)

在这场长访谈中,OpenAI 硬件负责人 Richard Ho 回顾了自己从验证、超级计算机设计到 Google TPU,再到组建新硬件团队的经历。他解释 OpenAI 为何公开部分芯片方向:公司仍依赖 GPU,也希望整个硬件生态继续进步。访谈把加速器性能放进系统层面考量,重点讨论内存带宽、功耗、先进封装、网络和制造能力,而非只看单颗芯片的规格。Ho 还谈到招聘团队、与内存供应商合作,以及在需求仍有不确定性时作长期投资。他讨论了模型未来是否可能参与芯片设计,但没有声称 AI 已经替代专业工程师。受访者直接参与项目,使内容具有罕见的一手价值;具体竞争性能和未来规模仍主要是预期,缺少独立基准验证。

推荐理由

OpenAI 硬件负责人 Richard Ho 从 TPU 经历谈到新硬件团队的建设,解释为什么芯片必须与内存、封装、网络和供应链一起设计。定制加速器需要回应不断变化的模型需求,也离不开专业供应商与长期投入。他还说明自研方向与继续使用 GPU 可以同时存在。适合关注 AI 硬件路线与产业协作的读者,理解架构选择背后的条件;公开计划不等于已经验证的量产表现。

AWS CEO Matt Garman 在长访谈中回顾公司从服务初创企业起步,到如今约 1690 亿美元营收规模、增长 37% 的历程。他认为智能体工作负载正在改变云服务假设:智能体可能只需短暂创建数据库,却需要快速启动的计算沙箱、独立权限和网关。AWS 一方面为初创企业保留紧缺 GPU 容量,另一方面服务大型前沿实验室;他提到未来几年采购 200 万块 NVIDIA GPU,以及 2026 年约 2200 亿美元资本开支计划,供给仍受电力、施工、内存、芯片和机房约束。他认为多元客户需求能降低泡沫风险,但也承认估值过热和供应链冲击。他还梳理 Nitro、Graviton、Trainium 的长期自研路线,并指出企业智能体目前大多需要人工监督;安全、自主执行和企业数据权限仍是难点。Bedrock 的数据隔离与现场支持团队是 AWS 的应对方案。访谈提供了稀缺的一线经营信息,但部分市场及环境主张仍属企业自身表述。

推荐理由

AWS CEO Matt Garman 讨论云服务怎样适应智能体:快速创建和销毁资源、隔离执行环境、短时且细粒度的权限,都提出了不同于传统人类操作的新要求。他也谈到自研芯片、容量分配与企业落地的现实取舍。这场访谈最有启发的地方,是应用负载正在改变云平台的产品设计,适合关注 AI 基础设施和企业采用的人;投资规模与增长预期保持为 AWS 的判断。

作者 No Priors: AI、Machine Learning、Tech、& Startups

Walter Goodwin:内存带宽如何影响模型架构(在新标签页打开)

Fractile 创始人兼 CEO Walter Goodwin 介绍了一条贯穿模型负载、电路设计、物理实现、封装与存储合作的全栈推理硬件路线。他认为,许多定制加速器仍使用相同的 HBM 基础组件,要获得真正不同的能力,需要深入改变芯片底层。Fractile 最初选择基于 SRAM 的推理方案,但模型规模增长和长上下文注意力暴露了容量与经济性限制。新路线希望兼具 DRAM 的容量与成本优势,以及更高的带宽。Goodwin 提出,单芯片带宽目标约为 HBM 方案的 25 倍,平台预计在次年下半年开始放量;这些属于公司前瞻性主张,并非已验证的部署结果。目标是缩短长时间运行的推理智能体任务,而不仅是让聊天机器人反应更快。他解释,更高带宽可能让激活更稀疏的混合专家模型具备经济性,并改变注意力机制中计算与存储需求的平衡。他还区分设计迭代提速与实际生产提速:制造仍需 3 至 5 个月,规模爬坡更久,芯片必须有数年的有效使用期才能支撑投资。AI 辅助设计可以扩大架构尝试范围,但传统布局、仿真与最终验证仍是瓶颈。他最后认为,前沿实验室需要多样化、可共享的硬件平台,因为独押自研芯片可能使其无法及时采用竞争对手的突破。

推荐理由

Fractile 创始人 Walter Goodwin 认为,长上下文与长时间运行的智能体,需要同时兼顾内存带宽、容量和成本。他解释从 SRAM 路线转向更高容量存储的考虑,并讨论带宽改善可能怎样改变稀疏模型与注意力机制的经济性。访谈让硬件与模型的相互影响变得具体,也提醒读者区分技术方向、供应商目标与已交付结果。适合了解推理芯片下一步竞争的人。

作者 TechTechPotato

ASML CEO:计算扩张的制造与供应链约束(在新标签页打开)

在与行业分析师 Ian Cutress 的对话中,ASML CEO Christophe Fouquet 区分了晶体管微缩与系统集成这两条提升计算密度的路径。他回顾了 ASML 从 Philips 分拆后选择整合专业伙伴、而非包办所有零部件的路线,并以 EUV 的漫长研发说明供应商之间为何必须建立长期信任。他认为,技术想法再好,也要有可扩展的供应链和可靠的运营能力,才能制造、交付并维护大量设备。谈到 AI,他把工业数据的重要性置于模型选择之上,解释了 ASML 与 Mistral 如何分工,还讨论了大型工程组织支持初创企业、欧洲企业规模化,以及存储器需求变化等问题。这些判断来自企业一线,但市场预测仍需独立验证。

推荐理由

ASML CEO Christophe Fouquet 从 EUV 的长期研发谈到计算产业的扩张条件:设备要能够反复制造、交付到全球并持续运行,专业伙伴也需要提前共享规划。他对 Mistral 合作的解释,则把工业领域数据与模型能力连接起来。访谈为 AI 基础设施讨论补上制造和产业协作视角,适合了解算力供给为什么有自己的节奏,以及工业 AI 为什么需要独特的业务数据。

ClawLabs 介绍团队如何从终端编码会话迁移到 Codex Desktop、分布式测试机器,最终转向共享的持久智能体服务器。更多算力并未消除由人替同事和智能体传话的瓶颈;团队可见的会话让代码变更背后的意图得以共享,也让贡献者能一起引导工作。现场通过共同修改游戏,以及追溯原始对话来理解评审变更,展示了这种协作。服务器还承载仪表板、会议摘要、设计迭代和维护自动化。讲者区分了持续检查的循环与具有明确终点的目标:修复流程先复现问题、验证修复,再由另一个智能体审核;此外还有性能回归检查,以及据称持续十八天、产出百余 PR 的数据库迁移目标。Kevin Lin 随后介绍开源多租户控制平面 OpenClaw Enterprise,其控制包括把受信任运行时代码与智能体执行隔离,限制网络和文件访问,使用模型审查行动,并为智能体分配独立服务账号。社区智能体获得仓库只读权限,向 Linear 写入时需团队批准;软件智能体则负责修改仪表板。团队称内部部署了四百余个 Claw,并将平台定位为与 OpenClaw Foundation 和合作伙伴共同开发的厂商中立基础设施。插件问题和生成摘要不准确等现场限制为愿景补充了边界;部署规模与效率主张没有独立评估。

推荐理由

Peter Steinberger 与 Kevin Lin 演示团队如何从个人编码会话,转向共享、持久运行的智能体。任务意图、讨论与产物可以一起被查看,维护工作也能在会话结束后继续推进;部署与权限控制则承接更长的运行周期。这场分享让智能体的新应用形态具象化:当工作持续存在、多人共同参与,执行环境和管理方式也要随之改变。适合关注团队 AI 工具与开源协作的读者。

作者 Richard MacManus

Airbnb:从内部 AI 平台走向用户产品(在新标签页打开)

Airbnb CTO Ahmad Al-Dahle 详细介绍了了公司如何通过“由内而外”的方法向“AI 原生”组织转型。该策略涉及在内部使用 AI 来彻底改变软件工程——例如从依赖文档的工作流转向直接进行代码原型设计——这导致 60% 的代码由 AI 编写,功能交付速度提升了 80%。文章还涵盖了内部上下文图“Everest”的使用(该图用于加速杂货配送等新服务),以及一种平衡了前沿模型与基于成本、延迟和性能需求的定制开源模型的多模型策略。

推荐理由

Airbnb CTO Ahmad Al-Dahle 介绍先改变内部工作,再把相关能力用于客户产品的路线。内部工具 Everest 组织工程上下文,客服等场景则检验真实部署的效果。他在报道中表示,团队同比多交付了近 80% 的功能和改进。内容的启发在于把内部平台、组织采用与用户体验连起来,适合希望从员工效率工具进一步走向客户产品的团队,理解模型能力进入核心业务时还需要补上哪些工作。

本期硅谷 101 再次访谈阿里国际站总裁张阔,距离其发布 Accio Work 约半年。张阔的核心观察是:模型在通用榜单上不断逼近满分,但商家在真实经营中的体感提升并不成比例。团队从阿里国际站的百万级真实经营与问答数据中整理出 107 个电商任务并开源,覆盖采购比价、船期预订、交易纠纷判断等七大类,分为 L1-L4 难度;在最前沿模型、无人干预条件下,任务通过率约为 61%。他把 Agent 能力概括为 model × harness × context,强调三者缺一不可,垂直产品的优势来自二十多年积累的交易、供应商与行业上下文。成本方面,XWork 通过帕累托最优路由,把简单任务交给小尺寸或高性价比模型、复杂任务交给前沿模型,并以集约采购和工程/上下文优化,使跑完 107 个任务的成本约为 Codex 与 Claude Code 的三分之一(约 3.69 美元 vs 9 美元以上)。节目还讨论中美 SaaS 与电商生态差异、AI 对 SaaS 的削弱与融合、多 Agent 建议冲突时以经营目标为准,以及采购下单、产品品味、预算分配等最终判断仍应留给人。这是一次有具体数据和实践框架、但立场偏向厂商的访谈。

推荐理由

阿里国际站总裁张阔把模型进步放回商家的真实工作:比较报价、识别钓鱼邮件、预订船期和处理纠纷。他介绍团队整理的 107 个商业任务,说明模型、运行框架、上下文与多模型路由需要共同优化。按他的口径,特定评测中最前沿模型的无人干预通过率约为 61%。这场对话适合关注垂直 AI 产品与商业采用的读者,帮助区分榜单能力和实际任务交付。

阅读设置

更多