企业官网建设流程全解析

1. 为什么这篇要聊“把模型真正跑起来”这件事

前两篇分别写了硬件选型和基础环境搭建，很多朋友私信问我，二手服务器到手之后，除了跑点容器、挂个网盘，到底还能做什么。这篇我直接说结论：最有实用价值的方向，是把本地模型服务跑起来，让它解决实际工作里的具体问题。可能有人觉得这一句是废话，但真做起来，坑比想象中多得多。

我先交代一下目前的硬件底子。一台二手双路服务器，具体型号不写了，免得有广告嫌疑，CPU 是两颗十年前的老至强，内存 64G，没有独立显卡。这台机器做不了重型训练，也跑不动特别大的模型，但在 CPU 推理这条路上，只要选型合理，依然能提供非常可用的私有 AI 服务。我把它定位成：一台只对家里局域网和特定办公网段开放的小型 AI 服务器，提供模型推理、私有知识库问答、简单文本处理这几类能力。

这篇实践记录围绕的核心问题只有一个：在没有高端显卡、没有海量内存、没有复杂集群的条件下，怎么把私有 AI 平台搭得既够用又稳定。我会把这台二手服务器上从选型、部署、调优，到实际跑起来踩坑的完整过程写清楚，参数、命令、测试数据都会给全。如果你手里也有一台配置差不多的老旧服务器，又想自己搞一套私有 AI 服务，这篇文章可以直接当操作手册来用。

2. 先从选型说起：二手机器上的模型和框架要怎么定

2.1 模型选择：7B 到 13B 的量化模型是甜点区间

在决定跑什么模型之前，我先把这台机器的推理上限粗算了一遍。64G 内存对 CPU 推理来说还算宽裕，但真正限制吞吐的是内存带宽和 CPU 的 SIMD 指令集。老的至强处理器支持 AVX2，不支持 AVX-512，这决定了它在量化模型上的表现会比现代服务器差一截，但也不是不能跑。

我的实际建议是：参数量在 7B 到 13B 之间的量化模型比较合适。具体来说，Q4_K_M 或 Q5_K_M 这种 4-bit 到 5-bit 量化版本，模型文件体积大约在 4GB 到 8GB 左右，配合 64G 内存完全装得下，还能留出充足的内存做上下文缓存。我现在主力用的是 13B 级别的中等量化模型，大约 7GB 文件，加载后占内存 9GB 左右，同时跑两三个服务进程也不吃力。

这里有一个很多人容易忽视的点：CPU 推理的瓶颈通常不在模型大小，而在于上下文长度和并发数。上下文越长，每次生成需要处理的 KV Cache 就越大，计算量呈非线性上涨。所以我把上下文限制在 4096 到 8192 之间，再长就不是这台机器能舒服承担的了。

2.2 推理框架：为什么选了 CPU 友好的路线

市面上主流的推理框架很多，有偏 GPU 的，也有官方出的 C++ 运行时。在我这个没有显卡的环境里，最合适的选择是两条路：一条是 gguf 格式搭配原生 C++ 推理程序，另一条是基于纯 CPU 优化的其他推理后端。我最后选了前者，原因很直接：

• 它对 CPU 推理的支持最成熟，支持 AVX2 指令集优化，老 CPU 也能用上全部指令特性。
• 生态里现成的量化模型文件最多，不需要自己处理格式转换。
• 提供一套简单的 HTTP 接口，可以被各种应用直接调用。
• 进程模型简单，一个模型一个进程，出了问题好查、好杀、好重启。

选框架时还有一个维度很多人会忽略，就是服务化能力和周边生态。我需要的不是一套测试用的命令行工具，而是一个能长时间运行、能被外部应用稳定调用的后端服务。这个框架有内置的 OpenAI 兼容接口，这意味着我后续接任何工具都不用再做协议适配，直接用标准方式请求就行。

2.3 选型成本测算：一台旧机器到底能省多少

