1. 项目概述与核心价值

最近在折腾一些AI应用的原型，发现一个挺有意思的现象：很多开发者，包括我自己，都习惯在本地用命令行（CLI）快速调用大模型API来测试想法、处理文本或者写点小脚本。比如用 curl 或者写个简单的Python脚本去调用OpenAI的接口，这确实很方便。但时间一长，问题就来了：脚本散落在各处，每次都要重新处理认证、处理响应格式、管理对话历史，甚至想给其他非技术同事用一下，还得教他们配环境、装依赖，沟通成本巨大。

就在这个当口，我发现了 bravian1/gemini_cli_server 这个项目。初看名字，它像是一个为Google的Gemini大模型设计的命令行服务器。但深入使用后，我发现它的定位远不止于此。它本质上是一个 轻量级的、标准化的AI能力网关 。它把调用Gemini API的复杂性封装起来，对外暴露一个极其简单的HTTP接口。这样一来，任何能发送HTTP请求的工具——无论是你的终端里的 curl ，还是Python、Node.js脚本，甚至是像 HTTPie 、 Postman 这样的图形化工具，都能以统一、无痛的方式获得Gemini的文本生成、多轮对话等能力。

这个项目解决的核心痛点，正是“AI能力集成”的最后一公里问题。对于开发者而言，它意味着你不再需要在自己的每一个小工具、每一个脚本里重复编写API调用、错误处理和上下文管理代码。你只需要在本机或内网启动这个服务，然后像调用本地函数一样，通过HTTP请求去“消费”AI能力。对于团队协作，它则提供了一个共享的、稳定的AI服务端点，避免了每个人维护自己那套可能随时过期的密钥和脚本。简单来说， gemini_cli_server 把强大的云端Gemini模型，变成了你本地开发环境中的一个“基础设施服务”，随用随取，稳定可靠。

2. 项目架构与设计思路拆解

2.1 核心设计哲学：单一职责与接口标准化

gemini_cli_server 的设计非常符合Unix哲学中的“单一职责”原则。它的职责非常明确： 作为一个纯粹的“协议转换器”和“会话管理器” 。它不负责复杂的业务逻辑，不处理用户数据持久化（除非是临时的对话上下文），更不涉及前端界面。它的核心工作只有三件：

  1. 接收标准化请求 ：监听一个HTTP端口，接收符合其预定格式的JSON请求。
  2. 转换并调用上游API ：将收到的请求，转换为Google AI Studio (Gemini API) 官方SDK所需的格式，并携带有效的API密钥进行调用。
  3. 返回标准化响应 ：将Gemini API的响应，重新封装成结构化的JSON数据，返回给调用方。

这种设计带来的最大好处是 解耦 。你的应用逻辑（无论是数据分析脚本、自动化工具还是聊天机器人后端）完全不需要关心Gemini SDK的版本更新、认证方式变更或是网络请求的细节。它只需要和一个稳定的、文档清晰的HTTP接口对话。这极大地提升了代码的健壮性和可维护性。

2.2 技术栈选型分析

从项目代码来看，它通常基于一个轻量级的Web框架实现，比如Python的 FastAPI 或 Flask 。选择Python是顺理成章的，因为Google官方提供的 google-generativeai SDK就是Python库，集成起来最方便。使用 FastAPI 这类现代框架，能自动生成OpenAPI文档，方便接口调试和前端对接，同时其异步特性在处理并发请求时也有优势。

项目结构通常会包含以下几个核心模块：

  • 主服务器文件 (如 server.py 或 main.py ) : 包含HTTP路由定义、请求验证和主循环。
  • 核心服务层 (如 gemini_service.py ) : 封装所有与Gemini API交互的逻辑，包括模型加载、参数设置、上下文历史管理、流式响应处理等。这里是项目的“心脏”。
  • 配置管理 (如 config.py 或环境变量) : 管理API密钥、服务器端口、默认模型参数等。 强烈建议通过环境变量来管理API密钥 ，避免硬编码在代码中导致安全风险。
  • 数据模型 (Pydantic Schemas) : 使用Pydantic等库定义请求和响应的数据格式，确保输入输出的类型安全，并自动生成清晰的API文档。

