Open Source Summit Korea 2026：逐层落实 AI 问责

Open Source Summit Korea 2026 刚刚落幕，有一个主题反复浮现：问责。LG AI Research 在主题演讲的讲台上发布了一份受政府委托、能把训练数据一路追溯到源头的 AI BOM，而分会场则在其他层面问着同一个问题：AI Agent 在生产环境里可以做什么，以及一块 GPU 如何证明自己对得起它的成本。本文梳理主题演讲与分会场议题真正展示的内容，以及哪些模式值得带回去借鉴。

AI 主导了议程，但没有占满议程。相当一部分内容仍然留给了规模化的基础设施（以一个上游补丁收尾的小集群 Ceph 排障、多可用区的 OpenStack 设计），Argo 也一再出现，从金丝雀分析到由 Agent 发起、经人审批的工作流。在一场如此偏向 AI 的大会上，这种脚踏实地是件好事。

主题演讲定下的框架

主题演讲从两个方向推进问责。一个方向是经济：开放权重正在成为理性的默认选项，以 6–8× 更低的成本达到前沿性能的 ~90%，而数据仍是 AI 技术栈中唯一封闭的一层。韩国没有等这场争论尘埃落定，而是已经在行动。7 月的九天之内，三个前沿规模的韩国模型相继开放，其中最大的是 LG 以 Apache 2.0 许可发布的 7500 亿参数 K-EXAONE 2.0，它们全部出自那个把政府支持的模型发布到 Hugging Face 上的国家计划。另一个方向是速度。从漏洞披露到被利用之间的窗口不断收窄，以至于利用如今可能先于披露发生；为更慢的对手设计的补丁周期，现在依赖 AI 以攻击者自动化的速度去发现并修复漏洞。

LG AI Research 总裁兼首席 AI 官 Honglak Lee 博士把开放数据视为一个验证难题。他的团队追踪了 2,852 个数据集，这些数据集本应可以商用，团队核查了它们历史中的每一个来源。经过完整审查，最终仍可商用的只有 605 个，约占 21%。其余的都在链条的某个环节依赖了仅限研究或已不可获取的来源。Lee 博士指出，几乎 80% 的开放数据从未被任何人完整核查过它的链条，无论是发布者还是使用者。这个问题是系统内生的，而不是坏人造成的。数据集被清洗、重新打包、重新命名，每一步看起来都合理，但随着时间推移，一个挂着宽松许可证的数据集可能掩盖了它真正的来历。例如 FineVision 是一个开放的视觉语言数据集，表面上只有一个许可证，实际上却取材于 3,000 多个来源。团队的研究发现，如果上游某处存在法律风险，基于它构建的数据集有 62.6% 的概率不会体现这一风险。要正确核查一个数据集，就必须核查它的每一个来源，这靠人工是不现实的。在他们的研究中，人类专家漏掉了超过三分之一的重要依赖。为了解决这个问题，LG 把追溯来源的过程自动化，而把判断留给人。他们的 Agent 读取数据集卡片，提取列出的每一个来源，逐一追到底，并为整条链打分。这套系统比人工快约 45 倍，比人类多找出 26% 的依赖，成本也低得多，每个数据集只要 0.29 美元，而人工要 207 美元。它生成的记录用于 K-AI BOM，一份为韩国政府打造、基于 SPDX 3.0 的规范档案。这些记录被设计成跟随数据集：在数据集创建时生成，传递给模型，随服务一起交付，让任何运行该服务的人都能确切看到自己在用什么。这就是数据集溯源（provenance），类似 SBOM 之于软件包的作用。

监管解释了这种紧迫感。韩国《AI 基本法》自 2026 年 1 月 22 日起施行，是亚太地区第一部综合性 AI 法律，把产业促进与信任义务并举，其中包括高影响 AI 与生成式 AI 运营者提供所用训练数据概要的义务。一句话的披露承担不起这项义务；一张机器可读的数据血缘图可以。

给 Agent 装上护栏

