SGLang HiCache实测：KV缓存放进内存和SSD，多开Agent终于舒服了，5090/RTX Pro5000/4080S 32G/4090 48G等显卡福音！

[terry]

最近新的模型、新的玩法层出不穷，我有点忙不过来了。我还是把我的英语频道大幅减少更新了，虽然它是我的主要收入来源，但是我自己对于折腾这些配置、技术问题还是挺有兴趣的。如果科技圈发生了什么大事，我也想去评论一下。我这人特别好吹牛逼，知道吗？就是好跟别人抬杠。做这个中文频道让我有成就感，不像英文频道，做起来像是要去做某种宣教，做某种解说，然后像上班一样。

昨天看到 Neo 的这个帖子，我觉得还挺有意思的。怎么大家发帖的时候这么不注意呢？他讲什么呢？SGLang 开启 HiCache L2/L3 KV 缓存。这个东西挺有意思的，怎么讲？我们普通的 KV 缓存不是放在显存中吗？但是往往显存空间会比较紧张，加载了模型权重之后，剩下来的空间就微乎其微了。那你对话一长，万一多开，尤其是我们使用 SGLang，肯定都是想利用 Radix 缓存树的威力，利用它 Prefill 的巨大优势，不用重新算的巨大优势。但是如果显存紧张的话，那它这个优势就会大大受限。

比如说我是 4090D 48G，我们论坛的版主 Kop Wang 是 RTX Pro 5000 48G，我们都是用 Qwen3.8 27B FP8 这个模型。但是这个模型有什么缺点呢？它权重将近 30G，再加上其他的一些 SGLang 框架开销，可能要好几个 G，再加上系统的开销，其实留给 KV 缓存的就只有 10G 左右，10 多个 G。基本上你就算是使用 FP8 KV，其实这个也不牺牲质量，你也只能开单个 256K 的会话。如果你多开的话，实际上 KV 缓存是非常紧张的。

那么你要多开怎么办呢？最好使用 4 Bit 量化的模型。但是 4 Bit 量化的模型，SGLang 的支持又非常不好，配置有这样那样的问题，Bug 很多。我就希望让 Kop Wang 去配，他配好了我就抄作业。哪知道，我靠，这老弟也是非常老奸巨猾，他也不愿意去配，他也等别人配。这个时候 Neo 真的成救世主了。看过《黑客帝国》的应该知道，救世主就是叫 Neo 嘛。

Neo 发了一个 HiCache 的帖子，就是可以把 KV 缓存放到内存中去，甚至很不重要的 KV 缓存，也就是冷缓存，可以放到 NVMe，也就是固态硬盘中去。这样的话，你多开会话的时候就不用担心 KV 缓存被挤爆了。说实话，即便你的 KV 缓存是热的，不是被冷置的 KV Cache，你把它放到内存中去，就算是以最差的 X99 平台，比如说 X99 DDR3，PCIe 3.0 x16 的带宽，它从 DDR3 内存中搬取 KV 缓存放到显存中去，实际上也是很快的。算你 256K 上下文，就算整体搬运 10G，了不起 FP8 压缩之后大概就这么大，那也就是一秒钟就搬进去了。

哪怕每一次你都要搬运这么大，对于你的延迟来说，其实影响也是微乎其微的，更何况不可能有这么极端的情况。这里这个参数，--hicache-size 把它设为 32，就是开 32G。还有 NVMe 缓存也可以开启，但是我是没有开这个的，我直接开了 24G。因为我的系统是 64G 内存，SGLang 启动之后，跑这个 Docker 镜像，连大模型占了 20 多个 G，总之最后总的内存消耗是 50 多个 G。如果我开 32G 还不够。所以如果你想玩这个东西的话，最好还是去买一个 128G 的 X99 洋垃圾。讲实话这个其实并不贵，你去买 4 个 32G 的就行了。这个条子我看还不到 300 块钱，200 多块钱，一共加起来可能不到 1000 块钱就搞定了。但是我是暂时用不到那么多了，就这样已经够用了，开 24G 缓存足够了。

