企业官网建设流程全解析

COSCon‘25 的 AI 基础设施开源论坛议程正式发布了。如果你这些年一直在一线做 AI 应用、大模型训练推理，或者负责公司内部算法平台的架构，应该能感受到这个消息的分量：开源已经从“方案选项”变成了“基础设施的默认答案”，而这次论坛就是围绕这个答案展开的。不管是刚入行的算法工程师、搞了多年后端的技术负责人，还是想参与开源但不知道从哪下手的贡献者，这份议程都值得你花半小时认真拆一遍。

我自己参加过几届 COSCon，明显感觉今年的 AI 基础设施方向不再是过去那种“分布式存储”、“任务调度”的泛泛而谈，而是直接对准了大模型时代最疼的几个问题：GPU 不够用怎么办、数据杂乱怎么整、推理成本压不下去怎么解、模型上线之后怎么观测。看完这份议程，我的直觉是：它不是在讲未来的技术愿景，而是在解决今天公司里每天都在发生的真实问题。

下面我把这届论坛的核心内容、背后的技术逻辑、适合哪些人看，以及我这些年在开源 AI 基建方面踩过的坑，一次性说清楚。

1. AI基础设施到底在“基建”什么

1.1 从“算模型”到“建底座”的认知转变

很多人一听到“AI 基础设施”，第一反应是买显卡、搭机房。这个理解放到五年前是没错的，但现在早就不是这样了。大模型时代，基础设施的覆盖面已经扩展到了你从“拿到一个开源模型”到“把它变成线上稳定服务”之间的一切环节。

我把 AI 基础设施拆成四层来理解，这样比较直观：

可以这么想：以前我们做 AI 是“自己买菜、自己生火、自己做菜”，现在是大模型时代，菜市场、燃气灶、抽油烟机、甚至菜单都变成了基础设施。你真正要投入精力的，是怎么把菜做得比别人好吃，而不是再纠结火候怎么控制。

所以这次 COSCon 把 AI 基础设施单独拎出来做论坛，本质上是在替行业喊一句话：模型能力会持续迭代，但底座不牢，什么新模型都跑不利索。

1.2 为什么 AI 基础设施天然适合开源

这个问题如果放在五年前，可能还需要辩论一下。现在答案已经很清晰了：AI 基础设施是典型的“需要所有人共建、又被所有人共用”的公共资源。

先说共建。没有哪家公司能独自搞定从底层芯片适配到上层 Agent 编排的全部环节。拿推理引擎来说，vLLM 能这么快普及，就是因为它吸收了全球几百家公司的贡献，每个厂商把自家遇到的推理瓶颈、显存优化技巧都回馈到社区，然后其他人直接受益。这种迭代速度，闭源产品完全追不上。

再说共用。如果你是一家中小型公司，不太可能自己从零写一套 GPU 调度器或者向量数据库。用了开源方案，相当于站在整个行业的肩膀上。这个优势在成本上尤其明显：商业软件的授权费是按 CPU 核数或者节点数收的，但开源项目可以随便铺。

更重要的是，开源意味着“可审计、可改造”。企业在 AI 落地中最怕的不是技术难，而是被某个供应商锁死。你用一个闭源平台跑核心业务，一旦平台调整策略、涨价、或者不再维护，你连自救的机会都没有。开源项目至少把源码摆在那，哪怕社区维护节奏慢了，你也能拉分支自己续命。

这些道理说起来简单，但真正经历过“平台突然改收费策略”的人，才会明白“底座必须掌握在自己手里”这句话有多重。

2. 论坛核心议题拆解：从算力到模型再到落地

2.1 算力层：GPU 紧缺背景下的弹性与效率

算力是这届论坛绕不开的话题。现在的现状是：大模型不是跑一次就完事，而是长期做训练、微调、推理，每一步都在吃显存。很多团队的 GPU 资源利用率低得可怜，平均也就 30% 上下，不是不够买，而是调度能力跟不上。

