二手服务器搭建私有AI平台：从选模型到部署推理引擎全指南

聊到私有 AI 平台，我猜很多人和我一样，第一反应是"搞台好机器装个界面就算搭完了"。但真到自己动手，尤其用的还是一台二手服务器，事情远没有这么简单。

这是这个系列的第三篇。前面两篇我分别讲了怎么淘硬件、装机、做系统虚拟化，以及把存储、网络和基础容器环境跑起来。说实话，到这一步，机器只是"活"了，离"能用"还差一大截。这一篇我打算把整个平台里最核心的一块补上：让服务器真正具备推理能力，把它变成一台随时可调用的私有 AI 服务。也就是说，从这章开始，你可以对着它提问、让它写代码、让它总结文档，而且所有数据都留在你自己的机房或者说自家角落里。

这篇文章适合两类人：一类是手里刚好有闲置服务器、想物尽其用的玩家；另一类是团队里想搭建内部 AI 服务、又不想把所有数据交到外部平台上的开发者。我会按照我自己实际操作的顺序来写，从选模型、装推理引擎，到接前端、调性能、踩坑复盘，尽量做到你照着做也能跑通。

1. 整体链路设计：三层架构与框架选型

1.1 前两篇的铺垫和本篇的任务

简单回顾一下。前两篇我做完了硬件安装、系统部署、虚拟化穿透和存储池规划，服务器的基础盘已经齐了。这套配置放在今天的消费级电脑面前算不上多豪华，但胜在稳定：双路老平台、大容量 ECC 内存，加上一张二手显卡，满打满算是一台"能干活"的机器。

但一台服务器如果只装了系统，那和一块会发热的砖头没有区别。这一篇的任务很明确，把它变成真正的私有 AI 平台。想达到这个目标，需要拆成四件事：

• 选一个合适的模型，并且把它下载到本地；
• 部署推理引擎，把模型加载起来对外提供接口；
• 做一个好用的对话界面，让非技术用户也能直接使用；
• 做一些基本调优，让响应速度、稳定性和资源占用达到可用的水平。

我先把我最终采用的架构摆出来。整个系统按三层来组织：最底层是模型文件，中间是推理引擎，最上层是接入层。模型文件负责存储参数，推理引擎负责把模型跑起来并提供标准 API，接入层则是对外服务的界面或脚本。这样拆分的好处是每一层都可以独立替换，以后想换模型、换前端，都不用动到底层。

1.2 推理引擎三选一：llama.cpp、Ollama、vLLM 怎么定

这是本次搭建最需要想清楚的一步。市面上主流的推理引擎就那几个，我逐个评估了一轮。

Ollama 是最省事的，装完就能拉模型跑命令，自带接口，适合想快速体验的人。但它有几个问题：一是对低配置机器的细粒度控制不够，可调参数有限；二是它把环境、模型和运行逻辑封装得太死，出问题时反而不好排查。如果是给没有运维经验的人用，Ollama 确实友好，但我这台服务器后续还要折腾多模型切换和自定义采样逻辑，直接用它等于给自己上锁。

vLLM 是生产环境里的"正规军"，吞吐量高，连续批处理做得好，适合高并发场景。但它对显存和驱动的要求比较高，尤其是 PagedAttention 带来的显存管理优势，需要一定规模的显存才能发挥出来。我这台二手服务器的显卡性能有限，跑小模型用 vLLM 属于杀鸡用牛刀，而且依赖装起来也相对繁琐。

最后选了 llama.cpp，理由很直接：依赖少、参数透明、单机推理性能足够。它几乎不挑硬件，CPU 也能跑，GPU 能加速多少就加速多少。对一台二手机器来说，"能用、可控、不折腾"比"极致的吞吐"更重要。我自己在选型时会把兼容性和排查成本放在第一位，llama.cpp 在这点上最合适。

为了把选型理由说得更直观，我列了一张对比表，是我在开始动手前做的笔记。