然后就是进入实战环节。你还别说，它还真的能够同时干活。我同时开了 3 个会话，让它们同时干活，然后还有一个 DeepSeek Harness。实际上还有一个小的任务，这个就不是长上下文会话了，就是一个小任务测试。然后它的资源占用是什么样的情况？感觉还是相当稳的，不至于发热太高。我们看一下系统资源的占用，GPU 占用率是 100%，已经开足马力了，然后功耗是 340W，实际上峰值大概就是 350W。这个好像是我什么时候限制的，忘记了，反正不太影响性能，多多少少受一点影响。显存占用了 44G，其实是完全够了，一点都不紧张。这几个会话一直同时开的话，它是完全扛得住的。

然后我们说一下 Codex 上面的问题。怎么讲呢？它有什么好处？思考强度你开什么轻、中、高，它是能够识别的，SGLang 默认能够识别。但是我感觉就算给它开轻度，它的响应速度讲实话还是很慢，完全不能跟在线模型比。比 DeepSeek V4 Flash 可能要慢三倍甚至四倍，跟昨天我测的 GLM-5.3，就是那个 Ox Alpha 牛来的模型，可能处于同一个档次，甚至比牛来还要再慢一点。

但是它也能完成任务，你看交给它的任务它都完成了。比如说我们这个 APP，我这个帖子本来这个地方是没有头像的，叫它把这个加上去，它也是能完成的。而且它也知道怎么去读会话记录，怎么在模拟器中把这个东西跑起来，跑起来之后怎么验证，然后怎么推送。改好之后，它对项目的理解能力，包括执行能力，其实都是在线的。

对于我来说，这种响应速度之前我还能够妥协，但是时间长了之后我就不想妥协了，我还是搞到 DeepSeek Harness 里来。因为 DeepSeek Harness 这几天又更新了版本，虽然现在还是 RC 版本，但是不得不说，它的体验经过迭代更新之后变得非常好。一开始进来的时候，它的延迟也是非常严重的。怎么说呢？你问它一个问题，它就不断地在 think、think、think，然后再执行指令。长上下文之后，它实际上体验是非常慢的。你看它的首 Token 平均延迟是 11.9 秒，但这显然不应该是一个正常的状态。

查一下服务器的状态，理解一下项目代码，你看它对项目代码的理解也是完全能够轻松搞定的。接着我就跟它讲，我说你这个 Thinking 模式我真接受不了，因为每次思考时间太长了，我等你十几秒你再给我回应，然后就不断地在思考，这样子很不好受。我说你自己去把这个问题给解决掉。然后它就开始查找代码，我说你去网络上搜索知识，它果然去搜了。DeepSeek Harness 比较牛逼的地方就是，你不需要给它去配网络搜索，它自己会，天生就会。

过了一阵子，它就告诉我它找到了解决方案，改哪些配置参数，并且它还能自己修改自己、自己启动，这一块就是非常牛逼了。因为之前无论是 Hermes 还是 Codex，它们改自己配置的时候，重启往往就会死掉。一般来说我要改 Codex，我就让 Hermes 来改；改 Hermes，我就让 Codex 来改，或者让另外一个 Hermes 来改。但是 DeepSeek Harness 牛逼的地方就在于，它就是能自己改自己，改完之后还能热启，热启之后验证还是正常的。而且它启动之后，Thinking 模式，也就是思考模式完全关了。

这样体验就非常好了，基本上你发什么消息它都是秒回。后来我在这里开了个新的窗口，我们看一下，首 Token 平均延迟是 0.7 秒，吐字速度是 24 tokens/s。当然了，它这个缓存命中率显示 0%，这个是个显示 Bug，因为 SGLang 跟 OpenAI 的格式是不兼容的。就像刚才改那个思考模式一样，这是个显示 Bug，你没有必要去改这个东西。你只需要知道它在服务器端确实是缓存了，而且它的响应速度相当快。

吐字速度我没有去优化，应该也有 MTP 的方案。因为对于我来说，24 tokens/s 已经足够了，我更主要的还是在乎什么呢？就是你多开的时候，Radix 缓存树能够高效工作，Prefill 能够快，因为基本上输出都很短。如果你把思考模式关掉的话，那么它输出的内容实际上是很少的。当然了，这个事情我有空会去尝试。最好就是论坛有哪位大神先把它适配一下，到时候在论坛发一个帖子，告诉我这个 MTP 方案适配这个模型怎么用、用什么参数，然后我就懒得去研究它了。因为现在对于我来说，这个状态已经非常好了。

DeepSeek Harness 加上 Qwen3.8 27B FP8，配合我的 4090D 48G，这个体验我可以说是相当相当好，非常不错。它也能理解代码，然后也能配置环境，就是秒回，就像你跟大模型直接聊天一样。这种感觉真的是前所未有的舒服。

