企业官网建设流程全解析

COSCon 的议程终于公布了。作为一个从第一届开始就蹲直播、后来自己也上台讲过两回的老开源人，每年秋季等这份议程已经成了我的固定仪式。今年让我最上头的，不是主会场那些宏大叙事，而是一场专门把 AI 基础设施单独拎出来的论坛——在这个模型满天飞的年份，真正决定 AI 能不能落地的，其实是那些最容易被人忽略的算力调度、数据管线、推理优化和平台工程。底座稳不稳，直接决定上层应用能走多远。这篇就把我读完议程后的第一手解读整理出来，聊聊 AI 基础设施为什么值得开源圈拿出整整一个论坛来讨论，以及普通开发者和开源爱好者能从里面挖到哪些真正有用的东西。

1. 为什么AI基础设施成了开源社区绕不开的议题

1.1 AI基础设施到底覆盖了哪些层

很多人一听 "AI 基础设施" 就以为说的是 GPU 集群，这个理解太窄了。我把 AI 基建拆成五层来看：最下面是算力层，包括 GPU、NPU 这些加速卡，异构计算框架，还有资源调度系统；往上是数据层，数据集整理、数据标注、特征工程、数据版本管理都在这一层；再往上是模型层，预训练、微调、量化、推理服务、模型注册和评测基准；接着是平台层，负责把上面的能力封装成 API、工作流和可观测体系；最上面才是应用层，AI Agent、RAG 知识库、AI 编程助手这些东西。

用盖房子来类比可能更好懂：模型是装修风格，产品是家具陈设，而 AI 基础设施是水电骨架和承重墙。平时看不见，一旦出了问题，整个屋子都没法住。过去两年大家把注意力都放在"哪个模型又刷榜了"上面，直到真正把模型搬进生产环境，才发现网络带宽、GPU 利用率、数据清洗链路、推理延迟、成本账单，每一个环节都能让人崩溃。这也是为什么 AI 基础设施从一个后端话题，变成了连产品经理都在讨论的前台话题。

对开发者来说，理解这五层还有一个实际用处：你可以快速定位自己的技术栈到底卡在哪一层。比如你用开源模型做应用，发现效果不好，问题可能不在模型本身，而在数据层没做好；发现响应很慢，问题可能在推理服务和调度策略上。方向判断对了，才能选对工具，避免拿锤子到处找钉子。

1.2 为什么这件事必须开源

AI 基础设施如果走封闭路线，会有一个很现实的问题：信任没法建立。模型是黑盒、算力调度是黑盒、数据管线也是黑盒，企业把核心业务放上去之前，总要问一句"你的底层到底干了什么"。开源天然解决这个问题——代码看得见、日志查得到、问题可复现，出了问题社区会一起修。

更重要的是，基础设施从来都是规模效应的游戏。一个调度框架，用的人越多，暴露的场景越多，迭代越快，最终形成事实标准。今天我们熟悉的 Linux、Kubernetes、Prometheus，都是这么走过来的。现在的 AI 技术栈正在重复服务器时代走过的路：一开始百花齐放，然后通过开源社区的协作统一底层接口，最后形成大家默认的公共层。谁在这个阶段参与得越深，谁在未来的标准制定里话语权就越大。

对中小团队来说，开源基建还意味着不被锁定。商业云厂商的托管服务确实方便，但等你把数据、工作流、监控全绑上去之后，迁移成本会高到让你怀疑人生。开源项目至少给了你一条退路，也可以用社区版先把架构跑通，再按需购买商业支持。这种安全感和可选择性，在基础设施选型里比什么都重要。

2. 论坛议程的整体编排逻辑：把AI基建拆成三层

从已经公开的议程信息来看，能明显看出组委会想做的一件事：把"AI 基础设施"这个大词，拆成三个互相咬合的层面来讲。这个编排思路挺务实的，没有停留在"AI 很厉害"的口号上，而是把技术人真正关心的算力、数据、工具链问题摆到了台面上。对听众来说，按这条主线去听，会比自己随机串场要高效得多。

2.1 算力层：异构计算、调度与成本优化

