bionic-gpt/bionic-gpt · 上手攻略

  • 仓库：bionic-gpt/bionic-gpt
  • 链接：https://github.com/bionic-gpt/bionic-gpt
  • 分类：llm-infra（on-premise ChatGPT 替代 / Agentic RAG 平台）
  • 作者：spark
  • 更新：2026-07-26

一、是什么

Bionic GPT 是一个自托管（on-premise）的 ChatGPT 替代品，定位企业内部的私有生成式 AI 平台。它用 Rust 写了一个高性能 Web Server，把 RAG、文档解析、模型路由、鉴权、审计、可观测性这些通常要自己拼装的"内部 ChatGPT 必备件"打包成一个可直接落到 Kubernetes 上的完整栈。

它不是单一服务，而是按生产部署目标设计的一整套系统：Nginx 入口 → OAuth2 Proxy（外部 IdP 登录）→ Rust 编写的核心服务 → RAG 引擎 / 文档引擎 → Postgres（用 PgVector 做向量库）→ S3 兼容对象存储。模型侧支持本地开源模型（Ollama）和外部托管模型（OpenAI、Anthropic），可以同时挂多个模型并在 UI 里切换。

仓库主语言是 Rust（后端 + UI），许可为 NOASSERTION（公司 Purton Tech 旗下，开源但不挂标准 OSI 协议）。截至 2026-07-24 仍在持续提交，仓库 Stars ~2.3k，没有正式 semver Release（仓库以 commit pin 的 docker-compose.yml 作为安装源）。

二、解决什么问题

公司内部想用 ChatGPT，但又不能把合同、代码、内部 Wiki 推给 OpenAI——这是 2023 年起反复出现的需求。Bionic GPT 直接给出一个"装上就能用、能 SSO、能审计、能在 K8s 上跑 1000 人"的成品，主要痛点对位：

  • 数据出域焦虑：整套堆栈本地化部署，LLM 可以用本地 Ollama，也可以接外部 API；聊天内容全部进自己的 Postgres，方便审计和合规。
  • 多模型灵活切换：管理员可以在 UI 里挂多个 LLM，用户按需切换；模型用量通过 token 配额和反向代理限流。
  • RAG 开箱即用：HTML、PDF、CSV、PNG、PPTX 等 80% 的"难搞格式"内建支持，配 embeddings 引擎和 chunking 算法不用写代码；批处理通过 Airbyte 接 Sharepoint、NFS、FTP、Kafka 等数据源。
  • 团队 & 权限：Teams、子 Teams、SSO、RBAC、Postgres Row Level Security 双层把关。
  • 安全 & 合规观感：容器尽量从 scratch 编译、非 root 运行、最高级 CSP、SAST 流水线、SIEM 集成接口。
  • 可观测：Prometheus 兼容的指标 + Grafana 仪表盘。

适合的典型角色：甲方 IT / 平台团队要给业务部门交付"内部 ChatGPT"；安全/合规要求所有 LLM 调用落审计；研发团队需要一个集中模型网关和内部 RAG 工作台。

三、快速安装

3.1 最小可行：本地 Docker Compose（PoC）

适用：本机或小团队验证。只用于 PoC，不能上生产。

前置：Docker 已安装。

macOS / Linux：

curl -O https://raw.githubusercontent.com/bionic-gpt/bionic-gpt/bb67c2d9bf5ca8d54049b6ee910e7a381185aa9f/infra-as-code/docker-compose.yml
docker-compose up

Windows PowerShell：

Invoke-WebRequest -Uri https://raw.githubusercontent.com/bionic-gpt/bionic-gpt/bb67c2d9bf5ca8d54049b6ee910e7a381185aa9f/infra-as-code/docker-compose.yml -OutFile docker-compose.yml
docker-compose up

启动后访问 http://localhost:3000。Compose 链路通常包含 Postgres、对象存储、Rust 服务、Web UI 几个容器。

3.2 生产：Kubernetes（推荐）

官方文档路径走 k3s / Docker Desktop 内置 K8s / 云厂商 EKS·AKS·GKE。Helm chart 或 Kustomize 配置位于 infra-as-code/ 目录（具体子目录名以仓库当前结构为准）。生产部署前必做：

  1. 准备外部 Postgres（含 PgVector 扩展）和 S3 兼容对象存储。
  2. 准备外部 OAuth2/OIDC IdP（Google Workspace、Okta、Keycloak、Azure AD 等）。
  3. 设置环境变量 APP_BASE_URL 为对外 URL（用于 OAuth2 回调）。
  4. 配置 Ingress（官方默认用 Nginx）+ TLS。
  5. 接入 Prometheus + Grafana。

⚠️ 注意：官方文档明确说"docker-compose 不推荐生产"，只用于 PoC；上生产必须走 K8s 那一套并自行加固 Postgres / S3 / IdP。

3.3 模型接入

  • 本地模型：部署 Ollama，Bionic 在 UI 里把 Ollama 端点配上即可。
  • 外部模型：在管理后台填 OpenAI / Anthropic API Key，Bionic 通过反代统一计费、限流。
  • 可同时挂多模型，用户在聊天界面切换。

