企业官网建设流程全解析

开源圈最近最值得蹲的一件事，应该就是 COSCon'25 的 AI 基础设施开源论坛议程正式放出来了。我花了一个晚上的时间把完整议程翻了一遍，越看越觉得，这一届和以前不太一样。不管你是做后端、做算法、做 MLOps，还是只对大模型背后那套支撑体系好奇的人，这份议程里都有值得仔细看的东西。

COSCon 是开源社主办的中国开源年会，一直是社区驱动的路子：台上讲的人大多是项目核心维护者，台下坐着的是真在写代码的一线工程师。2025 年这届单独把 AI 基础设施做成一个完整分论坛，我理解背后其实是一个行业信号——大家不再满足于"用上大模型"，而是开始认真琢磨大模型到底是怎么稳定跑起来的，以及如果我要自建一套 AI 底座，需要哪些开源组件。

这篇就把我看到的议程框架、背后的技术脉络、哪些演讲最值得蹲、以及怎么高效逛会，一五一十地写下来。内容不带滤镜，只从从业者实际收益的角度出发。

1. COSCon'25 与 AI 基础设施开源论坛：到底在聊什么

1.1 开源社和 COSCon 是怎么一回事

先把背景说清楚。COSCon 也就是中国开源年会，由开源社主办，到 2025 年已经是第十多年了。它和很多商业厂商办的"技术营销大会"有本质区别：议程核心由社区成员投票和组委会筛选，讲者大多是活跃在开源项目一线的人，而不是挂着 CTO 头衔来发产品通告的。所以同样叫论坛，这里的含金量通常要实在不少，很多项目的第一手进展你只能在这样的场合听到。

AI 基础设施开源论坛，顾名思义，聊的是支撑 AI 应用落地的底层能力：硬件适配、算力调度、数据治理、模型训练、推理优化、MLOps 平台，以及开源生态本身怎么治理。这些内容放在两三年前还属于研发内部的事，现在已经被摆到公共论坛上来专门讨论，这本身就是产业成熟的信号。能从一个论坛的设立判断行业阶段，是挺有意思的一件事。

1.2 为什么 2025 年要单独做一个 AI 基础设施论坛

我个人的观察是，2023 到 2024 年行业的主旋律是"大模型能干什么"，到了 2025 年，话题已经变成"大模型怎么能低成本、高稳定地跑起来"。AI 应用公司遍地开花之后，最缺的已经不只是模型参数的攀比，而是把模型变成服务的工程能力。很多团队模型选型都定了，结果卡在推理吞吐上不去、GPU 利用率只有 20%、数据流水线一跑就是三天这类问题上。

在这条链路里，开源项目已经是事实标准。从 GPU 层的驱动与容器方案，到 K8s 上的调度器，再到推理引擎，主流选择基本都是开源。论坛的更深层目的，我认为是让这些各自发展的开源项目在同一个场子里对话：调度的跟训练的聊一聊，做推理的跟做数据集的说一说。基础设施的问题从来不是孤立出现的，往往是你把推理引擎优化得挺好，结果发现数据加载成了新瓶颈，这种跨层对话才是论坛真正值钱的地方。

2. 议程设计思路：从算力到模型服务的完整链路

2.1 从底层硬件讲到上层应用，全栈覆盖的逻辑

看这份议程，我第一感受是它的分层思路特别清晰，基本是照着 AI 落地链路从上到下捋了一遍：芯片与异构计算适配、大规模集群调度与容错、数据处理与治理、分布式训练框架、推理优化与部署、MLOps 平台与开源评测。这个设计不是随便拼盘，而是有意把"基础设施"这个宽泛概念拆成一个个可讨论、可实践的技术课题。

为什么要这样设计？因为 AI 落地最大的痛点是分层断档。搞算法的人常常不知道底层排队机制会让自己训练慢一倍，搞平台的人也不了解模型的 KV Cache 特性和显存行为。论坛把每一层都摆出来，就是为了补上这个断层。比如讲 K8s 集群调度如果只讲调度器参数，不讲训练侧的实际需求，那调度器怎么调都是盲调。只有把上下游需求放在一起，讨论才有意义。

2.2 议题筛选标准：拒绝广告味，只要硬核技术

