企业官网建设流程全解析

第三篇了，先接个前情。前面两篇我把一台二手服务器的硬件选型、系统安装、容器基础环境都折腾了个遍，机器总算是“活”过来了。但这台机器能干什么，说实话，在刚点亮屏幕的那一刻我心里也没底。搭建私有 AI 平台这件事，最初的动力很简单：不想把数据和对话记录都交给公网服务，也想有块能随意折腾的“自留地”。当时朋友劝我别折腾，说二手硬件跑大模型纯属受罪，云主机按小时租也就几块钱。我当时嘴上没反驳，心里想的是：“我自己有 24G 显存，想怎么玩怎么玩，还不用看别人脸色。”现在三个月过去了，这台二手服务器已经在我手底下连续运行了九十多天，中间还扛过了两次小区检修断电。这第三篇我就专门聊聊，从“能开机”到“真能干活”这段路，我到底踩了哪些坑，又是怎么把模型选型、推理编排、多用户接入、性能调优和日常运维一步步落地的。

1. 私有 AI 平台到底该跑哪些模型：我的选型思路

1.1 先想清楚用途，再选模型

很多人一听说自建 AI 平台，第一反应就是“把最大的那个模型装上去”。这个想法在云端租几张顶级显卡可能没问题，但在二手服务器上就是灾难。我一开始也犯过这个毛病，盲目下了一个超大体积的模型文件，结果光是加载权重就把内存吃光了，连系统都被迫开始换页，整机卡成幻灯片。那次的教训让我学乖了：选模型的第一步是先想清楚这台机器到底要服务谁、要跑什么场景。

我的实际情况是：家里四个人，加一个小团队五个人，日常需求集中在三类。第一类是最常见的通用问答，包括写邮件、改文案、翻译、整理会议纪要，这类任务对模型的知识覆盖和中文能力要求中等偏上；第二类是代码辅助，主要是补全函数、解释报错、写单元测试，这类任务对响应速度极其敏感，等十秒才蹦出第一个字根本没法用；第三类是文档检索，把几十份 PDF 和内部笔记收集起来做语义搜索，这需要单独的向量化模型，而不是让通用对话模型去硬扛。

明确了三类场景之后，选型就有方向了。通用问答我用了一个 7B 规模的量化模型作为主力，追求速度和稳定；代码辅助单独接了一个专业代码模型，虽然参数规模不大，但对编程语法的理解明显更强；文本向量化则用专门的 Embedding 模型，配合一个简单的向量数据库，实现“把文档喂给机器人当背景知识”的效果。很多人在小团队里部署私有 AI，只盯着对话模型，把 Embedding 模型这个环节给漏了，后面等你想做“文档问答”的时候才会发现还得回头补课。

1.2 量化模型、显存和速度：我的对比记录

模型选型的核心矛盾永远是显存、速度和输出质量的三角拉扯。完整精度的模型文件动辄十几 GB 甚至几十 GB，以我手头这块 24G 显存的卡来说，跑小参数模型还能塞进去，跑稍大参数的模型就必须上量化。量化说白了就是把模型权重从 16 位浮点数压缩到 8 位或 4 位整数，体积变小、计算变快，代价是精度损失。这就像一个厨师把所有菜谱从精装本压缩成口袋本，做出来的菜大体没错，但有些细节调味会差一点。

我做了三组量化方案的对比测试，直接说结果。第一组是 4 位 AWQ 量化的小参数模型，显存占用最低，生成速度最快，实测在我的机器上能跑到每秒 40 到 50 个 token，日常问答体感跟网页版差不多；第二组是 4 位 GPTQ 量化的小参数模型，表现略慢一点，但接口兼容性和工具调用能力更好；第三组是中等参数规模的量化模型，输出质量确实上了一个档次，回答更有条理，但速度掉到了每秒 20 到 30 个 token，连续对话时明显能感觉到“卡”。最终我把主力定在了第一组方案上。