对比维度	Ollama	llama.cpp	vLLM
安装复杂度	极低	中等	较高
GPU 显存利用	一般	灵活可控	优秀
高并发吞吐	一般	中等	强
参数可调性	有限	细粒度	中等
排障难度	封装较深	日志直接	依赖复杂
适合场景	快速体验	个人/小团队自用	生产高并发

从表格能看出来，llama.cpp 不是每一项都占优，但每一项都不是短板。特别是当你的硬件并非顶级时，"中庸但稳定"才是核心诉求。

1.3 服务链路与目录规划

架构定了，服务链路也就清晰了。我的规划是这样的：

浏览器或脚本先访问前端的 Web 界面，前端再把请求转发给推理服务，推理服务读取本地模型文件计算，最终把结果流式返回给前端。中间所有通信都走 HTTP，接口遵循业界通用的标准模型服务协议。

做规划时我顺手把目录也定好了，避免后面文件放得乱七八糟。我的服务器上采用这样的目录结构：

/data/ai/models/ 模型文件统一存放 /data/ai/llama.cpp/ 推理引擎程序 /data/ai/frontend/ 前端界面数据 /data/ai/logs/ 日志输出

目录规划看似小事，但对后续维护影响很大。模型文件动辄几个 GB，如果和系统盘混在一起，磁盘占满时系统会变得不稳定。分开目录存放还有一个好处：以后想换盘、迁移，只需要把整个目录拷走就行，不用和系统文件纠缠。

2. 模型选型与下载：先把"脑子"装进服务器

2.1 显存内存算清楚，再定模型档位

模型是整个平台的大脑，选多大档位的模型，不是凭感觉，而是拿显存和内存一笔一笔算出来的。

我当时手头的硬件是这样的：显卡有 22G 显存，系统内存 128G。这个组合其实很有代表性，很多二手服务器都是"内存大、显存中等"，所以选型策略也相对明确。

先看量化模型的大小。以主流的 7B 级别模型为例，Q4_K_M 量化之后的模型文件大约在 4.4GB 左右，加上推理过程中的 KV Cache 和临时缓冲，总显存占用大约在 6 到 8GB。14B 级别的模型，Q4_K_M 文件大约在 8.8GB，整体显存占用大约在 12 到 15GB。34B 级别如果是 Q4 量化，文件轻松超过 20GB，加上推理开销就压不住了。

所以我直接把目标锁定在 14B 这个档位。这个档位既能把显存吃满，又不会因为容量不够导致频繁换出到内存，速度和效果之间比较平衡。如果你的显卡只有 8G 或 12G 显存，我建议老老实实选 7B 档，体验会顺畅很多。

选参数档位时我习惯用一个简单公式先粗算：

需求显存 ≈ 模型文件大小 × 1.3 + 上下文缓冲

这个 1.3 是我按实际经验取的系数，主要覆盖推理缓存和运行时开销。以 14B 的 Q4 量化模型为例，8.8 × 1.3 大约是 11.4G，加上一个常规长度的上下文缓冲，12G 到 15G 显存是比较合理的预期。这个估算虽然粗略，但比"感觉差不多"要可靠得多。

2.2 下载、校验与目录组织

模型选好了，接下来就是把文件拉下来。我一般从模型托管平台直接拉取 GGUF 格式的量化版本。GGUF 是当前 llama.cpp 生态里最通用的格式，一个文件包含完整的模型结构和权重，拷走就能用，非常省心。

如果你和我一样选了中文场景为主的模型，注意优先选指令微调版本，而不是基座版本。指令版经过对话对齐，回答问题时不需要额外套话术，开箱即用。基座版更适合做继续预训练或特殊微调，直接拿来聊天体验会差很多。

下载具体操作大概是这样的。先在模型页复制好下载地址，再用下载工具拉到 /data/ai/models 目录下。文件比较大，我建议使用支持断点续传的工具，避免网络抖动导致前功尽弃。