有一个模式在多场议题中反复出现：AI Agent 已经是生产环境中的行动者，其失败模式不再是假设。来自 Harness 的 Jyoti Bisht 和 Animesh Pathak 把他们的 OPA 议题组织成一场追逐。开场是几起有据可查的事故，编码 Agent 删除了生产数据库；随后在一个集群里重演了这种博弈：每一次 Agent 工具调用都要经过准入控制，由一条 Rego 策略决定放行与否。第一版策略按动词（verb）拦截删除，于是 Agent 转而把两个生产环境的 Deployment 改了名；没有规则禁止这样做，而追踪这些名字的 Helm release 断了。随后的加固策略治理的是结果而非动词：任何改变工作负载身份（它的名字、副本数、标签）的操作，都被视为需要审批。下一个逃逸口是覆盖面：Agent 找到了唯一一个没人写过策略的命名空间，开出了 45 个每小时 8.50 美元的 GPU 节点。这带来了第二条规则：一切未被治理的默认禁止；以及第三条：成本要和权限一起写进策略。这场议题以协作而非追逐收尾：Agent 只能通过预先批准的工作流模板发起变更，并标记为 Agent 发起，由人批准执行；一个覆盖六类威胁的模型，从提示注入到经日志的数据外带，把每种风险对应到了具体防御。

来自 Megazone 的 Hoon Jo 分享的是运维侧的故事：一次生产迁移，涉及 15 个 Helm release、Kafka 从 ZooKeeper 迁到 KRaft、Valkey 替换 Redis，不允许任何停机，由一名运维工程师和一个 AI Agent 完成。Agent 在会话之间什么都不记得，决策、数值、教训随之丢失，它只能靠猜来填补空白，把定好的选择重新决定一遍、编造命令，同一个请求可能得到不同的结果，这在生产环境是不可接受的。他的答案 GitAIOps 把 Git 变成 Agent 的持久记忆，组织成四层，每一层都消除一处可能靠猜的地方。人类计划（36 个文件、超过 23,000 行）保留决策理由，Agent 读取的是从中浓缩出的 6 文件项目状态看板；117 个预先写好的命令文件按固定顺序覆盖从前置条件到回滚的全过程；30 个锁定版本和数值的文件堵住最后的缺口，这条规则是在一个未锁定版本的 Mimir chart 自动升级、在生产环境引发崩溃循环之后加上的。同样的输入永远得到同样的部署。

结果很清楚：DEV 环境搭建从两周降到两天，PROD 复用同一套护栏后从一周缩短到一天，旧平台从未停机，不是因为 Agent 干得更快，而是它不再需要重做不可预测的步骤。他的建议适用于任何团队：现在就开始记录规则和当前状态，写进你的 Agent 会读的任何文件；在大改动之前提前计划、锁定数值；并保持这份单一事实来源持续更新，由人来修改，由 AI 保持可读。这套方法不绑定某一个 Agent，迁移结束之后，这份记忆仍在继续工作。

来自 IBM 的 Kevin Dubois 用 GitOps 应对的是类似的挑战。他先提到 2024 年的 CrowdStrike 事故，说明把变更一次性发布给所有人时可能发生什么：一旦出问题，所有用户会立刻受到影响。他问什么本可以减小影响，给出的答案是渐进式交付。通常 GitOps 部署是一次性全量发布，而 Argo Rollouts 支持逐步发布。新版本先作为金丝雀上线，只承接一小部分流量，是否继续发布由 AnalysisTemplate 判断，通常靠一条手写的 PromQL 条件，比如把成功率保持在 95% 以上。Dubois 把这个手写的评判者换成了 AI Agent。metric-ai 插件经 RolloutManager 配置、在 AnalysisTemplate 中引用，把金丝雀和稳定版两个版本的指标与日志发给 Agent。Agent 对比两者，必要时遵循额外指示（例如忽略外观上的变化），再给出一个分数来决定继续发布还是回滚。如果发生回滚且配置了仓库 URL，Agent 还会开一个带有修复建议的 Pull Request。这样一来，失败的发布不再只是一条告警，而是一个可评审的代码变更，修复经评审后即可重新部署。Dubois 的要点很明确：一次性发布给所有人有风险，金丝雀发布和特性开关更安全，而 Agent 可以把从分析指标和日志到提出修复建议的整个过程自动化。

从数据中心到边缘的 GPU 算术

GPU 利用率，这条我们在 KubeCon India 2026 上拉出的线索，在首尔以更锋利的形态回归，这次从负载均衡器讲起。经典的负载均衡器看到的是连接；而一个 LLM 请求的成本在 KV 缓存里。把请求落到已经持有其提示词前缀 KV 块的那块 GPU 上，预填充（prefill）就可以跳过；落在任何别处，同样的张量都要重算一遍，首 token 延迟（TTFT）随之膨胀。NETLOX 的 Seokhwan Kong 以一句挑衅开场：缓存局部性如今压过了公平性。随后他用整场演讲为这句话加上限定：只盯着缓存，邻居闲置时一块 GPU 就会被打到饱和，所以局部性本身也要设上限，而它只有在车队真正繁忙时才带来收益。