说实话，对于小团队和家庭使用场景，“稳定输出 + 快速响应”比“偶尔惊艳但经常等待”重要得多。我现在的配置是：主力服务 7B 量化模型，当用户明确需要更高质量回答时，可以在请求参数里临时指定调用另一个更大规模的模型。这种“多模型按需切换”的思路，比单一模型吃遍所有场景要灵活得多，也更容易在一台二手服务器上落地。

2. 推理服务编排：从“能跑”到“好跑”

2.1 推理引擎选哪个

模型文件本身只是一个“大脑”，要让它真正对外提供服务，还得有一个推理引擎把模型跑起来，并且暴露成可以调用的接口。目前开源生态里最常用的两个推理引擎，一个主打高吞吐和 OpenAI 兼容接口，一个主打轻量化和极低资源占用。你可以把前者理解成一个功能完备的餐厅后厨，菜品多、出菜快，但需要足够大的厨房空间；后者更像街头快餐车，一个人就能操作，出餐也不慢，但菜式相对简单。

我的建议是：如果你手上显存充足，且希望平台后续能对接各种现有工具，直接选择前者，它自带的 API 接口可以直接伪装成业内标准格式，上层应用替换后端不需要改任何代码。如果机器比较老、显存紧张，或者你只需要一个命令行问答工具，后者更合适。我最初两台都试过，后来因为要接 Web 界面和手机端，统一换成了前者，运维上也只需要维护一套服务。

这里有一个很关键的概念叫 KV Cache。语言模型在生成回答的时候，会把已经算过的历史上下文缓存下来，避免每次生成下一个 token 都从头计算。这个缓存非常吃显存，上下文越长，缓存占用越大。所以推理引擎通常会有一个参数让你控制“给缓存留多少显存”，另一个参数限制最大上下文长度。我在调优时把最大上下文长度从默认的 32K 降到了 16K，显存余量立刻多出了 6G，可以同时多跑两个并发请求，对日常使用几乎没有影响。

2.2 多模型同时服务与显存分配

小团队使用私有 AI 平台，最大的尴尬是不同的人想用的模型不一样。有人喜欢响应快的，有人追求质量高的，还有人只想用代码补全。如果同时把三个模型常驻显存，24G 显存很快就不够用了。我的解决方法很简单：主力模型常驻显存，其他模型按需加载。也就是说，只有收到特定请求时，平台才会把备用模型临时拉起来，服务完一段时间没有新请求就自动卸载，把显存还给主力模型。

一开始我用了一个定时脚本，每五分钟检测当前是否有请求在跑，如果空闲就手动卸载备用模型。后来发现推理引擎自带 API 本身就支持多模型管理，可以直接注册一个“备用模型”的实例，并设置它的启动策略为按需。这样上游请求进来时，引擎自己会判断要不要唤醒备用模型，不需要我再写额外的调度脚本。这个配置改完之后，我基本就不用管显存分配这件事了。

这里要特别提醒一个坑：不要让“按需加载”变成“频繁换卡”。如果用户每隔几分钟就调用一次备用模型，模型就会反复加载、卸载，每次加载都要花几十秒，既浪费时间又把显存占得满满的。我在后台设置了一个冷却时间，备用模型被加载后至少保持半个小时，防止这种抖动。调完这个参数之后，整个平台的响应稳定了很多。

2.3 一个能抄作业的容器编排模板

我的推理服务全部跑在 Docker 容器里，编排用的是 Compose 文件。所有人都说容器化部署很“现代”，但其实核心价值只有一个：把环境依赖和配置固化下来，换机器也能一键拉起。我的 Compose 文件里包含了三个核心服务：推理主服务、Embedding 服务、网关代理服务。容器配置里挂了 GPU 设备、模型目录、日志目录，并且设置了资源限制和自动重启策略。

我给一份简化后的配置片段供参考：

services: llm-server: image: my-llm-image:v1 runtime: nvidia environment: - MODEL_NAME=main-7b-awq - GPU_MEMORY_UTILIZATION=0.92 - MAX_MODEL_LEN=16384 volumes: - /data/models:/models - /data/logs:/logs restart: unless-stopped ports: - "8000:8000" embedding-server: image: my-embedding-image:v1 runtime: nvidia environment: - MODEL_NAME=embedding-v1 volumes: - /data/models:/models restart: unless-stopped ports: - "8001:8001" gateway: image: caddy:2 volumes: - /data/caddy/Caddyfile:/etc/caddy/Caddyfile ports: - "8080:80" restart: unless-stopped