从我看到的议题构成来看，这个论坛有明显的"内行标准"。大部分演讲者都是开源项目的核心维护者或一线工程师，讲的都是怎么在真实场景里解决具体问题，而不是企业宣传式的内容。这类演讲通常会有源码分析、有真实压测数据、有踩坑复盘，信息密度比那些泛泛而谈的行业趋势报告高很多。

更难得的是，我注意到议程里留了不少圆桌和开放讨论的位置，主题涉及 AI 基础设施开源项目的治理困境、商业化与社区的平衡这类"房间里的大象"。这些话题在商业大会上基本没人敢聊，但在社区大会上反而是最有火花的部分。我的建议是：这类圆桌只要有条件，一定要去听现场，因为真正有价值的观点往往是在对话的缝隙里蹦出来的。

3. 核心议题深度拆解：这些演讲真正在讲什么

3.1 算力层：万卡集群的调度与容错，治的是"常态故障"

算力这块，议程里最硬核的方向应该是大规模训练集群的调度与容错。很多人没概念，觉得跑大模型就是把代码交上去等结果，但真实情况是：在一万张卡的集群上，故障是常态而不是异常，几乎每天都有卡要掉线、有节点要重启。这时候靠的不是玄学，而是调度器和框架层的容错机制。

这里要提几个绕不开的开源项目。Volcano 是 K8s 上的批处理调度器，专门为 AI 工作负载设计了 gang scheduling（团伙调度），解决的是"一个任务需要同时申请 64 张卡，缺一张整个任务就起不来"的问题。Kueue 则是做租户级配额管理的，多个团队共享集群时，谁先谁后、资源怎么分，都得靠它来定策略。还有 Ray，它更偏上层分布式计算，尤其适合强化学习这类需要高频调度小任务的场景。

调度这层有个很容易被忽视的细节：GPU 调度不只是"给不给卡"的问题，还涉及怎么切分。NVIDIA 的 MIG 可以把一张物理卡切成多个独立实例，MPS 则让多个进程共享计算单元，而时间片调度又会在推理场景带来上下文切换开销。这些方案的取舍直接决定 GPU 利用率是 20% 还是 80%。我建议重点听一听这类议题里关于共享调度的利弊分析，这往往是项目落地时最容易被坑的地方。

3.2 数据层：AI 项目里最耗时、最不被重视的环节

业界有个共识，一个 AI 项目 70% 的时间花在数据上。议程里数据相关议题分量不轻，我觉得也正是冲着这个痛点去的。数据的核心工作不外乎三条线：采集与清洗、版本与血缘管理、安全与权限治理。

做大规模预训练或者微调的人都知道，原始语料里重复内容、低质量内容、敏感信息混在一起，直接训出来的模型经常语言流畅但知识混乱。现在常见做法是用 MinHash 做近似去重，用困惑度过滤低质文本，再用规则和模型结合的方式做 PII（个人隐私信息）脱敏。这一套流程跑下来，数据量通常要缩水三分之一甚至更多。只有处理到这个程度，数据才敢喂给模型。

版本管理这块，DVC 和 LakeFS 是两个经常被拿来对比的工具。DVC 的思路是像用 Git 管代码一样管数据，把数据集的元数据和内容地址记录下来，支持回滚和分支。LakeFS 则更彻底，直接把对象存储包了一层 Git 语义，让数据仓库也能做分支合并。我自己的体会是，如果没有这一类工具，等你想复现三个月前的一个实验时，可能连当时用的是哪版数据都查不到。

3.3 模型层：分布式训练框架，从"一人做饭"到"流水线食堂"

训练框架这块，议程涉及的分布式技术值得展开说说。现在大模型动辄百亿千亿参数，一张卡根本放不下，必须把模型拆开放到很多张卡上。拆的方式决定了效率：数据并行是"每人拿一份数据、大家共享一份模型"；张量并行是"把一层网络切成多份放多卡"；流水线并行则是"把网络按层切成多段，像工厂流水线一样接力跑"。

显存优化上绕不开 DeepSpeed 的 ZeRO 系列，我一般用一个类比跟新人解释：传统数据并行就像十个人一起做饭，每个人都要带一整套锅碗瓢盆，浪费；ZeRO 则是十个人分别带锅、带碗、带菜，到点凑一起用，省下的是重复占用的空间。ZeRO-1 分片优化器状态，ZeRO-2 再分片梯度，ZeRO-3 连参数都分片，代价是通信量上涨。FSDP 就是 PyTorch 对这个思路的原生实现，目前已经大量用于百亿级模型训练。