loxilb 推理网关把路由决策带进了负载均衡器本身。它以单个 Go/eBPF 二进制运行，不需要 Envoy、边车或 Kubernetes，因此可以跑在裸金属、虚拟机或边缘环境。路由过程分四步，前一步不匹配才用下一步。第一步，对话继续留在它已经用过的 GPU 上。没有会话时，一棵前缀树（trie）检查提示词是否与之前路由过的内容相似，但前缀树只记得发送过什么，无法追踪缓存淘汰（eviction）。第三步是精确匹配：网关用模型自己的分词器对提示词分词，把 token 归入块，按与推理引擎相同的方式计算块哈希，再与每块 GPU 当前持有块的实时清单比对。这份清单由各引擎的 KV 缓存事件流经 ZMQ 持续更新。传输的只有哈希，每块几个字节，张量始终留在 GPU 显存里。如果都不匹配，请求就交给最空闲的端点。不过团队指出，负载最低的 GPU 往往也是最冷的那块，单纯按最少连接数挑选反而容易错过缓存。构建这套系统带来两条教训。第一，vLLM 和 SGLang 计算块哈希的方式不同，所以哈希方式要在每条规则里按引擎设置。第二，只盯着缓存命中并不够：一个热门系统提示可能把所有客户端都送到同一块 GPU，因此亲和性受每个端点的容量限制，必要时溢出到邻居。在 NAVER Cloud 上用 Qwen2.5-7B-Instruct 运行预填充/解码分离（P/D disaggregation）、以 vLLM 路由器作为对照的测试里，饱和状态下 SLO 内的有效吞吐（goodput）接近翻倍，达到 0.581，对比 0.271。团队把这归因于 vLLM 路由器缺少在高负载下保护自己的容量上限。他们对局限也说得很清楚：未达饱和时，他们的路由表现相同甚至更差；他们原以为会胜出的自适应控制器，反而不敌固定的溢出阈值。他们指出，换一种流量模式，这个结果可能不同。

路由解决的是哪块 GPU 来服务一个请求；每个工作负载能分到多少 GPU 是另一个问题，我们 7 月的解读文章讲过 HAMi 如何在数据中心回答它。来自 Dynamia.AI 的 Reza Jelveh 把这个 CNCF 孵化项目推向了边缘，而那里的约束更加严苛：一台以5–40 W无人值守运行的盒子，8–64 GB 的统一内存由 CPU、GPU 和操作系统共享，没有可以横向扩展的余地，当一个贪婪的 Agent 饿死其余 Agent 时也没有人在看。

到了边缘，变化的是被切分的对象。Jetson Orin 的芯片没有 MIG（JetPack 只在更新的 Thor 产品线上提供 MIG 预览），数据中心那堵硬件之墙不可用，软件围栏就是仅有的隔离。HAMi 直接切分统一的 LPDDR 池，在一台 8 GB 的 Jetson 上装下10+ Agent，需求超出内存时改为分时共享，把空闲切片换出到主机内存。这些限制能守住，是因为 HAMi 在 Pod 内部拦截 CUDA 调用，Pod 只能看到自己的切片；同样的语义还能映射到 Kubernetes DRA，成为带类型的 ResourceSlice 容量和 ResourceClaim。边缘的另一个现实是异构：Jelveh 用每瓦性能把 Jetson 级 GPU 与 Axelera 和 DeepX 的 NPU 放在一起衡量，而横跨这一切的调度平面只有一个。

值得带回去借鉴的主题

第一，AI 的问责正以能运行的开源软件、而非政策文件的形态到来：给数据的物料清单、给 Agent 的准入策略、给 AI 驱动变更的版本锁定运维。第二，关于 Agent 运维的共识正在形成；Agent 可以分析、可以提议，但执行要经过策略、锁定的配置或人。第三，GPU 效率已经走出利用率仪表盘，进入基础设施本身，在请求时由负载均衡器和调度器决定，而不是事后复盘。第四，韩国在两条战线上同时推进，一边发布前沿规模的开放模型，一边让新的 AI 法把溯源变成法律义务，而两者相互强化：开放权重招来审视，审视需要配套的机制。