注意那个GPU_MEMORY_UTILIZATION参数，它告诉推理引擎可以用多少比例的显存。我设成 0.92，意思是不让缓存把显存彻底占满，留一点余量给显示输出和其他小进程。这个值不建议设成 0.99，虽然看起来利用率更高，但一旦有别的进程占用一点显存，推理引擎就会因为分配失败而直接崩溃。我身边已经有好几个朋友栽在这个参数上了，都是“想榨干最后一点显存”导致的，实测下来 0.90 到 0.93 之间是最稳的。

3. 把小团队接进来：用户、权限和配额

3.1 统一入口和认证

平台跑通之后，下一步就是让家人和团队成员接入。如果直接把推理服务的端口暴露给所有人，问题马上就来了：没有任何身份区分，谁也不知道某个请求是谁发的；更糟糕的是，一旦有人提交了一个超长文档，显存就会被这个请求独占，其他人的体验直接归零。所以我用网关做了一个统一入口，所有用户都通过网关访问，网关负责做身份认证、请求转发和限流。

认证这块我没有引入复杂的单点登录系统，就用最简单的做法：每个用户分配一个独立的 API Token，客户端带着 Token 请求网关，网关校验通过后转发给推理服务。对于家庭成员来说，他们不需要理解 Token 是什么，我会帮他们把 Token 配置好，手机上装一个客户端就能直接用。对于小团队里的开发者，我会给他们发 Token，并告诉他们如何用命令行工具发起请求，方便他们调试脚本。

这个“人人都有独立身份”的做法，还有一个额外好处：日志里可以清楚看到每个用户的使用量。我每个月会导出一份统计数据，看看谁在用、用了多少、占用了多少算力。发现某个用户请求量异常大的时候，我会找他私下聊一下是不是有自动化任务在跑，避免影响其他人的体验。如果你打算在公司内部推广私有 AI 平台，这个日志审计能力几乎是必须的。

3.2 配额与并发限制

个人自建平台最常见的问题是“一个人把资源全占了”。我见过有人让 AI 生成一篇 8000 字的长文，结果整个平台卡了五分钟，所有人都来问我“是不是挂了”。为了解决这个问题，我在网关层做了两层限制：第一层是限制每个用户每分钟的最大请求数，第二层是限制单次请求的最大上下文长度和最大输出长度。

我给出的配额表长这样：

千万别小看这张表。限流之后，最明显的变化是平台的“尾部延迟”降下来了。以前总有个别请求慢得像蜗牛，现在每个请求都能稳定在几秒内返回。这里也建议把“单次最大输出长度”设成一个合理的值，比如 2048 或 4096，防止有人让模型把一整本书从头写到尾。这不是限制用户的自由，而是保护整台机器的呼吸空间。

3.3 数据与隐私边界

私有 AI 平台一个很大的卖点是数据不出内网，所有请求都在自己的服务器上处理。但这不代表用户就可以随意上传一切内容。我在搭建完成之后给所有用户发了一份简单的使用指南，里面明确了两件事：第一，模型是基于公开语料训练的，不要把它当成可靠的专业顾问，涉及医疗、法律、财务的建议需要人工二次确认；第二，尽量不要把包含个人身份信息、密码、银行账号等敏感数据发给模型，因为这些数据会留在本地的对话记录里，如果服务器磁盘损坏或者被入侵，后果依然很严重。

我还做了一个“对话记录默认只保留 30 天”的策略，定时任务会自动清理历史记录，避免对话文件无限膨胀。运维上有一条经验：私有平台的安全责任全在自己身上，比用公网服务要有更强的安全意识，因为公网服务至少有专业的安防团队盯着，你的二手服务器只有你自己。这件事想清楚之后，很多部署决策就会变得保守得多。

4. 性能调优和一台服务器的成本账

4.1 三个最关心的性能指标