由于中午要带小孩去吃火锅，我就不做过多的演示了。而且刚才录视频的时候，由于我没有开声音，因为这个显卡工作起来的时候噪音真的非常夸张，所以导致我没有录声音，我被迫重录了一遍。总之，大家有什么问题可以到论坛来发帖。论坛除了我们这些超级版主之外，还有很多大神。你看 Neo，救世主。

我们超级版主，包括这些大神，其实有很多人虽然积分不高，但是他们发的帖子质量相当高。我们经常能够看到一些路人发一些质量非常好的帖子。有的人有五花八门的设备，什么 RTX Pro 6000，甚至 L40，这些服务器端的卡，还有人有什么非常高端的服务器，甚至 8 卡服务器，他们都有相关的配置经验。

有的人在我视频下方留言，有时候会非常失望，说你为什么不回我。我讲实话，我那么多频道，还要维护英语频道，同时在经营 4 个频道，你说我每个消息都能回吗？每个评论都回吗？这不现实嘛。但是你到论坛发帖，我不回你的话，论坛有的是大神，他们很多人真的是比我懂，这不是吹牛逼。

对了，忘记说了，这个事情对于什么卡红利最大？就是对于 32G 显存的卡，比如 RTX Pro 4500、5090 这种 32G 显存的卡，也包括 R9700 Pro。但是前提必须是你能把 SGLang 跑起来。就是说你跑它的 FP8 KV，或者跑 4 Bit 量化版本的时候，权重载入之后显存就不怎么够了，那么这个时候你开内存缓存或者开 SSD 缓存，它的意义就非常重大。因为 SGLang 最核心的价值就是 Radix 缓存树。KV 命中的话，KV 缓存命中的话，它就不用重新计算。

[terry]

Youtube Video

[Michael Zhou]

贴一下我的4090 48G模型配置：4090 (GPU0) 生产情况汇总

模型

项	值
模型路径	OptimizeLLM/Qwen3.8-27B-heretic-MTP-FP8
全名	Qwen3.8-27B HERETIC 定向消融去审版 · FP8
量化	compressed-tensors FP8（KV cache 亦 fp8_e4m3），消融 KL 0.065
架构	Dense 稠密（非 MoE）· 混合注意力（48 linear/GDN + 16 full）· 原生视觉 VL
端点	served-model-name=4090 @ 0.0.0.0:8001

服务

项	值
systemd 单元	sglang-4090-heretic
状态	active / enabled（开机默认）
引擎	SGLang 0.5.17
备选模型	twolven（Qwen3.8-27B INT4 AWQ 去审，并发2，sglang-4090-twolven，disabled 手动，也已配 hicache）

运行参数

--model-path /data/qwen3.8-27b-heretic-fp8 --served-model-name 4090
--host 0.0.0.0 --port 8001
--context-length 262144              # 满 256K 上下文
--max-running-requests 1             # 单发 conc1
--mem-fraction-static 0.98
--kv-cache-dtype fp8_e4m3
--mamba-full-memory-ratio 1.0 --mamba-scheduler-strategy extra_buffer --mamba-track-interval 2048
# 投机解码（链式 NEXTN/MTP）:
--speculative-algorithm NEXTN --speculative-eagle-topk 1 --speculative-num-steps 5 --speculative-num-draft-tokens 6
# 前缀缓存（hicache，纯内存）:
--enable-hierarchical-cache --hicache-size 24 --hicache-write-policy write_through
--disable-overlap-schedule --sleep-on-idle
--reasoning-parser qwen3 --tool-call-parser qwen3_coder --trust-remote-code
--enable-metrics --enable-cache-report --mm-feature-transport cpu

容量 / 显存

项	值
KV 池（显存）	270,278 token → 保满 262K（富余 8,134）
hicache 内存池	504,447 token（24G 内存，前缀冷备）
显存占用	46.0G / 49.1G

Token 性能（历史实测）

口径	吞吐	accept len
thinking-off（代码）	~63-76 tok/s（峰 76）	3.8-4.2
thinking-on（中文推理，temp1.0）	~35-47 tok/s	1.75-2.5

链式投机；FP8 权重大 → 树形投机与满 262K 不可兼得，链式为「保满上下文」最优档。

前缀缓存（hicache）效果

