二、规模：2026 年区域数字经济 GMV 预计同比增长 17%，达 3680 亿美元，2035 年有望超过 1 万亿美元。分行业：电商 2260 亿（+18%）、在线旅游 590 亿（+10%）、在线媒体收入 440 亿（+22%）、出行与外卖 400 亿（+15%）、数字金融交易额 1.65 万亿（+16%）。

三、指标：报告以 token 作为衡量 AI 经济的新基准，预计未来五年区域 AI 使用量增长 60 倍。

四、智能体购物：72% 的用户已在用比价追踪等自动化功能，75% 愿意让 AI 智能体自主比价并完成下单；62% 比一年前更信任 AI。用户最看重的保障是隐私（44%）、说清楚能做什么不能做什么（36%）、可撤销交易（30%）。

五、条件：未来五年数据中心容量需扩大约 3 倍，AI 负载占大头；报告点名新加坡《数字基础设施法案》的强制 PUE 规则、马来西亚企业绿电供应机制（CRESS），以及预计 2026 年 11 月签署的东盟数字经济框架协议（DEFA）。

【可核验】

谷歌官方博客：https://blog.google/company-news/inside-google/around-the-globe/google-asia/e-conomy-sea-report-2026/

【我们的判断】

一、背景：这份年报自 2016 年起每年发布，过去主要看电商、外卖等 GMV。今年把生成式 AI 用户数和 token 用量放到最前面，说明行业衡量 AI 的口径正在从「有多少人试过」转向「实际消耗多少算力」。这与 Vercel AI 网关、OpenRouter 等用 token 份额看模型市场的做法一致。

二、横向比较：58% 的劳动人口渗透率意味着东南亚已不是 AI 的「后发市场」。美国云厂商和中国的阿里云、华为云近两年都在马来西亚、泰国、印尼扩建算力，开源权重模型又让本地企业可以自建部署。区域需求增长 60 倍的预测若兑现，这里会是中美模型和云服务正面竞争最直接的市场之一，也是中国大模型出海的主要落点。

三、影响：75% 愿意交给智能体下单，但只有 30% 把「可撤销交易」列为前提，说明消费者对智能体出错的代价认识还不充分。平台若在退款、责任划分上没有规则，信任可能在第一批事故后快速回落。DEFA 若如期签署，跨境数据流动和数字支付规则统一，将直接影响智能体跨境购物能否落地。

四、需要注意：报告由谷歌参与发布，数据多来自问卷和机构测算；GMV 是交易额而非 AI 收入，60 倍是预测而非实测，引用时应区分。

打开这条短讯 →原文 →

蚂蚁集团与 vLLM 开源量化推理内核库 Humming：一套 JIT 框架覆盖 INT4/NVFP4/MXFP4 等格式，支持平头哥真武 810E，自测在 H200、B300 上最高达 Marlin 的 2 至 5 倍

产品/应用 2026-10-21 11:33（UTC+8）

【要点】

蚂蚁集团与 vLLM 社区在 vLLM 官方博客宣布开源 Humming：一个面向量化推理的 GEMM 内核库，采用即时编译（JIT），Apache 2.0 许可。

一、思路：把「量化格式描述」和「执行方案」拆开，用共享组件按负载拼出内核，而不是为每种权重/激活组合单独写一个内核。支持稠密和 MoE，覆盖 WnA16、W8A8、W4A8、W4A4 及 INT4、MXFP4、NVFP4 等格式。

二、硬件：支持 NVIDIA 从 Turing 起的全部架构，以及平头哥（T-Head）真武 810E 等兼容 CUDA 的国产加速卡。

三、社区测试称：稠密 W4A16 在多数配置上持平或超过 vLLM 现用的 Marlin，H200 大批量约为 Marlin 两倍、部分 B300 场景超三倍；MoE 下 MXFP4 在 H20/H200 约两倍，B300 上 Grouped 路径最高约 5 倍；对比基线还包括 FlashInfer 和 DeepGEMM。

四、还支持 Blackwell 张量核里 PTX 没有公开的两种格式 float4e0m3、float8e3m4；Rubin 不支持这两种格式。

【可核验】