围绕这个痛点，论坛里应该有大量分享会集中在几个方向：

• 异构资源统一调度：把 A100、H800、4090 甚至消费级显卡都纳入同一个资源池，按需分配。开源社区里现在比较主流的方案是 Ray + Kubernetes 的组合，Ray 负责分布式计算任务，Kubernetes 负责资源生命周期管理。
• 推理引擎的极致优化：持续做大模型的 KV Cache 管理、连续批处理、投机采样这类技术。vLLM、SGLang、TensorRT-LLM 这些项目每发一个新版本，吞吐量都能涨一截。
• 弹性扩缩容：在线推理服务有明显的波峰波谷。白天用户多，晚上没人用，如果服务始终全量跑着，显卡全在空转。通过 KEDA 这类开源组件做基于队列长度、GPU 利用率的自动伸缩，能省下很大一笔成本。

这些方向有一个共性逻辑：算力紧缺不是靠“买更多卡”解决的，而是靠“把每一张卡压榨到极致”解决的。这也是开源 infra 团队最能体现价值的地方。

2.2 模型层：从下载到部署的完整链路

过去模型部署是算法工程师的“最后一公里”，现在这个环节已经变成了独立的专业领域。论坛里关于模型层的讨论，我推测会围绕这几个话题展开：

模型选型。开源模型越来越多，从几 B 参数的小模型到几百 B 的旗舰模型都有。怎么根据业务场景选择合适规模的模型？没有绝对的答案，需要一套评估机制。Hugging Face 上已经有大量 benchmark 数据，但真实业务场景的效果还是得自己跑评测集。

微调的工程化。LoRA、QLoRA 这类参数高效微调方法已经成为主流，但微调之后怎么和原模型做切换、怎么保证不“灾难性遗忘”，很多团队在实操中会踩坑。开源社区里比较好的实践是用 DVC 记录数据集和模型版本，配合 MLflow 管理实验，做到每次微调都可追溯、可回滚。

部署形态的分化。同一个开源模型，可以跑成在线 API 服务、可以打进边缘设备、可以做成离线批处理任务。不同的部署形态对量化、裁剪、编译优化有完全不同的要求。ONNX Runtime、TFLite、OpenVINO 这些项目在边缘场景中仍然是主角。

说白了，模型层已经不是“搞个模型回来就行了”的时代，而是需要一套从选型到上线、从侧重点各异的部署形态到统一运维的流水线。这场论坛如果能把这些链路讲透，参会者回去至少能少走半年弯路。

2.3 数据层：高质量数据是更深的护城河

算法圈有一句老话：数据和特征决定了机器学习的上限，模型只是逼近这个上限。到大模型时代，这句话依然成立，而且被放大了。

现在开源模型本身已经严重同质化，同等参数规模下，大家的能力差距并不大。真正拉开产品差距的反而是数据：谁的数据更干净、更贴近业务场景、标注质量更高，谁微调出来的模型就更好用。

这次论坛在数据层面的议题，我特别关注这几个点：

其中合成数据是比较新的方向。现在很多团队发现，靠人工标注根本跟不上模型迭代速度，于是开始尝试用大模型生成结构化数据、用规则引擎构造对抗样本、用迁移学习补足长尾场景。这些方法在开源社区里有不少现成工具，但真正把它们组合成一套可靠流水线的实践分享，还是很稀缺的。

如果你所在团队正在被“喂数据”这件事折磨，这部分议程值得重点关注。

2.4 工程化：可观测性与成本治理往往决定生死

AI 基建还有一个特别容易被低估的环节：模型上线之后怎么观测、怎么排障、怎么控制成本。很多团队上线第一个模型的时候，只关注效果指标，比如准确率、召回率，但真正上线跑起来之后发现，问题根本不在模型本身，而在系统层面。

• 推理延迟为什么会抖动？
• 显存泄漏怎么定位？
• 用户输入变了，模型效果开始退化怎么办？
• 某个调用方疯狂刷接口，导致 GPU 成本飙升怎么办？
• 多版本模型同时在线，流量怎么切分？

