1. 项目概述：一个开源的ChatGPT Web应用

最近在GitHub上看到一个挺火的项目，叫 chatgpt-web-dev/chatgpt-web 。简单来说，这就是一个让你能自己搭建一个类似ChatGPT官方网页版聊天界面的开源项目。它不是官方出品，而是一个由社区开发者维护的、基于OpenAI API的Web应用。如果你觉得官方的ChatGPT Plus订阅太贵，或者想拥有一个更私密、可定制、甚至能集成自己公司知识库的AI对话平台，那么这个项目就提供了一个非常棒的起点。

这个项目的核心价值在于“自主可控”。它把调用OpenAI API（或者兼容API，如Azure OpenAI、Ollama等）的能力，封装成了一个拥有友好用户界面的Web应用。这意味着，你不再需要每次都去OpenAI的Playground写代码测试，也不需要依赖任何第三方可能不稳定的客户端。你可以把它部署在自己的服务器、NAS，甚至是家里的树莓派上，完全掌握自己的对话数据和应用体验。对于开发者、技术爱好者，或者有特定企业应用需求的小团队来说，这无疑是一个极具吸引力的选择。

2. 核心架构与技术栈拆解

要理解这个项目，我们得先把它拆开看看里面到底用了哪些“零件”。一个典型的 chatgpt-web 类项目，其架构通常分为前端和后端两大部分，通过API进行通信。

2.1 前端技术选型：React与现代化工具链

目前主流的 chatgpt-web 项目，前端大多采用 React 框架构建。React以其组件化、声明式UI和庞大的生态，成为构建复杂单页面应用（SPA）的首选。项目通常会搭配 TypeScript ，为JavaScript加上强类型，这在大中型项目中能显著提升代码的可维护性和开发体验，减少运行时错误。

状态管理方面，可能会使用 Zustand 或 Redux Toolkit 这类轻量级方案来管理全局的对话列表、用户设置等状态。UI组件库则常见 Ant Design 、 MUI (Material-UI) 或 Tailwind CSS ，它们提供了丰富的预制组件和现代化的设计语言，能快速搭建出美观、一致的界面，让开发者更专注于业务逻辑而非样式细节。

构建工具链则离不开 Vite 。相比于传统的Webpack，Vite在开发阶段提供了极快的热更新（HMR）速度，能大幅提升开发效率。它使用原生ES模块，启动服务几乎是瞬间完成，这对于需要频繁修改和预览的UI开发来说，体验提升是巨大的。

2.2 后端技术栈：Node.js与Fastify/Express

后端是项目的“大脑”，负责处理业务逻辑、与AI模型API通信以及数据持久化。 Node.js 凭借其非阻塞I/O和高并发特性，非常适合处理大量并发的API请求，尤其是像聊天这种需要保持连接（如SSE）的场景。

Web框架的选择上， Fastify 是一个高性能的后起之秀，它的核心优势就是快，号称是Node.js领域最快的Web框架之一。它的插件架构清晰，对JSON Schema的原生支持使得API输入验证变得非常优雅和高效。当然，传统的 Express 框架凭借其极简的设计和庞大的中间件生态，依然是一个可靠且流行的选择，许多项目也会基于它进行开发。

与数据库的交互，ORM（对象关系映射）工具如 Prisma 或 TypeORM 被广泛使用。它们允许开发者用TypeScript（或JavaScript）对象的方式来操作数据库，自动生成类型安全的查询，避免了手写原始SQL字符串的繁琐和潜在错误。数据库本身，对于轻量级部署， SQLite 是绝佳选择，它无需单独安装数据库服务，一个文件搞定所有；对于需要更高并发和更复杂查询的生产环境， PostgreSQL 或 MySQL 则是更强大的选择。

2.3 通信与实时性：SSE与WebSocket的抉择