下载完之后，有一个步骤千万别跳过：校验哈希。模型文件在传输过程中如果出现损坏，加载时可能报错，也可能不报错但回答乱码。更麻烦的是，损坏的模型很难一眼看出来，总是要到用的时候才发现。所以我会在下载完成后跑一次哈希校验，和托管平台上的 SHA256 值做比对。

sha256sum /data/ai/models/qwen2.5-14b-instruct-q4_k_m.gguf

把输出的哈希值和页面对比，一致就说明文件完整。这一步只花十几秒，却能省下后面大把排查时间。

2.3 先用命令行跑通一次对话

我不建议一上来就直接启动服务，因为一旦出问题，你分不清是接口的问题、网络的问题还是模型本身的问题。更稳妥的做法是，先用 llama.cpp 的命令行工具直接加载模型，跑一次对话，确认模型文件本身没问题。

这一步我把它叫作"冒烟测试"。确认模型文件能正常加载、能输出正常内容之后，再去做 HTTP 服务封装，排障范围就会小很多。我当时就是在命令行先跑了一轮，发现某个量化等级下模型回答明显质量退化，于是换了另一个量化版本重新下载，避免了把坏模型带到服务层。

如果你也是第一次跑模型，看到控制台刷出一堆加载日志不要慌。重点看两个地方：第一，是否成功加载了权重文件；第二，是否成功初始化了 GPU 加速。只要这两步没有明显报错，就可以输入第一句话测试了。

3. 推理服务部署：把模型变成可调用的 API

3.1 编译带 GPU 加速的 llama.cpp

明确模型文件没问题之后，开始部署推理引擎。llama.cpp 的部署方式有两种：一种是直接下载官方编译好的预编译包，另一种是自己从源码编译。预编译包简单，但可能没启用你需要的加速指令集；自己编译稍微费点时间，但性能和功能都更有保证。

我个人倾向自己编译，特别是 GPU 加速这一项，必须编译进去才有。编译本身不复杂，把仓库拉下来，创建构建目录，让 CMake 自动检查本机的环境就行。

git clone https://github.com/ggml-org/llama.cpp.git cd llama.cpp cmake -B build cmake --build build --config Release -j

编译完成后，重点关注 build/bin 目录下的几个可执行文件。带 server 字样的程序就是后面要用的核心服务；不带 server 的那个是命令行工具，前面冒烟测试用的就是它。

编译过程中最容易遇到的问题是缺依赖。不同的 Linux 发行版，缺失的库名字不太一样，通常装上基础开发工具包就能解决。编译报错时不要慌，看日志里提示缺哪个头文件，搜索引擎一查基本都有答案。整个编译过程在我这台机器上大概十分钟左右，算很快了。

3.2 启动 HTTP 服务与关键参数

llama.cpp 自带一个 HTTP 服务端，启动后直接暴露标准 API，接口协议和主流大模型服务保持一致，这是整个部署链路里最顺的一环。

启动服务的命令我实际用的是这个：

./llama-server \ -m /data/ai/models/qwen2.5-14b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080 \ -ngl 99 \ --ctx-size 8192 \ --api-key changeme

我来逐个解释这几个参数，因为它们直接决定服务跑得稳不稳。

-m指定模型文件路径，这个不用多说。--host 0.0.0.0表示监听所有网卡，这样局域网内的其他设备也能访问，而不只是本机。--port指定服务端口。-ngl 99是最关键的参数，意思是把模型的层尽可能多地加载到 GPU 上。99 不是真的有 99 层，而是一个"尽量全放"的写法。层数加载得越多，推理速度越快。--ctx-size 8192是上下文长度，也就是模型能记住的对话上下文长度，这个值越大越吃显存。--api-key是访问密钥，相当于给服务加一把锁，防止局域网内其他设备乱调用。