第一个层面是算力。这方面的议题基本都围绕一个核心矛盾：GPU 又贵又缺，但利用率普遍不高。很多团队买了卡，跑起来才发现一台机器上 GPU 空转的时间比计算时间还长；多团队共享集群时，资源分配全靠吵架；训练任务和推理服务混部的时候，互相抢资源导致谁也跑不快。

开源社区这几年在算力调度上交出的答卷，正是这一层重点讨论的内容。Kubernetes 生态里的 Kueue、Volcano 这类项目，专门解决批量任务排队和资源配额的问题；Ray 在分布式计算和弹性伸缩上做得比较成熟，已经有不少公司在生产环境跑了大规模训练和推理任务；更细的还有 GPU 共享、MIG 切分、内核态调度等优化手段，每一招都能把硬件的利用效率再往上顶一截。

算力层还有一个绕不开的话题是成本。跑一次训练、部署一组推理服务，账单数字往往让老板皱眉，这种"算力水账单"问题在社区里被反复讨论。开源方案的价值在于，它能让你把成本拆到每个任务、每个模型、甚至每次请求上——用开源监控和计量工具做好账单分析，再结合调度策略做弹性伸缩，省下来的钱往往比换更便宜的云厂商还要可观。

我特别建议做平台工程的同学重点关注这一层。你们平时最头疼的资源碎片化、任务排队时间长、不同框架的镜像管理混乱，在这类议题里几乎都能找到对应的开源解法。听完之后哪怕只回去落地一个调度策略，都值回票价了。

2.2 数据与模型层：从开源模型到数据治理

第二层是数据和模型。现在开源模型的选择已经多到让人挑花眼，从通用大模型到垂直行业小模型，从英文主导到中文友好的中文社区模型，几乎每一个细分需求都能找到对应产物。但模型只是起点，真正决定业务效果的是数据怎么组织、怎么清洗、怎么喂给模型。

这一层会聊到数据集的构建与治理：原始数据里噪声太多、版权不明、缺乏标签怎么办；数据版本怎么管理，才能让每一次模型训练都可回溯；评测集怎么设计，才能防止模型"刷题"式地过拟合。这些都是生产环境下每天都会遇到的硬骨头。开源数据集、开源数据工具链在这里的价值，是让团队不必从零开始，直接站在前人的肩膀上做增量。

模型层的另一个关键词是推理服务化。训练出一个好模型只是第一步，把模型高效地部署成可调用的服务才是真正的考验。vLLM 这类推理引擎通过 PagedAttention 等机制大幅降低显存占用、提升吞吐，已经成了很多团队部署开源模型的首选；配合 Triton、ONNX Runtime 等跨框架推理服务，一套底座可以同时跑多种框架的模型，运维复杂度下降得不是一点半点。

还有模型评估和可观测性。用开源评测框架给模型打分，用 Langfuse 这类开源工具追踪每次推理的输入输出、Token 消耗和延迟，出了问题能在链路里直接定位。在许多实际案例里，线上模型效果突然变差，最后查出来是上游数据字段格式变了，这种问题没有可观测链路的话，排查起来简直是灾难。

2.3 工具链与Agent层：应用开发的最后一公里

第三层是离应用最近的工具链和 Agent 生态，也是今年最热闹的方向。AI Agent 已经从"能聊天"进化到"能干活":自动规划任务、调用工具、读写代码、操作浏览器，背后需要一整套工程化支撑。MCP 这类开放协议正在把模型和外部工具之间的交互标准化，让 Agent 不再局限于某个厂商的封闭生态。

AI 编程是另一个绕不开的话题。开源社区里出现了不少 AI 编程助手和代码补全工具，可以直接接入本地的编辑器，在保护代码隐私的前提下提供智能补全和重构建议。与之配套的还有 AI 代码审计和软件供应链安全工具——AI 动辄生成几千行代码，质量门禁和漏洞扫描就变成了刚需，开源审计工具可以帮助团队在合入代码之前把明显的问题拦下来。

为了让 Agent 稳定可用，这一层还离不开可观测性和测试评估。Agent 每一步决策、每次工具调用都需要被记录和追踪，否则出了问题根本没法复现。开源方案在这里的优势是数据和链路完全自主可控，可以按自己的业务需求做深度定制。社区里甚至已经开始出现专门给 Agent 写测试的测试框架，把传统软件工程里的单测、集成测、回归测理念搬到了 Agent 开发里。