聊天应用的核心体验之一是“流式响应”，即AI的回答不是一次性返回，而是一个字一个字地“流”出来。这能极大地提升用户的感知速度和交互自然度。实现流式响应，主要有两种技术： SSE (Server-Sent Events) 和 WebSocket 。

  • SSE ：它是一种允许服务器主动向客户端推送数据的技术，但连接是单向的（服务器到客户端）。对于聊天这种“客户端发送一条消息，服务器流式返回一条回答”的典型场景，SSE完全够用。它的优点是协议简单，基于HTTP，兼容性好，在浏览器端使用 EventSource API即可轻松接入。 chatgpt-web 项目大多采用SSE来实现流式输出。
  • WebSocket ：提供了全双工通信通道，适合需要高频、双向实时数据交换的场景，如在线游戏、协同编辑。对于基础的AI对话来说，用它有点“杀鸡用牛刀”，会引入不必要的复杂性。

因此，在 chatgpt-web 中，你会看到后端通过调用OpenAI的流式API，然后将接收到的数据块通过SSE连接源源不断地推送给前端，前端再将其逐步渲染到聊天界面上。

注意：OpenAI的API密钥等敏感信息，绝对不应该硬编码在前端代码或直接暴露给浏览器。后端的一个重要职责就是作为“代理”，前端只与自己的后端通信，由后端携带密钥去调用OpenAI API。这样既保护了密钥安全，也便于在后端实现速率限制、请求日志、费用监控等高级功能。

3. 核心功能模块深度解析

一个完整的 chatgpt-web 应用，远不止一个简单的输入框和回复区域。它包含了一系列提升用户体验和实用性的功能模块。

3.1 对话管理与上下文保持

这是最核心的功能。系统需要维护一个“会话”（Conversation）的概念。每个会话包含一个对话列表，其中每条消息都需要标明角色（ user , assistant , system ）和内容。

上下文保持 是难点。OpenAI的API本身是无状态的，它并不记得你之前说过什么。因此，每次发送新消息时，后端都需要将本次消息连同之前一定轮次的历史对话（即“上下文”），一起组装成一个消息数组发送给API。这个历史窗口的长度是有限的（由模型的最大Token数决定，例如gpt-3.5-turbo通常是4096个tokens）。如何高效、准确地管理这个上下文窗口，是后端逻辑的关键。

常见的策略是“滑动窗口”：只保留最近N条对话，或者当累计的tokens数接近上限时，从最旧的消息开始逐步丢弃。更高级的实现可能会对历史对话进行总结压缩，将一大段历史浓缩成一条 system 提示，从而为新的对话腾出空间。这部分逻辑直接影响了AI能否进行长篇幅、连贯的对话。

3.2 模型参数与角色预设

用户需要能够调整AI的“性格”和“行为”。这主要通过两类设置实现：

  1. 模型参数 ：前端需要提供界面让用户调节这些关键参数：

    • Temperature（温度） ：控制输出的随机性。值越低（如0.2），输出越确定、保守；值越高（如0.8），输出越有创意、不可预测。
    • Max Tokens（最大生成长度） ：限制单次回复的最大长度，防止AI“话痨”产生过高费用。
    • Top_p（核采样） ：与Temperature类似，另一种控制随机性的方式，通常二者选一调节。
    • Presence/Frequency Penalty（存在/频率惩罚） ：用于降低重复词汇出现的概率，使回答更多样。

  2. 角色预设（Prompt Templates） ：这是提升效率的利器。用户可以创建和保存不同的“角色”，比如“代码专家”、“创意写手”、“英文学术润色”。每个角色背后其实是一段预定义的 system 提示词。当用户选择某个角色时，这段提示词会被自动插入到对话上下文的开头，从而无需每次手动输入“请你扮演一个...”。后端需要设计相应的数据表来存储和管理这些用户自定义的预设。

3.3 数据持久化与用户系统

如果希望对话记录不丢失，就需要引入数据库。基本的数据模型包括：

  • 用户表 ：存储用户名、加密后的密码哈希、邮箱等。
  • 会话表 ：关联用户，存储会话标题（通常自动从第一条消息生成）、使用的模型、创建时间等。
  • 消息表 ：关联会话，存储每条消息的角色、内容、Token消耗、时间戳。

用户系统不仅提供了数据隔离（A用户看不到B的对话），也为未来扩展付费、额度管理等功能奠定了基础。身份认证通常采用 JWT (JSON Web Token) 。用户登录后，后端生成一个有时效的Token返回给前端，前端在后续请求的HTTP Header（如 Authorization: Bearer <token> ）中携带此Token，后端验证Token有效性后处理请求。

3.4 管理后台与监控