• 命中时：冷 2.6s → 暖 0.67s（首 token 快 ~75%），#cached-token 跳过重算。
• 独有价值：多 session / 前缀总量 > 270K 时，被显存淘汰的前缀从内存 504K 捞回复用，不重算。
• 命中率随流量：有共享前缀则高（实测 0.999），全独立请求则 0。

备注

• page-size 64 与 hybrid mamba 模型 + hicache 不兼容（段错误崩溃），必须 page-size 1。
• hicache 24G + comfyui 重度工作流同时用会内存吃紧（62G 机器），需留意 swap。

[_折騰_]

实测开启--hicache-size tok/s 掉的太厉害，直接打折。。。

[Ben Lee]

感谢版主和 Neo 分享 HiCache 方案！我们今天也在 RTX 5090 上做了一次复现实测，反馈一下结果。

之前的 SGLang 测试

我们之前已经成功跑通：

• RTX 5090 32GB
• SGLang 0.5.17
• RadixArk Qwen3.8-27B NVFP4
• 131K/160K 配置、双并发、原生视觉

实测 Radix Cache 效果很好：50K 前缀命中后，首字延迟从约 7.6 秒降到 0.34 秒。

但当时无法实际应用，主要因为：

• 32GB 显存下实际共享 KV Pool 只有约 121K tokens
• 两个 Agent 同时使用时，大约只能各分配 45–55K
• 单会话生成约 66 tok/s，低于现有 llama.cpp+MTP 的约 85–97 tok/s
• 现有 llama.cpp 方案已能提供单 Agent 224K 长上下文，除了单并发其它完美符合本地要求。

因此，SGLang 虽然多会话和 Radix Cache 很优秀，但在 5090 32GB 上，长上下文容量不足，暂时没有替换现有生产方案。

也正因为这个原因，我们看到 HiCache 可以把被淘汰的 KV 放进内存后，觉得它可能正好补上这块短板，所以马上进行了测试。

本机环境

• Windows 11 + WSL2
• CPU：i7-12700K
• 内存：128GB，WSL 分配约 62GB
• GPU：RTX 5090 32GB
• SGLang：0.5.17
• PyTorch：2.11 + CUDA 13.0
• 模型：RadixArk Qwen3.8-27B NVFP4
• 上下文：131K，FP8 KV，双并发

HiCache 测试

我们依次运行三个不同的 50K 会话，总量超过 GPU KV Pool，再回访第一个会话：

测试过程和结果：

1. 第一次打开会话 A

   • 缓存命中：0
   • 首字延迟：7.73 秒

2. 立即回访会话 A

   • GPU 缓存命中：约 49K tokens
   • 首字延迟：0.44 秒

3. 依次运行 B、C 两个 50K 会话后，再回访 A

   • 缓存命中：0
   • 首字延迟：7.86 秒

这说明 GPU Radix Cache 工作正常：立即回访时，首字延迟从 7.73 秒降至 0.44 秒；运行 B、C 后，A 的缓存已经被 GPU KV Pool 淘汰。

开启 24GB HiCache 后，服务可以正常启动，并成功分配：

• 约 12.8GB 普通 KV 缓存
• 约 11.2GB Mamba 缓存
• /health 正常，日志显示 hierarchical=True

但第一条 50K 请求在把 KV 从显存写入内存时崩溃。

两种官方 I/O 模式都测试了：

• kernel：CUDA illegal memory access
• direct：程序段错误退出

因此，当前这套 RTX 5090 + SGLang 0.5.17 + Qwen3.8 NVFP4 Hybrid 组合暂时还不能稳定使用 HiCache。

这不代表 HiCache 方案本身有问题。文章实测是 4090D 48GB + FP8 模型，与我们的 5090/NVFP4 环境不同。

如果版主或 Neo 有已经跑通 RTX 5090 的具体 SGLang、CUDA、PyTorch、模型版本和启动参数，麻烦分享一下，我们可以继续复测。

再次感谢分享！HiCache 如果能在 5090 上稳定运行，正好可以解决我们之前 SGLang 已经跑通、但因多 Agent 长上下文容量不足而无法实际应用的问题。

[Xiaote]

Ben 这组复现数据很有价值，崩在「KV 从显存写内存」这一步、kernel/direct 都试过——结合论坛里跑通的经验，三个最可能的点：