这里要特别提醒上下文长度这个参数。它看起来越大越聪明，实际上对显存消耗很大。上下文从 4096 加到 8192，KV Cache 的显存开销会明显上升。如果你的显卡显存紧，建议先用 4096，跑稳了再往上加。

启动成功后，终端会输出监听地址和端口。这时你可以在本机用命令测一下接口是否正常，比如用 curl 发一个最简单的对话请求。能正常返回内容，就说明服务已经处于工作状态了。

3.3 用 systemd 托管服务，断开会话也不怕

走到上面一步，服务已经能用了，但还差一个关键环节：不能依赖当前终端会话。如果你直接在 SSH 终端里启动服务，一旦关掉终端或者网络断开，服务就跟着停了。这个坑我踩过不止一次，所以现在都会用 systemd 把服务托管起来。

在 Linux 系统上，创建一个服务单元文件，内容大概是这样：

[Unit] Description=Private AI Inference Service After=network.target [Service] ExecStart=/data/ai/llama.cpp/build/bin/llama-server -m /data/ai/models/qwen2.5-14b-instruct-q4_k_m.gguf --host 0.0.0.0 --port 8080 -ngl 99 --api-key changeme Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target

把文件放到系统服务目录下，然后执行systemctl daemon-reload，再执行systemctl enable和systemctl start，服务就在后台稳定运行了。之后你用systemctl status查看状态，用journalctl -u查看日志，管理起来非常顺手。

这一步的价值在哪儿？在于把"实验"变成了"服务"。以后断电重启，服务会自动拉起，不需要你每次都跑到机房手动敲命令。这也是二手机器做私有平台最需要养成的好习惯：一切以服务方式运行，而不是靠人工爱护。

3.4 容器的方案B：真想上 Docker 怎么搞

有人可能更习惯用 Docker 管理一切，这完全没问题，我也试过。不过要提前说一句：在二手机器上跑 Docker 加 GPU 直通，复杂度会比裸机部署高一点。

如果你坚持容器方案，大概的流程是先安装支持 GPU 的容器运行时，然后在启动容器时指定资源参数：

docker run -d \ --name llama-server \ -v /data/ai/models:/models \ -p 8080:8080 \ --gpus all \ ghcr.io/ggml-org/llama.cpp:server-cuda \ -m /models/qwen2.5-14b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080 \ -ngl 99

如果你所在的团队已经有一套标准的容器发布流程，用 Docker 能保持一致的管理习惯。但如果你和我一样是单机自用，我倾向裸机加 systemd，少一层中间环节就少一层故障点。

还有一点要提醒，容器镜像的 GPU 版本和宿主机驱动通常是绑定的。升级宿主机驱动后，容器镜像也要跟着适配，否则会出现明明设备存在却无法加速的情况。这个兼容性问题在旧硬件上尤其容易出现。

4. 前端与客户端接入：让家人同事都用上

4.1 Open WebUI 部署与模型对接

有了 API 服务，技术上讲你已经可以用脚本调用了。但要让不熟悉命令行的人也能用，还得有一个图形界面。我选的是 Open WebUI，它功能完整、界面干净，而且支持多用户登录，非常适合内部小团队使用。

部署方式我用的是 Docker，因为它依赖的服务比较多，直接装到系统里容易把环境搞乱。

docker run -d \ -p 3000:8080 \ --name open-webui \ --add-host=host.docker.internal:host-gateway \ -v /data/ai/frontend:/app/backend/data \ --restart always \ ghcr.io/open-webui/open-webui:main

启动后，打开浏览器访问服务器的 3000 端口，进入界面。首次进入需要注册一个管理员账号，然后进入模型管理设置，把后端服务的地址填进去。因为我前面把推理服务跑在本机 8080 端口，所以填的地址就是http://host.docker.internal:8080。填好之后再设置对应的 API Key，前端就和推理服务打通了。

这一步做完，你就能在网页上直接和模型对话了。整个界面和那些商用大模型产品长得几乎一样，支持流式输出、代码高亮、对话历史保存，内部用起来体验已经很完整。