博客：https://vllm.ai/blog/2026-10-21-humming

代码：https://github.com/vllm-project/humming

【我们的判断】

一、背景：量化是降推理成本的主要手段，但格式越来越多（INT4、NVFP4、MXFP4……），推理框架要为每种组合维护专门内核，Marlin、FlashInfer、DeepGEMM 各管一块。Humming 想用一套 JIT 框架统一这些路径。

二、横向看，DeepSeek 刚开源生产推理栈 DeepInfer，AWS 往 vLLM 贡献 KV 传输，中美大厂都在把推理底层能力往开源框架里放。蚂蚁的特点是同时照顾国产卡：真武 810E 能直接用上同一套内核和调优，对受出口管制、需要混用英伟达与国产硬件的中国部署方更有现实意义。

三、局限：性能数字是内核级微基准，端到端收益取决于模型和负载；国产卡只列了支持、没有给出与英伟达同口径的数据；仓库 2 月已建，此次是正式发布，接入 vLLM 的默认路径还要看后续合并。

打开这条短讯 →原文 →

Anthropic API 上线「用户档案」：网关和转售方给每个请求标注终端客户，安全处置只落到单个客户、不再连坐整个组织；配套封禁通知 webhook 尚未开通投递

产品/应用 2026-10-21 11:32（UTC+8）

【要点】

Anthropic 在 Claude 平台发布说明（10 月 20 日条目）新增「用户档案」（user profiles）：转售 API 的网关、平台可以告诉 Anthropic 每个请求是替哪个终端客户发的，安全处置因此只落在这个客户身上，不再连坐整个组织。

一、用法：每个终端客户调用一次 POST /v1/user_profiles 注册，拿到 uprof_ 开头的 ID，之后每个请求带 anthropic-user-profile-id 请求头。档案分两类：application（自家产品的单个用户，默认）和 passthrough（转售原始推理的下游公司）。不收费、不影响价格。

二、可填字段全部可选：名称、国家、自有客户 ID、开户时间、姓名或邮箱的哈希等，不含对话内容；Anthropic 不核验这些信息。

三、档案自带只读的 programs 字段（含网络安全核验计划状态），即可信访问计划可以落到单个终端客户。

四、Admin API 同时上线组织 webhook（beta）：档案被限制、封禁或解除时推送事件，但文档注明事件投递尚未开通。

五、覆盖 Claude API、Claude Platform on AWS 和 Anthropic 托管的 Foundry；Bedrock 和 Google Cloud 只认 ID 格式、不查档案。

【可核验】

使用指南：https://platform.claude.com/docs/en/manage-claude/user-profiles

API 参考：https://platform.claude.com/docs/en/api/user_profiles

组织 webhook：https://platform.claude.com/docs/en/manage-claude/organization-webhooks

发布说明：https://platform.claude.com/docs/en/release-notes/overview

【我们的判断】

一、背景：Anthropic 对 API 流量跑自动安全分类器，此前一旦某个下游用户触发处置，整个转售方组织都可能被停。OpenCode 遭「大规模蒸馏攻击」、CERT-In 通报智能体越权等事件后，模型厂商一边收紧，一边需要不误伤 OpenRouter 这类聚合方和基于 Claude 做产品的平台。

二、横向看，OpenAI 早有 safety_identifier 参数（取代旧的 user 字段）和处置通知，用哈希后的终端用户 ID 让处置只针对个人，未提供时同样可能停掉整个组织。Anthropic 这次走得更远：档案是需要提前注册的持久对象，区分「应用用户」和「转售公司」，还能挂网络安全核验等计划，相当于把 KYC 下沉到终端客户一级。

三、影响：对网关是降低连坐风险的保险，但也意味着要向 Anthropic 报送下游客户的国家、身份哈希等信息，增加合规工作；不带 ID 的请求仍按自家流量算，处置照旧落到整个组织，事实上把报送变成了标配。

打开这条短讯 →原文 →

AWS 为 vLLM 分离式推理贡献推送式与双向 KV 缓存传输，自测首 token 时间最多快 3 倍

产品/应用 2026-10-21 10:23（UTC+8）

【要点】