判断私有 AI 平台跑得好不好，我会看三个指标：首 token 延迟、生成速度、并发吞吐量。首 token 延迟指的是用户点击发送到屏幕上出现第一个字的间隔，类比下馆子，就是你坐下之后到第一道菜端上来的时间。生成速度是每秒能蹦出多少个字，相当于上菜速度。并发吞吐量是整台机器同时能接待多少桌客人。

我在调优前先记录了这三组数字。首 token 延迟通常在 200 到 500 毫秒之间，体感很流畅；生成速度就是前面说的每秒 40 到 50 个 token；并发吞吐量则比较惨，同时处理三个以上请求时，每个请求的速度都会明显下降。这说明瓶颈不在模型大小，而在显存带宽和算力上限。明确了这一点，我就知道优化方向不是换更强的大模型，而是想办法让现有的资源服务更多并发请求。

4.2 实测调参记录

我做的第一个优化是把批量推理参数打开。批量推理的意思是，当多个请求同时到达时，推理引擎会在一个批次里同时处理它们，而不是一个接一个排队。这就好比后厨拿到四份订单，如果分别做四道菜，每道都要重新开火；如果四份是同一道菜，就可以一起下锅，效率立刻翻倍。打开批量推理之后，并发三个请求时每个请求的速度下降明显减轻了，整体吞吐量提升了不少。

第二个优化是调低最大上下文长度。很多用户根本用不到 32K 的上下文，但我之前把上限设得很高，导致显存被缓存预占了大半。把上限降到 16K 之后，显存余量多了很多，相当于多出了几条“排队通道”。实际使用中，真正需要超长上下文的场景少之又少，反而是一些用户会一次性粘贴几千字的文档进去问问题，这时候 16K 也足够用了。

第三个优化比较冷门：给模型设置更低的温度参数。温度参数控制的是回答的随机性，数值越高越有创造性，越低越保守。对于小团队的实用场景，我把默认温度从 0.8 降到了 0.6，回答明显更稳定，废话更少。这个参数不需要改系统配置，在 API 请求参数里就可以指定。

4.3 成本账：自建和云端怎么选

很多人觉得自建私有 AI 平台的成本一定比用云服务低，其实这件事得算细账。我把自己这台机器的成本列出来，给大家一个参考。硬件整体投入大约一万多元，包括二手服务器主机、两块 GPU、内存、固态硬盘和一堆线材；整机功耗实测在 380W 左右，按一天 24 小时开机算，每天大概 9 度电，居民电价约 0.6 元/度，一年电费大约 2000 元；再加上偶尔换风扇、换硬盘的维护费用，一年的总持有成本大约在 4000 到 5000 元。

作为对比，我查了一下主流云 GPU 实例的价格，按每小时 3 元估算，如果你想每天用 4 小时，一个月就是 360 元，一年 4300 元上下。乍一看，自建并没有便宜很多，而且还要自己承担硬件故障、运维、升级的痛苦。但如果你把“数据隐私”和“7x24 随时可用”这两个维度算进去，自建的优势就会凸显出来：云服务是按小时计费的，你不可能 24 小时都开着，而自建服务器是随时待命的，凌晨三点想跑个任务也没人拦你。

这里我算了一笔按每年 365 天、每天 24 小时不停机的理论账。如果完全按云端按小时价格跑一年，费用会是 2.6 万元左右，自建一年的电费加折旧明显低于这个数。当然，现实中没人会租一台云主机一年不关机，所以这个对比意义不大。真正有意义的是：如果你有超过三四个固定用户，每天使用时长加起来超过 6 小时，自建的性价比就会开始显现。而且服务器是自己的，想怎么折腾都行，这种“拥有感”无法用钱衡量。

5. 三个月运维实录：我踩过的坑和养成的习惯

5.1 断电恢复：一次教训换来的服务编排

第一次停电发生在一个周六下午，小区变压器检修，整栋楼断了电。当时我在外面，没来得及远程关机，来电之后服务器倒是自动开机了，但所有容器都没有恢复运行。我回到家打开终端一看，Docker 服务起来了，但是里面的推理服务、网关、向量库全部处于停止状态，等于整个 AI 平台瘫痪了半天。