很多朋友问我，买新机器和用旧机器，成本差距到底有多大。我按自己的情况算一笔账：

• 二手服务器整机成本，大约相当于一台中端家用台式机的三分之一。
• 内存是捡漏来的 DDR3 服务器内存，1G 的价格非常便宜，64G 总花费不到一顿饭钱。
• 没有购买任何 GPU，省掉了开销最大的部分。
• 整机功耗待机大约 90W，满载跑推理大约 200W 出头，按一天开 8 小时算，电费开销远低于租用一台同配置云主机。

如果去租公有云的 CPU 实例，一个月费用就能抵上这台机器硬件成本的相当一部分。所以二手服务器做私有 AI，本质是用一次性硬件投入，换取长期的推理成本归零。前提是你能接受它的性能上限——吞吐量不高、并发有限，但对个人和小团队来说完全够用。

3. 部署过程实录：从空系统到能聊天的模型服务

3.1 基础环境检查

如果你的系统是前两篇里说的最小化安装，那在装推理环境之前，先确认几项硬指标：

grep -E "avx2|avx512" /proc/cpuinfo | head -n 1 free -h df -h /data

没有任何输出说明这台 CPU 连 AVX2 都不支持，那就别跑量化推理了，老机器只能老老实实做存储或跑轻量服务。内存方面，建议至少留出模型文件体积两倍以上的空闲内存。磁盘方面，模型文件不算大，但几十 G 的余量还是要有的，因为后面可能同时放好几个不同用途的模型。

我按常规路径装了基础依赖，包括编译工具链、git、Python 虚拟环境工具，再把推理框架的源码拉下来编译。编译时间在二手机器上会长一些，半个小时左右属于正常，不用慌。

3.2 模型文件怎么选、怎么放

模型下载我建议先在自己的电脑上下好，再通过局域网传到服务器，而不推荐直接在服务器上跑下载脚本。原因有两个：一是老服务器的网络稳定性参差不齐，断点续传不一定好用；二是模型文件比较大，在服务器上用浏览器下载容易超时。

拿到模型文件后，目录规划很重要。我按这个结构组织：

/data/models/ ├── chat/ │ └── 13b-q4_k_m.gguf └── embed/ └── m3e-base/

模型文件放一个目录，嵌入模型放另一个目录，后面接知识库的时候就能直接按路径引用。建议不要把所有文件堆在一层目录里，后续维护会非常痛苦。

下载完成后，记得先校验一下文件完整性。我在传文件时遇到过几次静默截断，模型文件缺了尾巴，加载到一半直接报错，排查了很久才发现是传输问题。校验方式很简单，下载页通常有 SHA 值，传完后算一遍对比即可。

3.3 启动第一个模型服务的完整步骤

这一步我直接给出一套经过验证的启动流程。先起一个后台会话，再在会话里加载模型：

screen -S ai-service

进入会话后执行启动命令，参数按我调过的来：

./runner \ -m /data/models/chat/13b-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080 \ -c 4096 \ --threads 16 \ --mlock

几个参数单独说一下：

• -c 4096是上下文长度。我不是为了省内存，而是为了让单次请求的响应延迟稳定在可接受的范围。上下文拉长后，CPU 算力就会大量花在历史 token 的处理上，交互体验会变得很拖沓。
• --threads 16不是越大越好。老 CPU 开超线程后，物理核心和逻辑核心之间有资源争抢，实测下来，取物理核心数左右的效果反而最好。我用 16 是因为这台机器有两个物理 CPU，每个 8 核。
• --mlock强制锁页，避免模型被换出内存。这条很重要，不加的话，用着用着可能出现响应突然变慢的情况，就是模型页面被换到交换分区了。

等启动日志出现模型加载完成的提示后，先用本机 curl 测一下 API 是否正常响应：

curl -s http://127.0.0.1:8080/v1/models

