当前位置：首页 > news >正文

NAS跑大模型实战：GLM-5在家庭服务器上的部署与优化

news 2026/6/4 13:30:33

1. 项目概述：当大模型真正“落进”家庭机柜

最近刷到一条消息，标题很抓人：“国产最强 GLM-5 开源！你的 NAS 能跑得动吗？”——我盯着屏幕停了三秒，不是因为兴奋，而是下意识摸了摸手边那台跑了五年、风扇声像老式电扇的群晖 DS920+。它现在还在跑着 Plex、Photo Station 和一个轻量级 Home Assistant，但“跑 GLM-5”？这问题像拿算盘问能不能跑《赛博朋克2077》——表面是技术提问，内里全是现实水位线的试探。

GLM-5 是智谱 AI 在 2024 年底正式开源的全新一代通用大语言模型，支持 128K 上下文、原生多模态理解（文本+图像）、强化推理能力（尤其在数学与代码生成上实测优于同参数量 Llama-3-70B），最关键的是，它首次实现了全精度开源+商用友好协议（Apache 2.0）+ 官方量化工具链完整支持。这不是又一个“纸面参数漂亮”的模型，而是真正在 Hugging Face 上能一键git clone、在消费级硬件上可部署、且已有数十个社区项目基于它落地的“可用型基座”。

但“可用”不等于“你家能用”。NAS 这个词，在普通用户心里是“自动备份照片”“远程看监控”，在极客眼里是“低功耗家用服务器”，而在大模型语境下，它突然成了一个残酷的性能标尺：它没有 PCIe 5.0 插槽，没有双路 CPU，内存插槽最多 32GB，GPU 接口要么没有、要么只支持低功耗 MX 系列；它的散热是被动+小风扇，功耗墙被钉死在 30W–65W 区间。所以，“你的 NAS 能跑得动吗？”本质是在问：在零改装、不换机、不接外置显卡、不拉专线的前提下，你手头那台用来存电影和照片的盒子，有没有可能成为你个人 AI 助理的物理载体？

答案不是简单的“能”或“不能”，而是一张分层能力图谱：

✅能加载、能响应、能完成简单问答——这是最低门槛，靠 CPU + 量化模型就能做到；
⚠️能流式输出、能处理中等长度文档（<5K 字）——需要内存带宽与缓存协同优化，对 DDR4 频率和通道数敏感；
❌无法实时多轮对话+本地 RAG+图像理解三合一运行——这已超出绝大多数 NAS 的热设计功耗（TDP）与内存带宽上限。

这篇文章不讲“GLM-5 多牛”，也不堆参数对比表。我要带你一帧一帧拆开：一台真实在用的 NAS（以群晖 DS920+、威联通 TS-464C2、极空间 Z4S Pro 三款主流机型为锚点），从固件底层、内存拓扑、存储 IO、温度策略到模型加载路径，全程实测验证哪些环节会卡死、哪些地方能“偷”出 20% 性能、哪些配置看似合理实则自废武功。所有结论都来自我连续 17 天、在 3 台设备上反复重装系统、更换内核、编译 wheel、压测温度的真实记录——包括那个让群晖用户集体沉默的“DSM 7.2.2 内核模块签名强制校验导致 llama.cpp 无法加载”的坑。

如果你正打算把 NAS 升级成家庭 AI 中枢，或者刚买了 Z4S Pro 想试试“本地 ChatGPT”，又或者只是好奇“大模型离普通人到底还有多远”——这篇就是为你写的。它不承诺“一键起飞”，但保证让你清楚知道：油箱在哪、油量多少、哪段路必须绕行、哪个加油站能加到真油。

2. 核心需求解析：为什么偏偏是 GLM-5？为什么非得在 NAS 上跑？

2.1 GLM-5 的“可部署性”不是宣传话术，而是工程选择

很多人看到“开源大模型”，第一反应是去 Hugging Face 下transformers加载。但现实是：原生 PyTorch 格式的 GLM-5-9B（INT4 量化后仍占 5.2GB 显存）在无 GPU 的 NAS 上根本起不来——torch依赖本身就会因 glibc 版本、CUDA 构建链缺失而报错。真正让 GLM-5 在 NAS 场景脱颖而出的，是智谱团队在发布时同步推出的glm_cpp工具链（非官方命名，实为glm-cpp+llama.cpp深度定制分支）。

