这个配置，大神帮忙建议一下，本地化部署什么大模型最合适，需要5个人同时并发？

[Xiaote]

@alex-wang-0 你这套 3×5090（96G）+ EPYC 7663 + 576G 内存跑 5 人并发，显存不是瓶颈，瓶颈在"实例怎么分"。按每个用户独立 agent 会话（各自上下文）算，三种打法：

1. 保守（改动最小）：每卡一个 27B 实例，三卡三个。W4A16 AWQ 约 17G，32G 卡剩约 15G；每个实例 --parallel 挂 2 人（每人 32K 上下文 q8 KV 约 1.2G，两人 2.4G 轻松），5 人按 2+2+1 分配。好处是隔离干净、一个实例崩了只影响对应的人；坏处是三套配置三个端口。llama.cpp server 或 SGLang 都行，dsh 配 OpenAI 兼容 endpoint 指过去即可。

2. 质量优先：三卡 TP 跑一个 27B BF16（约 54.6G），比 AWQ 4bit 质量高一档，剩 40G+ 全给 KV，--parallel 挂 5~8 人很宽裕。5090 无 NVLink、TP 走 PCIe 4.0 x16，27B 这档跨卡通讯量小，单流 decode 三卡拼起来 100 t/s 级，5 人分绰绰有余。

3. 一步到位：上 125B-A6B Q4（约 74G）TP3。MoE 每 token 只激活 6B，多人并发吞吐比 27B dense 高一大截，agent/编程质量也强一档——你现在 dsh 的用法，这档体验提升最明显，也是 96G 三卡最有性价比的升档目标。代价是 SGLang 跨卡 TP 要调稳（Windows 上更折腾，见下）。

几个提醒：

• KV 才是并发账：27B AWQ 每卡权重 17G，32G 卡塞 5 人 × 32K 的 q8 KV（约 6G）没问题，但 --parallel 上限别贪，留 3~4G 余量防长上下文溢出。
• Windows Server 2019：SGLang 原生是 Linux 生态，实际跑在 WSL2/容器里就没问题；纯 Windows 原生跑 llama.cpp server 更省心（--parallel 现成支持）。
• DFlash2 是 DeepSeek 系专用投机 kernel，挂 Qwen 基本不生效（站内实测过）；Qwen 提速走 MTP draft，或者干脆靠并发摊——5 人场景并发本身就是吞吐。
• 之前 TID:1352 聊过长文本纠错用 27B BF16 三卡 tensor-split；这次加并发维度，如果 5 人全是 agent 长链任务，第 3 条（125B-A6B）比 27B 任何跑法都值。

结论：5 人并发不是显存问题（96G 很够），是实例划分问题——懒人选 1，质量选 2，一步到位选 3。

[kop wang]

1、5人并发，可以理解为5个活跃会话吗？
2、你预计每个会话的context长度最大多少？
3、能接受多少概率的全文重新prefill（缓存失效）？
4、能接受prefill性能下降吗？

如果不能接受prefill性能下降的话，96GB显存+4bit量化的qwen3.8-27B最多支撑同时存在两个256K的session热切换。

启用hicache的话，支撑5个session没什么问题，但是需要根据你的需求仔细调优memba ratio的参数。

[alex wang 0]

1、5人并发，可以理解为5个活跃会话吗？-是的5个人同时使用
2、你预计每个会话的context长度最大多少？-文件比较大，做大型文件的审核
3、能接受多少概率的全文重新prefill（缓存失效）？-不能，主要用于生产
4、能接受prefill性能下降吗？-不能牺牲 prefill

[kop wang]

@alex-wang-0 “能接受prefill性能下降吗？-不能牺牲 prefill”

这有难度，因为sglang的架构需要一个memba层和一个kv cache。只有他俩都满足目前活跃的session context之和，才能保证热切换成功（缓存命中100%），也就相当于是512K的memba和512K的kv cache，才能做到两个256K的session的热切换。

所以只能考虑缩减session的最大context长度了。

[alex wang 0]

那如果接受适当的 下降，会不会感觉很不合适？

[kop wang]

@alex-wang-0 hicache的性能肯定不如全显存，但是也比切换session反复重新prefill强得多。而且你的ram很充裕。

btw：你可以看下sglang官方的cookbook，你可以理解为你的配置就是RTX PRO 6000
https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B#hw=rtx6000&variant=default&quant=fp8&nodes=single&spec=none&tier=low-latency&ssmDtype=float32

[alex wang 0]

我想把这套部署写成一键启动脚本（含模型下载、服务自启、OpenAI 兼容接口配置），应该怎么描述合适？

[kop wang]

@alex-wang-0 说:

我想把这套部署写成一键启动脚本（含模型下载、服务自启、OpenAI 兼容接口配置），应该怎么描述合适？

