中级 17 分钟部署

基于 GB10 的中小企业私有 AI 助手: mesures

木桌上,一台笔记本电脑旁摊放着几张纸。
直接回答

在 GIGABYTE AI TOP ATOM(NVIDIA GB10 芯片,128 GB)上,一套完整的软件栈(Open WebUI 界面、gpt-oss 120B 模型和 bge-m3 检索模型)启动耗时 66 秒,占用 68 GB。它在 6 分钟内索引 5000 页,在 500 页知识库上 86% 的情况下能找到正确文档(5000 页时为 78%),单人提问时 10 秒给出回答。在 200 条回答期间,没有任何容器向外部发送数据包。每条回答的 GPU 耗电为 0.15 Wh。

一家希望借助 AI 查询其合同和流程文件的中小企业,很快就会面临一个问题:我的文档会被发送到哪里?私有助手将一切都保留在办公室的一台机器上。它基于 RAG(检索增强生成):系统先在您的文件中检索相关段落,再由模型撰写回答。我们在 GIGABYTE 免费提供的一台 AI TOP ATOM 上,使用一家虚构企业的文档,对一套完整的技术栈进行了测量。

作者: Mohamed Meguedmi·更新于 2026-11-12·在 GIGABYTE AI TOP ATOM 上测得
i
透明度
本系列指南所用硬件由 GIGABYTE 免费提供。测量结果和观点均为我们自己的;GIGABYTE 在发布前未审阅或批准本内容。本页面不包含任何联盟链接。我们的数据、信息图和照片均可根据 CC BY 4.0 许可自由再利用,但须注明 哪个LLM。
关键数字
6,1min
索引 5000 页所需时间
86%
的问题找到了正确文档(500 页)
≈ 10s
为单人生成完整回答
0paquet
200 个回答期间向外部发送的数据
平托在一只手中的 AI TOP ATOM,俯视及正视图:灰色外壳与百叶式前面板。
一台约一升大小的机箱,可直接放在办公桌上:无需服务器机房。图为我们的设备,背景已做中性化处理。 放大 ↗

#技术栈的组成:三个软件,68 GB

私有助手由三个组件构成,我们将它们安装在 AI TOP ATOM(型号 ATAGB10-9000,DGX OS 7.5.0)上的 Docker 容器中。模型通过 llama.cpp(build 11430)运行。