只要返回的 JSON 里能看到当前模型 ID，就说明服务已经起来了。这时我可以从另一台电脑访问 8080 端口。如果访问不通，多半是防火墙或监听地址的问题，把监听地址设成0.0.0.0以后，记得确认系统防火墙是否放行了对应端口。

4. 把服务接到日常工具里：本地模型要能干活才算数

4.1 打通局域网访问：从一台机器到整个办公网

模型服务在 8080 端口跑起来以后，需要让局域网内其他机器也能访问。我在路由器和服务器本地防火墙两层都做了放行，并且只允许内网网段访问，不暴露到公网。

这一步的实际配置可以这样写：

ufw allow from 192.168.0.0/16 to any port 8080 ufw enable

规则表示仅内网可访问该端口。云服务器或家用路由器的管理后台里如果有端口转发设置，记得检查一遍，别把自己暴露到外网。

随后在另一台机器上验证连通性。我习惯先试最基本的模型列表接口，再试真实对话接口。如果局域网通但请求响应很慢，优先排查是不是启动参数里线程数没调对，或者模型文件放在机械硬盘上导致加载慢。

4.2 隐私优先的聊天助手接入姿势

这个私有 AI 平台我日常用得最多的场景，是接到团队的内部问答工具里。因为接口兼容 OpenAI 格式，所以无需改代码就能让很多现成应用直接指向这台服务器。

实际使用中，我需要控制好三件事：

• 并发数。本地 CPU 推理不是并发友好的，同时来八个请求不会并行加速，反而会让每个请求都变慢。我在网关层限制最大并发数，比如同时只能处理两个请求，其余排队。
• 超时。模型的生成速度和 GPU 没法比，外部客户端默认的超时时间经常不够用。我把客户端超时设成 120 秒以上，避免正常的长文本生成被误判为超时。
• 请求大小。限制单个请求的最大输入长度，防止有人一次性塞进来一篇超长文档，导致服务卡死。

用了一会儿你就会发现，私有模型在正常业务场景下足够可靠，点对点的聊天问答、代码片段解释、文本改写、摘要提炼这些任务，它都能完成。唯一的限制是它不能联网搜索最新信息，所以在时效性要求高的场景下需要配合外部的检索组件。

4.3 知识库问答是怎么用小模型加出大效果的

纯靠模型自身的知识，很多内部资料它是不懂的。我想让它能回答关于团队内部文档、项目规范、产品说明这类问题，于是给它接了一个本地知识库。

整体逻辑简单说：先把文档切成小段，用嵌入模型转成向量，存到本地向量数据库；提问时，先把这个问题的向量和库里所有向量做相似度检索，挑出最相关的内容片段；最后把这些片段和问题一起交给语言模型生成回答。

这个过程里最重要的选型是嵌入模型。我用的m3e-base是一个体积很小的本地嵌入模型，跑起来占用资源极少，但中文语义理解能力足够应付大多数内部文档检索场景。相比直接拿大模型做嵌入，这种小尺寸、独立部署的嵌入模型更适合老旧服务器。切分策略也值得讲几下：我把文档按 300 到 500 个字符切成一段，段与段之间保留少量重叠，这样既不会因为太短丢失语义，也不会因为太长导致检索精度下降。实测下来，针对几千字的技术文档做问答，召回效果已经能满足日常查询。

5. 真实性能数据和三处明显的心跳停顿

5.1 我测出来的几组关键数据

部署完成后，我跑了几个维度的压力测试，数据可以直接参考：

大概什么体验呢？一句简短的“你好”，首 token 不到 2 秒，算是在可接受范围里；但要它写一篇 500 字的小短文，可能要等 40 到 60 秒。对于想看一秒蹦几十个字的爽快感的人来说，这种机器确实做不到。但对于跑批量离线任务、内部知识问答这类场景，这个速度足够让人安心。

5.2 排查过的最典型的三个坑