这个工具链做了三件关键事：

彻底剥离 CUDA 依赖：全部运算走 x86_64 AVX2 / AVX-512 或 ARM64 NEON 指令集，连 OpenBLAS 都被替换成更轻量的fp16专用 kernel；
支持 GGUF 多级量化无缝切换：从 Q8_K（精度最高，体积最大）到 Q2_K（体积最小，精度损失明显），中间有 Q5_K_M、Q4_K_S 等 7 种档位，每种都经过实测吞吐与 perplexity（困惑度）校准；
内置 HTTP API Server 且默认启用流式响应（streaming）：无需额外搭 FastAPI，./main -m glm5-q4k.gguf -c 2048 --port 8080 --threads 6一行命令即启服务，返回格式完全兼容 OpenAI API（/v1/chat/completions），这意味着你手机上的任何支持自定义端点的 AI App（如 PromptPal、LM Studio Mobile）都能直连调用。

提示：很多教程跳过这点直接教pip install transformers，结果在群晖 Docker 里卡在torch._C导入失败。根源在于——NAS 不是开发机，它要的是“编译好、丢进去、就运行”的二进制，不是“先配环境再跑代码”的工作流。

2.2 NAS 的不可替代性：不是“能跑”，而是“该跑”

有人会问：既然这么麻烦，为什么不买一台二手 RTX 3090 主机？答案很实在：静音、常开、省电、免维护、空间友好。

一台满载的 RTX 3090 主机待机功耗 45W，峰值超 350W，风扇噪音 42dB（相当于图书馆翻书声），你愿意让它 24 小时开着放在书房角落？
而一台 DS920+ 满载功耗 32W，实测运行 GLM-5-Q4K 时整机功耗 38.6W，风扇转速维持在 1800 RPM 以下，噪音低于 26dB（接近耳语）；
它插在路由器旁，接一根网线，不用显示器、不用键鼠，通过 Web 界面或 SSH 就能管理；
更重要的是——它天然拥有可靠存储+自动快照+跨设备同步能力。你喂给它的私有知识库（PDF、会议纪要、家庭账单扫描件），不会像本地 PC 那样因系统崩溃而丢失，也不会像云服务那样存在隐私泄露风险。

我在 Z4S Pro 上部署 GLM-5 后做的第一个实用功能，是“家庭健康问答助手”：把三甲医院公开的《常见慢性病居家护理指南》PDF 拆解为 chunk，用 ChromaDB 做本地向量库，再通过 GLM-5 的指令微调能力（glm5-instruct-q4k.gguf）实现自然语言查询。老婆问“高血压吃阿司匹林要注意什么”，NAS 在 2.3 秒内返回结构化答案，并附上原文页码。整个过程数据不出局域网，响应延迟比手机连 Wi-Fi 访问云端 API 还低 180ms。

这就是 NAS 的核心价值：它不是大模型的“降级容器”，而是隐私优先、场景闭环、长期可信的 AI 落地终端。

2.3 “跑得动”的真实定义：四层能力阶梯

我们把“跑得动”拆解为四个递进层级，每个层级对应明确的硬件指标与用户体验：

层级	用户可感知表现	关键硬件瓶颈	实测达标机型（代表配置）
L1：能启动、能应答	输入问题后 5–12 秒返回首字，支持单轮问答	CPU 单核性能 ≥ Intel i3-8100（3.6GHz）、内存 ≥ 16GB、SSD 读取 ≥ 300MB/s	DS920+（J4125 四核 2.7GHz，16GB DDR4，M.2 NVMe 缓存）
L2：可流式、低延迟	输入后 1.5 秒内开始流式输出，每秒生成 ≥ 8 token，支持 3 轮以内上下文维持	内存带宽 ≥ 25.6 GB/s（双通道 DDR4-2666）、CPU 支持 AVX2、SSD 随机读 IOPS ≥ 50K	TS-464C2（Ryzen R1600 六核 3.1GHz，32GB DDR4，2×M.2 NVMe）
L3：稳运行、不降频	连续问答 30 分钟，CPU 温度 ≤ 78℃，无主动降频，响应延迟波动 < ±15%	散热模组接触面积 ≥ 45cm²、导热硅脂厚度 0.15mm±0.02、机箱风道设计支持垂直对流	Z4S Pro（N100 四核 3.4GHz，32GB DDR5，双风扇+铜管散热）
L4：可扩展、易集成	支持同时加载 2 个模型（如 GLM-5 + Whisper.cpp）、可挂载外部 USB3.0 SSD 作为向量库存储、HTTP API 兼容 Home Assistant 自动化	USB3.0 主控带宽 ≥ 5Gbps、内核支持 FUSE、文件系统支持 XFS/BTRFS	TS-464C2（USB3.2 Gen2x2，Linux 5.10 内核，BTRFS 默认）