AWS 在机器学习博客发布两项为 vLLM「预填充/解码分离」推理做的 KV 缓存传输改进，并称都已作为与硬件无关的功能贡献给 vLLM。

一、推送式传输：vLLM 的 NIXL 连接器默认由解码端在预填充完成后再「拉」KV 块，协调步骤卡在首 token 的关键路径上。AWS 改为预填充端主动推送，把准备工作提前。在 EC2 P5en（GPU、EFA 互联）1P1D 部署上跑 Qwen3-32B，首 token 时间（TTFT）最多快 3 倍，每 token 输出时间（TPOT）最多快 30%。

二、双向传输：多轮智能体对话里，解码端生成的 KV 以前回不到预填充端，下一轮要重算。双向传输让两端复用已算好的上下文；多轮测试中 TTFT 对 Qwen3-32B 最多降 1.6 倍，对 GLM-5-FP8 最多降 3.3 倍。

三、两项功能先在 Trainium 集群上开发验证，博客结果来自 GPU 集群。

【可核验】

推送式 KV 传输：https://aws.amazon.com/blogs/machine-learning/push-based-kv-transfer-to-improve-ttft-and-tpot-for-disaggregated-inference-in-vllm/

双向 KV 传输：https://aws.amazon.com/blogs/machine-learning/improve-ttft-for-multi-turn-agentic-workloads-with-bi-directional-kv-transfer-in-vllm/

【我们的判断】

一、背景：预填充/解码分离已是大规模推理的主流做法，llm-d 1.0、DeepSeek 的推理栈和 NVIDIA Dynamo 都在围绕它做文章，瓶颈越来越落在两端之间搬 KV 缓存的那一步。

二、AWS 的两项改动都瞄准智能体负载：长上下文、多轮反复重发历史，正是 TTFT 最容易恶化的场景。和此前多家只在自家栈里优化不同，AWS 选择贡献给 vLLM 上游，且强调与加速器无关，GPU 用户同样受益，也有助于把 Trainium 拉进主流开源生态。

三、局限：数字均为 AWS 自测，只有 1P1D 小规模配置，且依赖 EFA 这类 RDMA 网络；博客发布已一天多，具体合并状态和适用版本请以 vLLM 仓库为准。

打开这条短讯 →原文 →

投机解码 EAGLE-4 首个公开版本发布：一个草稿模型按批大小和硬件自动调节，团队自测 Qwen3.8-27B 单请求最多提速约 3.6 倍

研究论文 2026-10-21 05:24（UTC+8）

【要点】

投机解码方法 EAGLE 系列背后的团队（Eagle AI Corp）10 月 20 日发布 EAGLE-4 首个公开版本 v0.1.0：推理代码、技术论文和 Qwen3.8-27B 的草稿模型一起放出，以插件形式接入 SGLang、vLLM 和实验性的 TokenSpeed。EAGLE 此前几代被广泛用于各大推理引擎的加速。

一、思路：同一个草稿模型按当前批大小、硬件和负载实时测算起草和验证的成本，自动决定每步猜多少个 token，并保持目标模型的输出分布不变。论文认为，DFlash 2、DSpark 这类固定块长的并行起草方法在大批量时会浪费计算。

二、论文数据（团队自测，Qwen3.8-27B，4 块 B300，温度 0）：单请求吞吐是不加速时的 3.59 倍，是 DFlash 2 的 1.28 倍、DSpark 的 1.40 倍，是模型自带多 token 预测（MTP）头的 1.62 倍；512 并发时为 DFlash 2 的 1.70 倍、DSpark 的 1.99 倍。在 4 核 CPU 云主机上平均提速 2.71 倍，也测了手机。

三、发布说明里的实测（同引擎关闭加速作对比）：vLLM 单并发从 241.6 提到 722.8 tok/s（2.99 倍），SGLang 8 并发 1.91 倍、64 并发降到 1.35 倍；AMD MI355X 8 并发 2.07 倍，但 ROCm 版本还在验证中。

四、使用条件：需要安装团队打过补丁的引擎版本，官方原版引擎不带这些接口。许可证是「源码可用」而非开源：过去 12 个月营收超过 2000 万美元的机构做商用需另签授权，也不得用来做与 EAGLE-4 竞争的产品。