对于一个严肃的自用或团队使用的部署，一个简单的管理后台是必要的。它可能包含以下功能：

  • 用户管理 ：查看用户列表、调整用户额度（如每月可用Token数）、禁用/启用账户。
  • 令牌消耗统计 ：以图表形式展示全局或单个用户的Token消耗趋势，关联费用估算（因为OpenAI API按Token收费）。
  • 对话日志审计 ：出于安全或合规考虑，管理员可能需要查看历史对话记录（此功能需谨慎设计权限并告知用户）。
  • 系统配置 ：动态修改系统级的API密钥、默认模型参数等，而无需重启服务。

这些功能使得项目从一个“玩具”升级为一个可运维的“工具”。

4. 从零开始部署与配置实操指南

假设我们选择了一个功能相对完整的 chatgpt-web 项目进行部署。以下是一个基于典型技术栈（React + Node.js + PostgreSQL）的实操流程。

4.1 环境准备与依赖安装

首先，确保你的服务器或本地开发环境已经安装：

  • Node.js ：版本建议在18.x或20.x LTS以上。可以去Node.js官网下载安装包，或者使用 nvm （Node Version Manager）来管理多个版本。
  • PNPM ：推荐使用 pnpm 作为包管理器，它比npm和yarn更快，磁盘空间利用更高效。可以通过 npm install -g pnpm 全局安装。
  • Git ：用于克隆项目代码。
  • 数据库 ：这里以PostgreSQL为例。你可以选择安装在本机，也可以使用云数据库服务（如Supabase、Aiven）。本地安装后，需要创建一个新的数据库，例如命名为 chatgpt_web 。
# 示例：在Ubuntu上安装PostgreSQL
sudo apt update
sudo apt install postgresql postgresql-contrib
sudo -u postgres psql
# 进入psql命令行后，创建数据库和用户
CREATE DATABASE chatgpt_web;
CREATE USER app_user WITH ENCRYPTED PASSWORD 'your_strong_password';
GRANT ALL PRIVILEGES ON DATABASE chatgpt_web TO app_user;
\q

4.2 后端服务配置与启动

  1. 克隆项目与安装依赖 ：

    git clone https://github.com/your-chosen/chatgpt-web.git
cd chatgpt-web/server
pnpm install

  2. 环境变量配置 ：后端的所有机密和配置都通过环境变量管理。在项目根目录创建 .env 文件。

    # 数据库连接
DATABASE_URL="postgresql://app_user:your_strong_password@localhost:5432/chatgpt_web?schema=public"
# OpenAI API配置
OPENAI_API_KEY="sk-your-openai-api-key-here"
OPENAI_API_BASE="https://api.openai.com/v1" # 如果你用Azure OpenAI或第三方代理，需要修改此处
OPENAI_API_MODEL="gpt-3.5-turbo"
# JWT密钥，用于加密Token，务必使用强随机字符串
JWT_SECRET="your-super-secret-jwt-key-change-this"
# 服务端口
PORT=3001
# 跨域设置（前端地址）
CORS_ORIGIN="http://localhost:3000"

    警告： .env 文件必须加入 .gitignore ，切勿提交到代码仓库。 JWT_SECRET 和 OPENAI_API_KEY 是最高机密。

  3. 数据库迁移 ：如果项目使用Prisma，运行以下命令来创建数据库表结构。

    npx prisma migrate dev --name init
# 或者根据项目文档，可能是
# pnpm run db:push
# pnpm run db:migrate

  4. 启动后端服务 ：

    pnpm run dev # 开发模式，带热重载
# 或
pnpm start   # 生产模式

    如果看到 Server is running on port 3001 之类的日志，说明后端启动成功。

4.3 前端应用构建与运行

  1. 进入前端目录并安装依赖 ：

    cd ../client # 假设前端代码在client目录
pnpm install

  2. 配置前端环境 ：前端通常也需要一个配置文件，来指定后端API的地址。可能是 .env.development 或 vite.config.ts 中的代理设置。

    # .env.development