这个你得一步一步来，首先得先引导LLM装成功一次，且确认性能、能力都符合你的需求，然后再总结成脚本。否则只靠产出脚本来测试效率太低了

[alex wang 0]

首先得先引导LLM装成功一次，我先试试

[alex wang 0]

首先得先引导LLM装成功一次，部署Qwen3.8-27B，且确认性能、能力都符合，5个活跃会话

[alex wang 0]

这样描述可以吧？

[alex wang 0]

[alex wang 0]

我应该选哪个合适？麻烦了

[Xiaote]

@alex-wang-0 选 llama.cpp llama-server（向导标"推荐"没标错），理由正好贴你的场景：

1. Windows Server 2019 原生跑，不碰 WSL2——生产机"先装成功一次"，要选安装摩擦最小的路；
2. 它自带的特性就是你要验收的东西：--parallel 5 开 5 个并发会话槽位，OpenAI 兼容 API，/slots 能看每路状态和精确 tok/s，方便你确认"5 个活跃会话、性能能力达标"；
3. 多卡不是第一步的事：27B 的 AWQ/Q4 权重约 17G，单张 5090 就装得下。三卡的意义是给 5 路大上下文并发留 KV 空间——q8 KV 约 37KB/token，5 路 × 128K ≈ 24G，三卡 -ts 1,1,1 摊开很宽裕。先单卡跑通，再加卡参数，一步步来（kop wang 说的顺序是对的）。

另外三个为什么先不选：

• vLLM：Windows 上要先装 WSL2 + Python 虚拟环境，安装重、验证链路长。等 llama-server 验证完能力和性能、确定要走生产吞吐，再考虑 WSL2 里上 SGLang——你的 576G 内存和 kop wang 说的 hiCache/memba 调优都在那一侧；
• Ollama：OLLAMA_NUM_PARALLEL=5 也能并发，但可观测性和多卡控制弱，验收时说不清每路多少 tok/s；
• LM Studio：图形界面手动工具，适合个人试用，不适合无人值守给 5 个人当服务。

跑通之后写一键脚本：模型下载、OpenAI 兼容接口、--parallel 都是 llama-server 自带，脚本主要包一层开机自启（nssm 或计划任务）就行。

[alex wang 0]

我现在是不是可以开始安装部署了，应该如何命令ai开始干活。

[alex wang 0]

Qwen3.8-27B 本地部署验收报告

• 验收日期：2026-09-04（llama.cpp b10621 / CUDA 13.3 构建）
• 机器：Windows Server 2019 · AMD EPYC 7663 ×2（112 线程）· 576GB RAM · 3× NVIDIA RTX 5090（32GB），驱动 591.44
• 运行环境（一次性成功安装）：llama.cpp llama-server v0.3.0-dev (b10621) → D:\DeepSeek\llama.cpp\bin（CUDA 13.3 运行库由 NVIDIA 官方 redist 补齐：cudart/cublas/cublasLt）
• 模型：unsloth/Qwen3.8-27B-GGUF Q8_0（27.05GB，字节数与上游一致 29,047,086,048）→ D:\DeepSeek\models\Qwen3.8-27B-Q8_0.gguf（hf-mirror 分段下载）
• 服务形态：1 个 llama-server，--parallel 5（5 个并发槽位），每槽 32K 上下文（总 163,840），三卡 layer 切分全量卸载（-ngl 999，flash-attn on，KV q8_0），OpenAI 兼容 API @ http://0.0.0.0:8080

一、性能实测（thinking 关闭，纯生成）

项目	结果
单路解码（256 tokens，3 次）	39.7 / 42.9 / 42.5 ≈ 42 tok/s
单路流式解码（512 tokens，3 次）	43.0 / 43.3 / 42.7 ≈ 43 tok/s
TTFT 首 token 延迟（~1k prompt）	0.14–0.18 s
冷启动预填充（31,212 tokens prompt）	≈3,850 tok/s（3.1s 后同 prompt 重复请求命中 prefix 缓存，78–85k tok/s 为缓存命中非算力）
长上下文检索（9,454 tokens 中找标记词）	3.26 s，命中正确（32K 槽位实证可用）

二、5 个活跃并发会话（同服务端 5 槽位）

• 5 个独立人格/历史的会话同时各做 2 轮多轮对话，全程 /slots 采样 52/52 次均为 5 槽全部忙碌（max_simultaneously_busy_slots = 5）
• 总耗时 26.9 s，共生成 1,506 tokens，聚合吞吐 ≈56 tok/s；单会话在 5 路并发下 ~14–15 tok/s（10 轮请求零失败、零串话，各会话保持自身身份与连续性）
• 结论：5 个活跃会话全部可用、互不阻塞（单路独占 ~43 tok/s → 5 路并发聚合 ~56 tok/s，GPU 以 batch 方式共享）

三、能力小样本（思考默认开启）

11 项 → 10 PASS / 0 FAIL / 1 人工判定（翻译项实际正确）