注意：这里的“达标”不是理论值，而是我用stress-ng --cpu 8 --timeout 1800s模拟满载、同时运行glm-cpp服务、用curl每 5 秒发起请求、用s-tui实时监控温度与频率后得出的实测阈值。比如 DS920+ 在 L1 层级完全合格，但在 L2 层级，当开启 2048 上下文窗口时，第二轮问答延迟会飙升至 8.2 秒（首字），原因是 J4125 的 L3 缓存仅 6MB，无法有效缓存 KV Cache。

3. 硬件适配深度拆解：三款主流 NAS 的实战表现

3.1 群晖 DS920+：老将的极限压榨

DS920+ 是 2020 年发布的经典机型，搭载 Intel Celeron J4125（4 核 4 线程，基础频率 2.0GHz，睿频 2.7GHz），TDP 10W，集成 UHD Graphics 600。它没有 M.2 插槽（需另购 PCIe 扩展卡），内存最大支持 8GB（官方）或 16GB（民间破解），使用 DDR4-2400 单通道。

实测部署路径：

系统准备：DSM 7.2.2（内核 4.4.302），禁用所有非必要套件（Audio Station、Surveillance Station）；
环境构建：通过 SynoCommunity 安装Python 3.11（非 DSM 自带 Python），再用pip install wheel+pip install numpy==1.26.4（必须指定版本，否则与 glibc 2.28 冲突）；
模型获取：从 Hugging Face 下载glm5-chat-q4k.gguf（4.8GB），存放于 SSD Volume1；
服务启动：./main -m /volume1/homes/admin/glm5-chat-q4k.gguf -c 1024 --port 8080 --threads 4 --ctx-size 1024。

关键发现：

✅ 单线程推理速度：1.8 token/s（Q4_K_M 量化），满足 L1 层级；
⚠️ 当--ctx-size设为 2048 时，首字延迟从 5.3s 拉长到 9.7s，原因是 J4125 的内存控制器仅支持单通道，带宽瓶颈暴露；
❌ 无法启用--flash-attn（闪存注意力），因该特性依赖 AVX-512 指令集，J4125 仅支持 AVX2；
🔥 连续运行 20 分钟后，CPU 温度达 82℃，触发主动降频至 1.6GHz，此时吞吐下降 37%。

实操心得：DS920+ 的最优配置是Q4_K_S 量化 + ctx-size=1024 + threads=3。别贪上下文长度——多出来的 1024 tokens 会吃掉你 40% 的响应稳定性。我最终把它定位为“家庭轻量问答终端”，专用于孩子作业辅导（数学题解析）、菜谱查询、快递单号识别，效果非常扎实。

3.2 威联通 TS-464C2：Ryzen 架构的均衡之选

TS-464C2 发布于 2023 年中，搭载 AMD Ryzen R1600（2 核 4 线程，基础 3.1GHz，睿频 3.5GHz），TDP 15W，集成 Radeon Vega 3 GPU，支持 DDR4-2666 双通道（最大 32GB），自带 2×M.2 2280 PCIe Gen3×2 插槽（可做高速缓存或独立存储）。

实测部署路径：

系统准备：QuTS hero 5.1.2（Linux 5.10.159），启用 BTRFS 文件系统，创建 RAID1 SSD 缓存池；
环境构建：通过 Container Station 部署 Ubuntu 22.04 LTS 容器（非 QNAP 自带 Linux Station），安装build-essential、libopenblas-dev、python3.10-venv；
模型获取：下载glm5-instruct-q5k_m.gguf（5.9GB），存于 M.2 缓存池；
服务启动：./main -m /mnt/cache/glm5-instruct-q5k_m.gguf -c 2048 --port 8080 --threads 4 --flash-attn。

关键发现：

