1. 百人共学场景下这套架构到底要解决什么问题先把背景说清楚。所谓“百人共学”不是一百个人同时在线看直播那种单向输出而是一百来号人各自带着问题进来在同一套 AI 问答入口里查资料、问概念、做练习、互相看别人的提问记录。这种场景对架构的压力和单人本地跑一个模型完全是两码事。单人玩本地大模型你装个 Ollama拉个模型命令行里ollama run一下就能聊爽得很。但一旦人数上到几十上百问题立刻变成三类第一类是并发一百个人不可能排队等你一个一个回答第二类是知识一致性大家问的“课程大纲里第三章讲什么”“这个术语在本课程里怎么定义”答案必须统一不能 A 问出来一个说法、B 问出来另一个说法第三类是成本与可控性你不可能给一百个人每人发一个 API Key 去调云端大模型账单会失控而且课程资料属于内部内容不适合到处传。所以这套架构的核心目标可以浓缩成一句话用一套自托管的大模型推理服务 一套带知识库检索的对话前端撑住百人级别的共学问答同时保证答案有据可查、内容不出内网。关键词里出现的 Open WebUI、Ollama、Svelte、RAG、知识库其实就是这条链路上的五个关键角色。我先把它们的分工讲明白后面再逐个拆。Ollama负责“跑模型”。它把模型权重、推理进程、显存调度这些脏活累活封装成一个本地 HTTP 服务对外暴露一个兼容常见接口规范的端点。你可以把它理解成“模型的操作系统”。Open WebUI负责“给人用”。它是一个网页版对话界面支持多用户、多会话、模型切换、知识库上传前端用 Svelte 构建交互响应快部署也简单。SvelteOpen WebUI 的前端框架。它本身不是你要单独部署的东西但理解它有助于你知道为什么这个界面在百人并发下依然跟手以及二次开发时该往哪改。RAG检索增强生成。简单说就是“先查资料再让模型基于资料回答”而不是让模型凭记忆瞎编。这是保证答案有据可查的关键。知识库RAG 的“资料仓库”。课程讲义、FAQ、术语表、往期答疑记录全都切块、向量化后存进去供检索调用。提示很多人一上来就纠结“用哪个模型最强”但在共学场景里检索质量往往比模型参数更决定体验。模型再强喂给它的资料是错的、缺的答案照样跑偏。我在实际搭这套东西之前踩过的最大误区就是把它当成“装个软件”的活。实际上它更像搭一个小型内部服务有计算资源规划、有网络端口管理、有数据持久化、有权限控制。下面我按真实搭建顺序把每个环节的取舍和坑讲透。2. 为什么选 Ollama 而不是直接上推理框架2.1 自托管推理的三种路线对比在决定用 Ollama 之前我认真对比过三条路线这里直接上表省得你再去一个个试。路线代表方案上手难度多模型管理显存调度适合场景直接调云端 API各类在线大模型服务极低无需管理无需关心个人尝鲜、对数据外发不敏感原生推理框架各类底层推理引擎高需自己写需自己调有专门工程团队、追求极致性能封装型本地服务Ollama低内置自动小团队自托管、快速落地选 Ollama 的核心理由是它把“模型生命周期管理”这件事做掉了。你不需要自己去下载权重文件、转换格式、写加载脚本、处理显存碎片。一条ollama pull就把模型拉下来ollama run就能跑服务化之后还能常驻。对于百人共学这种“不是极致性能、但要稳定可用”的场景这个取舍非常划算。你不是在做一个要压榨每一滴算力的商业产品你是在做一个能让一百个人顺畅提问的学习工具。工程复杂度低意味着出问题时你能快速定位而不是陷在底层框架的报错里。2.2 模型选型的真实考量模型选型这块我的建议是别迷信参数越大越好。百人共学场景里绝大多数问题是概念解释、资料检索、简单推理不需要顶级大模型。真正需要大模型兜底的复杂问题占比很低。我的实际配置是“一大一小”双模型策略主力模型选一个 7B 到 14B 量级、中文能力扎实的通用模型负责日常问答。这个量级在单张消费级显卡上就能跑响应速度可接受。兜底模型留一个更大的模型只在主力模型明显答不好时手动切换或者用于离线批量处理资料。这样做的原因是显存是稀缺资源。如果你把显存全给一个大模型并发一上来就排队如果全给小模型复杂问题答不好。双模型按需切换是性价比最高的折中。注意模型文件动辄几个 GB下载慢是常态。建议提前在有带宽的机器上拉好模型再把模型目录整体拷贝到目标机器比现场下载省几个小时。模型默认存放在用户目录下的隐藏文件夹里迁移时整个目录打包即可。2.3 服务化部署的关键参数Ollama 装好之后默认只监听本机。要让 Open WebUI 容器能访问它必须让它监听所有网卡。这一步是新手最容易卡住的地方。# 让 Ollama 监听所有网卡供容器访问 export OLLAMA_HOST0.0.0.0:11434 # 限制同时加载的模型数量避免显存被多个模型挤爆 export OLLAMA_MAX_LOADED_MODELS2 # 控制单个模型的并行请求数数值越大并发越高但显存占用越大 export OLLAMA_NUM_PARALLEL4 # 模型空闲多久后卸载单位秒设短一点能及时释放显存 export OLLAMA_KEEP_ALIVE300这几个参数里OLLAMA_NUM_PARALLEL是最需要反复调的。它决定了同一个模型能同时处理几个请求。设太小一百个人排队等设太大显存爆掉直接报错。我的经验是从 2 开始观察显存占用和响应延迟逐步往上加找到那个“还没爆但已经够用”的平衡点。OLLAMA_KEEP_ALIVE也值得说一句。默认模型加载后会常驻显存好处是下次请求秒回坏处是显存一直被占着。共学场景有明显的使用波峰波谷课间和晚上是高峰凌晨基本没人。把空闲卸载时间设短一点能让显存在低谷期释放出来给别的用途。3. Open WebUI 的部署与多用户配置3.1 用容器编排把两个服务串起来Ollama 和 Open WebUI 我建议用容器编排工具统一管理好处是网络互通、启动顺序可控、配置集中。下面是我实际在用的编排脚本核心部分做了脱敏处理你可以直接参考结构。services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - 11434:11434 volumes: - ./ollama-data:/root/.ollama environment: - OLLAMA_HOST0.0.0.0:11434 - OLLAMA_MAX_LOADED_MODELS2 - OLLAMA_NUM_PARALLEL4 - OLLAMA_KEEP_ALIVE300 # 如果有显卡这里需要挂载显卡设备具体写法依硬件而定 open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui restart: unless-stopped ports: - 3000:8080 volumes: - ./webui-data:/app/backend/data environment: - OLLAMA_BASE_URLhttp://ollama:11434 - WEBUI_SECRET_KEY换成你自己的随机字符串 depends_on: - ollama这里有几个细节必须强调。第一OLLAMA_BASE_URL用的是服务名ollama而不是localhost因为容器之间通过内部网络通信服务名就是主机名。第二两个服务都挂了数据卷ollama-data存模型webui-data存用户、会话、知识库这两个目录绝对不能丢丢了等于重来。第三WEBUI_SECRET_KEY一定要换成随机字符串它用于会话加密用默认值有安全风险。提示如果你在带图形界面的系统上部署显卡驱动和容器运行时的配置是另一个大坑不同硬件写法差异很大。建议先确认容器能识别到显卡再启动 Ollama否则模型会退化成纯 CPU 推理慢到无法接受。3.2 多用户与权限的实操设置Open WebUI 默认第一个注册的账号是管理员。这一步很关键一定要第一时间注册管理员账号否则后面被别人抢注了你就失去控制权了。管理员登录后在设置里要做几件事关闭公开注册。共学场景是内部使用不能让任何人随便注册进来。改成管理员手动创建账号或者用邀请码机制。设置默认用户角色。普通学员给普通权限能对话、能用知识库但不能改系统设置、不能删别人的会话。配置模型可见性。如果你有多个模型可以控制哪些模型对普通用户可见避免他们误选到不适合的模型。我踩过的一个坑是一开始没关公开注册结果部署到公网测试时被扫到涌进来一堆陌生账号。虽然没造成实质损失但清理起来很烦。部署完第一件事就是关注册这个顺序不能反。3.3 Svelte 前端带来的实际体验差异Open WebUI 的前端用 Svelte 构建这一点在百人并发时体现得很明显。Svelte 的特点是编译时把框架逻辑尽量消解掉运行时开销小所以页面在大量会话列表、长对话历史的情况下依然流畅。这对共学场景的意义在于学员会频繁切换会话、翻看历史记录、对比不同回答。如果前端卡顿体验会断崖式下跌。我实测下来即使一个账号下有几十条会话记录列表滚动和切换都没有明显迟滞。如果你要二次开发比如加一个“课程专属入口”或者“常见问题快捷按钮”改的就是 Svelte 组件。它的语法比很多前端框架都直观变量绑定和响应式声明写起来很顺手。不过对于大多数共学场景原生功能已经够用不建议一上来就改源码维护成本会上去。4. RAG 知识库让答案有据可查的核心环节4.1 RAG 到底在解决什么问题先讲个真实场景。学员问“课程里说的‘向量检索’和‘关键词检索’有什么区别”。如果直接问模型它可能给你一段泛泛而谈的解释甚至把两个概念搞混。但如果课程讲义里明确写过这个对比RAG 的做法是先把问题转成向量去知识库里找出最相关的几段讲义再把这几段讲义连同问题一起喂给模型让模型基于讲义回答。这就是 RAG 的本质把“模型凭记忆回答”变成“模型基于给定资料回答”。前者不可控后者可追溯。关键词里提到的“rag 是什么”“rag 教程”“rag 知识库”说的都是这套机制。而“rag 瓶颈”“rag hit rate”则点出了它的命门检索命中率。如果检索出来的资料和问题不相关模型再强也答不对。所以 RAG 的功夫一大半花在资料处理和检索调优上。4.2 知识库资料的预处理资料预处理是 RAG 里最枯燥但最决定成败的一步。我的经验是分三步走第一步清洗。把课程讲义、FAQ、术语表里的格式噪音去掉。页眉页脚、页码、重复的标题、无关的广告语全部清掉。这些噪音会污染向量让检索结果跑偏。第二步切块。这是最讲究的一步。切太大一块里混了好几个主题检索出来一半有用一半没用切太小上下文不完整模型看不懂。我的经验值是每块 300 到 500 字并且尽量按语义边界切比如按小节、按问答对切而不是机械地按字数切。第三步加元数据。每块资料打上来源标签比如“第三章讲义”“FAQ-检索相关”。这样检索出来之后界面上能显示“答案来自第三章”学员一看就知道依据在哪信任感立刻上来。注意切块大小没有万能值必须结合你的资料特点调。讲义类资料段落长可以切大一点FAQ 类资料一问一答就按问答对切。调完之后一定要用真实问题测检索效果别凭感觉。4.3 检索参数调优与命中率提升Open WebUI 内置了知识库功能上传文档后会自动切块、向量化、建索引。但默认参数不一定适合你的资料需要手动调。关键参数有两个检索返回块数和相似度阈值。返回块数默认可能返回 3 到 5 块。返回太少可能漏掉关键信息返回太多噪音增加还会挤占模型的上下文窗口。我的经验是 4 到 6 块比较稳。相似度阈值低于这个阈值的块不返回。设太高可能什么都检索不到设太低一堆不相关的块混进来。这个值需要根据你的向量模型和资料特点实测。提升命中率的几个实操技巧问题改写。学员的提问往往口语化、有错别字。可以在检索前先用模型把问题改写成更规范的检索语句命中率会明显提升。混合检索。纯向量检索对语义相似但用词不同的情况好纯关键词检索对专有名词准。两者结合效果更稳。定期补充资料。共学过程中学员问的新问题、给出的好答案定期整理进知识库知识库会越用越准。关键词里提到的“agentic rag”“graphrag”“ontology rag”都是 RAG 的进阶形态核心思路是让检索过程更智能、更结构化。但对于百人共学这种场景把基础 RAG 做扎实比追新概念重要得多。基础没打好上再花哨的框架也是空中楼阁。4.4 知识库与对话的联动配置在 Open WebUI 里知识库和对话的联动是这样工作的你创建一个知识库上传资料然后在对话界面选择“使用这个知识库”。之后每次提问系统都会先去知识库检索再把结果拼进提示词。这里有个容易忽略的点不同课程模块建议建不同的知识库。比如“基础概念”“实操案例”“常见问题”分开建。这样学员提问时能精准选择对应的知识库检索范围小命中率自然高。如果全塞一个大知识库里检索范围太大噪音就多。另外知识库的更新不是实时的。你上传新资料后需要等系统完成向量化才能生效。资料多的时候这个过程可能要几分钟别急着测试等处理完再问。5. 百人并发下的性能与稳定性实战5.1 并发压力的真实来源很多人以为并发压力来自“一百个人同时提问”。实际上真实压力分布是这样的同时在线可能有一百人但大部分在阅读、思考、看别人的问答。同时提问峰值可能就十几个人。同时触发检索提问的人里用了知识库的会触发检索这是额外的计算开销。所以真正的瓶颈往往不是模型推理而是检索环节和上下文拼接。尤其是知识库资料多、返回块数大的时候每次提问都要做向量检索和大量文本拼接这部分开销不容忽视。我的应对策略是把检索和推理的资源分开考虑。检索是 CPU 和内存密集型推理是显存密集型。如果部署在同一台机器上要留足 CPU 和内存给检索别让推理把资源吃光。5.2 响应延迟的优化手段延迟优化我做了几件事效果从大到小排列模型量化。用 4 位量化版本的模型显存占用大幅下降速度明显提升质量损失在共学场景里几乎感知不到。这是性价比最高的一招。限制上下文长度。共学问答不需要超长上下文把模型的上下文窗口设小一点推理速度会快很多。知识库检索结果精简。返回块数从 6 降到 4拼接的文本少了推理输入短了整体延迟下降。会话历史截断。长对话会拖慢推理设置只保留最近若干轮历史老对话不参与推理。这几招组合下来我实测的响应时间从最初的十几秒降到了几秒体验完全不一样。5.3 稳定性保障与故障排查稳定性这块我总结了几个必须做的动作设置重启策略。容器编排里配restart: unless-stopped服务崩了自动拉起。监控显存占用。显存爆掉是本地推理最常见的故障。定期看显存曲线发现持续高位就要调低并行数或换小模型。日志集中查看。Ollama 和 Open WebUI 的日志都要能方便地看到出问题时第一时间定位是推理层还是应用层。定期备份数据卷。用户、会话、知识库都在数据卷里定期备份出事了能快速恢复。我遇到过一次典型故障某天下午突然所有人都问不出答案界面一直转圈。排查发现是显存被占满Ollama 无法加载模型。原因是上午有人手动切换了一个大模型加载后没释放下午并发一上来就爆了。解决办法就是前面说的把OLLAMA_KEEP_ALIVE设短让空闲模型及时卸载。提示故障排查的顺序建议是“先看容器状态再看服务日志最后看资源占用”。大部分问题在前两步就能定位不用一上来就怀疑模型本身。6. 这套架构跑起来之后我的一些真实体会架构搭完、跑顺之后回头看有几个判断和当初的预期不太一样值得分享。第一知识库的质量比模型的选择更影响满意度。我一开始花了很多时间对比模型后来发现学员的抱怨主要集中在“答非所问”而根源是知识库资料没整理好、切块不合理。把资料重新清洗切块之后同样的模型满意度明显上升。第二百人场景下简单可靠比先进重要。我一度想上更复杂的检索方案后来忍住了。基础 RAG 加合理的资料处理已经能满足绝大多数需求。复杂方案带来的维护成本和故障点在共学这种非专业运维场景里是负担。第三给学员的引导很重要。再好的架构如果学员不知道怎么问效果也打折。我在界面上加了几个示例问题引导大家用“具体、带上下文”的方式提问检索命中率和回答质量都上去了。第四留出扩展余地。这套架构后续可以接更多东西比如把常见问答沉淀成独立知识库、接入更多模型做对比、增加使用统计看哪些问题问得最多。但扩展的前提是基础稳别在基础没跑顺的时候急着加功能。最后分享一个我反复验证过的小技巧每次调整知识库或模型参数后用同一组固定问题做回归测试。这组问题覆盖概念解释、资料检索、多轮追问等典型场景。改完参数跑一遍对比回答质量比凭感觉判断靠谱得多。这组测试问题本身也可以沉淀进知识库一举两得。