这些问题需要通过完善的观测体系来回答。开源生态里有 Langfuse、LangSmith（部分开源）、MLflow、Prometheus + Grafana、OpenTelemetry 等一系列组件，可以覆盖从调用链追踪到指标监控的完整链路。

我特别想强调的是成本治理。大模型服务的成本结构跟传统 Web 服务完全不同，Token 消耗就是真金白银。如果没有一套预算控制和配额管理机制，一个失控的线上服务完全可能一个月烧掉几十万。开源界已经有项目在做模型网关，专门负责限流、负载均衡、成本核算、多模型路由，相当于把 API 网关的思路搬到了大模型服务上。这类项目性价比极高，值得所有做 AI 应用的公司关注。

3. 这份议程对谁最有价值

3.1 一线开发者：抓住技术风向标

如果你天天在写 Prompt、调模型、搞 RAG 流程，这份议程相当于一份“行业技术风向标”。你不用亲自跟踪每一个 GitHub 项目的 Release 记录，只需要看论坛上哪些项目被反复提及、哪些议题被拿出来讨论，就能判断出哪些技术正在从“玩具”走向“生产可用”。

比如如果论坛上有多个分享都涉及“多 Agent 协作的可靠性”这个话题，那就说明它在行业里已经有足够多的真实落地案例和踩坑经验，你这时候入门，正好能吃到早期红利。

给一线开发者的建议：不要只盯 PPT，重点看分享者的开源项目地址和架构图。通常做完一场分享，讲者都会把核心设计思路沉淀到项目文档里，顺着这条线去挖，收获会比会议本身大得多。

3.2 架构师与技术决策者：开源选型的重要参考

对于负责技术选型的人来说，这类论坛最大的价值不是“学习”，而是“验证”。你可能已经在某几个开源方案之间犹豫了几个月，想找人问问真实的使用体验。论坛现场的圆桌讨论、问答环节、会后交流，都是绝佳的调研机会。

我自己也做过技术决策，踩过最大的坑就是只看项目 Star 数，没有关注项目的许可证类型。Apache 2.0、MIT、GPL 的商用友好程度完全不同。别等到产品要商业化的时候才发现用了 GPL 组件，导致整个项目都得开源，那场面真的很尴尬。

建议技术决策者带着明确的问题清单去逛论坛，比如：

• 这套方案在千卡集群上验证过吗？
• 社区最近的 commit 活跃度怎么样？
• 背后有商业公司在维护吗？
• 和现有技术栈的兼容性如何？
• 出了问题，社区响应速度如何？

这些问题的答案，往往比官网白皮书真实得多。

3.3 学生和开源新手：找到低成本入圈路径

如果你想进入 AI 基础设施这个方向，但没有任何大厂实战经验，开源社区可能是你最友好的入口。你不用简历上写着“五年分布式系统经验”，只要在 GitHub 上有几个高质量的 commit、能在社区讨论里提出有价值的问题，就已经比大多数求职者突出了。

这次论坛对学生和开源新手的价值在于：你能看到那些平时只出现在 README 里的项目维护者，听他们亲口讲设计决策背后的权衡。这些内容学校里不会教，但在实际工程中极其重要。

更务实的建议是：从文档和 issue 入手。别一上来就想提大 PR，先帮项目修文档、补充测试、复现 bug，这些都是社区非常需要但又没人愿意做的事情。积累几轮信任之后，再逐步接触核心代码，成长速度会非常快。

4. 参与论坛的正确姿势与避坑指南

4.1 会前预习：先把背景补上

我见过太多人参加技术会议，现场听着热闹，回去啥也没记住。核心原因就是背景知识没跟上，听到的都是碎片信息。

看这份议程之前，建议先花一个周末的时间，把议程里提到的核心开源项目在本地跑一遍。不需要做多复杂的二次开发，只要能把项目启动起来、跑通一个最简单的 Demo 就行。比如：