VITE_API_BASE_URL=http://localhost:3001/api

  3. 启动前端开发服务器 ：

    pnpm run dev

    Vite会启动一个本地服务器，通常在 http://localhost:3000 。打开浏览器访问此地址，你应该能看到聊天界面。

  4. 构建生产版本 ：用于部署到生产环境。

    pnpm run build

    构建产物会生成在 dist 目录下，你可以将其部署到Nginx、Apache等静态文件服务器，或Vercel、Netlify等云平台。

4.4 使用Nginx进行生产环境部署

对于生产环境，我们通常会用Nginx作为反向代理和静态文件服务器。

  1. 安装Nginx ：

    sudo apt install nginx

  2. 配置Nginx ：编辑站点配置文件，例如 /etc/nginx/sites-available/chatgpt 。

    server {
    listen 80;
    server_name your-domain.com; # 你的域名或IP

    # 前端静态文件
    location / {
        root /path/to/your/chatgpt-web/client/dist;
        index index.html;
        try_files $uri $uri/ /index.html; # 支持前端路由
    }

    # 反向代理到后端API服务
    location /api/ {
        proxy_pass http://localhost:3001/; # 后端服务地址
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
        # 如果后端是SSE，需要以下配置
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 86400s; # SSE长连接超时时间
    }
}

  3. 启用配置并重启Nginx ：

    sudo ln -s /etc/nginx/sites-available/chatgpt /etc/nginx/sites-enabled/
sudo nginx -t # 测试配置语法
sudo systemctl restart nginx

  4. 使用PM2管理Node.js进程 ：确保后端服务在后台稳定运行。

    cd /path/to/your/chatgpt-web/server
pnpm install -g pm2
pm2 start ecosystem.config.js # 或 pm2 start npm --name "chatgpt-api" -- run start
pm2 save
pm2 startup # 设置开机自启

至此，一个基础的生产环境就部署完成了。通过域名或服务器IP，你就能访问属于自己的ChatGPT Web应用了。

5. 高级配置与功能扩展思路

基础功能跑通后，你可以根据需求进行深度定制和扩展。

5.1 集成多种AI模型后端

项目的强大之处在于其可扩展性。除了官方的OpenAI API，你可以通过修改后端的API调用逻辑，轻松接入其他兼容OpenAI API格式的服务。

  • Azure OpenAI ：微软云提供的OpenAI服务，合规性更好。只需将 OPENAI_API_BASE 指向你的Azure端点，并在API Key和请求头中做相应调整。
  • Ollama ：在本地运行Llama 2、Mistral等开源大模型的神器。它提供了与OpenAI兼容的API接口。将 OPENAI_API_BASE 改为 http://localhost:11434/v1 ，并使用任意非空字符串作为API Key即可。这样，你就可以完全免费、离线地使用这个Web界面与本地模型对话。
  • 其他第三方代理或API ：一些国内外的服务商也提供了兼容OpenAI的API网关，可以用于解决网络访问问题或获取不同的模型。

5.2 实现流式打字机效果与消息渲染

前端的流式渲染体验是关键。当后端通过SSE推送来一个数据块（chunk）时，前端需要将其追加到当前助手消息的末尾。

一个健壮的实现需要考虑：

  • 消息状态管理 ：当前会话中，需要区分“已完整接收的消息”和“正在接收中的消息”。通常会在状态中维护一个 pendingMessage 或 streamingMessage 。
  • 自动滚动 ：当新内容不断追加时，聊天容器应自动滚动到底部。可以使用 useRef 钩子获取容器DOM，并在每次内容更新后调用 scrollIntoView 。
  • Markdown渲染 ：AI的回答通常包含Markdown格式（代码块、列表、加粗等）。前端需要使用如 react-markdown 、 marked 等库，配合 highlight.js 进行代码高亮，将纯文本渲染成美观的富文本。
  • 停止生成按钮 ：在流式生成过程中，需要提供一个按钮，点击后能向后端发送一个中止信号，并优雅地停止接收SSE流。

5.3 添加文件上传与知识库检索（RAG）