4.2 权限、多用户和基础配置

前端跑通只是第一步，给内部用还得做权限管理。Open WebUI 自带用户体系，管理员可以创建多个账号，也可以开放注册然后审核。我建议内部使用一律关闭开放注册，改成管理员手动创建账号，避免任何人都能访问你的模型服务。

模型权限方面，可以在管理面板里限制哪些用户能用哪些模型。比如有人只想用轻量的 7B 模型做日常问答，有人需要 14B 模型做代码分析，都可以按账号区分。另外默认的生成参数也能改，比如 Temperature 采样温度，默认值偏高会导致回答发散，内部知识问答场景我一般会把默认温度调低一些，回答会更稳定。

到这里，整个平台对普通用户来说已经完全可用了：打开网页、登录、提问、得到回答。你已经拥有了一个真正意义上的私有 AI 平台，数据完全在内网流转，不经过任何外部服务。这一点对于注重数据隐私的团队来说是核心价值。

4.3 用 Python 调用接口做自动化

图形界面之外，我还习惯留一个 API 调用入口，方便写自动化脚本。比如让模型定期总结日志、批量处理文本、自动回复内部工单，都是走 API 来实现。

用 Python 调用其实非常简单，基于标准 HTTP 库就能实现。我贴一个最简例子：

import requests api_url = "http://127.0.0.1:8080/v1/chat/completions" api_key = "changeme" payload = { "model": "qwen2.5-14b-instruct", "messages": [ {"role": "user", "content": "用三句话总结私有化部署的优势"} ], "stream": False } resp = requests.post( api_url, json=payload, headers={"Authorization": f"Bearer {api_key}"}, timeout=120 ) print(resp.json()["choices"][0]["message"]["content"])

这里有几个细节要注意。接口的model字段只是标识名字，实际加载哪个模型由启动服务时指定的-m决定，填错也不会报错，但不能真正切换模型。stream设置为 False 时会一次性返回完整结果，适合脚本处理；设置为 True 时走流式，适合聊天场景。超时时间建议不要设太短，长文本生成可能耗时较久，设 30 秒以下的超时很容易误判为服务故障。

我实际拿这个接口做了一个简单的内部小工具，把一堆产品文档拖进去，让模型逐个生成摘要。整个过程不需要打开浏览器，脚本跑完把结果写进表格，效率比手动复制粘贴高很多。

5. 性能调优与实测记录

5.1 上下文长度、并发与采样参数怎么调

整个链路跑通之后，我开始花时间做性能调优。这里说的调优不是盲目调参数，而是找到当前硬件条件下的最佳平衡点。

第一个值得调的是上下文长度。前面我建议先用 8192，如果你的主要场景是长文档总结，这个值可以往上加；如果只是日常问答，4096 就够。上下文越长，显存占用越高，同时首字延迟也越高。我建议按实际场景来，不要追求最大值。

第二个是并发数。llama.cpp 启动时可以设置并发槽位，默认并发通常只有 1，意味着同时只有一个人能提问。多人使用时需要调高并发槽位，但要清楚一个事实：并发数和单请求速度是互相妥协的。并发越高，单个请求拿到的算力越少，每秒生成 token 数会下降。内部小团队 2 到 4 个并发槽位是比较合理的区间。

第三个是采样参数。Temperature（温度）默认偏高时模型回答更有创造力，但稳定性和准确性下降。我实测下来，内部知识问答场景温度设置在 0.3 到 0.6 之间效果最好，代码生成则建议更低。

这四个参数之间是联动关系。上下文、并发、采样共同决定了显存和内存的占用。调整时一次只动一个变量，观察效果，别同时改好几个，否则出了问题你根本不知道是哪个参数引起的。

5.2 实测数据：显存占用、速度与温度

调优如果没有数据支撑，就是玄学。我在服务器上跑了几轮实测，把几个关键数字记录下来，供你参考。