✅ 双通道 DDR4-2666 提供 42.7 GB/s 带宽，KV Cache 加载速度比 DS920+ 快 2.3 倍；
✅--flash-attn可启用，使 2048 上下文下的首字延迟稳定在 1.4s（实测 1.37s）；
✅ 连续运行 45 分钟，CPU 温度稳定在 72–74℃，无降频；
⚠️ 默认容器镜像的glibc版本为 2.35，与glm-cpp编译时的 2.31 不兼容，需手动替换libc.so.6（风险操作，建议用官方提供的qpkg安装包）。

注意：QNAP 官方尚未提供glm-cpp的 qpkg，但社区已编译好适配 R1600 的版本（SHA256:a7f3e...），安装后可通过 Web 界面一键启停服务。这是我目前主力使用的机型，承担“家庭知识中枢”角色：对接 Notion API 同步笔记、接入 Home Assistant 控制灯光与空调、定时分析 NAS 中的监控录像（用本地 Whisper.cpp 转文字后喂给 GLM-5 总结异常事件）。

3.3 极空间 Z4S Pro：N100 平台的静音标杆

Z4S Pro 是 2024 年新锐产品，搭载 Intel N100（4 核 4 线程，基础 0.8GHz，睿频 3.4GHz），TDP 6W，集成 UHD Graphics 700，支持 DDR5-4800（最大 32GB），双风扇+铜管散热，官方宣称“满载噪音 < 22dB”。

实测部署路径：

系统准备：ZOS 4.3.2（基于 Debian 12，内核 6.1.0），启用 Z-App 商店安装Docker；
环境构建：拉取ghcr.io/ggerganov/llama.cpp:latest镜像，docker run -it --rm -v /mnt/data:/data -p 8080:8080 ghcr.io/ggerganov/llama.cpp:latest；
模型获取：下载glm5-chat-q3_k_s.gguf（3.2GB），存于/mnt/data/models/；
服务启动：/bin/bash -c "cd /app && ./server -m /data/models/glm5-chat-q3_k_s.gguf -c 2048 --port 8080 --threads 4"。

关键发现：

✅ N100 的 IPC（每周期指令数）比 J4125 高 41%，在相同频率下吞吐更强；
✅ DDR5-4800 双通道带宽达 76.8 GB/s，KV Cache 加载几乎无等待；
✅ 散热模组实测：满载 60 分钟，CPU 温度 68.2℃，风扇转速始终未超 2100 RPM；
✅ 支持--mlock参数（锁定内存不交换），避免因系统内存紧张导致推理中断。

实操心得：Z4S Pro 是目前我测试中唯一能稳定跑通L3 层级的机型。它让我第一次在 NAS 上实现了“语音输入→Whisper 转写→GLM-5 总结→TTS 合成播放”的全链路闭环。整个流程平均耗时 4.8 秒（从按下录音键到听到合成语音），其中 GLM-5 推理仅占 1.9 秒。它的静音表现甚至优于我的 MacBook Air，真正做到了“存在感为零，能力感拉满”。

4. 模型量化与参数调优：如何在 8GB 内存里塞下 9B 模型

4.1 GGUF 量化原理：不是“压缩”，而是“精度重分配”

很多新手以为“Q4_K”就是把权重砍掉一半精度，其实完全错误。GGUF 量化是一种分组精细控制技术：它把模型权重矩阵按 32 列一组切分，每组独立计算 min/max，再用 4-bit 整数表示该组内各权重相对于 min 的偏移量。Q4_K_M 中的 “K” 指 kernel-aware（内核感知），意味着对矩阵乘法中高频使用的部分（如 attention 的 Q/K/V 投影）保留更高精度（6-bit），对低频部分（如 FFN 中间层）用更低精度（2-bit）。

这就解释了为什么Q4_K_M（5.9GB）比Q4_K_S（4.8GB）体积更大，但实际推理速度反而快 12%——它把计算资源精准投给了最影响延迟的模块。

我用llama.cpp自带的quantize工具对同一份glm5-chat-f16.bin做了 7 种量化，实测结果如下（DS920+ 平台，ctx-size=1024）：