这是向企业级应用迈进的重要一步。基本思路是：

  1. 文件上传与解析 ：前端支持上传PDF、Word、TXT等文件。后端接收到文件后，使用像 pdf-parse 、 mammoth.js 这样的库提取文本内容。
  2. 文本分割与向量化 ：将长文本按语义分割成较小的片段（chunks）。然后使用嵌入模型（Embedding Model，如OpenAI的 text-embedding-3-small ）将每个文本片段转换为一个高维向量（向量化）。
  3. 向量存储 ：将这些向量及其对应的原始文本，存储到专门的向量数据库（Vector Database）中，如 Pinecone 、 ChromaDB 、 Qdrant 或 PGVector （PostgreSQL的向量扩展）。
  4. 检索增强生成 ：当用户提问时，先将用户问题向量化，然后在向量数据库中搜索与之最相似的几个文本片段（即“相关知识”）。最后，在调用大模型API时，将这些相关知识作为上下文（或系统提示）的一部分，与用户问题一起发送。模型就能基于你提供的专属知识来生成回答，从而实现“基于文档的问答”。

这个功能模块相对独立，可以逐步迭代加入。

5.4 用户额度与费用控制

对于多用户或需要控制成本的场景，额度管理必不可少。

  • Token计数 ：每次成功调用API后，OpenAI的响应头里会包含本次请求消耗的Token数（ usage 字段）。后端需要准确记录每个用户、每次请求的Token消耗。
  • 额度模型 ：可以为用户设置每日、每月或总体的Token额度上限。每次请求前，检查用户剩余额度是否足够。
  • 费用估算 ：根据使用的模型（如 gpt-3.5-turbo 每百万输入Token 0.5美元，输出Token 1.5美元）和消耗的Token数，可以估算出本次请求和累计消耗的费用，并在管理后台展示。
  • 请求频率限制 ：使用如 express-rate-limit 中间件，限制单个IP或用户的请求频率，防止滥用。

6. 常见问题排查与性能优化

在实际部署和运行中，你肯定会遇到各种问题。这里记录一些典型场景和解决思路。

6.1 部署与运行问题

问题现象 可能原因 排查步骤与解决方案
前端页面空白，控制台报跨域错误 后端CORS配置不正确或前端API地址配置错误 1. 检查后端 .env 中的 CORS_ORIGIN 是否包含前端访问地址（如 http://localhost:3000 ）。
2. 检查前端配置的 VITE_API_BASE_URL 是否指向正确的后端地址和端口。
3. 在后端代码中，确保CORS中间件正确配置，允许前端域名的请求头（如 Authorization ）。
登录成功但后续请求返回401 JWT Token失效或未正确传递 1. 检查前端登录后是否将Token正确存储（通常放 localStorage ），并在后续请求的 Authorization 头中携带（ Bearer <token> ）。
2. 检查后端 JWT_SECRET 是否一致，Token是否过期。可以在 jwt.io 解码Token查看有效期。
流式响应中断，回答不完整 网络不稳定、代理超时或服务器响应超时 1. 检查Nginx配置中关于代理超时的设置（ proxy_read_timeout ），对于SSE需要设置得很长或关闭。
2. 检查后端服务器本身是否有超时限制。
3. 如果是云服务器，检查安全组/防火墙是否放行了后端端口。
数据库连接失败 数据库服务未启动、连接字符串错误、权限不足 1. 运行 sudo systemctl status postgresql 确认数据库服务状态。
2. 核对 .env 中的 DATABASE_URL ，确保用户名、密码、主机、端口、数据库名正确。
3. 使用 psql 命令行工具，用配置中的用户名密码尝试手动连接。

6.2 性能与稳定性优化

当用户量增多或对话变长时，性能问题会凸显。

  1. 数据库连接池优化 ：确保你的ORM（如Prisma）或数据库驱动配置了连接池。这能避免频繁创建和销毁数据库连接带来的开销。在Prisma的 schema.prisma 文件或数据源配置中，可以设置 connection_limit 等参数。

  2. API调用超时与重试 ：调用OpenAI等外部API可能因网络波动失败。后端代码必须设置合理的超时时间（如30秒），并实现重试机制。重试时最好加入指数退避策略（Exponential Backoff），例如第一次失败后等1秒重试，第二次失败等2秒，以此类推，避免雪崩。

  3. 上下文管理的性能 ：对于长对话，每次请求前从数据库读取全部历史消息并计算Token数，可能成为性能瓶颈。可以考虑：

    • 缓存 ：将活跃会话的上下文缓存在Redis等内存数据库中，避免频繁查询SQL。
    • 异步计算 ：在消息存入数据库后，异步计算其Token数并更新到消息表或会话表的一个字段中，下次计算总Token数时直接求和，避免实时调用Tokenizer。

  4. 静态资源优化 ：前端构建时，确保代码分割（Code Splitting）、图片压缩等优化选项开启。使用Nginx为静态资源配置长时间的缓存头（Cache-Control），减少重复加载。

  5. 监控与告警 ：生产环境必须要有监控。可以集成：

    • 应用性能监控 ：使用如Prometheus + Grafana来监控Node.js服务的内存、CPU、请求延迟、错误率。
    • 日志聚合 ：使用ELK Stack或Sentry收集和查询应用日志，便于故障排查。
    • 额度告警 ：设置当用户或全局Token消耗达到阈值时，发送邮件或Slack通知。