排查之后发现原因有两个：一是我的 Docker 容器没有配置自动重启策略，容器退出后不会自动拉起来；二是推理服务依赖模型目录，而模型目录挂载的网络文件系统在开机时还没准备好，导致容器的启动顺序混乱。解决办法是给所有容器加上restart: unless-stopped策略，同时用系统服务单元来管理容器依赖关系。现在我配置了一条简单的启动链路：先确保网络存储挂载就绪，再启动 Docker 服务，之后才拉起推理容器和依赖服务。自从做了这个调整，第二次断电之后服务器自动恢复了，等我回家时所有服务已经在线，群里的朋友甚至没察觉到断电这回事。

5.2 显存泄漏与定时重启

显存泄漏这件事，不跑长周期还真发现不了。我的推理服务一开始连续跑了五天，刚开始一切正常，到第三天的时候，偶尔会有请求变慢的情况，我当时没在意。到第五天，有用户反馈“转圈圈转半天也不出结果”，我一看监控面板，显存占用已经飙到 100%，新进来的请求连模型权重都加载不了，全在排队等待。

排查过程比较痛苦，一开始我怀疑是模型文件损坏，重新下载了一遍，没用；又怀疑是驱动问题，重装驱动，还是没用。最后查了推理引擎的日志才发现，长时间运行后，模型的缓存没有完全释放，每次请求结束后都会残留少量显存碎片，积少成多就把整块显存啃干净了。这个问题的根源在推理引擎对缓存的管理策略，我不能直接改它的源码，稳妥做法就是定时重启容器，让显存重新初始化。我现在设置了一个每天凌晨四点的定时任务，重启推理服务，尽量选在没人用的时候，重启过程只要 40 秒左右，对实际体验影响几乎为零。

另外我还写了一个监控脚本，每五分钟检查一次显存占用，如果持续超过 95% 就自动重启容器。这个脚本很简单，用的是基础命令加日志记录，但关键时刻真的能救人命。从此之后我再也没遇到过“平台静默死亡”的情况。

5.3 我现在的运维清单

这三个多月跑下来，我慢慢形成了一套固定的运维节奏。每天早上花两分钟看一眼监控面板：GPU 温度、显存占用、磁盘剩余空间、容器运行状态。每周五晚上做一次数据备份，把模型配置、容器定义和用户数据增量备份到另一块独立的硬盘上。每月导出一次用户使用统计，看看有没有异常的请求模式。每次升级模型之前，我会先在本地跑几个测试问题，对比新旧版本的输出质量，再决定要不要切过去。

对于模型文件的存放，我坚持“只保留当前版本和一个备用版本”的原则，不把旧版本全都堆在磁盘里。很多人喜欢“先下载再说”，结果一个模型几十 GB，几个模型下来磁盘就爆了。我的经验是：模型升级前确认新版本足够稳定，再删除旧版本，不要盲目囤积。日志文件同样需要定期清理，我用日志轮转功能把每个容器的日志大小控制在 200MB 以内，超过的部分自动压缩归档，每周再手动清理一次归档目录。

说实话，这套平台从一开始的“折腾着玩”到现在的“稳定服役”，本质上靠的不是什么高深技术，而是把运维动作规范化和自动化。我现在的习惯是，每周五看一眼监控面板，顺手清一下日志；模型出新版也不急着追，先在自己账号上试两天再切换。这台二手服务器已经连续运行了将近一百天，除了两次断电之外没有出过任何大问题。回头看，当初花大把时间折腾硬件和部署，其实真正的门槛不在于“会不会装”，而在于“想清楚拿它干什么”。一台二手服务器最珍贵的不是那些硬件参数，而是它给了你一块完全由自己掌控的实验田。如果你想搞一台类似的机器，我建议你不要一上来就盯着最大模型、最强算力，先把小团队的日常需求梳理清楚，再按需选模型，按量做配额，按计划搞运维，这台机器才能真正成为你的私有 AI 平台，而不是一台落灰的噪音源。