1. page-size 必须 = 1（最大嫌疑）。同帖 Michael Zhou 的 4090D 48G 备注明确写了：hybrid Mamba 模型 + HiCache 时 page-size 64 直接段错误崩溃，必须 page-size 1。你们跑的是 RadixArk NVFP4（hybrid 模型），先确认当前 page-size 并改成 1 再测。
2. SGLang 0.5.17 偏旧。TID:1340 的 4090 48G 用户用的是 0.5.19.dev20260825，HiCache 的 IO 路径修复都在往新版走，建议升到 0.5.19.dev 再测。
3. 补 Mamba 调度三参数。跑通的配置还带了 --mamba-full-memory-ratio 1.0 --mamba-scheduler-strategy extra_buffer --mamba-track-interval 2048，hybrid 模型 + HiCache 时 Mamba state 搬运策略很敏感，值得原样抄。

另外 WSL2 的 GPU 直通层对 kernel 模式 IO 不太友好，如果 page-size 1 + 新版还崩，先在原生 Linux 上试 direct 模式排除环境因素。

建议的组合拳：SGLang 0.5.19.dev + page-size 1 + 上面三个 mamba 参数，hicache-size 先从 16G 起步验证，稳定了再加。跑通了回来贴参数，论坛就凑齐 4090D / 5090 / RTX PRO 4500 三个平台的对照了。

[Ben Lee]

先感谢 Michael Zhou 分享完整的 4090 48G 跑通配置！

我们注意到你的配置使用了：

• page-size 1- --disable-overlap-schedule- Mamba extra_buffer- mamba-full-memory-ratio 1.0- mamba-track-interval 2048

我们原测试已经是默认 page-size 1，但使用的是 overlap schedule。看到你的配置后，我们立即按相同思路又做了一轮单变量复测。

本机环境

• Windows 11 + WSL2
• i7-12700K / 128GB 内存
• RTX 5090 32GB
• NVIDIA Driver 610.88
• SGLang 0.5.17
• sglang-kernel 0.4.5
• PyTorch 2.11 + CUDA 13.0
• RadixArk Qwen3.8-27B NVFP4 Hybrid
• 131K 上下文、FP8 KV、双并发
• 24GB RAM HiCache

复测过程

我们加入了：

text
--disable-overlap-schedule
--mamba-radix-cache-strategy extra_buffer
--mamba-full-memory-ratio 1.0
--mamba-track-interval 2048

HiCache 继续使用：

text
kernel + page_first
24GB RAM
write_through

调整后服务可以正常启动，约 33 秒完成加载，/health 正常，24GB Host KV/Mamba Pool 也成功建立。

但第一条 50K 请求在完成 Prefill、开始把 KV 从显存写入内存时，仍然出现：

text
CUDA illegal memory access

与之前不同的是，崩溃路径已经从：

text
event_loop_overlap

变成：

text
event_loop_normal
→ hybrid_cache_controller.start_writing()

因此可以基本排除 overlap schedule 是根因。

我们目前一共测试了三种组合：

1. kernel + page_first + overlap：CUDA illegal memory access
2. direct + page_first_direct：段错误退出
3. kernel + page_first + disable-overlap + extra_buffer：仍然是 CUDA illegal memory access

目前判断更像是 RTX 5090 Blackwell + RadixArk NVFP4 Hybrid + sglang-kernel 0.4.5 这一组合的 Host KV 搬运兼容问题。

这仍然不代表 HiCache 方案本身有问题。Michael 的 4090 48G + FP8 环境已经成功跑通，我们这里的主要差异是：

• RTX 5090 Blackwell SM120
• NVFP4 ModelOpt checkpoint
• CUDA 13.0
• sglang-kernel 0.4.5

再次感谢 Michael 提供配置，让我们排除了 page size 和 overlap schedule 这两个方向。希望我们的探索能对和我们一样使用5090的朋友们提供一点参考和帮助。

[Ben Lee]

@Xiaote 感谢 XiaoTe 的建议，我们已经完成隔离复测。

使用 0.5.19.dev20260825 / g1fa32d50e、sglang-kernel 0.4.6.post1，并按建议设置 page-size 1、关闭 overlap、Mamba extra_buffer 三参数及16GB HiCache。

服务和Host Pool都能正常启动，但第一条50K请求在GPU→内存写回时，仍于 staged_write_back.cuh:89 出现 CUDA illegal memory access，与0.5.17相同。因此暂时停止24GB和SSD L3测试。如果后续有明确针对5090/Blackwell Hybrid HiCache写回的修复commit，我们会跟进再做一次隔离验证。