四、核心用法

4.1 管理后台

  • 创建 Team、邀请用户、绑定 SSO。
  • 配置外部 IdP、回填 OAuth2 client。
  • 设置全局 LLM（本地 Ollama + 外部 API 混合），给各 Team 分配配额。
  • 启用审计日志、SIEM 转发。

4.2 创建 Assistant（Agentic RAG 流水线）

Assistant = 一个可共享的 RAG 应用。在 UI 里几步完成：

  1. 选 embeddings 模型与 chunking 算法（无需写代码）。
  2. 配置系统提示词，约束 LLM 回答风格。
  3. 选择数据集（dataset），数据集由以下方式喂养： - 用户手动上传 PDF/HTML/CSV/PNG/PPTX； - Airbyte 批量同步（Sharepoint、NFS、FTP、Kafka…）； - 实时流式摄取。
  4. 发布 Assistant，团队内可一键共享。

4.3 Assistants API（OpenAI 兼容）

任何 Assistant 都能一键暴露成 OpenAI 兼容的 API：Bionic 给你 API key + endpoint，业务系统直接用 OpenAI SDK 调用，省去自建接口。

from openai import OpenAI

client = OpenAI(
    base_url="https://your-bionic-host/api/v1",   # 实际地址以部署为准
    api_key="bk-...",                              # Bionic 颁发的 key
)

resp = client.chat.completions.create(
    model="your-assistant-name",                   # 即 Bionic 里的 Assistant 名
    messages=[{"role": "user", "content": "总结一下我司安全规范"}],
)
print(resp.choices[0].message.content)

⚠️ 具体路径、key 前缀以你部署版本的文档为准，README 上没有给出稳定的版本号，本节命令形式示意。

4.4 限流与配额

  • IAM 角色 → token 用量上限（按角色分级）。
  • API key 继承所属用户的 throttle limit。
  • 反向代理层统一拦，避免单模型被压垮。

4.5 可观测与审计

  • Prometheus 抓取指标，Grafana 出仪表盘。
  • Postgres 里直接查所有对话（合规审计）。
  • 审计日志记录"谁、什么时候、做了什么"。

五、典型适用场景

  • 企业内部 ChatGPT：合规要求所有对话留痕、不能出域；想用 SSO + RBAC。
  • 研发 RAG 工作台：把 Confluence、Sharepoint、内部 Git 仓库做成数据集，给团队一个"问内部知识"的入口。
  • 多模型网关：让不同业务线用不同模型，统一计费、统一审计、统一限流。
  • PoC 验证"自托管 LLM"可行性：单台笔记本上 docker-compose 跑通，再决定是否升级 K8s。

六、坑与注意

  1. 没有 semver Release：仓库以 commit pin 提供 docker-compose.yml，升级时要看具体 commit diff，没有稳定的 1.x 升级路径。生产锁定 pin 时要心里有数。
  2. 生产一定要 K8s：官方明示 docker-compose 只服务 PoC；K8s 部署需要自己准备 Postgres、S3、IdP 三个外部依赖。
  3. 许可不是标准 OSI：许可证字段是 NOASSERTION，使用前请直接看 LICENSE 文件确认条款，尤其是商用、再分发、衍生作品部分。
  4. 审计落 Postgres：所有问答都进库，存储膨胀要提前规划；按业务合规要求可能要加 TTL 或归档策略。
  5. RAG 不是"装上就懂业务"：默认 chunking、embedding 不一定匹配你司文档结构（合同、表格、图片居多的话要重点调）；OCR 已内建但要测试。
  6. 依赖外部 IdP：默认不开"本地账号登录"，生产前必须先有可用 OIDC，否则用户体验割裂。
  7. MCP / 多 Agent 编排不是它的强项：Bionic 重点是"门户 + RAG + 治理"，不是 LangGraph/AutoGen 那种 Agent 编排框架。要做复杂 Agent 工作流要去别处。

七、与同类对比

项目 定位 关键差异
Bionic GPT 自托管 ChatGPT + Agentic RAG 平台 一体化（含 SSO/审计/RBAC），Rust 性能好，多模型网关，Airbyte 集成
Open WebUI 自托管 LLM 聊天前端 偏前端 + Ollama 集成，治理/审计/RAG 都更轻量
AnythingLLM 桌面级 RAG 工作台 单机友好，企业级 RBAC/审计/SSO 比 Bionic 弱
Dify LLM 应用开发平台 强 Workflow/Agent 编排，权限模型偏应用层而非企业 SSO
n8n + LLM 节点 通用自动化 + LLM 灵活但要自己拼 SSO、审计、配额
私有化 ChatGPT Enterprise / Copilot 商业产品 闭源、贵、不能完全本地方案时才会考虑

八、一句话推荐

如果你要给公司交付一个"能 SSO、能审计、能挂本地+云端模型、能直接灌 Sharepoint/PDF 的内部 ChatGPT"，Bionic GPT 是当前 Rust 生态里少有的'全栈成品'，先用 docker-compose 做 PoC，再按 K8s 那套上生产。 不适合用来做复杂 Agent 编排或当成 LangChain 替代品。