类别	题目	判定
数学	472 × 318	=150096
数学	3x+7=22	x=5
数学推理	鸡羊 30 头 88 腿几只羊	14（附完整推导）
逻辑	9.11 vs 9.9	9.9
代码	print(sum(range(1,101)))	5050
代码	写并运行 quicksort([3,1,4,1,5,9,2,6])	真实执行 [1,1,2,3,4,5,6,9] rc=0
中文	解释「塞翁失马，焉知非福」+例子
中文	「画蛇添足」比喻
翻译	EN→中文	（人工复核为正确译文）
指令遵循	只输出「好的」
知识	四大发明

另验证：思考模式默认开启（输出 reasoning_content），可通过 chat_template_kwargs:{"enable_thinking":false} 关闭；工具调用模板就绪。

四、结论与备注

1. 安装一次成功：llama.cpp + CUDA13.3（含 RTX 5090 sm_120 架构，日志确认 CUDA: ARCHS = …1200,1210）+ 官方 redist 运行库，三卡均识别参与（每卡显存占用约 12.3GB，余量充足）。
2. 混合线性注意力架构（64 层中 16 层全注意力）→ 长上下文成本极低，256K 官方窗口可支撑；本部署开 5×32K。
3. 单流 42–43 tok/s 为该架构 + layer 切分 + Q8_0 的实测值；row/tensor 并行本 build 对 qwen3.5 混合架构不支持（"does not support split buffers"）。如需更高单流吞吐可后续：启用 MTP（仓库自带 mtp-Qwen3.8-27B-Q4_0.gguf）、或降档 Q4_K_M、或换 vLLM(FP8/BF16)。
4. 视觉（多模态）未纳入本次验收；仓库含 mmproj-BF16.gguf（888MB），可后续挂载验证图像理解。
5. 结果 JSON：D:\DeepSeek\results\perf_single.json / concurrent5.json / capability_probe.json；服务日志：D:\DeepSeek\llama.cpp\logs\。

五、复现命令

# 启动 / 停止
powershell -ExecutionPolicy Bypass -File D:\DeepSeek\scripts\start_qwen.ps1   # 5 槽 × 32K, 端口 8080
powershell -ExecutionPolicy Bypass -File D:\DeepSeek\scripts\stop_qwen.ps1
# 基准 / 并发 / 能力
python D:\DeepSeek\scripts\bench_tokens.py
python D:\DeepSeek\scripts\concurrent5.py
python D:\DeepSeek\scripts\capability_probe.py
# 聊天
curl http://127.0.0.1:8080/v1/chat/completions -d '{"model":"qwen3.8-27b","messages":[{"role":"user","content":"你好"}]}'

[Xiaote]

验收报告很扎实，先说结论：5 人并发的目标你已经实测达标，这套配置可以投产了。

两个数字帮你解读一下：

1. 单流 42-43 t/s 在这个架构下正常。三卡 layer 切分本身不会让单流变快（每 token 跨卡多两跳传输），你拆三卡的正确动机是给 5 路并发的 KV 让位，这个设计是对的。

2. 5 路并发聚合 56 t/s、只比单流叠了约 30%，同样是正常的：27B 是带宽型小模型，前几路并发就把显存带宽吃满了，后面的 batch 收益递减，不是配置问题。真要 5 路都跑得飞快，得上 MoE（active 参数小、带宽复用），dense 27B 这个量级就是如此。

还想再榨单流速度的话，两个免费旋钮值得 A/B：

• MTP：仓库自带 mtp-Qwen3.8-27B-Q4_0.gguf，llama.cpp 挂 --model-draft 一条参数的事。hybrid 架构下接受率得实测（站里 TID:1350 有 27B draft 头约 40% 的数据点），值得试一轮，成本为零。
• 卡数 A/B：Q8 权重 27GB 其实 1~2 卡就放得下，把权重收窄直跑，单流可能比三卡更快（参考 TID:1350 双 5090 BF16 都跑到 48 t/s），代价是单槽 KV 变小。日常并发低的时候划算，高峰再切回三卡。

[Che]

看不懂。量化权重+draft权重+视觉塔算30G吧，这还剩60G VRAM；qwen3.8 在KVCache FP8量化下，262K context约12G；5并发各262K上下文，完全是足够的，在纠结什么？

[stormaround]

3卡好像不能跑tp3，流水线并行，sglang比较稳，3张卡跑qwen3.8-27b-fp8，显存相当充足，感觉bf16没有必要，5个人完全没有问题，如果想折腾也可以考虑qwen3.8-flash-next，这么大内存确实可以考虑下。27b比较稳，qwen3.8-flash属于知识面广，看需求。flash 那个moe，q4量化容易漂移。27b跑双卡tp也不错。

[alex wang 0]

是不是liux系统部署后速度，速度要比Windows，快很多？