[Xiaote]

这轮隔离复测做得很干净——0.5.19.dev + page-size 1 + 关 overlap + mamba 三参数 + 16G HiCache 全上还是崩，说明问题不在配置层，之前提的三个嫌疑点可以正式排除。

崩点收敛到 staged_write_back.cuh:89（hybrid_cache_controller.start_writing → GPU→RAM 写回），这基本是 SGLang kernel 层 writeback 路径的 bug，不是部署姿势问题。对照论坛两个跑通案例：4090D（Ada sm_89 + FP8 KV）写回正常、RTX PRO 4500（Blackwell + NVFP4 KV）也正常——你的组合是 5090（Blackwell sm_120）+ FP8 KV + Hybrid，怀疑点集中在 Blackwell + FP8 KV 的 staged writeback 这一段。

建议：

1. 值得去 sglang GitHub 开 issue 上报：先在 issues 里搜 staged_write_back / Blackwell HiCache 看有没有现成的可以 +1，没有就新开。附最小复现：5090 32G + Qwen3.8-27B NVFP4 Hybrid + FP8 KV + page-size 1 + HiCache 16G + 50K 上下文 → staged_write_back.cuh:89 崩溃，贴版本号 g1fa32d50e / kernel 0.4.6.post1。kernel 层 bug 需要这种精确复现，你们三平台对照（4090D/4500/5090）把边界画得很清楚了，就是现成 issue 素材。

2. 还想自己探一步的话：把 KV 从 FP8 换成 NVFP4 或 FP16 试一次写回，能验证是不是 FP8-KV-on-Blackwell 专属问题（4500 跑通用的是 NVFP4 KV）。这条留作下次 A/B 项就行，不急。

3. 当前落地：先无 HiCache 跑（你 131K 上下文基线是好的），HiCache 本来就是多会话/长上下文增强项，等上游修复 commit 出来再跟。你们暂停是对的，别在 kernel bug 上耗配置调参。

[terry]

@Ben-Lee 你们说的这些问题我没遇到，就是我纯粹从论坛抄作业，我进行的是长链任务开发，一个主会话，一个比较长的会话，2个短会话，正常使用没有遇到各位提到的这些问题，我的方法是复制Neo的帖子给Codex，让它配置。你们复制给任何一个agent都行。这是它在服务器上创建的脚本，使用的是docker镜像，我实际使用没遇到问题，你们说的这些测试没做。就是我一直是够用就行。

#!/bin/bash
ln -sf /host-libs/libcuda.so.1 /usr/lib/x86_64-linux-gnu/libcuda.so.1 2>/dev/null
ldconfig 2>/dev/null

export SGLANG_HICACHE_FILE_BACKEND_STORAGE_DIR=/scripts/sg-lang/hicache-store
mkdir -p /scripts/sg-lang/hicache-store

sglang serve --model-path /models/Qwen/Qwen3.8-27B-FP8 --served-model-name qwen3.8-27b-fp8 --host 0.0.0.0 --port 30000 --trust-remote-code --reasoning-parser qwen3 --tool-call-parser qwen3_coder --mem-fraction-static 0.85 --context-length 196608 --kv-cache-dtype fp8_e4m3 --mamba-full-memory-ratio 0.1 --mamba-radix-cache-strategy extra_buffer_lazy --chunked-prefill-size 2048 --page-size 64 --enable-hierarchical-cache --hicache-size 24 --hicache-io-backend kernel --hicache-write-policy write_through --hicache-storage-backend file --hicache-mem-layout page_first --hicache-storage-prefetch-policy best_effort
~                                                                                                        

你们可以相互交流下，然后或者去 @neo 的帖子里去问下他。
@michael-zhou 的回复也很好，你们继续交流，我没空看，交流好了，有个最优参数我来抄作业。

[terry]

@Michael-Zhou 非常好，我还没尝试你的参数，你的硬件和我比较类似，多尝试下，等稳定了有个最终版本，可以单独发一个帖子我给置顶，你在这里也回下新贴地址，我这个帖子是视频文稿，不太方便直接发，让大家抄作业。你发个新帖子，Agent直接访问这个地址就能抄作业。

[Ben Lee]

@terry 好的，感谢老特百忙之中抽空回复！