【可核验】

GitHub 发布页：https://github.com/eagle-hq/EAGLE-4/releases/tag/v0.1.0

代码与说明：https://github.com/eagle-hq/EAGLE-4

论文：https://github.com/eagle-hq/EAGLE-4/blob/main/EAGLE4_Paper.pdf

PyPI：https://pypi.org/project/eagle-harness/0.1.0/

草稿模型：https://huggingface.co/EAGLE-Corp/Qwen3.8-27B-EAGLE4

许可证：https://github.com/eagle-hq/EAGLE-4/blob/main/LICENSE

【我们的判断】

一、投机解码是今天降低大模型推理成本的主要手段之一，按批大小和硬件自动调节，针对的是线上服务负载忙闲变化的真实痛点。

二、所有对比数据都来自团队自己，且只在 Qwen3.8-27B 一组模型上系统测过；高并发下提速明显收窄，换模型需要自己训练草稿模型。

三、要换用打补丁的引擎、营收超过门槛就要另签商业授权，大公司直接上生产的门槛比前几代高。

打开这条短讯 →原文 →

UCSD FastVideo 开源 FastH3 Omni：蒸馏版 MiniMax-H3，带参考图和人声的有声视频生成最多快 12 倍，单张 RTX 5090 可跑

模型发布 2026-10-21 04:33（UTC+8）

【要点】

加州大学圣迭戈分校 Hao AI Lab 的 FastVideo 团队 10 月 20 日开源 FastH3 Omni：它是从 MiniMax 开源视频模型 MiniMax-H3 蒸馏出来的加速版，输入文字提示加参考图片、参考视频片段和参考人声，就能生成带同步声音的视频。权重、推理代码和训练代码一起放出，此前它只在 Reactor 的 API 上独家预览。

一、提速方式：把原模型的 50 次 Transformer 计算压到 8 次，用的是团队的并行解码蒸馏（PDD）加分布匹配蒸馏（DMD）。

二、速度（团队自测）：在 8 块 GB200 上，27 组相同输入的端到端延迟比原模型低 5.6 到 11.9 倍，例如一张参考图生成 10 秒视频从约 78.5 秒降到约 9.4 秒；团队称部分任务在其 UniServe 服务框架下可实时生成 768p 的 5、10、15 秒视频。

三、本地运行：提供 NVFP4 量化感知蒸馏和 FP8 权重，可在 DGX Spark 和 RTX 5090 上跑，FP8 版本附有 RTX 4090 配方；首日支持 ComfyUI。

四、训练成本：64 块 B300、3500 步，约 7800 GPU 小时。

五、许可：沿用 MiniMax-H3 社区许可协议；英伟达 FastGen 团队、Nuva Lab 和 Reactor 参与合作。

【可核验】

技术博客：https://haoailab.com/blogs/fastvideo-omniref-update/

模型合集：https://huggingface.co/collections/FastVideo/fasth3-omni

主权重与许可：https://huggingface.co/FastVideo/FastVideo-FastH3-Omni-8-Step-V1

代码：https://github.com/hao-ai-lab/FastVideo

发布帖：https://x.com/haoailab/status/2112625528805208257

【我们的判断】

一、带参考图、参考声音的视频生成通常要几十秒到几分钟，压到十秒以内并能放到单张消费级显卡上，会让个人创作者和小团队更容易用上开源视频模型。

二、这是第三方团队对 MiniMax 模型做的蒸馏，不是 MiniMax 官方发布；画质对比只是同种子的定性样例，团队也说明不能证明输出与原模型一致。

三、所有速度数据都是团队自测，硬件以英伟达新卡为主，老显卡上的表现还需要社区验证。

打开这条短讯 →原文 →

谷歌把 Gemini 带进全球 Android Auto 和内置谷歌系统的汽车，并上线个人智能：授权后可调取邮件、日历、相册和地图来回答与导航

产品/应用 2026-10-21 04:32（UTC+8）

【要点】