从整个论坛的编排来看，这三层是一条完整的价值链：算力省下来，数据和模型才能跑得动；模型和服务稳定了，上层的 Agent 和应用才有发挥空间；而工具链又反过来提升开发和运维效率，形成正向循环。这样拆开讲，即使是刚入行的开发者，也能找到自己最应该深入的那个切入点。

3. 议题之外：几个值得重点跟踪的开源方向

论坛议程里能看到的内容已经很多了，但作为一个经常泡开源社区的老人，我还想额外提醒几个容易被忽略、但实际落地价值很高的方向。这些方向不一定每个都有独立议题，但会在多个演讲里反复出现，值得重点跟踪。

3.1 开源大模型与私有化部署

开源大模型已经成了很多企业做 AI 应用的首选底座，原因很直接：数据安全、定制空间、长期成本。私有化部署虽然没有公有云那么省心，但数据不出内网这个特性，对金融、医疗、政企这些行业几乎是刚需。现在团队可选的路子很多：需求轻量就上 Ollama，体验一把本地起服务的感觉；追求并发和性能就上 vLLM，把吞吐打满；想要完整的模型服务化体系，可以走 KubeFlow 或 Ray Serve 这条更重的路线。

选型建议我给一条：先明确你的场景是"学习验证"还是"生产服务"。学习验证随便折腾，Ollama 就够了，显卡差点也能跑量化版；生产服务必须考虑高可用、压测、监控、回滚，一上来就要按平台工程的标准去设计。很多团队栽跟头就栽在"先用着，以后再说"，结果模型一上线就裸奔。

量化也值得关注。同样的模型，从 FP16 量化到 INT8 甚至 INT4，显存占用可能砍掉一大半，推理速度还能提升。代价是精度有一定损失,需要在成本和效果之间做权衡。论坛上如果有讲量化和推理优化的议题，建议认真听一下，这部分经验基本都是踩坑踩出来的。

3.2 开源知识库与RAG落地

RAG 是当前把大模型落地到企业场景最稳妥的方式之一，核心思路是先检索相关内容，再让模型基于检索结果生成回答，减少一本正经地胡说八道。一个典型的开源 RAG 链路包括：文档解析、文本分块、向量化、向量检索、重排序、提示词组装、生成与引用溯源。

这个链路看起来简单，细节全是坑。文档解析阶段，PDF 里的表格、扫描件、页眉页脚处理不好，后面全白搭；文本分块阶段，切得太碎会丢失上下文，切得太大会稀释语义，分块大小和重叠率要根据文档类型反复调；检索阶段，向量模型的选型和 embedding 维度会直接影响召回效果，单路召回不够的时候还得加关键词召回做混合检索。

开源方案在这条链路上的优势非常明显。Dify、RAGFlow 这类项目把整个流程封装成了可视化编排工具，配置相对友好；向量数据库可以选 Qdrant、Milvus 或者轻量的 Chroma；重排序模型也有开源版本，能把检索结果里最相关的内容排到前面。强烈建议你先用开源组件把一个最小可用的链路跑通，再逐步替换瓶颈环节，而不是一上来就追求大而全的平台。

3.3 边缘计算与嵌入式AI

论坛讨论的热点大多在云端，但边缘和终端场景同样重要，尤其是面向硬件和嵌入式开发的工程师。工业质检、智能摄像头、可穿戴设备、车机交互，这些场景往往对延迟和隐私极其敏感，必须在本地完成推理，端侧 AI 和嵌入式开源项目因此成了基础设施里不可忽视的一环。

端侧推理的核心是把模型压到设备能跑的尺寸。除了量化，还有模型蒸馏、剪枝、算子融合等优化手段。开源推理引擎在端侧的支持差异很大，移动端有 TFLite、MNN、NCNN 这些老牌选手，更轻量的嵌入式场景则需要 BSP、交叉编译环境和底层算子库的紧密配合。很多工程师平时用的开源软件镜像站、包管理器，本质上也是这套基础设施的一部分，只是平时不太会被当作主角来讨论。