注意：关于API密钥安全 。这是此类项目的生命线。务必不要在代码仓库中提交任何包含真实API密钥的配置文件。应该使用 .env 文件（并加入 .gitignore ）或直接在运行服务的系统环境变量中设置。在服务启动时读取这些配置。

2.3 与直接调用SDK的对比优势

你可能会问，我直接用 google-generativeai 库写几行代码不就行了，为什么要多此一举架设一个服务器？这里有几个关键优势：

  1. 环境隔离与依赖管理 ：你的主项目可能用的是Node.js、Go或者Java。为了调用一个Python的SDK，你需要额外配置Python环境、安装依赖，可能还会遇到版本冲突。而使用HTTP服务，你的主项目可以用任何语言，只需发起一个HTTP请求，彻底解除了语言绑定的限制。
  2. 集中化的配置与监控 ：所有对Gemini的调用都经过这一个服务。你可以在这里统一设置请求超时、重试策略、频率限制、日志记录和监控指标。如果想切换API密钥、调整默认模型参数（如 temperature , top_p ），只需要重启或热更新这一个服务，所有调用方立即生效。
  3. 成本与用量控制 ：可以在服务层集成简单的用量统计和配额管理，防止某个脚本的无限循环调用导致意外的API费用激增。
  4. 便于横向扩展 ：当请求量增大时，你可以将这个服务容器化（Docker），并配合负载均衡器进行水平扩展，而无需改动调用方的任何代码。

3. 核心功能与接口详解

3.1 核心接口设计

一个设计良好的 gemini_cli_server 通常会提供以下核心HTTP端点：

  • POST /v1/chat/completions : 这是最核心的接口，模仿了OpenAI的Chat Completion API格式，降低了使用者的迁移成本。请求体包含 messages 数组（角色为 user 或 model 的消息历史）和 model 参数（指定使用的Gemini模型，如 gemini-1.5-pro ）。
  • POST /v1/generate : 一个更简单的接口，可能只接收一个 prompt 字符串和模型参数，用于单轮生成任务。
  • GET /v1/models : 返回当前服务支持或可用的Gemini模型列表。
  • WS /v1/chat/completions (可选): 提供WebSocket接口，用于支持流式响应（streaming），这对于需要实时显示生成结果的聊天应用至关重要。

这种设计，尤其是兼容OpenAI API格式，是一个巨大的亮点。这意味着无数为OpenAI API编写的客户端库、工具（如LangChain、LlamaIndex）甚至现有的应用程序，只需修改API Base URL，就能无缝切换到由 gemini_cli_server 提供的Gemini能力上，迁移成本极低。

3.2 请求与响应格式剖析

以兼容OpenAI格式的 /v1/chat/completions 接口为例，一个典型的请求如下：

{
  "model": "gemini-1.5-pro",
  "messages": [
    {"role": "system", "content": "你是一个乐于助人的助手。"},
    {"role": "user", "content": "请用Python写一个快速排序函数。"}
  ],
  "temperature": 0.7,
  "max_tokens": 1024,
  "stream": false
}

服务端在收到这个请求后，内部会进行以下关键操作：

  1. 消息历史重组 ：Gemini API的对话格式可能与OpenAI略有不同。服务需要将 messages 数组中的 system , user , assistant 消息，正确地映射并拼接成Gemini SDK所需的对话历史结构。
  2. 参数映射与转换 ：将 temperature , max_tokens 等通用参数，映射为Gemini SDK对应的参数（如 max_output_tokens ）。
  3. 上下文管理 ：如果服务支持多轮对话的“会话”概念，它需要维护一个会话ID ( session_id ) 与对应消息历史的映射关系。这样，后续携带相同 session_id 的请求就能在之前的对话基础上继续。

处理完成后，返回的响应格式也会模仿OpenAI，确保客户端能正确解析：

{
  "id": "chatcmpl-abc123",
  "object": "chat.completion",
  "created": 1677652288,
  "model": "gemini-1.5-pro",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "当然，以下是一个Python实现的快速排序函数...（代码省略）"
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 25,
    "completion_tokens": 120,
    "total_tokens": 145
  }
}