谷歌 10 月 20 日宣布，Gemini 已在全球的 Android Auto 和内置谷歌系统（Google built-in）的汽车上可用，并从当天起在车里推出 Personal Intelligence（个人智能）：经用户授权后，Gemini 可以调取 Gmail、日历、Google 相册、地图、YouTube 和搜索里的个人信息，用语音直接回答和导航，不用碰手机。

一、能做什么：官方举的例子包括「我的登机口是哪个、航班准点吗」一句话同时查确认邮件和航班延误；「沿路找一家符合我平时口味的室内餐厅」会参考饮食偏好；「带我去上周拍过照片的那家洗车店」会从相册里找出地点再导航。

二、隐私设置：默认不连接任何应用，需要用户在 Gemini 设置里主动开启，可随时关闭；内置谷歌系统的汽车只有在用户本人在车上、手机已连接时才给出个性化回答。不开启时，导航、音乐、电话和普通问答照常可用。

三、上线范围：Personal Intelligence 当天起在 Android Auto 推出，内置谷歌系统的汽车要在未来几个月陆续上线；仅限 18 岁以上的个人谷歌账号，不含 Workspace 企业和教育账号，暂不覆盖欧洲经济区、瑞士、英国和尼日利亚。

【可核验】

谷歌官方博客：https://blog.google/products-and-platforms/platforms/android/android-auto-cars-with-google-built-in-gemini-personal-intelligence/

【我们的判断】

一、车载是语音助手最常用、也最不能分心的场景，把个人数据检索和跨应用推理搬进车里，是 Gemini 从「问答」走向「替你办事」的一个落地点，覆盖的是 Android Auto 的庞大装机量。

二、效果取决于用户愿意授权多少个人数据；欧洲和英国暂不开放，说明隐私合规仍是这类功能扩张的主要限制。

三、文中的用例都是官方演示，实际在嘈杂车内、口音和多步请求下的准确率还需要用户反馈来检验。

打开这条短讯 →原文 →

AMD 与英特尔把各自的 x86 PyTorch 优化合并进 oneDNN，作为统一默认加速库；AMD 并入 ZenDNN 并加入 UXL 基金会

产业/资本 2026-10-21 03:24（UTC+8）

【要点】

AMD 和英特尔 10 月 20 日宣布，把各自为 PyTorch 做的 x86 CPU 优化合并到同一个开源库 oneDNN 里，让开发者在两家处理器上走同一条软件路径。

一、具体做法：两家把 oneDNN 定为 PyTorch 在 x86 上的默认开源加速库；AMD 把自家 ZenDNN 的优化并入 oneDNN，同时继续针对 AMD 处理器做优化。oneDNN 由 UXL 基金会（Unified Acceleration Foundation）管理，AMD 已加入该基金会并成为指导成员。

二、由来：这是两家共同参与的 x86 生态顾问小组提出的建议。

三、下一步：两家还在合作制定 AI Compute Extensions（ACE），一套加速矩阵乘法的新 x86 指令集，计划之后通过 oneDNN 接入 PyTorch。

四、红帽方面表示支持，称这是消除生态碎片化的一大步。公告没有给出性能数字或时间表。

【可核验】

AMD 新闻稿：https://newsroom.amd.com/news/amd-intel-collaborate-simplify-ai-development-on-x86-cpus-pytorch/

【我们的判断】

一、此前在 x86 CPU 上跑 PyTorch，AMD 和英特尔各有一套优化库，开发者和框架维护者要分别适配；合并成一条上游路径，降低的是维护成本，不是马上提升性能。

二、这和谷歌 TorchTPU、亚马逊 TorchNeuron 是同一趋势：硬件厂商都在争取让 PyTorch 代码「不改就能跑」。

三、ACE 被定位为下一代 x86 指令集，公告没有说明哪些芯片、何时支持，对 CPU 推理速度的实际影响要等硬件和 oneDNN 更新落地后再看。

打开这条短讯 →原文 →

ChatGPT 推出「锁定聊天」：用 PIN 或面容 ID 把敏感对话从记录和搜索中隐藏，数据保留设置不变

产品/应用 2026-10-21 02:29（UTC+8）

【要点】