Open WebUI 0.11.4
Web 界面:账户、文件导入、知识库和对话。它还负责将文档切分为片段(默认每段 1,000 个字符,重叠 100 个字符),并为每个问题保留最相近的 5 个片段。
gpt-oss 120B(MXFP4)
Le modèle qui rédige la réponse, servi par llama-server (le serveur fourni avec llama.cpp). MXFP4 est son format d'origine, déjà compressé. Il est réglé pour 10 demandes en parallèle. C'est un modèle MoE (mélange d'experts) : à chaque token, il n'utilise que 5,1 de ses 117 milliards de paramètres.
bge-m3(Q8_0)
嵌入模型,此处使用 Q8_0 版本(8 位量化)。它将每个片段转换为一串表示其语义的数字,从而可以对问题和片段进行比较。该模型支持多语言,因此适用于法语。

在清空磁盘缓存后完整启动,直到界面就绪耗时 66 秒。软件栈占用 68.0 GB 内存:gpt-oss 120B 进程在 GPU 侧占用 63.6 GB,bge-m3 占用 0.8 GB;其余由 Open WebUI 和系统占用。

启动后,机器上仍有 48.6 GB 可用。本指南中的内存以 GB 为单位,与 Linux 的显示方式一致:1 GB = 1024 MB。本系列的第一篇指南详细介绍了 gpt-oss 120B 的速度:每秒 58 个 token。

#虚构企业与 100 个问题

打造专属本地 RAG 的完整套件。

借助我们的经验和引导式路径,搭建你的本地 RAG,用你自己的文档工作。

  • 在线空间,终身可用
  • PDF + 文件
  • 30 天内退款

Lustrelle 是我们虚构的一家中小企业:拥有一个车间、一个仓库、一个售后服务部门和若干办公室。它的 60 份文档均为 Markdown 格式的文本文件(一种简单文本,用少量符号标记标题和列表)。内容涉及人力资源、车间安全、备份、费用报销、客户退货以及培训计划。文档中包含精确的数字、名称和条件,以便每个回答都可核查。

为了达到贴近实际的数据量,我们按照测试规程的规定,加入了 Service-Public 的公开信息页,由此得到三个规模递增的知识库。本指南的方法细节由我们测试规程的一份补充条款确定,该条款日期为 2026 年 10 月 7 日,早于助手给出第一个回答。测试规程在首次测量之前即已冻结;方法、注明日期的补充条款列表以及我们表格中的数据均发布在我们的方法页面上。

我们测量所用的三个知识库。页数仅供参考;文件数为精确值。
Base文件内容
50 页26Lustrelle 60 份文档中的 26 份
500 页114Lustrelle 的 60 份文档和 54 份 Service-Public 说明页
5000 页701Lustrelle 的 60 份文档和 641 份 Service-Public 信息页

这 100 个问题均按原样提出,未经改写。其中 80 个问题的答案可在文档中找到:50 个事实类问题、10 个流程类问题、10 个数字类问题和 10 个综合类问题。另有 20 个问题在文档中没有答案:用于检验助手是否会承认无法回答,而不是编造答案。

Fait
我们有多少名消防初期处置队员?预期答案:十名,从员工中指定。
Chiffre
60 cm 烟熏橡木款 Brindille 吊灯含税价格是多少?预期答案:含税 360 €(天然橡木款 348 €,烟熏饰面另加 12 €)。
文档中没有答案时
Lustrelle 是否通过了 ISO 9001 认证?预期回答:助手说明文档中未提及此事。

#部署技术栈:相关命令

整个技术栈由三个容器和两个 Docker 网络组成。第一个网络是“内部”网络:Docker 不为其提供任何对外访问。两个模型服务器仅连接到该网络。Open WebUI 连接到这个内部网络以便与模型通信,同时还连接到第二个网络,您通过它在浏览器中打开界面。

以下命令即我们在 2026 年 10 月 7 日和 8 日测试中所用的命令,路径已作简化。llama.cpp(build 11430)在本机上针对 GB10 芯片编译;编译命令见本系列的 70B 教程。

创建网络并启动三个容器(于 2026 年 10 月 7 日和 8 日测试)
docker network create --internal g6-interne     # réseau interne : aucun accès à l'extérieur
docker network create g6-front                 # réseau d'accès pour le navigateur

# 1. gpt-oss 120B : génération, 10 demandes en parallèle, contexte de 131 072 tokens
docker run -d --init --name g6-gen --network g6-interne --network-alias gen --gpus all --ipc=host \
  -e LD_LIBRARY_PATH=/llama -v ~/llama.cpp/build/bin:/llama:ro -v ~/models/gguf:/models:ro \
  nvcr.io/nvidia/pytorch:26.03-py3 \
  /llama/llama-server -m /models/ggml-org/gpt-oss-120b-GGUF/gpt-oss-120b-MXFP4.gguf -ngl 99 -fa on -c 131072 -np 10 \
  --jinja --host 0.0.0.0 --port 8080 -a gpt-oss-120b

# 2. bge-m3 : plongements (embeddings)
docker run -d --init --name g6-emb --network g6-interne --network-alias emb --gpus all --ipc=host \
  -e LD_LIBRARY_PATH=/llama -v ~/llama.cpp/build/bin:/llama:ro -v ~/models/gguf:/models:ro \
  nvcr.io/nvidia/pytorch:26.03-py3 \
  /llama/llama-server -m /models/ggml-org/bge-m3-Q8_0-GGUF/bge-m3-q8_0.gguf -ngl 99 --embeddings --pooling cls \
  -c 16384 -b 8192 -ub 8192 -np 2 --host 0.0.0.0 --port 8080 -a bge-m3

# 3. Open WebUI : interface, bases de connaissances, RAG
mkdir -p ~/g6/webui-data
[ -f ~/g6/secret ] || openssl rand -hex 32 > ~/g6/secret
docker run -d --name g6-webui --network g6-front -p 127.0.0.1:3100:8080 -v ~/g6/webui-data:/app/backend/data \
  -e ENABLE_OLLAMA_API=false -e OPENAI_API_BASE_URL=http://gen:8080/v1 -e OPENAI_API_KEY=local \
  -e RAG_EMBEDDING_ENGINE=openai -e RAG_EMBEDDING_MODEL=bge-m3 \
  -e RAG_OPENAI_API_BASE_URL=http://emb:8080/v1 -e RAG_OPENAI_API_KEY=local \
  -e RAG_EMBEDDING_BATCH_SIZE=32 -e RAG_TOP_K=5 -e ENABLE_API_KEYS=true -e ENABLE_PERSISTENT_CONFIG=false \
  -e OFFLINE_MODE=true -e HF_HUB_OFFLINE=1 -e ANONYMIZED_TELEMETRY=false -e DO_NOT_TRACK=true -e SCARF_NO_ANALYTICS=true \
  -e WEBUI_SECRET_KEY="$(cat ~/g6/secret)" ghcr.io/open-webui/open-webui:v0.11.4
docker network connect g6-interne g6-webui     # Open WebUI parle aux modèles par le réseau interne

选项 -np 10 开启 10 个槽位:十个请求可以同时推进(NVIDIA 的 llama.cpp 指南默认设置为 4 个)。选项 -c 131072 设定总上下文长度,由各槽位共享。RAG_TOP_K 设为 5,表示每个问题检索五个片段。变量 OFFLINE_MODE、ANONYMIZED_TELEMETRY、DO_NOT_TRACK 和 SCARF_NO_ANALYTICS 会关闭 Open WebUI 的更新检查、联网下载和遥测。分块方式保持 Open WebUI 的默认设置,可在其界面中调整。

  1. 01
    打开 Open WebUI
    访问 http://127.0.0.1:3100 并创建管理员账户。选择 gpt-oss-120b 作为模型。
  2. 02
    创建知识库
    打开“知识”栏目,创建一个知识库并添加您的文件。Open WebUI 会读取每个文件、对其进行切分并计算其嵌入向量。
  3. 03
    查询知识库
    在对话中输入井号,后接知识库名称,然后提出问题。回答会连同其来源一起显示。

我们的测量通过 Open WebUI 的 API 进行,因此可以用脚本重放。以下是与我们的测量脚本(用 Python 编写)中相同的调用,改写为 curl 和 jq 版本。

创建知识库、向其中添加文件并通过 API 查询(我们调用的 curl 改写版)
U=http://127.0.0.1:3100
# jeton de connexion du compte de test (adresse et mot de passe à remplacer par les vôtres)
TOKEN=$(curl -s $U/api/v1/auths/signin -H "Content-Type: application/json" \
  -d '{"email":"admin@exemple.test","password":"MOT_DE_PASSE"}' | jq -r .token)

# 1. créer la base de connaissances
KB=$(curl -s $U/api/v1/knowledge/create -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"name":"lustrelle-p500","description":"test"}' | jq -r .id)

# 2. envoyer un fichier, attendre son traitement, l'ajouter à la base
F=$(curl -s -H "Authorization: Bearer $TOKEN" -F "file=@38-evacuation-incendie-exercices.md" "$U/api/v1/files/?process=true" | jq -r .id)
until curl -s -H "Authorization: Bearer $TOKEN" $U/api/v1/files/$F/process/status | jq -e '.status=="completed" or .status=="failed"' >/dev/null; do sleep 1; done   # attend la fin du traitement
curl -s -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d "{\"file_id\":\"$F\"}" $U/api/v1/knowledge/$KB/file/add

# 3. poser une question sur cette base (réponse complète, sans flux)
curl -s $U/api/chat/completions -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d "{\"model\":\"gpt-oss-120b\",\"stream\":false,\"files\":[{\"type\":\"collection\",\"id\":\"$KB\"}],
       \"messages\":[{\"role\":\"user\",\"content\":\"On a combien d'équipiers de première intervention incendie ?\"}]}"

#索引 50、500 和 5000 页

索引是指读取每个文件,将其切分为片段,用 bge-m3 计算嵌入向量,并将全部内容存入知识库。我们的脚本每次发送 4 个文件,并计时到最后一个文件处理完毕为止。没有任何文件失败。

导入 Open WebUI 0.11.4,2026 年 10 月 7 日。耗时统计至最后一个文件处理完毕,每次同时处理 4 个文件。
Base文件时长失败次数
50 页269,2 s0
500 页11446,8 s0
5000 页701365.9 秒(6.1 分钟)0
索引耗时横向条形图:50 页(26 个文件)耗时 9.2 秒,500 页(114 个文件)耗时 46.8 秒,5000 页(701 个文件)耗时 365.9 秒,即 6.1 分钟。右上角:软件栈占用 68.0 GB 内存,启动耗时 66 秒。
不同知识库规模下的索引耗时(横轴单位为秒)。每个条形左侧为页数(单个文档图标),下方为文件数(叠放文档图标)。最后一个条形下方的绿色数字为以分钟表示的同一耗时。右上角:技术栈占用的内存(68.0 GB)和启动时间(66 秒)。 放大 ↗

5,000 页内容在 6 分钟多一点即可就绪,约合每秒 1.9 个文件。因此,重新索引 5,000 页的文档库耗时不到 7 分钟。在此次索引过程中,GPU 消耗了 5.4 Wh。

#能否找到正确的文档?

在评估回答质量之前,首先要知道助手是否在正确的地方查找。我们的自动指标“找到正确文档”统计的是:在 Open WebUI 返回的来源中至少包含一份预期文档的问题数量。该指标针对答案在文档中的 80 个问题,由脚本计算;它不是质量评分,也不能说明回答是否正确。

每个知识库 100 条回答,每次并发 4 个问题,2026 年 10 月 7 日和 8 日。每个问题使用新对话,措辞不变,不追问。
Base找到正确文档无错误收到的回答单个回答的中位耗时
500 页86%(80 个问题中的 69 个)100 中 100约 40 秒
5000 页78%(80 个问题中的 62 个)100 中 100约 42 秒

文件数量增加约六倍(701 个对比 114 个)后,仍有 78% 的情况能找到正确文档。每个知识库的 100 个回答均已收到,没有技术错误或空回答,且每个回答都附有来源列表。借助该列表即可核查:点击来源按钮,就能看到所用的文件。

Open WebUI 法语界面截图。针对在 lustrelle-p500 知识库上提出的问题“我一年开自己的私家车为工作跑 8 000 公里:能报销多少?”,gpt-oss-120b 经过 6 秒思考后回答:6 000 公里按 0.50 € 计、2 000 公里按 0.30 € 计,共计 3 600 €。来源按钮已展开,列出了两个文件:一份 Service-Public 信息页和差旅费用报销文件。
Open WebUI 中一个附带来源的数字型回答,基于 500 页知识库。所用的两个文件列在回答下方。这是一个精选示例,并不代表成功率。 放大 ↗
法语版 Open WebUI 的截图。对于问题“Lustrelle 是否通过了 ISO 9001 认证?”(文档中并无答案),gpt-oss-120b 回答称所提供的文档未提及 Lustrelle SAS 有任何 ISO 9001 认证,并建议咨询该公司的质量部门。
对于答案不在文档中的问题:助手会如实说明,而不是编造一项认证。在 20 个此类问题中,它有 12 次明确说明了这一点(详见下文)。 放大 ↗
Open WebUI“知识”栏目的截图,显示了我们测试所用的三个知识库:lustrelle-p5000 含 701 个文件,lustrelle-p500 含 114 个文件,lustrelle-p50 含 26 个文件。
我们测试所用的三个知识库,如 Open WebUI 中所示。 放大 ↗

#可以同时支持多少人?

我们模拟了 1、5 和 10 个用户同时访问该技术栈。这些用户位于一台 Mac 上,该 Mac 通过经由私有网络 Tailscale 的 SSH 隧道连接到 ATOM。每个用户连续提出 6 个问题,问题之间没有停顿,回答以流式方式返回。我们记录首个词的输出时间和完整回答时间,取中位数。每组测试包含 6、30 或 60 个请求;无一失败。

从另一台设备(Mac,经 Tailscale 的 SSH 隧道)测得的延迟,2026 年 10 月 8 日。基于 6 至 60 个请求的中位数;无一失败。
用户Base首个词完整回答
1500 页9,0 s9,6 s
15000 页9,9 s10,2 s
5500 页33,1 s38,4 s
55000 页39,3 s44,7 s
10500 页52,4 s63,5 s
105000 页50,2 s64,8 s
水平条形图,显示 1、5 和 10 个并发用户在 500 页和 5000 页下的中位响应时间。1 个用户:完整回答用时 9.6 秒和 10.2 秒,首个词出现于 9.0 秒和 9.9 秒。5 个用户:38.4 秒和 44.7 秒,首个词出现于 33.1 秒和 39.3 秒。10 个用户:63.5 秒和 64.8 秒,首个词出现于 52.4 秒和 50.2 秒。
在 1、5 和 10 名用户(每名用户对应一个人形图标)情况下,基于 500 页知识库(蓝色)和 5 000 页知识库(橙色),得到完整回答的中位时间(整条柱)和得到首个词的中位时间(鲜艳颜色的实心部分)。横轴单位为秒。带三个点的气泡图标:首个词;实心气泡:完整回答。 放大 ↗

单独一人提问时,在 500 页的库上,完整回答需 9,6 秒;在 5 000 页的库上需 10,2 秒。当 5 人同时提问时,中位数分别升至 38 秒和 45 秒。10 人同时提问时,中位数约为一分钟:63,5 秒和 64,8 秒。库的规模对这些耗时影响不大:从 500 页到 5 000 页,差异在 0,6 到 6,4 秒之间。

第一个字在 gpt-oss 120B 的思考阶段之后才会出现:此时 Open WebUI 会显示“思考了 6 秒”或相近的时长。这一阶段叠加在读取文本片段的时间之上,并由各用户共享。我们的测试要求很严苛:每位用户连续提问,不留阅读时间,而真实用户会先读完回答再提下一个问题。

#按 5 至 20 人规模进行配置

在 10 名用户持续活跃的情况下,该技术栈基于 500 页知识库在 441 秒内完成 60 个回答:约每分钟 8 个回答。以下是基于这一测量结果的估算。一个 20 人的团队,若每人平均每 5 分钟提一个问题,每分钟会产生 4 个问题,即该吞吐量的一半。这只是一个数量级估计,而非实测:您的实际使用情况可能有所不同。

最多 5 人
一人提问时 10 秒给出回答;5 人在同一秒同时提问时约需 40 秒。
5 至 10 人
当 10 名用户持续提问时,大约一分钟可得到完整回答,且没有出现任何错误。服务器配置为并行处理 10 个请求。
10 到 20 人
我们没有测量超过 10 名同时在线用户的情况。上述计算表明,20 名按常规方式使用的人员所产生的负载仍低于实测吞吐量。

#保密性:我们核查了哪些内容

只有文档始终留在您自己手中,私有助手才有意义。因此我们检查了网络流量。在生成 200 个回答(每个知识库 100 个)的过程中,我们用 tcpdump 捕获了该技术栈两个 Docker 网络的数据包,然后列出了出现过的所有地址。

结果:该技术栈中没有任何容器向外部地址发送过数据包。捕获到的地址仅包括各容器和宿主机网关的地址,以及组播和本地广播地址(局域网发现消息)。Open WebUI 连接到一个可对外访问的网络,但仍未出现任何外部地址。而两个模型服务器则位于 Docker 与外部隔离的网络中。

i
证据适用范围
我们证明的是在我们的技术栈上、在我们的 200 次回答期间实际发生的情况。这并不能证明其他本地助手同样不会泄露数据。正式投入使用前,请检查您自己的网络、账户和备份,并根据您的合规义务对个人数据的处理进行审核确认。

#能耗:每个回答 0.15 Wh

在每个知识库生成 100 条回答期间(每次并发 4 个问题),我们每秒记录一次 GPU 功率。在 500 页知识库上,GPU 工作了 18.0 分钟,平均功率 50.5 W,峰值 68.1 W:共 15.2 Wh,即每条回答 0.15 Wh。在 5000 页知识库上,平均 50.7 W,共 15.4 Wh:结果相同,每条回答 0.15 Wh。

不同任务下的 GPU 能耗。每秒采样一次(nvidia-smi),采集于 2026 年 10 月 7 日和 8 日;空闲状态数据于 10 月 6 日至 7 日夜间采集,时长 30 分钟。
情况时长GPU 平均功率GPU 能耗
空闲,无任务30 分钟10,4 W—
100 个回答,500 页知识库,每次 4 个并发18.0 分钟50,5 W15.2 Wh,即每个回答 0.15 Wh
100 个回答,5000 页知识库,每次并发 4 个18.2 分钟50,7 W15.4 Wh,即每个回答 0.15 Wh
5 000 页的索引6.1 分钟53,2 W5.4 Wh

按 EDF Tarif Bleu Base 电价(含税每 kWh 20.01 欧分,2026 年 8 月 1 日起适用的价目表,不含订阅费)计算,1,000 个回答耗电 0.15 kWh,即 3 欧分。这些数字仅计入芯片自身报告的 GPU 功耗:据 NVIDIA 所述,nvidia-smi 显示的功率仅为 GPU 本身的功率。处理器、内存、SSD 和电源均未计入。本系列的另一篇指南详细介绍了长时间运行的能耗。

#逐条评分的回答质量

自动化指标无法判断回答是否正确。因此,在 500 页知识库上得到的 100 个回答均经过逐条评分。应作者要求,评分由 Anthropic 的 AI 模型 Claude 完成,而非由生成回答的模型(gpt-oss 120B)完成。

对于每个问题,Claude 都获得了预期答案、源文档以及下方的评分标准。评分范围为 0 至 2 分,评判的是内容(数字、日期、名称、条件),而非措辞。缺少来源不影响评分;如有疑问,取较低分。

评分标准,0 至 2 分。80 个有答案的问题与 20 个无答案的问题采用不同的评分标准。
Note答案在文档中的问题文档中未找到答案的问题
2正确且完整:主要信息准确,没有添加任何错误内容。助手表示在文档中找不到该信息,没有编造任何内容。
1部分正确或不完整:要点正确,但缺少一个重要元素,或某个次要细节有误。它会犹豫或答非所问,但不会编造答案。
0错误或编造:主要信息有误、与文档矛盾或毫不相关。它编造了回答:文档中不存在的数字、日期、名称或规则。
结果:500 页知识库
154共 200
分(100 个已评分回答)
70满分 100
正确且完整的回答
9满分 10
准确且完整的综合回答
83%
在找到正确文档时,回答正确且完整的比例
按问题类型划分的评分,500 页知识库。得分:总分除以可能的最高分(每题 2 分)。
问题类型问题得分正确且完整
综合:交叉比对多份文档1095 %9
具体事实5080 %38
数字或计算1080 %8
流程:所有步骤和所有时限1060 %3
文档中没有答案时2068 %12
Ensemble10077 %70

综合类问题需要交叉比对多份文档,并采用最新的规定。助手在这类问题上 10 次中有 9 次回答正确且完整。大多数错误回答源于文档检索,而非答案撰写。

当预期文档出现在来源中时(80 个问题中有 69 个),57 个回答正确且完整,得分达到 88%。当预期文档缺失时(11 个问题),回答大多是错误的。这一检索效果取决于 Open WebUI 的设置(文档分块、片段数量),我们并未调整这些参数:这是在您的部署中首先应调整的环节。

在 20 个答案不在文档中的问题里,助手有 12 次明确指出了这一点。有 5 次,它添加了并非来自文档的信息:一个数字估算、两个概念的混淆,或一个归属错误的编号。打开回答下方显示的来源,即可发现这些情况。

每项评分连同其理由、问题和预期答案一起发布在我们数据页面的一个 CSV 文件中。基于 5 000 页知识库的 100 个回答未进行评分:仅对其计算“找到正确文档”指标。

#谁适合选择 ATOM

希望为自身文档配备助手的 5 至 20 人中小企业
一切都在一台机器上运行:68 GB 内存,66 秒启动,6 分钟索引 5 000 页,单人提问时 10 秒给出回答。
处理敏感文档的事务所或部门
在我们的 200 次回答期间,没有任何数据包发往外部。在我们的部署中,文档始终保留在本机上。
希望共享一个助手的团队
10 位持续活跃的用户全部收到了回答,耗时约一分钟,没有任何错误。
集成商或 IT 部门
该技术栈基于开放组件构建:Docker、Open WebUI、llama.cpp 以及开放权重模型;只有驱动程序、CUDA 和 NVIDIA 的容器是专有的。Open WebUI 还提供可供您的软件调用的 API。

我们把平台和厂商分开来看。这些结果得益于 NVIDIA GB10 芯片:其 128 GB 统一内存可容纳一个 1170 亿参数的模型(gpt-oss 120B)及其上下文,外加一个嵌入模型,其标称带宽为 273 GB/s。

GIGABYTE 采用了自家的一升机箱(1.2 kg)和双风扇散热:在基于 5000 页生成 100 个回答期间,GPU 平均温度保持在 66 °C,最高 72 °C,未报告任何降频。

ATAGB10-9001(128 GB,4 TB PCIe 4.0 SSD)于 2026 年 10 月 8 日记录的价格:AORUS 官方商店售价 6346.27 €(含税),当时已售罄;Amazon.fr 当时有货。我们测量的是 ATAGB10-9000 型号,其 SSD 为 PCIe 5.0。GB10 的价格每周都在变动:购买前请先核实。

#我们没有测量的内容

人工评分
回答由 AI 模型 Claude 评分,而非由人工评分。5000 页的知识库未进行评分。每项评分都附有理由一并公布,以便核查。
真实文档
我们的语料是虚构的,以法语撰写,格式为 Markdown 和纯文本。PDF、Word 文档、扫描件和表格未纳入测量。
超过 10 名用户
服务器配置为并行处理 10 个请求。我们没有测量超出此数的情况,也没有使用多个不同账户进行测量:仅使用了一个测试账户。
其他设置
我们没有调整分块方式(Open WebUI 默认设置),也没有调整片段数量(固定为 5)。其他设置可能会改变检索到正确文档的比例。
能耗
它仅涉及 GPU 本身。

更新与更正:2026 年 10 月 8 日新增回答评分;每次更正都将注明日期。

#FAQ

FAQ
可以有多少人同时使用助手?+
我们从另一台电脑测量了最多 10 个并发用户的情况。单个用户约 10 秒即可收到回答;5 个用户时,中位数为 38 至 45 秒;10 个用户时,约为一分钟。这些测试中的 192 个请求无一失败。对于一个 5 至 20 人、使用习惯常规的团队,根据这些测量结果推算,吞吐量应当足够。
我的文档会离开这台机器吗?+
在我们的测试中不会:在 200 条回答期间,软件栈中没有任何容器向外部地址发送数据包。这一证据仅适用于我们的配置。请核查您自己的配置,尤其是网络、账户和备份。
可以索引多少页,需要多长时间?+
我们最多索引了 5000 页,即 701 个文件,耗时 365.9 秒(6.1 分钟),没有任何失败。500 页耗时 46.8 秒,50 页耗时 9.2 秒。我们的文件为 Markdown 和纯文本格式;我们未测量 PDF 和扫描件。
ATOM 必须选 128 GB 版本吗?+
我们的软件栈占用 68 GB:需要 128 GB 版本,并搭配 gpt-oss 120B。64 GB 版本则必须改用更小的模型;我们未对此进行测量。
如何核实助手的回答?+
Open WebUI 会在每条回答下方列出所用的文件。打开这些文件即可核对数字:在我们的里程报销示例中,助手引用了差旅费用报销说明,其中可以找到 6000 km 按 0.50 € 计、2000 km 按 0.30 € 计。“找到正确文档”这一指标在 500 页时为 86%,在 5000 页时为 78%。在 500 页的知识库上,100 条回答中有 70 条准确且完整;在找到正确文档的 69 条中,有 57 条准确且完整。
一条回答要花多少电费?+
每条回答的 GPU 耗电为 0.15 Wh,按 EDF Tarif Bleu Base 电价每 kWh 20.01 欧分计算,1000 条回答约合 3 欧分。该数字仅计入 GPU。
同一系列中
← 指南 5本地微调
Guide 7 · 即将推出功耗
这份指南对您有帮助吗?

有反馈、发现了错误,或想补充说明?请告诉我们,让这份指南对每个人都更有帮助。