纯前端大模型工作台：零后端本地优先，统一接入DeepSeek与Ollama

1. 为什么我会盯上这个纯前端大模型工作台第一次看到 lab 这个项目标题的时候我正在给自己折腾一套本地模型调用环境。说实话那段时间我试过太多方案命令行里敲ollama run、浏览器里开三四个标签页分别对着 DeepSeek、Qwen、Claude 的网页版、再装一堆客户端软件。每个工具都只解决一小块问题模型之间切换要重新登录、重新贴上下文历史对话散落在各个平台里想找上周调试的一段 prompt 得翻半天。所以当我看到 纯前端、零后端、本地优先 这三个词组合在一起第一反应是这东西如果真能做到那它解决的正是我这种人的核心痛点。所谓纯前端意思是整个应用就是一堆静态的 HTML、CSS、JavaScript 文件你把它丢到任何静态托管上或者干脆双击本地文件打开它就能跑零后端意味着没有服务器帮你转发请求、没有数据库存你的对话、没有账号体系本地优先则是说你的 API Key、对话记录、模型配置全部存在浏览器自己的存储里不上传任何地方。这套设计思路对谁有用我梳理了一下大概三类人最需要一是像我这样同时用多个模型服务、需要频繁对比输出的开发者二是对数据隐私敏感、不愿意把对话内容经过第三方服务器的用户三是想学习大模型 API 调用原理、希望有一个干净可读的参考实现的前端工程师。这个 lab 工作台把 DeepSeek、Qwen、Ollama 本地模型、Claude 这几类主流接入方式都覆盖了等于给你一个统一的操作台背后对接哪家模型由你自己配。我花了几个晚上把这个项目从源码到部署完整跑了一遍也踩了不少坑下面把我理解的设计逻辑、实操细节和排查经验完整分享出来。需要提前说明的是文中涉及的具体参数和步骤一部分来自项目本身的设定一部分是我基于常见前端工程实践做的合理补充你实际使用时以项目最新文档为准。2. 整体架构设计与技术选型拆解2.1 纯前端方案到底怎么绕开后端很多人第一次听到纯前端调用大模型 API会疑惑浏览器直接请求模型服务商的接口不会遇到跨域问题吗这确实是核心难点。传统做法是搭一个后端做代理转发但 lab 选择了另一条路。关键点在于主流大模型服务商的 API 大多支持CORS跨域资源共享或者提供了浏览器可直接调用的接口。DeepSeek 的开放平台接口、Claude 的 API 都允许从浏览器发起请求只要你在请求头里正确带上鉴权信息。Ollama 更特殊它本身就跑在你本机默认http://localhost:11434浏览器访问本机端口不存在跨域障碍只需要在 Ollama 启动时配置允许的来源即可。那零后端具体省掉了什么我列个对比表更直观维度传统带后端方案lab 纯前端方案部署成本需要服务器、需要维护进程静态文件丢哪都能跑数据流向对话经服务器中转浏览器直连模型服务隐私风险服务器可能记录日志数据不出浏览器鉴权存储服务端数据库浏览器 localStorage/IndexedDB扩展难度改后端要重新部署改前端刷新即可离线能力依赖服务器在线静态资源可离线模型调用看服务这个取舍的本质是把复杂度从运维侧转移到了浏览器侧。你不需要懂服务器、不需要买云主机、不需要配 Nginx 反向代理代价是你要接受 API Key 存在浏览器里这个事实。对于个人使用场景这个代价完全可以接受如果是团队协作、需要共享对话历史那纯前端方案就不太合适了。2.2 本地优先的存储设计思路本地优先这个词这两年很火但落到实现上lab 的做法其实很朴素所有状态都存在浏览器里。具体分几块API Key 与模型配置存在localStorage键名通常按服务商区分比如lab.config.deepseek、lab.config.ollama。这样刷新页面配置不丢但换浏览器、换设备就要重新填。对话历史数据量大一般用IndexedDB存因为 localStorage 有 5MB 左右的容量上限存几十轮长对话很容易爆。IndexedDB 能存几百 MB 甚至更多适合放消息列表。界面偏好主题、字号、侧边栏折叠状态这类用 localStorage 就够了。为什么这么设计因为纯前端没有服务端可以做会话管理浏览器存储就是唯一的持久化手段。这里有个经验不要把 API Key 和对话历史混在同一个存储里。Key 是敏感信息你可能想定期清理对话历史是资产你希望长期保留。分开存清理时互不影响。提示浏览器隐私模式无痕窗口下localStorage 和 IndexedDB 在关闭窗口后会被清空。如果你在无痕模式里配好了 Key关掉就没了别以为是 bug。2.3 多模型接入的抽象层怎么设计lab 要同时对接 DeepSeek、Qwen、Ollama、Claude这四家的接口协议并不完全一样。DeepSeek 和 Qwen 都兼容 OpenAI 的 Chat Completions 格式Claude 有自己的 Messages API 格式Ollama 又是另一套本地接口。如果每个都写一遍调用逻辑代码会非常臃肿。合理的做法是抽一层Provider 适配器。每个服务商实现一个统一的接口比如都提供chat(messages, options)方法内部各自处理请求格式转换、鉴权头拼接、流式响应解析。上层 UI 只跟这个统一接口打交道新增一个模型服务只需要加一个适配器文件。这个设计的好处在我实际改代码时体现得很明显我想给某个服务加个自定义请求头只需要改对应的适配器不用动 UI 层。反过来我想调整对话界面的交互也完全不用管底层是哪家模型。2.4 流式输出为什么是刚需大模型生成一段几百字的回复可能要十几秒如果等全部生成完再显示用户体验会很差。所以 lab 必然支持SSEServer-Sent Events流式输出也就是模型一边生成、前端一边渲染字一个个蹦出来。流式解析的坑不少。OpenAI 格式的流式响应是一行行data: {...}的文本最后以data: [DONE]结束Claude 的事件格式又不一样有content_block_delta这类事件类型。前端要用fetch拿到ReadableStream再用TextDecoder逐块解码按行切分遇到不完整的 JSON 要缓存起来等下一块拼上。这块逻辑如果写得不严谨就会出现回复显示到一半卡住或者JSON 解析报错的问题。3. 核心功能模块与实操配置要点3.1 DeepSeek 接入的完整配置流程DeepSeek 是当前热度最高的接入目标之一我重点说下配置细节。你需要先去 DeepSeek 开放平台申请一个 API Key这个 Key 只在创建时显示一次务必当场复制保存。拿到 Key 之后在 lab 的模型配置界面填三样东西Base URLDeepSeek 的接口地址通常是https://api.deepseek.com注意有些版本要求带/v1后缀具体看项目文档。API Key粘贴你申请到的 Key格式一般是sk-开头的一长串。模型名称DeepSeek 提供deepseek-chat通用对话和deepseek-reasoner推理模型等按需选择。配置完点测试连接如果返回正常就说明通了。这里有个我踩过的坑Base URL 末尾的斜杠。有的实现拼接路径时是baseURL /chat/completions如果你填的 baseURL 末尾带了斜杠就会变成//chat/completions部分服务端会返回 404。建议填的时候不要带尾部斜杠。关于推理模型的思考模式有个细节值得单独说。DeepSeek 的推理模型会返回reasoning_content字段也就是模型的思考过程。在多轮对话里如果你把上一轮的思考内容也塞回请求某些接口会报 400 错误提示思考模式下的reasoning_content必须正确回传或剥离。lab 这类工作台一般会在适配器里处理这个逻辑要么把思考内容单独展示、不参与后续上下文要么按接口要求原样回传。你如果自己改代码这块要特别小心。3.2 Ollama 本地模型的对接要点Ollama 是本地部署大模型最省心的工具之一lab 对接它有几个关键点。首先是 Ollama 服务本身要跑起来默认监听11434端口。然后关键一步是配置OLLAMA_ORIGINS因为浏览器从http://localhost:某端口访问http://localhost:11434也算跨域Ollama 默认只允许特定来源。你需要设置环境变量允许你的前端来源比如允许所有本地来源。这一步不做浏览器控制台会直接报 CORS 错误请求根本发不出去。其次是模型名称。Ollama 的模型名就是你ollama pull下来的名字比如qwen2.5:7b、deepseek-r1:8b。填的时候要跟ollama list显示的一致包括 tag 部分。再就是性能预期。本地模型跑得快不快完全取决于你的硬件。7B 参数的模型在普通消费级显卡上能跑到每秒几十个 token但如果是 32B 以上的模型没有足够显存就会非常慢甚至跑不动。我建议先用小模型验证链路通了再逐步换大模型。本地模型规模大致显存需求适用硬件7B6-8GB主流独显14B12-16GB中高端独显32B24GB高端独显70B48GB多卡或专业卡3.3 Claude 与 Qwen 的差异化处理Claude 的接口跟 OpenAI 格式差别较大主要体现在鉴权用x-api-key头而不是Authorization: Bearer请求体里messages的角色和结构有自己的规范还必须带anthropic-version头声明 API 版本。lab 的适配器会把这些差异封装掉你配置时只需要填 Key 和模型名如claude-3-5-sonnet之类。Qwen 这边如果你用的是阿里云百炼平台的接口它兼容 OpenAI 格式配置方式跟 DeepSeek 类似Base URL 换成对应平台的地址即可。如果你用的是本地部署的 Qwen通过 Ollama 或 vLLM那就走本地接口那套逻辑。这里有个通用经验不同服务商的模型名不要混用。你在 DeepSeek 配置里填了claude-3-5-sonnet请求发过去只会得到模型不存在的错误。每个 Provider 的模型列表是独立的配置时看清楚当前在哪个 Provider 下。3.4 对话上下文与系统提示词管理lab 作为工作台对话管理是核心体验。几个我实际用下来觉得重要的点系统提示词System Prompt决定了模型的角色和行为。你可以给不同的对话预设不同的系统提示比如你是一个严谨的代码审查员或者用通俗语言解释技术概念。建议把常用的系统提示存成模板切换对话时一键套用省得每次重打。上下文长度控制是个容易被忽视的问题。多轮对话越聊越长最终会超出模型的上下文窗口。lab 一般会提供几种策略保留最近 N 轮、按 token 数截断、或者做摘要压缩。我个人的习惯是保留最近 10 到 20 轮太早的内容对当前对话帮助不大反而占 token 还费钱。对话导出功能对开发者很实用。把一段调试好的对话导出成 JSON 或 Markdown既能存档也能作为 few-shot 示例喂给其他模型。导出格式建议包含角色、内容、时间戳方便后续处理。4. 从零跑起来的完整实操过程4.1 获取源码与本地启动第一步是把项目源码拿到本地。如果你用 Git直接克隆仓库如果只是想要静态文件下载压缩包解压也行。目录结构一般是标准的现代前端工程有package.json、源码在src目录、构建产物在dist。启动方式取决于项目用的是哪套工具链。如果是 Vite 这类通常两条命令npm install npm run dev跑起来后浏览器会打开一个本地地址比如http://localhost:5173。这时候你看到的就是 lab 的界面。如果项目提供了构建命令npm run build构建出来的dist目录就是纯静态文件可以直接丢到任何静态托管服务上或者用npx serve dist在本地起个静态服务器预览。注意直接双击index.html用file://协议打开很多现代前端项目会失效因为模块加载和路由依赖 HTTP 协议。老老实实用本地服务器跑。4.2 配置第一个模型并验证链路界面起来后先别急着配一堆模型挑一个最顺手的验证链路。我建议先用 DeepSeek因为它的接口标准、文档清晰、出错信息也友好。进入设置页找到模型配置区域新增一个 DeepSeek 配置填入 Base URL、API Key、模型名。保存后回到对话界面发一句你好测试。如果能看到流式回复一个字一个字出来说明整条链路通了前端发起请求、鉴权通过、服务端返回流、前端解析渲染。如果没通打开浏览器开发者工具看 Network 面板里那条请求的状态码和响应体。401 是 Key 不对404 是 URL 拼错400 多半是请求体格式问题CORS 错误则会在 Console 面板明确提示。这一步的排查思路我后面会详细展开。4.3 接入本地 Ollama 模型本地模型的价值在于完全离线、零成本、数据不出本机。配置步骤确认 Ollama 已安装并运行终端执行ollama list能看到已下载的模型。设置允许浏览器访问的来源重启 Ollama 服务。在 lab 里新增 Ollama 配置Base URL 填http://localhost:11434模型名填ollama list里显示的名字。发消息测试第一次调用可能会慢因为模型要加载进显存。我实测下来本地模型首次响应慢是正常的加载完之后的连续对话会快很多。如果你发现一直很慢检查是不是模型太大、显存不够导致部分层跑在 CPU 上。4.4 多模型对比的实用工作流lab 这类工作台最大的价值是让你能快速对比不同模型的输出。我的工作流是这样的同一个问题先在 DeepSeek 上问一遍再切到本地 Qwen 问一遍把两个回答并排看。对于代码类问题我还会再让 Claude 给一版三家对比下来往往能发现各自的盲区。具体操作上建议给每个模型开独立的对话标签页而不是在同一个对话里切换模型。因为不同模型的上下文处理方式不同混在一起容易乱。lab 如果支持多标签或分屏一定要用起来。5. 常见问题排查与避坑经验实录5.1 请求失败类问题速查我把实际遇到和社区里高频出现的问题整理成一张表方便你对号入座现象可能原因排查方向401 UnauthorizedAPI Key 错误或过期重新复制 Key检查有无多余空格404 Not FoundBase URL 拼写错误检查路径、尾部斜杠、/v1后缀400 Bad Request请求体格式不符检查模型名、消息结构、思考内容回传CORS 错误服务端未允许浏览器来源本地模型需配 OLLAMA_ORIGINS回复卡住不动流式解析异常看 Network 里流是否中断检查 JSON 拼接模型不存在模型名填错对照服务商文档或ollama list响应极慢本地模型太大/显存不足换小模型或检查硬件占用5.2 流式输出中断的排查思路流式输出中断是我遇到最多的问题表现是回复显示到一半突然停住或者干脆一个字都不出。排查分几步先看 Network 面板里那条请求如果是pending状态一直不结束说明服务端还在生成或者连接卡住了如果状态变成200但内容不完整多半是前端解析逻辑的问题。重点检查TextDecoder的使用流式数据是按字节块来的一个中文字符可能被切成两个块如果每个块单独解码就会乱码。正确做法是用{ stream: true }参数让解码器缓存不完整的多字节字符。另一个常见原因是 JSON 按行切分时最后一行可能是不完整的。比如收到data: {cho就切了解析必然失败。稳妥的做法是维护一个缓冲区每次拿到新数据先拼到缓冲区按换行符切分最后一段不完整的留在缓冲区等下次。5.3 API Key 安全与存储的取舍纯前端方案把 Key 存在浏览器里这确实有安全考量。我的建议是不要用主账号的 Key给 lab 单独申请一个设置好额度上限。定期轮换 Key尤其是发现异常调用量时。不要在公共电脑上配置 Key用完记得清理浏览器存储。如果项目支持优先用环境变量注入的方式而不是硬编码。需要清醒认识到任何存在浏览器里的密钥理论上都能被同一台机器上的其他程序读取。纯前端方案的定位是个人可信设备使用不是企业级安全方案。5.4 我踩过的几个真实坑说几个文档里不会写、但我实际撞上的问题。第一个是浏览器缓存导致的配置不生效。我改了模型配置保存后界面还是用旧配置发请求。后来发现是 Service Worker 缓存了旧代码强制刷新CtrlShiftR或者清掉缓存才正常。如果你改了代码没生效先怀疑缓存。第二个是本地模型和远程模型混用时的超时设置。远程 API 一般几秒内响应本地大模型可能要几十秒。如果前端设了统一的短超时本地模型请求会被提前掐断。建议给本地模型单独放宽超时。第三个是对话历史过大导致页面卡顿。我有个对话聊了几百轮每次打开那个标签页浏览器都要卡一下因为要一次性渲染所有消息。解决办法是虚拟滚动或者分页加载只渲染可视区域的消息。第四个是不同 Provider 的错误信息格式不统一。有的返回{error: {message: ...}}有的返回纯文本前端如果不做兼容处理错误提示就会显示成[object Object]。写适配器时记得把错误信息统一提取出来。6. 二次开发与扩展方向6.1 新增一个模型服务需要改哪里如果你想给 lab 加一个新的模型服务按适配器模式大致需要动这几个地方新建一个适配器文件实现统一的chat接口处理该服务的请求格式和鉴权在 Provider 注册表里登记这个新服务在配置界面加上对应的表单字段。如果新服务兼容 OpenAI 格式那更简单直接复用现有的 OpenAI 适配器只改 Base URL 和默认模型名就行。6.2 提示词模板与工作流自动化lab 作为工作台往上可以做很多提效的事。比如把常用的提示词存成模板库按场景分类再比如做链式调用把上一个模型的输出自动作为下一个模型的输入实现多步推理。这些扩展都不需要后端纯前端就能实现数据也都在本地。6.3 数据备份与迁移本地优先的代价是数据绑在浏览器上。换设备、清缓存都可能丢数据。建议定期用导出功能把重要对话和配置备份成文件。如果 lab 支持导入导出全部数据那就更省心。我个人的习惯是每周导出一次存到自己的笔记系统里。最后分享一个我自己的使用心得这类纯前端工作台最适合当模型试验田。你可以在里面随便试各种 prompt、对比各家模型不用担心数据外泄也不用为每次试验付费本地模型。等某个 prompt 调好了再拿到正式项目里用。这种本地试验、线上落地的节奏是我用下来觉得最舒服的方式。