COSCon‘25 的 AI 基础设施开源论坛议程出来了。如果你跟我一样这几年一边写业务代码一边折腾大模型应用大概会懂为什么这个坛子的消息能让人精神一振——AI 圈子的热闹大多集中在应用层刷榜、写 Agent、调提示词但真正让项目能跑起来、能撑住线上流量、能持续迭代的那层东西一直很少有人系统讲清楚。所谓“AI 基础设施”往小了说是模型怎么分发、推理怎么部署、数据怎么管理往大了说是算力、调度、开发工具链和运维体系如何闭环。这恰恰是开源社区最擅长也最有积累的地方。这篇文章我就结合自己多年在开源项目里摸爬滚打的经验把这场 AI 基础设施论坛背后的技术脉络、值得关注的核心议题以及普通开发者怎么从“围观”变成“参与”的方法论一次聊透。无论你是平台工程师、应用开发者还是刚准备踏入 AI 领域的学生看完应该都能找准自己的位置知道从哪儿下手。1. 为什么现在把“AI 基础设施”单独拿出来办一个论坛人工智能这几年不缺热点缺的是能把热点变成稳定生产力的底座。单独为此开一场论坛本身就是行业走向成熟的信号。1.1 AI 应用爆发之后海量项目卡在了基础设施层最近一年我用过和参与过的 AI 项目从 RAG 知识库、编程助手到各类 Agent数量不少。一个特别直观的感受真正拖住团队的从来不是模型效果不够好而是“模型之外的活”没人干。举个例子。你想在公司内部做一个基于私有知识库的问答系统模型可以选开源的几行代码就能调用。但接下来一连串问题就来了模型权重文件放哪、怎么统一拉取更新用 docker 部署还是 k8s 编排GPU 不够如何让 CPU 也能跑多用户并发会不会 OOM推理日志怎么采集如何做模型版本的灰度发布……这些问题单独看都不难叠在一起就是一套完整的系统工程。本质上是把 AI 能力“产品化”的必要管道业内叫 AI Infra。论坛把基础设施单列出来本质上是告诉大家**与其追每个新模型不如先把模型能稳定落地的环境建起来。**这就像大家装修时都盯着客厅沙发买但真正决定入住体验的是水电管线和网络布线。1.2 开源在 AI 基建里的独特价值标准、互通与可见AI 基础设施这块商业闭源产品也不缺但为什么开源社区的声音越来越大我理解有三个不可替代的价值。第一是可审计。模型推理是本地的还是被偷偷传走的权重有没有被篡改这些在开源栈里都可以逐行检查商业黑盒就没这么踏实尤其数据敏感的场景根本不敢用。第二是可移植。开源项目之间的组合像乐高格式和接口通常是开放的。你今天用 Ollama 做推理明天换成 vLLM后端抽象得好应用层甚至不用改代码。这类“不被绑定”的能力在基础设施层面太重要了。第三是可协作。一个数据管线的小毛病可能有人已经在 GitHub issues 里给出了补丁。开源项目背后的开发者来自不同公司反而推动了工具间互相兼容。一个很典型的例子模型格式标准。早期各家模型格式五花八门导致部署工具互不兼容。后来社区逐步收敛到 GGUF、SafeTensors 这类开放的格式上才让本地部署工具链百花齐放。这种标准化的推动力商业闭源产品通常没有动力去做——毕竟“封闭”本身也是一种商业模式。1.3 这场论坛适合谁很多人看到“基础设施”四个字容易被劝退总觉得是架构师的事情。我的看法完全相反这场论坛的内容覆盖面其实很广应用开发者关心模型怎么接、AI Agent 怎么编排、工具链怎么选能少走很多弯路。后端与平台工程师想了解大模型部署、GPU 调度、推理优化的最佳实践。开源爱好者与布道师关注组织开源、治理模式、社区协作机制。学生与研究者想低成本上手真实项目找到从论文到工程落地的桥梁。不管你是哪种身份只要在用 AI 做东西基础设施就是你躲不过去的坑。与其一个个踩不如看看开源社区沉淀出的“标准答案”。2. 论坛核心议题拆解一场从模型底座到交付管线的全景图虽然我还没拿到完整的演讲逐字稿但从这次公布的议程方向看论坛明显想给大家画一张“AI 基础设施全景图”。我归纳成四条主线每条都对应具体的开源项目和实践经验。2.1 模型算力与调度层大模型本地部署与统一调度这一层是大家最容易感知到的也是 AI 基础设施的第一公里。本地部署大模型的工具最近一年我高频使用的是 Ollama。它把模型下载、量化、API 服务全部封装好了一条命令就能把 Llama、Qwen、DeepSeek 这些开源模型跑起来。论坛上大概率会聊到这类工具背后的设计思路为什么选择 GGUF 格式作为统一分发格式如何做 KV Cache 量化怎么在多模型之间切换。更深一层是模型调度和推理引擎。单机跑一个模型容易多模型多 GPU 的高效调度是另一回事。vLLM 用 PagedAttention 把显存利用率翻了几倍TensorRT-LLM 做算子融合这些名词看着硬核但理解它们的核心就一句话让有限的 GPU 跑更多请求、更低延迟。部署时还有个绕不开的话题量化。简单说就是把模型参数的精度从 16 位浮点数压缩到 4 位或 8 位整数效果损失一点但显存占用和推理速度大幅改善。比如一个 7B 模型FP16 要占 14GB 显存4-bit 量化后只要 4GB 左右很多消费级显卡甚至纯 CPU 都能跑。内存和显存怎么估算一个简单经验公式显存占用GB≈ 参数量B× 每个参数的字节数FP16 精度每个参数 2 字节INT8 是 1 字节INT4 是 0.5 字节一个 7B 模型 INT4 量化后约需 3.5GB 权重空间加上推理过程中的 KV Cache 和激活值实际建议翻倍预算这也是为什么本地部署火起来以后大家开始重视“模型对硬件适配”的问题而不是单纯看“模型胜率排行榜”。2.2 数据层训练数据管线与开源镜像服务基础设施的第二层数据。大模型时代数据工程的复杂度和重要程度被严重低估。一个完整的数据管线包括采集、清洗、去重、格式化、版本管理。开源社区在 NLP 领域有很多成熟工具比如用于大规模数据清洗的 Haystack、用于数据版本管理的 DVC以及各类数据集的镜像服务。论坛上讨论这些议题本质上是在回应一个问题模型开源了但数据能不能也像代码一样做资产管理我个人很看好“开源模型 开源数据 开放接口”组合的方式。企业做私有化部署时最头疼的往往不是模型能力而是“如何把企业内部文档加工成模型能理解的格式”。这方面开源社区已经沉淀出很多 recipe数据配方比如文档解析、表格识别、知识图谱构建完全不必从零发明。另外模型下载慢、资源获取难的问题也在被社区逐步解决。很多国家和地区都有自己的开源镜像站、模型托管平台把重要的模型权重和数据集缓存到本地。这类平台的本质是把“基础设施的获取成本”降下来。2.3 模型服务与工具链Agent、提示词与测试部署有了模型和数据下一步就是怎么把它变成对外服务的能力。这一层最近变化最快。AI Agent 编排已经从纯 Demo 走向生产。业界在讨论统一的工具调用协议让 Agent 能标准化地调用数据库、API、浏览器等外部能力。论坛大概率会邀请做过大型 Agent 系统的工程师分享多 Agent 协作、规划、记忆和工具选择的实战经验。AI 编程工具链是最典型的基础设施化产品。现在主流的开源编程助手底层已经不只是简单的“补全”而是围绕仓库索引、代码检索、测试生成、CI 集成的完整链路。你可以把这类工具理解成把“AI 能力”变成了 IDE 里的一个基础设施插件谁都能接入。还有一块看似冷门但极其重要的AI 测试开发。模型输出有随机性同一个 Prompt 两次结果可能不同这导致传统的断言测试很难直接用在 AI 应用上。怎么评估模型回答质量、怎么建回归测试集、怎么监控线上效果漂移都需要一整套新范式的工具支撑。这是典型的“基建活儿”做得好能让整个团队都有安全感。2.4 边缘与嵌入式 AI 基建开源带来的最后一公里服务器的基建讲得再多很多场景最终要在终端设备上跑。比如摄像头、工控机、农业病虫害识别设备。这些嵌入式场景资源极其有限对推理框架的依赖更深。开源社区在嵌入式领域积累非常厚。举几个我实际接触过的例子- 基于 STM32 的采集设备配合开源 RTOS 和轻量级推理框架在单片机级别做语音唤醒或传感器分类农业病虫害识别项目通过开源数据集和模型剪枝把识别模型塞进边缘盒子离线也能用C# 生态有不少开源的 USB 摄像头组件配合 OpenCV 的封装层可以在 Windows 工控机上快速搭建视觉检测服务。这些项目验证了一件事AI 基础设施不只有云端的庞然大物还有边缘的轻量级利刃。论坛把边缘计算纳入议题说明大家开始正视“不是所有算力都在数据中心”的现实。3. 务实演练把一个开源 AI 基础设施项目完整跑起来光看议程不实操等于白看。这里分享一个我自己跑通的组合Ollama Open WebUI 开源模型可以在普通笔记本上十分钟搭建一个私有的 AI 问答助手完全本地运行、数据不出内网。这套方案非常适合作为你进入 AI 基础设施领域的第一块试验田。3.1 场景与选型从零搭一个私有知识问答助手我选择这个组合的理由很简单Ollama负责模型下载和推理服务跨平台有自动量化Open WebUI提供浏览器界面支持多用户、聊天记录、RAG 文件上传不用自己写前端Qwen / Llama 等开源模型在中文场景表现出色且对部署环境要求宽容。如果你想做得更完整可以再加一个开源的向量数据库比如 Chroma 或 Milvus把文档灌进去做“本地知识库 RAG”。这套技术栈的每一环都有开源替代品换掉任何一个组件都不影响整体结构。3.2 部署步骤与关键参数前提一台 16GB 内存以上的电脑或者任意一台云服务器CPU 即可有 GPU 更佳。操作系统建议 Linux 或 macOSWindows 也可以通过 WSL2 完成。第一步安装 Ollama。macOS 和 Windows 可以直接下载安装包Linux 一条命令搞定。curl -fsSL https://ollama.com/install.sh | sh第二步拉取模型。以阿里开源的 Qwen2.5 7B 模型为例默认带量化性价比很高ollama pull qwen2.5:7b如果机子性能一般可以选 qwen2.5:3b内存 8GB 也能跑。模型下载完成后直接用命令行就能开始对话ollama run qwen2.5:7b 用一句话解释什么是 AI 基础设施第三步启动 Open WebUI。官方推荐用 Docker 来跑避免污染宿主环境。我建议把模型服务地址显式传进去docker run -d \ --name open-webui \ -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -v open-webui-data:/app/backend/data \ ghcr.io/open-webui/open-webui:main浏览器访问http://localhost:3000注册一个本地管理员账号就能看到完整的聊天界面。第四步如果要做知识库问答我在实际使用中会先在 Open WebUI 的“文档”里上传 PDF 和 Markdown它会自动做切片和向量化然后直接在聊天时引用文档内容回答。整个过程完全不需要写代码适合验证 RAG 的整体流程。3.3 部署后必须关心的几个参数模型跑起来只是开始真正压测时你会碰到各种参数问题这里列三个最常调的参数作用建议值/经验num_ctx上下文窗口长度决定能“记住”多长的对话和文档默认 2048知识库问答建议 8192 起步越大越吃显存num_threadCPU 推理的线程数默认为物理核心数手动设太高反而因线程调度开销变慢keep_alive模型驻留内存的时间默认 5 分钟高频调用建议设为 -1 保持常驻但会持续占用内存修改方式是在Modelfile里配置或者通过 API 调用参数临时覆盖。比如用 curl 调推理接口时设置上下文长度curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 介绍一下开源许可证, options: { num_ctx: 8192 } }我踩过的坑是上下文长度调大后加载模型的时间肉眼可见变长且并发请求时内存会飙升。假如你的服务面向多人使用务必给 Docker 容器加内存限制。比如限制最大 8GBdocker run -d --memory8g --memory-swap8g ...否则内存被吃满后进程会触发系统 OOM表现是界面突然卡死日志毫无报错排查起来特别难受。4. 从使用到贡献开源参与的正确姿势与避坑指南你会用 Ollama、会部署 WebUI 之后其实已经到了“用开源”的层次。如果想进一步进入基础设施的核心圈参与开源本身是一门学问。这里分享我多年踩坑后总结的几个原则。4.1 许可证不是废话选错很麻烦很多新人对开源的理解就是“代码免费随便用”但开源世界里“自由”分很多种。这是最常见的几类许可证对比许可证允许商用要求开源衍生代码适用场景MIT是否代码库、工具、组件希望被最大化采用Apache-2.0是否需要专利保护的项目很多 AI 框架首选GPL-3.0是是希望衍生作品也必须开源偏软件精神模型特有协议视模型而定视模型而定Llama 系列、Qwen 系列各有商业限制条款实际教训我之前参与过一个项目主代码选了 MIT结果后来想引入一个 GPL 组件两边协议冲突最后只能返工重写那部分功能。在项目早期就把许可证定清楚比什么都重要。4.2 社区协作的“潜规则”从小处切入给开源项目提 PR 是参与的开端但方式不对很容易碰壁。我在 GitHub 上维护项目的几年里见过太多一上来就甩一个 5000 行大 PR 的新人这种基本都会被晾在一边。更靠谱的路径是从good first issue开始先修文档、补测试、修小 bug在 issue 里先说明你想做什么等维护者回应再动手避免白做功提交 PR 时把改动范围控制在最小方便 review如果碰到 CI 报错先把截图和日志贴全再问问题。先理解维护者的处境他们最怕不可维护的复杂度。你展示出“愿意学、能沟通、不添乱”的品质比一次性贡献大量代码更能赢得信任。4.3 从“用”到“维护”的心态转变很多人觉得自己水平不够不敢称自己是某个项目的维护者。其实开源维护不一定要写很深的核心代码干三件不显眼但重要的事triage issue帮项目整理 bug 报告区分有效和无效反馈回应用户问题在 Discussions 里解答部署问题对新手价值极大完善文档和样例中文文档贡献、快速上手模板都是稀缺资源。我自己在 GitHub 上维护过一个几百 star 的小项目核心代码可能不到 2000 行但花在整理 issue、写教程、处理兼容性问题上的时间远多于写代码。这也让我深刻理解开源基础设施项目的生命力不在于代码多炫而在于围绕它的生态是否健康。只要你参与过这些“幕后工作”你就已经算维护者了。5. 如果去现场参会、逛展与技术圈交流的实操建议论坛公布的议程只是一个索引真正的收获往往发生在分会场之外。如果你有机会去 COSCon‘25 现场或者通过直播参与我建议你做好这几件事。5.1 去之前先做功课不要空手进场。提前把感兴趣的议题对应的开源项目仓库 star 下来粗略浏览 README 和最近的 issue。这样你和演讲者、布道者交流时能问出有深度的问题也能听懂他们提到的技术名词。我常用的方法是在便签上写三个问题每逛完一个展位就问掉一个强制自己深度交流而不是蜻蜓点水。5.2 展位交流的黄金姿势开源项目的展位通常摆着电脑直接展示代码和 Demo。这一刻是最佳的学习窗口。你可以问“你们项目里最难维护的模块是哪个”“如果我想贡献你们最缺什么类型的人”“你们在生产环境遇到的最大坑是什么”这些问题通常能炸出比 PPT 上有用的多的一手经验。不要开口就是“你们怎么赚钱”维护者最关心的是技术本身。5.3 线下见面带来的信任优势我有个强烈的感受在 GitHub 上互撕一百条 issue 的两个人线下握一次手之后沟通成本会骤降 80%。开源协作本质上是信任协作。线下聊过之后回头提交 PR维护者会更加愿意帮你看代码。这种隐性优势是远程沟通很难替代的。6. 关于 AI 基建开源趋势我最后想说的论坛发布了但真正有意思的事才刚刚开始。我个人判断未来一年 AI 基础设施的开源竞争会从“单点工具”走向“全栈平台”。现在已经能看到一些开源项目把模型管理、数据管线、推理服务、监控告警做成一个整体解决方案。对这种趋势我的态度一直是平台统一是好事但别忘记数据自由和模型可移植性才是开源的根。如果你问我个人实操中最该提前做的事我会说三个把你最常用的推理引擎和模型分发工具彻底弄懂不止会装会调参选一个你日常用的开源项目持续贡献三个月哪怕只是修文档把项目里的关键数据流记录下来形成自己的“基建手册”以后不管换什么模型、换什么工具这套能力都能迁移。这是我自己从“只会调 API”到“敢说自己懂一点 AI 基础设施”的路径它不陡峭但需要动手和耐心。希望这篇文章能帮你把起点找对等论坛正式开场的时候你已经具备带着问题去听讲的底气了。