第一个坑是模型被换页导致推理速度突然跳水。跑了一段时间以后，服务响应突然从每秒 5 个 token 掉到每秒 0.5 个，CPU 占用率也不高，内存看起来也没满。排查半天，最后发现没加--mlock参数，模型页面被内核换到了 swap。虽然 swap 在机械盘上不算特别慢，但推理时要大量随机访问页面，性能立刻崩掉。加上锁页参数后重启，速度恢复。

第二个坑是单个长请求把服务卡死。有一次我拿一篇一万多字的文档去测试总结功能，结果请求发出去之后，服务整个失去响应。原因是上下文长度上限设置得比较大，而请求文本长度和生成 token 数叠加之后，KV Cache 占用的内存猛涨，把其他正常请求也拖垮了。我的处理办法是在网关层限制输入 token 数，并给单次生成长度设置硬顶，比如每次最多生成 1024 个 token。

第三个坑是日志刷屏导致磁盘满。推理框架默认会打印详细日志，跑了几天之后我一看磁盘，剩余空间没了一半。排查后发现是请求日志太大了。处理办法是把日志级别调高，只记录错误信息，同时加了 logrotate 自动轮转。

这三个坑都不是罕见问题，只要跑模型服务，迟早会遇到。写出来是希望各位少走弯路。

5.3 资源监控和临时扩容的土办法

没有现成的监控系统，也不需要一开始就上复杂组件。我自己用了一个很土但很有效的方法：写一个简单的每分钟采集脚本，把内存、CPU 平均负载、磁盘剩余空间写入一个文本文件。服务器真出问题的时候，翻一下记录就能定位到是哪个时间点出了异常。后来为了收集模型服务的延迟数据，我用了一个单文件性能统计工具，直接抓取 API 的响应耗时。二手机器上最好不要跑太重量的监控组件，轻量化方案反而更容易长期坚持。

至于扩容，内存里还有不少余量的时候，不需要动硬件。多跑一个嵌入式模型服务，或者同时加载一个中型模型，都没有太大问题。唯一的教训是，加服务之前先算好内存预算，别一次性全开，然后看空闲内存决定要不要开下一个。

6. 把平台盘活之后，我的几条实际体会

6.1 数据留在手里的安心感和代价是并列的

私有 AI 平台给我带来的最大价值，其实是数据主权。内部文档、聊天记录、业务数据不用再上传到任何第三方服务，所有环节都在自己的服务器上闭环。对一些数据敏感的场景，这是一个非常强的心理保障，也是私有化方案存在的根本理由。

但这个安心感是要付出代价的。最直接的代价是模型能力落后于最新的大模型，很多东西它不会，需要我通过调优、外挂知识库来弥补。其次是要自己维护整套环境，升级、备份、故障排查都得自己来，没有客服可以求助。不过对我来说，这些代价完全值得。

6.2 从一台废旧服务器长出来的小平台，能扩展的方向比想象多

把这套架构跑通后，我陆续又加了几种玩法：给静态博客加了一个 AI 摘要接口、写了定时脚本做内部资料归档、甚至让模型在凌晨自动处理一些批量文本任务。每加一个功能，其实都是在复用同一个模型服务和同一套知识库基础设施。最忙的那几天，这台机器同时挂着三个模型服务、一个知识库和一个离线批处理任务，全部加起来的资源占用还不到物理上限的一半。

如果你也想从一台二手服务器开始，我的建议很简单：不要一上来就贪大，先跑通一个模型，再跑通一个知识库，最后再接应用。把每一步都走扎实，这台机器就能成为真正属于你的私有 AI 底座。

最后再说一个小技巧：给模型服务写一个开机自动拉起脚本，万一断电重启，只要机器起来，所有服务都会自动恢复。这半年里我经历过好几次断电，重启之后服务自己就回来了，省了不少事。这台老服务器的价值，就这样在日常的一点一滴里真正沉淀下来了。