实操心得：流式响应 (Streaming) 的实现 。对于需要实时性的场景，实现流式响应是必须的。在FastAPI中，你可以返回一个 StreamingResponse ，在生成器函数中，逐块 ( chunk ) 地从Gemini的流式响应中读取数据，并按照OpenAI的流式数据格式（ data: {...}\n\n ）进行封装和发送。这能极大提升终端用户的体验，感觉就像模型在“实时思考”。

3.3 高级功能：函数调用与工具使用

现代大模型的一个重要能力是函数调用（Function Calling）或工具使用（Tool Use）。Gemini也支持此功能。一个进阶的 gemini_cli_server 可以实现对此特性的代理。

基本思路是：客户端在请求中除了 messages ，还可以传递一个 tools 数组，描述可供模型调用的函数。当模型认为需要调用某个函数时，它会在响应中返回一个特殊的结构，指示要调用的函数名和参数。服务器收到后，并不直接执行函数（出于安全考虑），而是将这一信息原样返回给客户端。由客户端决定是否、以及如何安全地执行该函数，并将执行结果作为下一条 message （ role 为 tool ）发送回来，继续对话。

这个过程对服务器来说是透明的，它只负责转发“模型想调用工具”的意图和“工具调用结果”的信息。这种设计既实现了复杂功能，又将潜在的安全风险隔离在了客户端。

4. 从零部署与配置实战

4.1 环境准备与依赖安装

假设我们基于Python和FastAPI来构建。首先，确保你的系统已安装Python 3.8+和 pip 。

# 1. 克隆项目仓库（这里以假设的仓库为例）
git clone https://github.com/bravian1/gemini_cli_server.git
cd gemini_cli_server

# 2. 创建并激活虚拟环境（强烈推荐，避免污染系统环境）
python -m venv venv
# Linux/macOS
source venv/bin/activate
# Windows
venv\Scripts\activate

# 3. 安装项目依赖
# 通常项目会提供 requirements.txt
pip install -r requirements.txt
# 如果没有，核心依赖通常包括：
pip install fastapi uvicorn google-generativeai pydantic python-dotenv

4.2 关键配置详解

配置是服务的灵魂。创建一个 .env 文件在项目根目录（ 务必将其加入 .gitignore ）：

# .env 文件
GEMINI_API_KEY=your_actual_gemini_api_key_here
SERVER_HOST=0.0.0.0  # 监听所有网络接口，方便其他设备访问
SERVER_PORT=8000      # 服务端口
DEFAULT_MODEL=gemini-1.5-pro
DEFAULT_TEMPERATURE=0.7
DEFAULT_MAX_TOKENS=2048
LOG_LEVEL=INFO

在代码中，通过 os.getenv 或 pydantic-settings 库来读取这些配置。例如，使用 pydantic-settings 可以更好地管理配置和验证：

from pydantic_settings import BaseSettings

class Settings(BaseSettings):
    gemini_api_key: str
    server_host: str = "127.0.0.1"
    server_port: int = 8000
    default_model: str = "gemini-1.5-pro"
    default_temperature: float = 0.7
    default_max_tokens: int = 2048
    log_level: str = "INFO"

    class Config:
        env_file = ".env"

settings = Settings()

4.3 服务启动与验证

配置好后，就可以启动服务了。使用 uvicorn 作为ASGI服务器来运行FastAPI应用：

# 假设主应用文件是 main.py，FastAPI实例名为 app
uvicorn main:app --host $SERVER_HOST --port $SERVER_PORT --reload

--reload 参数用于开发环境，代码修改后会自动重启，生产环境请移除。

服务启动后，打开浏览器访问 http://localhost:8000/docs ，你应该能看到自动生成的Swagger UI交互式API文档。这是FastAPI的一大优势，你可以直接在这里测试接口。

首先，测试模型列表接口 GET /v1/models ，应该返回一个包含可用模型信息的JSON。

然后，进行一个简单的聊天测试。你可以使用 curl 命令：

curl -X POST "http://localhost:8000/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-1.5-pro",
    "messages": [{"role": "user", "content": "你好，请介绍一下你自己。"}],
    "temperature": 0.7
  }'