量化类型	模型体积	首字延迟（s）	1024 tokens 吞吐（token/s）	Perplexity（WikiText2）
Q8_K	8.2 GB	4.1	1.2	8.7
Q6_K	6.1 GB	4.3	1.3	9.2
Q5_K_M	5.9 GB	4.5	1.4	9.8
Q4_K_M	4.8 GB	5.3	1.8	11.3
Q4_K_S	4.2 GB	5.1	1.9	12.6
Q3_K_M	3.6 GB	5.8	2.1	14.9
Q2_K	2.8 GB	6.7	2.3	21.7

注意：Perplexity 越低越好，代表模型对测试文本的预测越准确。可以看到，从 Q4_K_M 降到 Q3_K_M，体积减少 24%，但困惑度仅上升 25%；而降到 Q2_K，困惑度翻倍，说明语义理解已严重失真。Q3_K_M 是 NAS 场景的黄金平衡点——它在 DS920+ 上首字延迟 5.8s，但能稳定输出，且对家庭日常问答的准确率影响微乎其微。

4.2 关键参数详解：每一项都在和硬件博弈

glm-cpp启动命令中的每个参数，都是对硬件资源的精确调度：

--threads N：指定 CPU 线程数。不要设为逻辑核心总数！J4125 有 4 线程，但设--threads 4会导致 L3 缓存争抢，实测--threads 3反而快 18%。R1600 设--threads 4最佳（2 物理核 × 超线程），N100 设--threads 4无压力。
--ctx-size N：上下文窗口大小。每增加 1024 tokens，KV Cache 内存占用增长约 120MB（Q4_K_M）。DS920+ 的 16GB 内存中，DSM 系统常驻占 3.2GB，Docker 占 1.1GB，剩余约 11.7GB。若设--ctx-size 4096，仅 KV Cache 就吃掉 480MB，加上模型权重 4.8GB，总内存占用超 5.8GB，极易触发 swap，导致延迟飙升。推荐值：DS920+ 用 1024，TS-464C2 用 2048，Z4S Pro 用 3072。
--batch-size N：批处理大小。NAS 场景基本为单请求，设为 1 即可。设为 4 会预分配更多内存，但无并发请求时纯属浪费。
--mlock：锁定内存不交换。Z4S Pro 必开，DS920+ 建议关闭（其 swap 分区在 HDD 上，mlock 会提前耗尽内存）。
--no-mmap：禁用内存映射。当模型文件存于 NFS 或 SMB 共享卷时必开，否则mmap()会失败；本地 SSD 存储时关闭，可提升加载速度 30%。

实操心得：我在 TS-464C2 上曾误开--no-mmap，导致每次重启服务都要多花 12 秒加载模型。后来发现，只要把模型文件放在/mnt/cache/（BTRFS 缓存池），mmap就能正常工作，且利用 BTRFS 的 CoW（写时复制）特性，多个服务实例共享同一份模型内存页，极大节省 RAM。

4.3 温度与功耗的隐性博弈：散热才是终极瓶颈

所有 NAS 厂商都不会在官网参数里写明“散热模组接触面积”，但这恰恰是决定你能跑多久的关键。我拆解了三台机器的散热器：

DS920+：铝挤散热片 + 单热管，接触面积 32cm²，硅脂为信越 X-23，厚度约 0.22mm（偏厚，导致热阻高）；
TS-464C2：铜底+双热管+铝鳍片，接触面积 48cm²，硅脂为莱尔德 T-grease 2000，厚度 0.14mm；
Z4S Pro：均热板+双铜管+双风扇，接触面积 61cm²，硅脂为信越 X-23-7832，厚度 0.13mm。

我用红外热像仪实测 CPU IHS（集成散热盖）表面温度：

机型	无负载	满载 5 分钟	满载 30 分钟	是否降频
DS920+	38℃	71℃	82℃	是（降至 1.6GHz）
TS-464C2	32℃	65℃	74℃	否
Z4S Pro	29℃	58℃	68℃	否

有趣的是，Z4S Pro 的 N100 基础频率仅 0.8GHz，但睿频 3.4GHz，而 DS920+ 的 J4125 基础 2.0GHz，睿频 2.7GHz。按理说后者应该更“有力”，但实测 Z4S Pro 的持续吞吐高出 27%，根源就在散热——它允许 N100 长时间维持在 3.2GHz 以上运行，而 J4125 在 75℃ 就开始逐步降频。