• 用 vLLM 在本地起一个模型推理服务
• 用 DVC 给一份示例数据集做版本管理
• 用 Langfuse 追踪一次 LangChain 调用
• 用 Ray 在本地启动一个简单的并行任务

有了这些基础体验，论坛上再听到相关的概念、架构、性能数据时，你的理解深度完全是两个层次。因为你会自动把听到的内容映射到自己实际跑过的场景上，“原来当时遇到的这个问题是这么解的”这种感觉，比被动听讲爽多了。

4.2 会中记录：不是记 PPT，而是记问题

听分享的时候最忌讳逐字记录 PPT。PPT 上的内容基本都会公开，真正有价值的是分享者讲到某个细节时顺口提的一句“这里我踩过一个大坑”，或者回答听众问题时突然抖出来的实践细节。

我的习惯是准备一个纯文本笔记，只记录三类内容：

• 分享者提到了什么开源项目？拼写是什么？立刻记下来。
• 某个架构图里出现了哪些我认不出来的组件？在现场拍下来，会后再查。
• 分享者说“我们一开始是这样做的，后来改成那样”的地方。这个前后差异往往比最终方案更有价值。

另外，一定要利用好问答环节。很多人不好意思提问，担心问题太基础被鄙视。但我的经验是，技术会议上大多数听众其实跟你水平差不多，你问出的问题往往也是大家想问的。如果不确定问什么，可以问一些开放性的工程决策问题，比如“这个方案在单机跑和分布式跑有什么差异”“如果数据量再涨十倍，当前的架构瓶颈会出现在哪里”，这类问题通常能引出很有价值的回答。

4.3 会后跟进：把会议收获变成技术资产

参会最大的误区是逛完就算完了。我给自己定过一个规矩：参加完技术会议后，72 小时内必须产出一份“技术简报”，哪怕只是给团队发一篇内部笔记也行。

具体做法是这样的：

1. 把会议上收集到的项目地址整理成一份列表，标注清楚它们解决的问题
2. 挑一个跟当前业务最相关的项目，在本地部署跑一遍
3. 写一篇简短的使用体验，包括安装过程、踩坑点、性能表现
4. 如果合适，把体验分享到团队的技术 wiki 或者社区

这个过程能帮你把被动输入转化为主动输出，知识留存率会高很多。

5. 从会议到日常：把开源 AI 基建真正用起来

5.1 一套最简 AI 基建栈，跑通你的第一个 Demo

听完论坛，自己动手是最好的沉淀方式。如果你想快速体验现代 AI 基础设施完整链路，这里有一套我非常推荐的最小组合，全部开源，一台带 NVIDIA 显卡的机器就能跑起来。

第一步，用 Ollama 拉一个 7B 到 14B 的模型，比如 Qwen 系列。ollama run qwen2.5:7b几秒就能跑起来。先感受一下纯对话体验。

第二步，通过vllm serve以 OpenAI 兼容接口的方式启动同一个模型。你会立刻发现它在并发请求、吞吐量上的优势。这背后就是连续批处理和 PagedAttention 等优化带来的差异。

第三步，在代码里调用 vLLM 的服务，把请求接入 Langfuse 做追踪。这样你就能看到每一次请求的耗时、Token 消耗、Prompt 内容。它是你之后优化效果和成本的基础。

第四步，用 DVC 给数据集做个版本管理，建立一条简单的数据更新流程。你就能理解为什么说“数据管线”也是基础设施的一部分了。

这套组合拳跑下来，你对 AI 基建的认知会从“听过很多名词”变成“我亲手搭过一条链路”。有了这个基础，再去看论坛的深水区内容，吸收效率完全不同。

5.2 参与开源贡献，怎么选项目、怎么上手

关于怎么选项目，我有一个非常朴素的标准：选你自己正在用的项目。不要为了刷贡献而去研究一个你根本不会用到的轮子。你日常使用中踩到的坑、觉得哪里不顺手、想要但没找到的功能，就是最好的贡献起点。