如果一切正常，你将收到一个包含Gemini回复的JSON响应。至此，你的本地Gemini CLI服务器就成功运行起来了。

5. 客户端调用与集成示例

服务跑起来后，关键在于如何使用。以下展示几种常见的调用方式。

5.1 命令行直接调用 (curl/HTTPie)

对于快速测试或简单的脚本任务，直接在终端调用是最快的。

使用 curl ： 

# 非流式
curl -X POST http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [{"role": "user", "content": "用三句话总结量子计算的主要挑战。"}],
    "model": "gemini-1.5-pro"
  }' | jq '.choices[0].message.content'
# 使用 jq 工具可以漂亮地提取出回复内容

# 流式响应 (注意 `stream: true`，并处理 `data:` 前缀行)
curl -N -X POST http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [{"role": "user", "content": "讲一个关于太空探索的短故事。"}],
    "model": "gemini-1.5-pro",
    "stream": true
  }'

使用 HTTPie (更简洁)： 

http POST http://localhost:8000/v1/chat/completions \
  model=gemini-1.5-pro \
  messages:='[{"role":"user", "content":"列出5种提高代码可读性的方法"}]'

5.2 Python 客户端集成

在你的Python项目中，可以完全使用标准的 requests 库，或者使用兼容OpenAI的客户端库。

使用 requests 库： 

import requests
import json

def ask_gemini(prompt, history=None):
    url = "http://localhost:8000/v1/chat/completions"
    headers = {"Content-Type": "application/json"}
    messages = history or []
    messages.append({"role": "user", "content": prompt})
    
    data = {
        "model": "gemini-1.5-pro",
        "messages": messages,
        "temperature": 0.7,
    }
    
    response = requests.post(url, headers=headers, data=json.dumps(data))
    if response.status_code == 200:
        result = response.json()
        return result['choices'][0]['message']['content']
    else:
        raise Exception(f"请求失败: {response.status_code}, {response.text}")

# 使用示例
answer = ask_gemini("Python中如何优雅地合并两个字典？")
print(answer)

使用 openai 兼容库 (推荐)： 由于我们的服务器接口模仿了OpenAI，你可以直接使用 openai 这个Python包，只需修改 base_url 。

pip install openai

from openai import OpenAI

# 将客户端指向你的本地服务器
client = OpenAI(
    base_url="http://localhost:8000/v1", # 注意这里是 /v1
    api_key="not-needed", # 如果服务端不需要认证，这里可以填任意值
)

# 接下来的调用方式和官方OpenAI API一模一样！
completion = client.chat.completions.create(
    model="gemini-1.5-pro",
    messages=[
        {"role": "user", "content": "解释一下什么是递归。"}
    ]
)
print(completion.choices[0].message.content)

这种方式无缝集成，可以让你利用所有为OpenAI生态编写的工具和框架。

5.3 与其他工具和框架集成

  • LangChain / LlamaIndex : 这些流行的AI应用框架都支持自定义的OpenAI兼容端点。你可以轻松地将你的 gemini_cli_server 配置为一个LLM (Large Language Model) 供它们调用。
  • 自动化脚本 (Zapier, n8n, Make) : 这些无代码/低代码自动化平台通常支持Webhook或HTTP请求节点。你可以将它们连接到你的本地服务器，实现“当收到新邮件时，用Gemini总结并发送到Slack”这样的自动化流程。
  • 浏览器插件或桌面应用 : 开发一个轻量级前端，通过HTTP与你的后端服务通信，就能构建一个专属的、功能定制的AI助手客户端。

6. 生产环境部署与优化考量

将服务用于个人开发是一回事，用于小团队或生产环境则需要更多考量。

6.1 使用Docker容器化

容器化是保证环境一致性和便捷部署的最佳实践。创建一个 Dockerfile ：

FROM python:3.11-slim

WORKDIR /app

# 复制依赖文件并安装
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 复制应用代码
COPY . .

# 暴露端口
EXPOSE 8000

# 设置环境变量（或在运行时传入）
ENV GEMINI_API_KEY=""
ENV SERVER_HOST=0.0.0.0
ENV SERVER_PORT=8000

# 启动命令
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

构建并运行：