另一个值得关注的方向是高效微调。全参数微调千亿模型对绝大多数团队不现实，于是 LoRA、QLoRA 这类参数高效微调方法成了主流。LoRA 的思想是冻结原模型、只训练少量低秩矩阵，可训练的参数量能少到原来的 1% 甚至更低。议程里如果有团队分享"小预算复现大模型微调"的实操记录，我建议重点听，这种一线数据比任何理论分析都更有参考价值。

3.4 推理与部署层：如何把推理成本打下来

推理优化是当前 AI 基础设施里竞争最激烈、也是落地收益最直接的领域。议程里推理引擎相关的分享我预计会是关注度最高的，因为每个上线了大模型服务的团队，天天都在跟显存、吞吐、延迟做斗争。

这一块避不开的项目是 vLLM，它的核心创新 PagedAttention 解决了一个致命痛点：推理时生成的 KV Cache 会占大量显存，而传统方式会因碎片化浪费近一半空间。PagedAttention 的思路和操作系统虚拟内存很像：把 KV Cache 切成固定大小的块，按需分配，不用一块连续的显存。就这一个改动，配合 Continuous Batching 连续批处理，就能让吞吐量提升数倍。

顺便列一份当前推理优化主流工具的能力视角对比，方便你去听相关分享时快速进入状态：

还有一块别漏掉：量化。FP8、INT8、INT4 这些字眼会频繁出现，原理不复杂——用更低的数值精度换速度和内存，难点在于精度损失和质量损失的平衡。我的经验是，FP8 对大部分场景影响很小，INT4 就要谨慎评估，尤其是在代码生成这类对输出准确性要求很高的任务上，量化后质量可能肉眼可见地变差。

3.5 平台与生态层：MLOps、模型社区与开源评测

再往上一层，就是平台工程和生态工具。MLOps 这一名词被说了好几年，落到组件上无非是几件事：实验追踪用 MLflow，工作流编排用 Kubeflow Pipelines，模型服务用 KServe，可观测性则要把 OpenTelemetry 和 Prometheus 的能力扩展进 AI 场景。议程里的平台类分享如果能给出这套组合的真实落地方案，含金量会非常高。

生态层我看两个重点。一是模型社区，以 Hugging Face、魔搭 ModelScope 为代表，它们解决的不只是模型下载问题，更是模型托管、数据集共享、微调工作流标准化的问题。二是评测体系，OpenCompass 这类开源评测平台已经在逐步建立"大模型高考"的标准。需要提醒一句：评测榜单只能做参考，别迷信。评测集存在过拟合风险，一个模型在公开榜单刷分和在真实业务里好用，是两回事。开源评测的意义在于提供一个相对中立、可复现的度量基准，而不是给模型排位定生死。

4. 这些开源项目背后的"为什么能火"：选型逻辑与生态法则

4.1 现象级项目的共同特征：垂直打透、拥抱生态

听完一圈议题，你不难发现 AI 基础设施领域那些"一夜爆红"的项目，其实有非常清晰的共性。第一个特征是垂直打透，只解决一个问题，但解决到极致。vLLM 就是典型，它不做训练不做数据，只把推理吃透，反而成了推理层的默认选项。第二个特征是站在巨人肩膀上，凡是深度绑定 PyTorch、K8s 生态的项目，起步就自带用户基础，学习成本和迁移成本都低，传播起来特别快。

第三个特征很多人会忽略，就是治理透明。现象级开源项目通常文档完善、API 稳定、版本升级有清晰的兼容性策略。这在企业选型时几乎是生死线。我问过不少技术负责人，为什么不用某些能力更强的新项目，答案往往不是性能不够，而是项目治理不成熟，怕一升级就 breaking change，怕主维护者哪天不干了。技术在开源领域从来不只是技术问题，治理能力本身就是核心竞争力。

4.2 从热门项目到成熟生态：基金会治理与商业化的平衡

当一个项目火到一定程度，继续留在个人车库式维护就不现实了，这时候基金会治理的优势就体现出来。CNCF、LF AI & Data 这类中立基金会提供商标保护、版权归属、决策流程和法律援助，本质上是给开源项目装了一个"公共治理结构"。这既保护了核心维护者的权益，也给了企业用户一个"这项目不会突然消失"的确定性。