提示：如果你的 NAS 支持更换硅脂（如 TS-464C2），强烈建议换成信越 X-23-7832（导热系数 12.8 W/mK）。我实测 DS920+ 换脂后，满载 30 分钟温度从 82℃ 降至 76℃，虽仍会降频，但延迟波动从 ±35% 降至 ±12%，体验提升显著。

5. 实操全流程：从零部署到家庭 AI 中枢

5.1 准备工作：三步确认你的 NAS 是否具备基础资格

别急着下载模型，先做这三件事：

确认 CPU 指令集支持：SSH 登录 NAS，执行
```
cat /proc/cpuinfo | grep flags | head -1 | grep -E "avx2|avx512"
```
若输出含avx2，可运行 Q4_K 及以上量化；若只有sse4_2，只能跑 Q8_K（不推荐，太慢）；
DS920+ 输出含 avx2，TS-464C2 含 avx2+avx512，Z4S Pro 含 avx2。
检查内存与存储余量：
- 内存：free -h，确保可用内存 ≥ 模型体积 × 1.3（Q4_K_M 4.8GB → 需 ≥ 6.2GB 可用）；
- 存储：df -h，确保模型存放卷剩余空间 ≥ 模型体积 × 2（预留编译与缓存空间）；
- DS920+ 我用 1TB SSD 做单独 Volume，剩余 820GB，完全够用。
验证网络与端口：
- netstat -tuln | grep 8080确认端口未被占用；
- 在路由器后台设置端口转发（如需外网访问），或直接用 ZeroTier 组建虚拟局域网（更安全）。

5.2 模型下载与验证：避开哈希陷阱

Hugging Face 上的 GLM-5 模型由不同用户上传，质量参差。我只推荐两个来源：

官方智谱镜像（推荐）：https://huggingface.co/THUDM/glm-5/tree/main
文件名规范：glm5-chat-q4k.gguf、glm5-instruct-q5k_m.gguf，SHA256 可查；
TheBloke 镜像（社区权威）：https://huggingface.co/TheBloke/glm-5-GGUF
他会对每个量化档位做 perplexity 测试并公示结果。

下载后务必校验：

sha256sum glm5-chat-q4k.gguf # 应与 Hugging Face 页面显示的 SHA256 一致

注意：我曾下载过一个名为glm5-9b-q4k.gguf的文件，SHA256 对不上，用llama.cpp加载时报invalid magic number。后来发现是某搬运者用旧版convert.py转换，格式已过期。永远以官方或 TheBloke 的哈希值为准。

5.3 服务部署：三机型差异化操作指南

▶ DS920+（DSM 7.2.2）

安装Python 3.11（SynoCommunity）；
创建/volume1/homes/admin/glm目录，放入模型；
下载预编译glm-cpp二进制（[链接]），解压后chmod +x main；

编写启动脚本start_glm.sh：

#!/bin/bash cd /volume1/homes/admin/glm nohup ./main -m glm5-chat-q4k.gguf -c 1024 --port 8080 --threads 3 > /volume1/homes/admin/glm/log.txt 2>&1 &

chmod +x start_glm.sh，执行./start_glm.sh；
浏览器访问http://nas-ip:8080/docs查看 Swagger UI。

▶ TS-464C2（QuTS hero 5.1.2）

Container Station → 创建 Ubuntu 22.04 容器，挂载/share/CACHEDEV1_DATA/glm；

进入容器终端，执行：

apt update && apt install -y build-essential libopenblas-dev python3.10-venv git clone https://github.com/ggerganov/llama.cpp && cd llama.cpp && make clean && make LLAMA_AVX=1 LLAMA_AVX2=1 cp main /share/CACHEDEV1_DATA/glm/

将模型放入/share/CACHEDEV1_DATA/glm/；

启动命令：

./main -m /share/CACHEDEV1_DATA/glm/glm5-instruct-q5k_m.gguf -c 2048 --port 8080 --threads 4 --flash-attn

▶ Z4S Pro（ZOS 4.3.2）

Z-App 商店 → 安装 Docker；
创建glm文件夹，放入模型；
Docker → 创建容器：
- 镜像：ghcr.io/ggerganov/llama.cpp:latest
- 卷映射：/mnt/data/glm:/data
- 端口映射：8080:8080
- 命令：/bin/bash -c "cd /app && ./server -m /data/glm5-chat-q3_k_s.gguf -c 3072 --port 8080 --threads 4"
启动容器，访问http://z4s-pro-ip:8080。