以 14B Q4_K_M 模型、上下文 8192、并发槽位 4 为例，实测显存占用大约在 13 到 15G 之间。单请求情况下，生成速度大约在每秒 18 到 25 个 token。这个速度没有顶级消费级显卡那么快，但作为内部助手完全够用，读起来像正常打字速度。

并发 4 路同时请求时，平均每个请求的生成速度会掉到每秒 10 到 15 个 token，响应明显变慢。如果是单人使用场景，其实没有必要开高并发，把并发槽位设成 2 就能兼顾速度和稳定性。

硬件温度方面也值得关注。连续推理半小时后，显卡温度稳定在 65 到 75 摄氏度之间，整机功耗大约在 250W 左右。如果发现温度长期超过 85 度，建议清理一下散热器灰尘，或者给机箱加一个机柜风扇。二手服务器最大的敌人不是老化，而是积灰导致散热失效。

这些数字会因为你用的模型和显卡不同而不同，但量级可以作为参考。跑出自己的数据后，对照着调参数会更有方向感。

5.3 流式输出与前/后段耗时的概念

用过商用大模型产品的话，你会注意到回答是一个字一个字蹦出来的，这就是流式输出。这个体验在自建平台上同样重要。

一次完整请求的耗时其实分两段：前段叫 Prefill，也就是理解你输入的阶段；后段叫 Decode，也就是逐个生成 token 的阶段。Prefill 阶段速度很快，Decode 阶段才是决定体验的关键。你在界面上感觉"回答得慢"，主要就是 Decode 阶段每秒生成的 token 数不够多。

理解了这两个阶段，你就知道该怎么优化了。如果是日常对话场景，模型生成速度快即可；如果是长文档分析场景，输入内容很长，Prefill 阶段的时间占比会明显上升，这时候调高上下文反而会拖慢响应。我实测下来，服务于长文档场景时，固定上下文为 8192 比 16384 的实际体验更好，因为更短的上下文让 Prefill 阶段更快。

流式输出还有一个附带好处：用户看到文字在滚动产出，心理等待感会大大降低。如果在代码里接入前端，务必把流式开关打开，体验差异非常明显。

6. 常见问题排查实录

6.1 高频问题速查表

搭建过程中我踩了不少坑，也帮朋友排查过几台机器。把高频问题整理成了一张速查表，遇到类似情况可以直接对号入座。

典型现象	可能原因	解决思路
模型加载时内存报错	模型文件过大或上下文过长	换更低量化等级，或调小上下文
服务启动成功但响应超时	并发槽位被占满	调高并发槽位，或减少同时请求数
GPU 占用率很低但 CPU 很高	模型层没有完全加载到 GPU	检查 GPU 层加载参数是否设置正确
回答内容明显错乱	模型文件损坏或量化等级过激进	重新校验文件哈希，换更高质量量化版本
局域网设备无法访问	服务只监听了本机回环地址	检查监听地址是否为 0.0.0.0
容器里 GPU 不可用	容器运行时与驱动不匹配	确认容器运行时版本和显卡驱动版本兼容

这张表基本覆盖了我从零搭建到现在最常碰到的问题。遇到报错先别急着重装，对照表里按可能性从高到低逐项排查，大多数问题十分钟内能定位。

6.2 我踩过的三个坑

第一个坑是量化版本选错。当时我图省事，下载了一个极低比特的量化版本，模型文件是小了不少，速度也快了，但回答质量明显下降。你要知道，量化等级本质上是拿质量换体积和速度，等级越低，模型"理解能力"损失越大。以后选模型，我建议优先选 Q4_K_M 或 Q5 级别，平衡性最好，不要为了追求低显存占用选过低的量化等级。