docker build -t gemini-cli-server .
docker run -d -p 8000:8000 --env-file .env --name gemini-server gemini-cli-server

6.2 性能、安全与监控

  1. 性能优化 ：

    • 连接池与超时设置 ：确保HTTP客户端（如 httpx 或 aiohttp ）使用连接池，并合理设置连接、读取超时，避免单个慢请求阻塞整个服务。
    • 异步处理 ：利用FastAPI的异步特性，使用 async/await 处理请求，特别是在等待Gemini API响应时，可以释放事件循环处理其他请求。
    • 限流 (Rate Limiting) ：使用像 slowapi 这样的中间件，对API端点进行限流，防止滥用或误操作导致的过量请求。可以根据IP或API密钥设置不同的限制。

  2. 安全加固 ：

    • API密钥保护 ：如前所述，永远不要泄露API密钥。考虑实现一个简单的认证层，比如要求客户端在请求头中携带一个共享密钥 ( X-API-Key )，即使服务部署在内网，也多一层防护。
    • 输入验证与清理 ：严格验证客户端传入的 messages 内容，防止注入攻击。虽然Pydantic提供了基础的类型验证，但对于内容本身，可以进行长度限制、敏感词过滤等。
    • HTTPS ：如果服务需要通过公网访问（ 强烈不建议直接暴露，应通过反向代理 ），务必配置SSL/TLS证书，使用HTTPS加密通信。

  3. 监控与日志 ：

    • 结构化日志 ：使用 structlog 或 json-logging 输出结构化的JSON日志，方便被ELK（Elasticsearch, Logstash, Kibana）或Loki等日志系统收集和分析。记录每个请求的模型、token用量、耗时、状态码。
    • 健康检查端点 ：添加一个 GET /health 端点，返回服务状态（如数据库连接、Gemini API连通性）。这对于容器编排平台（如Kubernetes）的存活性和就绪性探针至关重要。
    • 基础指标 ：可以集成 prometheus-client 暴露一些基础指标，如请求总数、请求延迟分布、错误率等，便于监控系统（如Prometheus+Grafana）进行可视化告警。

6.3 常见部署架构

对于小型团队，一个简单的部署架构如下：

[客户端] -> [反向代理 (Nginx/Caddy)] -> [gemini_cli_server (Docker容器)]
                                     -> [可能还有其他服务]
  • 反向代理 ：处理SSL终止、负载均衡（如果你运行了多个服务实例）、静态文件服务、基础的路由和限流。
  • 使用进程管理器 ：在生产环境，不要直接用 uvicorn main:app 。使用 gunicorn 或 uvicorn 配合多个工作进程 ( workers )，并由 supervisor 或 systemd 来管理进程的生命周期，确保服务崩溃后能自动重启。
# 使用gunicorn启动多个worker进程
gunicorn -w 4 -k uvicorn.workers.UvicornWorker main:app -b 0.0.0.0:8000

7. 踩坑实录与进阶技巧

在实际部署和使用过程中，我遇到并总结了一些典型问题和优化点。

7.1 常见问题与排查

问题现象 可能原因 排查步骤与解决方案
启动服务时报 ModuleNotFoundError 虚拟环境未激活或依赖未安装。 1. 确认已激活虚拟环境 ( source venv/bin/activate )。
2. 运行 pip install -r requirements.txt 。
调用API返回 401 Unauthorized 或 Invalid API Key API密钥错误或未设置。 1. 检查 .env 文件中的 GEMINI_API_KEY 是否正确。
2. 确认运行服务的环境变量中已设置该密钥。
3. 在Google AI Studio检查API密钥是否启用、是否有额度。
请求超时或无响应 网络问题，或Gemini API响应慢，或服务进程卡死。 1. 检查服务日志，看是否有错误堆栈。
2. 尝试直接调用Gemini官方API，排除网络问题。
3. 在代码中为Gemini SDK调用设置合理的超时时间（如30秒）。
4. 检查服务器资源（CPU、内存）使用情况。
流式响应不工作，一次性返回全部内容 客户端未正确处理流式数据，或服务端未正确实现流式。 1. 确认请求中 "stream": true 。
2. 检查服务端代码，确保对于流式请求，返回的是 StreamingResponse 并正确分块发送数据。
3. 使用 curl -N 或专门的SSE (Server-Sent Events) 客户端测试。
多轮对话上下文丢失 服务端未实现会话管理逻辑。 1. 客户端需要在请求中携带一个唯一的 session_id 。
2. 服务端需要维护一个字典或使用Redis等缓存，将 session_id 与对应的消息历史列表关联起来。每次请求，根据 session_id 获取历史并拼接新消息。注意设置会话过期时间。
响应内容被截断 达到了 max_tokens (或 max_output_tokens ) 限制。 1. 增加请求中的 max_tokens 参数值。
2. 注意Gemini模型本身有token上限（如32K），你的 max_tokens 不能超过（上下文长度 - 输入token数）。