6.3 安全加固建议

安全无小事，尤其是涉及API密钥和用户对话数据时。

  • API密钥保护 ：如前所述，绝不在前端暴露。后端也应避免在日志中打印完整的API密钥。可以考虑使用密钥管理服务（如AWS KMS, HashiCorp Vault）或至少使用环境变量。
  • 输入验证与清理 ：对所有用户输入（聊天内容、文件名等）进行严格的验证和清理，防止SQL注入、XSS攻击。使用ORM本身能避免大部分SQL注入，对于XSS，确保前端Markdown渲染库是安全的（默认转义HTML）。
  • HTTPS强制 ：生产环境必须使用HTTPS。可以使用Let‘s Encrypt免费申请SSL证书，并在Nginx中配置。
  • 速率限制 ：不仅在应用层做，在Nginx层面也可以做全局的速率限制，防止恶意刷接口。
  • 数据备份 ：定期备份数据库。对于PostgreSQL，可以使用 pg_dump 命令或工具进行自动备份。

7. 总结与个人实践心得

折腾这样一个项目，从克隆代码到最终部署上线，并在此基础上添加自己想要的功能，是一个非常有成就感的学习过程。它强迫你去理解一个完整Web应用的方方面面：前后端交互、状态管理、数据库设计、部署运维、安全考量。

我个人在实践中有几点深刻体会：

第一，环境配置是第一个拦路虎。 尤其是数据库连接和跨域问题，几乎每个新手都会卡住。我的建议是，严格按照项目的README或文档操作，先确保后端能独立运行并测试API（可以用Postman），再让前端去连接。日志是你的好朋友，一定要学会看后端服务的控制台输出和浏览器的开发者工具（Network和Console面板）。

第二，流式响应的实现比想象中要细致。 最初我实现的版本，在快速连续发送消息时，SSE流经常会混乱或中断。后来发现是前端的事件监听器没有正确清理，以及后端在生成新响应时没有正确关闭之前的连接。处理好这些边界情况，才能有稳定的体验。

第三，Token管理和费用控制必须提前设计。 我开始只是简单记录，等到想加用户额度功能时，发现数据库表结构需要大改。最好在项目初期就设计好 user 表和 usage_log 表，记录每次请求的模型、输入/输出Token数、时间戳。这样后续做统计和限制会非常方便。

第四，关于模型选择。 如果只是自用或小范围使用， gpt-3.5-turbo 的性价比非常高，速度也快。但如果对回答质量要求高，或者需要处理复杂的逻辑推理、长文本分析， gpt-4 系列模型仍然是首选，尽管它更贵、更慢。接入Ollama运行本地模型是一个有趣的补充，适合处理一些不联网的、对实时性要求不高的任务，可以作为一种成本为零的备选方案。

这个项目就像一个乐高底座，为你提供了与AI对话的核心能力。在此基础上，你可以发挥创意，搭建出各种各样的应用形态。无论是把它当作一个纯粹的私人助理，还是作为某个垂直领域知识问答系统的前端，亦或是集成到更大的工作流中，其可能性都是无限的。

Logo
DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐

cover

DeepSeek-V4 上线验收标准：从压测到观测的工程实践

avatar DeepSeek技术社区
cover

多租户推理服务中密钥管理与配额熔断的工程实践

avatar DeepSeek技术社区
cover

知识库权限下放至段落级：DeepSeek RAG 增量索引与 ACL 同步的工程实践

avatar DeepSeek技术社区