ChatGPT 于 10 月 20 日推出「锁定聊天」（Locked chats）。用户可以把敏感对话从普通聊天记录、置顶和搜索中移走，放进一个需要验证才能打开的空间。

一、怎么解锁：网页和桌面端用 4 位账户 PIN；手机上可用 PIN、面容 ID、触控 ID 或设备解锁。在对话的「更多选项（•••）」里选择「锁定聊天」即可。

二、记忆：在锁定聊天里发送的新消息，不会更新普通聊天使用的记忆。

三、不变的部分：对话仍保存在账户里，原有的数据保留和「用于改进模型」设置都不变。

四、范围：发布说明写的是向 Free、Go、Plus、Pro 用户逐步推出，覆盖网页、iOS、Android 和新版 macOS/Windows 桌面应用；ChatGPT 官方帖称还包括 Business、Enterprise 和 Edu 方案。

【可核验】

ChatGPT 发布说明：https://help.openai.com/en/articles/6825453-chatgpt-release-notes#introducing-locked-chats

ChatGPT 官方帖：https://x.com/ChatGPT/status/2112597766333673624

【我们的判断】

一、这是防「身边人看到」的功能，适合共用设备或给别人看屏幕的场景，比如健康、财务、感情类对话。

二、它不改变 OpenAI 侧如何保存和使用这些对话；想让对话不进训练，仍要去关闭模型改进设置或使用临时聊天。

打开这条短讯 →原文 →

Gradium 开源 Phonon 端侧语音合成模型：参数不到 5000 万、无需显卡即可本地运行，仅英文 31m 版可商用

模型发布 2026-10-21 01:29（UTC+8）

【要点】

语音 AI 公司 Gradium 于 10 月 20 日开源 Phonon，一组可在设备上本地运行的文字转语音（TTS）模型，参数都在 5000 万以下，不需要显卡，也不需要联网。

一、三个版本：Phonon 31m 只做英文，约 64 MB，采用 Apache 2.0 许可，可以商用；Phonon 40m 有英、法、德、西、葡五个单语版本；Phonon 40m multilingual 用一套权重覆盖这五种语言。两个 40m 版本是 CC BY-NC 非商业许可，商用需另找 Gradium 授权。

二、速度（Gradium 自测）：在 MacBook Air M5 的 CPU 上约 7 毫秒开始出声，而 Kokoro 要 517 毫秒；在树莓派 5 上 31m 版 38 毫秒出声、3.7 倍实时速度。Qualcomm 测得在骁龙 8 Elite Gen 5 上 7.5 毫秒出声，Arm 测得在 Arm CPU 上 28 毫秒出声。

三、准确度（Gradium 自测）：在 500 句电话号码、邮箱、邮编等难读文本上，31m 版英文词错误率 1.70%，Kokoro 为 3.50%；测试集已公开在 Hugging Face。

四、生态：首日支持 Hugging Face Transformers、Ollama、LM Studio、MLX-Audio，可在浏览器、iPhone、Apple Watch 上运行；内置 100 多种声音，也能载入在 Gradium 平台克隆或设计的声音。

五、技术上基于 Kyutai 的 Pocket TTS 研究。

【可核验】

公告：https://gradium.ai/blog/release-phonon-open-weight

官方发布帖：https://x.com/GradiumAI/status/2112563128487514512

模型：https://huggingface.co/gradium/phonon-31m-en

多语言模型：https://huggingface.co/gradium/phonon-40m-multilingual

代码：https://github.com/gradium-ai/xn-ptts

难句测试集：https://huggingface.co/datasets/gradium/tts-hard-sentences-202610

【我们的判断】

一、本地语音合成的门槛又降了一档：几十 MB 的模型就能在手机、手表、浏览器里实时说话，适合游戏角色、离线助手和隐私敏感的应用。

二、只有英文 31m 版可直接商用；多语言和效果更好的 40m 版是非商业许可，这一点容易被「开源」两个字掩盖。

三、速度和准确度对比都来自 Gradium 和合作伙伴自己的测试，对手主要是 Kokoro 等同量级小模型，还没有第三方榜单结果。

打开这条短讯 →原文 →

本页由 AGI Pulse 聚合，仅保留标题与链接，不转载正文。编辑政策