开源硬件和嵌入式操作系统的组合，正在把 AI 的能力从云端下沉到各种物理设备上。这一块的参与者不一定都是大厂背景，反而是中小企业、创客和高校实验室贡献了大量有价值的项目。如果你做硬件相关的工作，这类议题和展台是绝对不能错过的，很多分享者本人就是项目的核心维护者，现场交流的价值比看十篇博客都大。

4. 参加COSCon'25的实操建议与避坑指南

议程再好，不会听会也白搭。我参加过好几届 COSCon，也在其他技术大会上踩过不少坑，总结下来：高效的参会绝对不是"准时进场、从头坐到尾"，而是有策略、有目标、有后续动作。

4.1 行前准备：先读议程，再定路线

收到议程之后，第一件事不是收藏，而是通读一遍，把感兴趣的议题标记出来。我个人的习惯是：每个时间段先按"最想听"排序，然后每个时段准备一个备选，因为现场可能会遇到某些热门会场站不下、某些演讲临时调时间的情况。重点标记那些有实操演示、有开源项目代码仓库地址、演讲者本身就是核心维护者的场次，这种内容的干货密度通常最高。

行前还有一个容易被忽略的环节：提前列出自己最近遇到的技术问题清单。比如"GPU 共享怎么实现""RAG 召回率一直上不去怎么办"，带着具体问题去听会，你会发现普通的技术分享瞬间变成了私人咨询。很多讲者在会后都愿意多聊几句，前提是你能提出一个让他觉得"这个人真的在做这件事"的问题。

另外，如果想在现场动手实操，记得带上笔记本并提前装好常用的开发环境；但如果是纯听讲和社交，轻装出行反而更舒服。会场通常会比较吵，带个降噪耳机和充电宝是明智的选择。

4.2 现场怎么听会才有收获

到了现场，别急着从头记到尾。技术分享的 PPT 一般都会公开，比起逐页抄笔记，更需要记录的是"这个方案为什么这么做"和"他踩过的坑是什么"。我记笔记只记三件事：可复现的结论、项目的仓库地址、以及当场冒出来的疑问。疑问可以在 Q&A 环节直接提问，也可以在会后找讲者交流。

Q&A 是全场价值密度最高的十分钟。很多人在大场合不敢提问，其实完全没必要有压力。提问的目标不是显得自己多厉害，而是解决自己的困惑。一个有效的问题通常包含三部分：我的场景是什么、我做了什么尝试、卡在了哪里。比如"我在 K8s 上用 Kueue 做配额管理，发现抢占策略不符合预期，有没有推荐的配置方式?"这种问题，讲者一听就知道你是真用户，回答也会特别具体。

如果现场有 Open Space 或闪电演讲环节，强烈建议参与。Open Space 是一种非正式的小型讨论，主题由参与者现场提出，主持人只负责引导秩序，每个人都能开口说话。我第一次参加时还有点拘谨，后来发现这种场合才是认识同行、碰撞思路的最佳场所。哪怕只是抛出一个自己正在纠结的问题，都可能收获好几个人从不同角度给出的建议。

4.3 会后跟进：把灵感变成Issue

会后最大的坑，是热情散场就结束了。我见过太多人在会上加了微信、拍了 PPT、说要回去试试，然后就没有然后了。我自己后来定了一条规矩：参会后一周内，必须把自己感兴趣的项目至少打开一次，给它提一个 Issue 或 Star 一下。

具体做法是，把会上记下的仓库地址整理成一个清单，逐个扫一遍 README、看最近的 Release 和 Issue 列表、跑一个最小示例。遇到文档不清楚或者跑不通的地方，直接提 Issue，附上自己的环境信息、复现步骤和日志。一个高质量的 Issue 本身就是对开源项目的重要贡献，同时也是你和维护者建立联系的开始。

如果时间和精力允许，还可以顺手写一篇参会总结发到技术社区，或者把某个项目的使用体验整理成教程。这个动作看起来是利他的，实际上是检验自己有没有真正理解的最佳方式——写不出来就说明没听懂，写出来了就会有人来和你讨论，你的圈子就自然扩大了。

5. 从围观到共建：普通开发者参与开源基建的路径

