#01 模型与平台
OpenAI 重申零数据留存并预览 Private Safety Processing OpenAI 在官方博客中重申，将对符合条件的 API 客户继续提供零数据留存（Zero Data Retention）承诺，并预览了名为 Private Safety Processing 的方案，用于在不牺牲数据隐私的前提下推进前沿模型的高级 AI 安全研究。 该公告于 2026 年 8 月 19 日发布，指向前沿模型场景，零数据留存面向的对象明确限定为符合条件的 API 客户。 Private Safety Processing 的核心变化是让自动化系统能跨相关交互识别滥用模式，而不是像现有 ZDR 兼容安全系统那样逐条评估交互；新机制只返回有限的安全信号，底层提示词和响应不会暴露给 OpenAI 人员。ZDR 部署中客户内容保留在客户控制的基础设施上，OpenAI 还在开发内容存于 OpenAI 基础设施、由客户控制密钥加密的选项。部分功能正与早期客户测试，官方计划 9 月开始推出并发布技术白皮书。 参考资料：https://openai.com/index/offering-zero-data-retention-for-frontier-models
OpenAI Blog · 2026-08-19 原文 #02 模型与平台
Stripe 正式签署协议收购 OpenRouter Stripe 官方宣布已签署协议，收购 AI 模型网关与路由平台 OpenRouter。 OpenRouter 联合创始人兼 CEO Alex Atallah 表示，OpenRouter 将照常运营，名称、产品、路线图和使命都不变，只是推进更快。Stripe 称，双方将共同帮助企业在 AI 时代同时管理收入与成本两端，通过智能路由请求和高效使用 token 提升盈利能力。 此前多家媒体在 8 月中旬报道 Stripe 拟收购 OpenRouter，今日由 Stripe 新闻稿与 OpenRouter 方面确认落地为已签署协议。公开声明未披露交易金额。 参考资料：https://x.com/patrickc/status/2090125021910020520
Stripe Newsroom · 2026-08-20 原文 #03 模型与平台
Google Search 上线多项 AI 学习工具 Google 在官方博客宣布为 Search 推出一批面向返校季的 AI 学习工具，并同步开放 Google AI 学生优惠。 生成式交互可视化已在全球英语版 AI Mode 上线，并已开始在 AI Overviews 中推出；练习测验已在全球英语版免费开放，覆盖 ACT、AP、GRE、SAT 等标准化考试。 AI Mode 中的笔记本将在未来几天向超过 180 个国家的英语用户推出，Lens 交互学习体验也将在未来几周以英语版面向全球推出；自定义文件生成已在 AI Mode 全球英语版上线，初期支持文档、幻灯片、表格和纯文字文件等格式，后续将进入 AI Overviews。公告配图可见「Add Notebook」与「Ask Google」等入口，未逐项披露地区与设备限制。 参考资料：https://x.com/Google/status/2090189825022349797
Google Blog · 2026-08-19 原文 #04 Qwen3.8-27B 本地生态
DFlash2 进入 llama.cpp，Qwen3.8-27B 实测提速 3 倍上下 llama.cpp 的 pull request #27342 加入 DFlash2 支持后，一名用户在 RTX 6000 上对 Qwen3.8-27B 的 DFlash2 实测中位速度达 140.6 tok/s，约为基线 47.4 tok/s 的 3 倍。 该用户来自 atomic.chat 团队，在 r/LocalLLaMA 发帖说明自己租了一张 RTX 6000，用四个提示词在四种解码设置下各测一遍：基线 47.4、MTP 114.7、DFlash 99.3、DFlash2 140.6 tok/s（四个任务的中位数）。他也指出平均约 3 倍的提升并不总出现，其中一项测试只勉强达到约 1.5 倍，收益取决于给模型的任务类型；视频画面部分做了加速以把时长压到 30 秒左右，屏幕上的 tok/s 与接受率为真实数据。DFlash2 的详细介绍见 inco.ai/blog/dflash2。 另一名开发者把 DFlash2 集成进其自研的 RTX 3090 Qwen3.8-27B 推理引擎。该引擎此前已包含 fp8 KV cache、int8 lmhead/embedtokens、fp16 循环状态、int8 激活、带 4 万词汇自有输出 draft head 的 MTP-4、GPTQ-int4 lmhead/MTP、split-KV 校验注意力、sampler 补丁以及 KVarN 262k 上下文等优化。本次新增 DFlash2 drafting：草案器是 Inco 为该模型发布的块状 drafter——5 层、单次非自回归预测 7 个 token 并带路径选择器。vLLM 侧的支持仍是 main 分支上的一个未合并 PR，作者将其移植回 0.27.1，并修复了其静默依赖的一个真实 bug：0.27.1 缓存的是应用温度后的 draft logits，而 main 缓存原始 logits，在 0<T≠1 时校验会用到错误的提议分布；每步 token 数从 2.8 提升到 3.3。draft 器被重量化为 W4A16，最终以 1.19 GB 的 GPTQ int4 形态发布，贪心接受率无损失，通过 fetchdflash2.py 脚本获取。作者自研的 lookup-augmented drafting 用一个 Triton kernel 扫描请求自身的 token 历史，查找最后 6–12 个已生成 token 的最近出现位置并提议其后续内容，在“复现每条命令”类任务上每步 token 数提升 29%（105 → 131 tok/s）、普通对话约 +5%，每步开销 0.075 ms，且保持精确、贪心路径不读取 draft 分布。混合模型前缀缓存在 0.27.1 默认关闭，需以 --mamba-cache-mode align 打开：24k-token 文档的续聊回合从约 23 秒降到 0.85–1.35 秒（逐 token 一致），64 个共享 5,820 token 系统提示词的并发请求批处理从 222 秒降到 16.9 秒，代价约占 14–16% 的 KV 池。64k 上下文下的 DFlash2 还做了分配器修复：drafter 的 5 个滑动窗口层曾迫使目标模型的 16 个注意力层补到 20、48 个 GDN 层补到 50，改为给窗口组补位后每 token 内存从 105 KB 降到 78 KB。 该引擎在功耗限制 250W 的 RTX 3090 上，今天对真实聊天提示词默认采样的测速约 138 tok/s（此前约 124），64 并发约 942 tok/s；三天前单请求为 82 tps、峰值 672，昨日更新后约 114 tps 单用户、64 并发约 1,000 tps。作者称全程精度不变（困惑度 8.09，GSM8K 96.5%），投机解码与状态续接在构造上精确。限制方面：每个并发请求占用 8 个 recurrent-state 槽位，DFlash2 在 1–4 个并发用户场景效果最好，8 并发以上 MTP 更优；2,048 token 的 draft 窗口也让长上下文自由散文场景下 MTP 仍略领先，两种模式用一个环境变量切换。项目代码位于 github.com/syv-ai/qwen38-27b-rtx3090，W4A16 DFlash2 drafter 发布在 huggingface.co/syvai/Qwen3.8-27B-DFlash2-W4A16。 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vsuaoj/dflash2speedsqwen3827bupto4times 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vsy4l2/ipushedqwen3827blimitsagaindflash2134tps
Reddit r/LocalLLaMA · 2026-08-19 #05 Qwen3.8-27B 本地生态
Unsloth 发布 Qwen3.8-27B Dynamic v3 GGUF Unsloth 发布新版 Qwen3.8-27B GGUF 量化，官方称同尺寸下精度比此前提升 10%，并新增保留 77% 精度的 1-bit 量化，可在 8GB 内存上运行。 Unsloth 创始人 danielhanchen 在 r/LocalLLaMA 发布公告，这批 GGUF 使用新版 Dynamic v3.0 方法，官方称其在 Div-300、KLD 等基准上比其他量化方法高出 10% 以上。官方同时说明：整个流程为训练后量化，不在 imatrix 校准数据集上训练模型，也不使用 QAT 或 QAD；所用的 imatrix 文件已公开供社区测试、评估和使用，并鼓励研究者基于这些量化权重与 imatrix 制作变体和微调，另附有相关的过拟合分析。 部分用户已注意到几小时前量化文件曾被更新，公告澄清这与任何修复无关，纯粹是为了让效果更好。同日官方还预告了 Unsloth Desktop 更新，将引入自动压缩（auto compaction），并允许外部 API 参与工具调用等。GGUF 文件位于 huggingface.co/unsloth/Qwen3.8-27B-GGUF，方法与完整基准详见 unsloth.ai/docs/basics/dynamic-3.0-ggufs。 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vsr67c/introducingqwen3827bdynamicv3unslothggufs 项目：https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
Reddit r/LocalLLaMA · 2026-08-19 #06 Qwen3.8-27B 本地生态
Qwen3.8-23B-Mini-Me：深度剪枝到约 22.7B 红迪 r/LocalLLaMA 上一位开发者发布了 Qwen3.8-27B 的深度剪枝版本 Qwen3.8-23B-Mini-Me，参数量从 27B 压到约 22.7B，未做任何微调，仅靠策略性移除网络层完成，作者称推理能力没有出现严重退化。 发布者表示，该版本在他自己的编码、agentic 使用和多轮对话场景下工作良好，但他明确说明没有运行任何基准测试，不声称它优于其他模型——定位只是原版 27B 稠密模型的一个更小版本，部分能力略逊于原版，换来更小的足迹和更快的运行速度。 模型提供 bf16、q8、q4 三种精度版本，目前只放出 MLX 格式。作者提示可沿用原版模型在 HuggingFace（Qwen/Qwen3.8-27B）页面给出的聊天设置，称用该设置未遇到循环或其他异常；同时提醒使用者接入自己的项目或用例前先做探测和测试。 按作者自述，与 27B 原版的差距集中在两类场景：边缘案例，以及提示词略欠明确的情况——后者原版模型更能在模糊指令下正确推断意图，剪枝版会相对逊色。 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vt2jef/qwen3823bminimeadepthprunedqwen3827bto227bb
Reddit r/LocalLLaMA · 2026-08-19 #07 Qwen3.8-27B 本地生态
Qwen3.8-27B 编码实测：社区称判断力优于 Gemini 3.7 Flash 一条红迪 r/LocalLLaMA 实测帖称，在真实 C++/OrcaSlicer 仓库级长期调试中，开源 Qwen3.8-27B 的工程判断力明显优于闭源 Gemini 3.7 Flash（High）：后者多次在测试尚未充分验证时提前宣告成功，而 Qwen 反复推翻自己的假设，并拒绝上马未达标的改动。 测试对象是一份为 Snapmaker U1 深度修改的 OrcaSlicer fork，功能涉及多线程 C++/TBB 切片、Local-Z 子层、多工具调度、G-code 生成、prime tower 生成、物理耗材/工具分配、确定性几何比较、实时打印时间估计、回归测试以及随机/非确定性切片行为；两个模型均以 coding agent 形式访问同一大型既有代码库。 Gemini 3.7 Flash（High）以原生上下文 262,144、FP8 量化、FP8 E4M3 KV cache、GPU 内存利用率 0.91、最大批处理 token 8,192、最大序列 4、默认 reasoningeffort 设为 xhigh 运行。作者称它快速产出了大量实现代码和验证基础设施，但其报告宣称新调度器“已通过全部完整性门控、与基线精确对齐、工具切换减少 32%、打印提速约 22%、可默认启用”；作者独立审计实际测试代码后发现多个门控远比报告所述宽松，例如“精确输出对齐”门控实际允许最多 300 处物理工具不匹配、100 处 Z 不匹配、100 处挤出不匹配，另一项几何门控的允许上限为 300 mm² 且误差小于 1.5%，而受控夹具下观测到的自然非确定性只有个位数 mm²。 改用 Qwen3.8-27B 后，作者称其行为几乎相反：发现了 TBB 并行区内的真实死锁（旧代码在 tbb::parallelfor 内创建 barrier，假定 N 个任务同时运行，Qwen 改以 tbb::taskschedulerobserver 修复）；定位到约 1e13 mm 坐标、约 1e13 秒估算打印时间的巨大坐标损坏 bug，并在验证 PrintInstance.shift 值后主动放弃了自己最初的解释；还证明 Local-Z 间歇性报错是既有 bug、与调度器无关（开关对照失败率为 3/8 对 4/8）。最终因一项精确对比测试仍有约 364–372 处 seam 不匹配，Qwen 坚持 texturedependencyscheduler 默认保持关闭。作者随后独立复核认为这个阻塞可能过严：测试把线段反向遍历（A→B 与 B→A 几何相同、起点不同）也计为 seam 不匹配。在其主观评分表中，Gemini 仅在原始实现速度和快速产出大量代码上占优，Qwen 在调试复杂交互、修正自身假设、区分相关性与因果、审查测试设计、避免过早宣告完成和生产保守性上领先；作者同时强调这只是一次项目、一种 agent 环境、一类任务的观察，不据此推断 Qwen 普遍更聪明。 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vssd63/qwen3827bvsgemini37flashhighforreal
Reddit r/LocalLLaMA · 2026-08-19 #08 Qwen3.8-27B 本地生态
Qwen3.8-27B SlopCodeBench：严格检查点得分偏低 一条红迪帖记录了对 Qwen3.8-27B 的 SlopCodeBench 实测，严格检查点得分偏低：HumanLayer Opus 5 子集（3 个问题、17 个检查点）中仅通过 3 个（17.6%），作者据此不推荐让该模型独立管理整个代码库，但核心检查点表现尚可。 测试由 u/corruptbytes 通过 OpenRouter 跑完（自述其本机 Mac 跑全部 9 个问题会崩溃），同题此前的多次运行记录公布在 michaelasper/benchmarks 仓库的对比页面。作者对结果的解读是：严格检查点差说明 Qwen 单独管理代码库会让其变得臃肿凌乱、失去组织性；核心检查点表现不错，配合 copilot 和清晰方向可以解决问题。 同一来源还列出了其他模型的对照：Opus 5 子集中 Opus 5·Claude Code 4/17（23.5%）、Opus 4.8·Claude Code 与 Sonnet 5·Claude Code 各 1/17（5.9%）；Fable、Sol、Kimi 子集（6 个问题、30 个检查点）中 Fable 5·Claude Code 与 GPT-5.6 Sol·Codex 各 10/30（33.3%），Kimi K3·Modal/OpenCode 8/30（26.7%），Kimi K3·Baseten/OpenCode 7/30（23.3%），Qwen3.8-27B·pi 4/30（13.3%）。 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vt2cjy/qwen3827bslopcodebenchresults 代码：https://github.com/michaelasper/benchmarks/blob/main/qwen3.8-27b-pi-on-slop-code-bench.md
Reddit r/LocalLLaMA · 2026-08-19 #09 Qwen3.8-27B 本地生态
Qwen3.8-27B 社区实测：调参、KV cache 与本地流体模拟 r/LocalLLaMA 用户 dsdt 发布帖子称，经过反复调参，其 Qwen3.8-27B Q6K 量化版配置在 2×RTX 5060 Ti（合计 32GB 显存）上跑出了最高约 70 t/s 的生成速度。 该配置基于 llama.cpp 的 llama-server：模型为 Qwen3.8-27B-UD-Q6K.gguf，加载 mmproj-BF16.gguf 视觉投影，上下文长度 100000 token，reasoningeffort 设为 medium 并开启 --reasoning 与 --reasoning-preserve；使用 tensor 模式拆分、flash-attn，KV cache 的 K、V 均用 q80，投机解码开启 draft-mtp 与 ngram-mod 混合（草稿长度上限 2，ngram 匹配窗口 24–86），采样参数为 temp 1.0、top-p 0.95、top-k 20、min-p 0.00，另设 -ngl 105、-np 1、batch-size 8869、ubatch-size 531。实测 prompt 处理 646.62 ms / 27 token（41.76 t/s），生成阶段 8624 token 平均 68.33 t/s（14.64 ms/token），3 秒滚动窗口早期在约 50–79 t/s 间波动、后期稳定在约 62–72 t/s；投机解码草稿接受率 80.04%（5510/6884），平均草稿长度 2.77 token，计算图复用 5569 次，全程共处理 8651 token 后干净停止、无截断。 另一名用户 fbms2 在 Qwen3.8-27B-Q6K 上对比了 KV cache 精度的影响：使用 Q8/Q8 时模型“思考”明显更多，输出质量感受也优于 Q4/Q4 或 Q8/Q4 组合，而 Q8/Q8 正是 dsdt 配置中采用的组合。该帖只附单一来源链接，属于单用户主观对比。 针对一篇称“Qwen3.8 27B 无法与 Opus 相比”的 X 帖文，用户 Danmoreng 用 pi 复现其流体模拟任务：在 RTX 5080 16GB 上以 IQ3XXS 量化、96k 上下文运行，首次尝试画面停留在蓝/黑屏未出结果，向模型指出问题后第二轮修复并流畅运行，全程耗时 42 分钟。过程包含 2 条用户消息、65 条助手消息、62 次工具调用、2 次压缩，输入约 182k、输出约 125k token，推理 token 约 360 万；结果页面、完整 trace 与代码仓库均已公开。发帖人还提到，GPT 5.6 Sol（High）在首次尝试中也未能完成该任务，只给出空白画面。 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vstyge/imighthavefoundtheperfectconfigparameters 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vsxca1/kvcachemayaffectalotonthequalityin 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vsyj2o/fluidsimulationqwen3827biq3xxs
Reddit r/LocalLLaMA · 2026-08-19 #10 开源模型与端侧工具
Ornith 1.5 系列开放权重，社区量化与 9B 实机可用 Ornith Lab 于 8 月 19 日发布 Ornith 1.5 系列，包括 9B 稠密模型（带视觉能力）和 35B-A3B 的 MoE 模型，两者均为 MIT 许可，训练采用自动生成自身任务的任务循环。 同日还公布了 397B 规模的更大模型，社群量化团队表示暂未对其做量化，但可应需求制作。 社区量化团队 AtomicChat 为两个模型制作了 AD（Atomic Dynamic）量化版本，9B 提供 14 个构建、35B-A3B 提供 13 个构建，并在相同 imatrix 上与 llama.cpp 官方量化做了对比。以团队自身 BF16 转制版为基准，9B 的 AD-IQ3S-IQ3XXS 为 4.29 GB、平均 KLD 0.1441、top-1 83.44%；AD-Q80-Q6K 为 8.55 GB、平均 KLD 0.0035、top-1 97.46%，同体积区间优于官方 Q5KM（6.47 GB，KLD 0.0299，top-1 92.80%）。35B-A3B 的 AD-Q6K-Q5K 为 26.25 GB、KLD 0.0158、top-1 94.85%，低于官方 Q6K 的 0.0167；最小档 AD-Q4K-IQ4XS 20.13 GB、KLD 0.0315、top-1 92.71%。模型与 imatrix、逐张量布局等已上传 Hugging Face 集合页。 一名 Reddit r/LocalLLaMA 用户发布了在 2024 年中端游戏本（4GB 显存、16GB 内存）上实测 Ornith-1.5 9B 的体验：在其由 6 个医学物理研究脚本生成任务组成的自设基准中，Ornith-1.5 9B 一次通过 5/6 项任务，未通过的一项也能根据反馈改进部分代码；对比的 Qwen 3.5 4B 仅通过 2/6，Ling-3.0 Tiny 与 Empero 2B/4B 蒸馏版各通过 3/6，且后三项任务在多次反馈下均无法完成。 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vsvr7f/ornith159bmightnotbebadatall 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vsx94f/wequantizedthenewornith159band35ba3b
Reddit r/LocalLLaMA · 2026-08-19 #11 开源模型与端侧工具
蚂蚁百灵开源 Ling-3.0-tiny 与 Ling-3.0-flash 共 6 个 Base 检查点 蚂蚁百灵宣布开源 Ling-3.0-tiny 与 Ling-3.0-flash 两款模型的 6 个 Base Model 检查点，覆盖预训练、中期训练与 WSM 合并三个阶段，全部未经过后训练。 官方表示这批检查点可作为持续预训练、微调与研究的灵活起点，已完成对话后训练的版本另有 Ling-3.0-tiny 与 Ling-3.0-flash。 Ling-3.0 系列此前已多次出现在本地模型讨论中，今日放出的 Base 权重直接面向研究与二次训练场景，而不是开箱即用的对话模型。官方同时给出两个模型的 Hugging Face 页面，供开发者直接下载。 参考资料：https://x.com/AntLingAGI/status/2090097017456590879 模型：https://huggingface.co/inclusionAI/Ling-3.0-tiny-base 模型：https://huggingface.co/inclusionAI/Ling-3.0-flash-base
#12 开源模型与端侧工具
S1-mini：600M 模型浏览器内 WebGPU 本地运行 Superwhisper 推出 600M 参数模型 S1-mini，可将原始语音转写文本整理为干净的书面文字。 模型会删除语料中的口误开头和自行纠正内容，补全标点与大写，并格式化口语化的数字、日期、时间和货币表述。 模型权重托管在 Hugging Face（superwhisper/s1-mini），官方提供基于 Transformers.js 的 WebGPU 演示页面（webml-community/s1-mini-webgpu），可在浏览器中 100% 本地运行，无需将音频或文本发送到服务器。 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vsze11/s1minibysuperwhisperrunning100locallyinthe 模型：https://huggingface.co/superwhisper/s1-mini 演示：https://huggingface.co/spaces/webml-community/s1-mini-webgpu
Reddit r/LocalLLaMA · 2026-08-19 #13 基础设施与开发者工具
RK3588 NPU 被反向工程：开源编译器跑起 GPT-2 RK3588 的 NPU 被完整反向工程：开发者复现了寄存器格式并构建开源编译器和运行时，使 GPT-2 能以约 36 tok/s 的速度运行，全程无需厂商 SDK。 结果由用户于 8 月 19 日发布在 Reddit r/LocalLLaMA。去年该用户曾以破解方式让这片 NPU 跑通单个视觉编码器，今年完成了寄存器格式的整体反向工程，并在此之上搭建开源编译器和运行时。 GPT-2 与 SigLIP 现在都能从 PyTorch、ONNX 和 JAX 三个框架导入并在该 NPU 上执行。两款模型的运行都不依赖厂商 SDK；作者把一年的开发过程整理成两篇博客：一篇回顾完整历程，另一篇发布 OpenNPU v1.0 开源编译器与运行时，均发布在其个人站点 amohan.dev。 参考资料：https://www.reddit.com/r/LocalLLaMA/comments/1vsudsl/reverseengineeringtherk3588npubuildingan 项目：https://amohan.dev/blog/2026/opening-the-black-box-a-year-building-an-open-compiler-for-the-rk3588-npu/
Reddit r/LocalLLaMA · 2026-08-19 原文 #14 基础设施与开发者工具
NVIDIA Holoscan：CLI、Skills 与 AI 编码 Agent 进入边缘开发 NVIDIA 在开发者博客发文，探讨通用编码 Agent 如何复用工程师可用的示例、文档和开发工具来开发 Holoscan 应用。 Holoscan 是 NVIDIA 面向边缘实时 AI 应用（从医学影像到机器人）的平台，HoloHub 是其配套仓库，收录不断增长的参考应用和组件。 该文探索了命令行工具（CLI）与 Skills 在 Holoscan 开发流程中的应用方式：编码 Agent 借助与真人工程师相同的 HoloHub 示例和文档，完成应用的搭建、构建与验证。文章未公开具体的 Agent 方案、CLI 命令与 Skills 定义细节。 文章于 8 月 19 日发布于 developer.nvidia.com，属于 NVIDIA 官方博客，面向希望用 AI 编码工具辅助 Holoscan 开发的工程师群体，讨论场景覆盖从医学影像到机器人的边缘实时应用。
NVIDIA Developer Blog · 2026-08-19 原文 #15 基础设施与开发者工具
NVIDIA FLARE：联邦多模态 AI 工作流 NVIDIA 在开发者博客介绍如何用 FLARE 构建联邦多模态 AI 工作流，聚焦视觉-语言模型（VLM）的联邦训练。 VLM 可支撑视觉问答、图像描述和图文推理等任务，但适配这些模型所需的数据往往分散在多个机构或组织内，而这些机构无法集中托管原始记录。 联邦学习提供了一种跨本地数据站点协作训练的方案：各站点数据不出本地，由 FLARE 协调训练过程。博客面向 VLM 场景展开，文章未给出具体涉及的多模态模型架构、联邦聚合策略和站点配置。 该文于 8 月 19 日发布在 developer.nvidia.com。
NVIDIA Developer Blog · 2026-08-19 原文