7.2 进阶技巧与优化

  1. 实现上下文缓存与摘要 ：对于超长对话，将所有历史消息每次都发送给API会消耗大量token，成本高且可能超出上下文窗口。可以实现一个摘要机制：当对话轮数超过一定阈值，或历史token数接近上限时，调用一次模型，让它自己总结之前的对话核心内容，然后用这个摘要替换掉旧的历史消息，再继续新对话。这能显著延长有效对话长度。
  2. 支持多模型路由与负载均衡 ：如果你的团队同时使用Gemini Pro、Flash甚至其他厂商的模型，可以在服务端实现一个路由层。根据请求的特定参数（如 model 字段，或自定义的 x-model-group 头），将请求转发到不同的后端处理逻辑或不同的API密钥。甚至可以实现简单的负载均衡，在多个API密钥间轮询，避免单个密钥的速率限制。
  3. 添加请求/响应中间件 ：利用FastAPI的中间件机制，可以轻松添加全局功能。
    • 日志中间件 ：记录每个请求的入参、出参、耗时。
    • 审计中间件 ：记录谁在什么时候调用了什么模型，用于成本分摊或审计。
    • 缓存中间件 ：对于某些重复性的、确定性高的查询（例如“将‘你好’翻译成英文”），可以将结果缓存一段时间（如Redis），直接返回缓存结果，大幅降低API调用成本和延迟。
  4. 优雅处理API限制与降级 ：Gemini API有每分钟、每天的请求次数和token数量限制。在服务端实现一个令牌桶或漏桶算法进行限流，当达到限制时，向客户端返回 429 Too Many Requests 而不是直接让请求失败。对于非关键任务，甚至可以设置一个降级策略，例如当首选模型不可用时，自动切换到备用模型。

7.3 我个人在实际操作中的体会

搭建这样一个服务，最大的收获不是代码本身，而是对“AI即服务”这种架构模式的深刻理解。它把一种不确定的、依赖外部API的“能力”，变成了一个确定的、可控的、可观测的“内部服务”。这带来的运维思维转变是巨大的。

我开始像对待数据库、缓存这些基础服务一样对待这个AI服务：关心它的SLA（服务等级协议）、监控它的QPS（每秒查询率）和延迟、规划它的容量和成本。例如，通过监控发现，晚上10点后团队的自动化脚本调用量激增，导致偶尔超时。于是我们增加了两个优化：一是对非实时任务实现了请求队列，平滑了流量高峰；二是为这些脚本设置了更长的超时时间和更低的 temperature ，在保证功能的同时提高了稳定性。

另一个深刻的体会是“接口标准化”的力量。因为兼容了OpenAI API，我们几乎没费什么力气，就让团队里用Node.js写的数据分析工具、用Go写的后台服务，都接入了这个Gemini网关。这种低成本的集成能力，是项目能否被广泛采纳的关键。

最后，关于成本控制。单纯架设服务而不加管控是危险的。我们为服务添加了一个简单的、基于内部用户ID的每日token用量统计和软限制。当用户快达到限额时，服务会返回警告信息。这并非为了阻止使用，而是为了培养团队成员的“成本意识”，让大家明白每一次AI调用都不是免费的，从而更负责任、更高效地使用这个强大的工具。

Logo
DeepSeek技术社区

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

更多推荐

cover

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

avatar DeepSeek技术社区
cover

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

avatar DeepSeek技术社区
cover

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

avatar DeepSeek技术社区