最后聊一个话题，也是很多刚接触开源的朋友最关心的：我知道了这些项目很重要，也想去参与，但代码量不够，到底能做什么？其实参与开源的门槛远比你想象的低，尤其是 AI 基础设施这类大型项目，需求是多元的，贡献方式也是多元的。

5.1 文档贡献是最友好的起点

很多人的第一个开源贡献来自文档，我就是这么走过来的。大型基础设施项目的文档量非常大，API 更新后文档没跟上、翻译不完整、示例代码跑不通、架构图过时，这些问题几乎每个项目都有。修一个文档错别字、补一段新手指引、把某个晦涩的概念用更通俗的例子讲清楚，都是实实在在的贡献。

文档贡献的最大好处是，它会逼着你把项目完整读一遍。为了写清楚一个模块的用法，你不得不去理解它的参数、返回值、边界条件，这个过程比单纯翻代码高效得多。而且文档 PR 通常 review 起来比较快，对新手友好，能让你在比较短的时间里走通"提交 PR、参与讨论、被合并"的完整流程，建立正向反馈。

一年下来积累十来个文档类的 PR，你就已经对这个项目的设计和结构有了比较深入的了解，这时候再转向代码贡献，会顺理成章很多。不少开源项目的核心贡献者，最初就是从"帮项目写文档"这个不起眼的动作开始的。

5.2 用真实业务问题驱动贡献，而不是只写Hello World

很多新手想做代码贡献，一上来就搜"good first issue"，结果找到的题要么太小没有成就感，要么和自己的实际场景完全无关。我的建议是反过来：先在自己的项目里认真用这个开源软件，用到深处一定会遇到问题，这才是最好的贡献入口。

比如你在生产环境里用某个开源向量数据库，发现内存占用异常，这就是一个绝佳的研究方向。你可以尝试定位是配置问题还是 bug，可以在社区里提问，可以先给项目提交一个详细的 Issue，说明现象、环境、复现路径和已经做的排查。维护者最缺的往往不是修 bug 的人，而是能把 bug 讲清楚的人。一个高质量 Issue 能帮助他们快速定位问题，省去大量来回沟通的时间。

在你能够稳定地提出高质量 Issue 之后，就有机会参与真正的代码修复了。从补一个测试用例开始，到修一个边界条件，再到实现一个小功能，路径会越来越清晰。核心心得是：真实需求带来的动力和耐心，远不是"为了凑贡献数量"能比的。

5.3 贡献开源不只有写代码，注意许可证与社区礼仪

最后必须强调，开源项目的贡献方式远不止代码。设计、测试、文档、翻译、社区运营、布道推广、用户支持，每一个环节都是贡献。尤其是 AI 基础设施项目，需要大量测试人员在真实环境里跑数据、反馈性能，需要有人帮忙整理用户案例，需要有人做中文社区的问题解答——这些工作同样重要，而且缺口很大。

如果你决定开源自己的项目，许可证的选择值得花点时间琢磨。MIT 和 Apache-2.0 都算宽松，商用友好，后者还多了一条明确的专利授权条款；GPL/AGPL 则强调代码共享，AGPL 对网络服务也有约束。很多项目因为许可证选得草率，后续商业化或合作时才发现处处受制。具体怎么选，要结合你的目标是"广泛采用"还是"保护代码不被闭源商用"，这也是每个开源参与者迟早要面对的选择题。

在社区沟通层面，尊重和维护者的时间很重要。提问前先搜文档和已有 Issue，提问时给出完整的上下文，收到回答后及时反馈结果，这些基本的社区礼仪会让你的贡献之路顺畅很多。开源社区本质上是个陌生人协作的网络，信任是靠一个个负责任的举动积累起来的。

最后说点个人体感。每年开完 COSCon，我都会重新整理一遍自己关注的开源清单，今年尤其如此。AI 基建这个赛道，表面上看是巨头之间的军备竞赛，实际上恰恰是开源社区最能发挥价值的地方——因为基础设施比拼的不是谁的发布会更响亮，而是谁能把信任、透明和生态做扎实。就像十年前没人能预料 Kubernetes 会成为整个行业的事实标准一样，今天你在论坛上听到的某个调度器、某个评测框架，也可能就是未来 AI 世界的底座。你不需要一开始就懂底层原理，先来听、来问、来提一个 Issue，就已经是参与筑底了。