商业化与开源的平衡是另一个躲不开的话题。现在主流模式可以叫 Open Core，核心功能开源，企业级能力以付费形式提供。做托管的也越来越多，比如你自己部署开源推理引擎免费，但想用云上的免运维版本就按量付费。这种模式的争议一直存在，但我不觉得它应该被指责。只有项目有收入、维护者能全职干活，这个项目才能持续健康。开源的可持续性，靠的是热爱，更不能只靠热爱。圆桌上如果能听到一线维护者对这个话题的真实心路，那是花钱都买不来的。

5. 参会指南：线上票怎么领、线下怎么跑、如何最大化收益

5.1 领票与议程筛选：别让"逛会"变成"赶场"

先解决怎么参会的问题。COSCon 一贯采取免费加公益的模式，线上直播和线下参会一般都需要提前报名，具体通道以官方发布为主。我的建议是尽早注册，一方面方便接收议程更新通知，另一方面线下名额往往有限。免费的场次不代表不重要，反而因为门槛低，参会者鱼龙混杂，你需要更早做好筛选。

议程筛选我有一套自己的排序逻辑：带源码实现的分享优先级最高，其次是带压测数据和真实生产案例的经验分享，再往下才是行业趋势类的内容。具体操作是拿到完整议程表后，把感兴趣的场次标出来，再按时间和场地排一条路线。热门场次大概率会满场，提前 10 到 15 分钟到场是基本的礼貌，也是一种策略。我见过太多人因为低估了大厂的吸引力，最后只能在门外听个响。

5.2 三类人群的现场路线图

针对不同角色，我给三份不同的逛会建议。如果你是后端或平台工程师，重点应该放在算力调度、MLOps 和推理优化相关场次，你关心的 GPU 利用率和部署架构问题基本都在这个范围里。如果你是算法或数据工程师，数据处理、分布式训练和评测体系的场次优先跑，你能带回团队的是选型依据和新工具信息。

如果你是技术管理者，反而建议多泡圆桌和开放讨论区，那里面聊的治理、生态、成本模型和团队组织问题，比单个技术点对你更有价值。另外别只盯着主会场，COSCon 的开放空间和闪电演讲环节经常藏着宝藏，很多有意思的实验性项目就是在这些非正式环节里第一次露出水面的。记住一条：在开源大会里，真正高价值的信息往往出现在离正式舞台有点远的角落。

6. 参会常见问题与避坑实录

6.1 高频疑问速查

我把历届参会时大家问得最多的问题整理成一个速查表，方便对照：

6.2 我踩过的坑和给你的建议

作为一个追了多年开源大会的人，我踩过的坑可以给你当反例。第一次参会我完全没有做功课，到场之后发现多个想听的场次在同时进行，最后只能满场乱跑，哪个都没听全。第二次我把自己关在主会场听了一整天，错过了一个非常感兴趣的圆桌，后来看回放才发现错过了许多关键讨论。正确的做法是提前规划路线，并做好取舍，一天之内不可能吸收所有内容，选择优先级最高的三到五场深度参与，比每场都蜻蜓点水强得多。

还有一个经常被忽略的细节：提问环节就是隐性福利。讲者在演讲里通常会留一手，属于"你问到我才展开"的内容。我在一个推理引擎的场次里问了一下 batch 大小与显存碎片的关系，那个维护者直接在台上给我们补了一段源码级别的解释，这些东西完全不会写到公开文档里。别害怕问题"太基础"，你问的往往也是别人想问的。最后提醒一句：好问题需要提前准备，现场临时想到的问题通常都太笼统。

我个人这几年做平台基建最深的体会是，AI 基础设施这类问题的答案通常不在某个官方文档里，而在写代码的人手里。这也是我一直坚持去开源大会的原因——你花一天时间坐在那里，听到的不仅仅是技术，更是一群人在过去一年里踩坑、破局、协作的真实故事。COSCon'25 的这份 AI 基础设施开源论坛议程，就是这些故事今年集中出现的地方。如果你正好也在为算力发愁、为推理性能焦虑、为数据管线苦恼，找个机会去听一听、聊一聊，大概率会碰上一个让你觉得"原来可以这样解决"的瞬间。