第二个坑是上下文开太大。有段时间我为了"让模型记得更多"，把上下文长度直接拉到 32768，结果服务频繁崩溃。排查后发现显存爆了。KV Cache 的大小和上下文长度高度相关，25600 的上下文直接吃掉了好多个 G 的显存。后来我把上下文降回 8192，服务才稳定下来。这个教训告诉我：上下文不是越大越好，够用就行。

第三个坑很典型：在 SSH 终端里直接启动服务，然后关闭了笔记本。第二天同事告诉我服务挂了，我一脸懵。后来才意识到终端会话结束，服务进程收到挂断信号就退出了。从那以后我再也没有手动终端跑过服务，统一改用 systemd 托管，开机自启加崩溃自动重启，世界清净了。

7. 成本账、现状盘点与后续扩展

7.1 一次性投入 vs 云服务租金

聊完技术，聊点现实的：这套自建平台到底值不值？我把成本算了一笔账。

硬件方面，二手机器加显卡加配件，一次性投入我控制在几千元以内。如果选择租用云 GPU 服务，按月付费，拿到同等配置的租金大约每月几百到上千元。一年多时间，这笔租金就足够把我这套硬件的成本覆盖掉了。而且硬件是一次性买断，用个三五年完全没问题。

运行成本方面，这台机器满载功耗大约 250W，按家庭电价算，每天 24 小时运行的电费大约每天几块钱。如果不需要 24 小时在线，还可以加一个定时开关机策略，把功耗再压一压。噪音确实存在，二手服务器的风扇声音不小，所以我把它放在了专门的设备间或阳台，日常基本不影响。

最大的隐性成本是维护时间。软件升级、驱动适配、模型替换，都需要投入时间。但话说回来，这个过程本身也是学习和掌控感的一部分，我觉得这笔时间花得很值。

7.2 现在这台服务器能干什么

目前这台服务器已经稳定运行了一段时间，我盘点了一下它能干的事情，其实比想象中多。

日常使用中最多的场景是私有问答助手。我把自己整理的笔记、技术文档导进去，让模型帮我检索和总结，数据完全不出内网。第二个好用的场景是代码辅助。把一段报错日志贴给它，让它分析可能的原因，响应速度虽然比不上云上的大模型，但胜在私密和没有调用次数限制。

我也尝试过让模型批量处理文本：给一堆产品描述，让它按统一格式输出摘要。跑了几轮之后，输出格式逐渐稳定，维护成本很低。严格来说这还不算完整的知识库 RAG，但对内部文档整理已经很有帮助。

整个平台最核心的价值其实不是"模型多聪明"，而是"数据完全由你掌控"。一次部署之后，模型、接口、界面、数据全部落在自己的硬件上，不依赖任何外部服务，没有按量计费的焦虑，也没有敏感数据外泄的风险。

7.3 后面还能怎么玩

平台搭好之后，扩展空间其实很大。我目前正在规划三个方向。

第一个方向是接入知识库。把团队内部的文档、会议纪要、操作手册统一导入向量库，配合检索增强生成，让模型回答问题时先查内部资料再作答。这是私有 AI 平台最实用的进阶方向。

第二个方向是多模型切换。现在我只部署了一个模型，但 llama.cpp 其实是支持同时加载多个模型的，可以按任务类型路由到不同模型。日常问答用轻量模型，深度分析用大模型，资源利用会更高效。

第三个方向是接 Agent 能力。让模型不只是聊天，还能调用工具、执行任务，比如自动跑脚本、抓取内部系统数据、生成日报。这会把平台从"问答机"升级成"数字员工"。

最后分享一个我个人的体验：整套设备刚点亮的时候，我只是觉得"能跑起来了"；等到家人和同事真的每天都在用、也确实觉得好用的时候，那种满足感是买一台云服务器给不了的。如果你手里也有一台闲置的服务器，不妨按这个思路试着把它变成你的私有 AI 平台。整个过程偶尔会让人抓狂，但每一次把问题解决掉，你对这套系统的掌控感就会多一点，这种踏实感，外面那些付费 API 也给不了你。