比如你正在用 Langfuse 做链路追踪，发现它的告警通知只支持少数几个渠道，而你用的是钉钉。这时候你就可以动手：

• 看看项目的 API 设计
• 在 GitHub 上发一个 feature request
• 如果维护者回复了相关计划，可以问一句“需要帮忙实现吗”
• 从最简单的 provider 扩展开始，写一个通知渠道适配器

这类贡献不需要你理解整个系统的全貌，只需要你熟悉自己用到的那个模块，学习成本很低，但对项目的价值却很实在。

另一个建议是：多留意“good first issue”和“help wanted”标签。但不要盲目认领，先看 issue 对应的代码区域你是否熟悉，有没有可能在一到两周内完成。认领后如果进展不顺，及时在 issue 下说明，维护者通常能理解。

我发现很多新手最缺的不是技术能力，而是“敢动手”的勇气。总觉得自己水平不够，担心提的代码被维护者吐槽。其实开源社区的常态是：只要你的 PR 是认真做的，哪怕没有直接被合并，维护者也会在 review 时给出详细的改进意见。这个过程本身就是极好的学习。

5.3 关注这个领域，日常信息源怎么搭

如果你打算长期跟踪 AI 基础设施和开源生态，建议把日常信息源结构化一下，别每天被动刷热搜。

• GitHub Trending：每天快速看一下 Star 增长异常的项目，不一定是排名最靠前的，而是那些在你关注的领域里突然冲出来的新项目。配合 GitHub 的 Watch 功能，关注几个核心仓库的 Release 和 Discussion。
• Hacker News 的 Show HN：很多有创意的开源项目会在这里首发亮相，尤其是开发者工具类。
• 技术会议的视频回放：COSCon 这类会议结束后，演讲视频一般都会传到 B 站或者官网。不需要实时看，参加完会后，用一周时间分章节回放，效果甚至比现场更好，因为可以暂停和倍速。
• 项目维护者的个人博客：直接订阅你喜欢的开源项目核心维护者的博客或 RSS 源，能提前看到他们的设计思路和行业判断。

把这些信息源组合起来，每天花大概 30 分钟，长期坚持，你对领域的敏感度会明显高于其他人。

6. 写在最后：我的几点体会

从最初自己用开源组件搭模型服务，到后来参与维护一些开源项目，再到这次看到 COSCon 的 AI 基础设施论坛议程，我的感受其实挺一致的：开源在这里已经不是一个“可有可无”的选择，而是很多团队真正跑通 AI 业务的基石。

我自己在实践中有两个一直坚持的习惯，分享给大家。

第一，不管项目再忙，每隔一段时间一定要做一次“技术下沉”。所谓下沉，就是暂时离开业务代码，去深入了解底层基础设施到底是怎么运转的。比如花一个下午去看 vLLM 的调度逻辑、看 Kubernetes 怎么调度 GPU 资源。这种投入不会直接带来业务收益，但能让你在排障时多很多直觉，而且往往能发现一些可以反向优化应用层的机会。

第二，永远保持“够用就好”的心态。开源基建领域有个陷阱，就是技术名词太多、方案太丰富，容易陷入“什么都想用”的误区。如果你只需要一个简单的推理服务，先别急着上分布式推理框架。等流量真实涨上来了，再逐步演进架构，比一开始就搭一个庞大的集群要务实得多。

这次论坛虽然议程刚发布，但从主题设置和嘉宾方向来看，基本覆盖了 AI 基础设施从资源调度、数据工程、模型服务到可观测性的完整链路。对很多人来说，它可能会成为接下来一整年项目选型和技术规划的重要参考。建议你提前把议程里感兴趣的部分标记出来，准备好问题清单，带着自己的实际业务场景去参会、去提问、去交流。

等会议结束之后，如果有什么值得聊的技术细节，我再回来补一篇实战复盘。