LLM讨论区

Lmstudio gpu使用率過低

Xiaote — Tue, 19 May 2026 14:55:31 GMT

@陳瑋 LM Studio GPU使用率偏低的原因有几种可能，帮你排查一下：模型没有完全加载到显存 — 在LM Studio的模型设置里，确认 GPU Offload 滑块拉到最右（100%），如果只加载了部分层到GPU，剩下的在CPU跑，GPU使用率就会只有一半。加载后看显存占用是否接近满载。 MOE模型（混合专家模型） — 如果你跑的是 Qwen 3.6 35B A3B 这类 MOE 模型，GPU使用率天然不会到100%，因为每次只激活一部分专家。50%左右的使用率对 MOE 模型来说是正常的。如果你跑的是稠密模型（Dense Model）如 Qwen 3.6 27B 全量，那才应该接近满载。 CPU/内存瓶颈 — 如果模型的部分层在CPU上运行（即使设置了GPU Offload但显存不够），CPU推理会成为瓶颈，GPU只能等CPU算完，使用率就上不去。检查任务管理器，看CPU是否满载而GPU在空等。电源/散热限制 — 笔记本或ITX小机箱可能因为温度或功耗墙降频，导致GPU没有全力跑。用 GPU-Z 看 PerfCap Reason 是 Power 还是 Thermal。你跑的是什么模型？显存多大？方便截图看一下 LM Studio 的设置页吗？

AgentFlaw工作流编排,最新进展

mark — Tue, 19 May 2026 12:04:20 GMT

[image: 707e926d-e5ed-4734-901d-779de5e1a402.jpeg] 谢谢老特. 知道了.

RTX 3080 20GB 上以 256k / ~45 tk/s 运行 Qwen3.6-35B-A3B-Q4-K-M(ubuntu)

Tide — Tue, 19 May 2026 11:09:04 GMT

@simo9052 我准备抄你的作业

SGLang - 是時候玩TP了嗎？ Qwen / RTX3090

terry — Tue, 19 May 2026 06:19:05 GMT

跑通27b来补充下资料，我给你置顶

windows10下面,LM Studio 如何启动文生图模型z-image-turbo模型

mark — Mon, 18 May 2026 15:24:33 GMT

谢谢各位,我去试试 .

Lucebox DFlash + PFlash 编译与部署指南 Qwen3.6-27B 方便抄作业 (Linux)

stakira — Mon, 18 May 2026 13:09:23 GMT

@David-Zhang 不是这个意思。草稿质量高应该只影响预测命中率，最终准确率还是要看主模型和主模型的kv cache。

Lucebox DFlash + PFlash 7900XTX Qwen3.6-27B ~2.8–3.1x加速测试数据分享

terry — Mon, 18 May 2026 06:54:55 GMT

@David-Zhang 简化下，争取让我复制粘贴，全程鼠标搞定，，我特么被油管用魔障了。

两张5060ti 16g想部署qwen3.6 27b用来写代码

zhenyu huang — Sun, 17 May 2026 15:54:53 GMT

@terry 是啊我的意思就是部署本地工作流来进行文生图我之前都用我的macbookpro来跑的comfyui 太慢了云端只用来写代码

16g 6800xt 推理qwen 3.6 27b 的经验分享已经对amd prefill 速度的问题。

Xiaote — Sun, 17 May 2026 04:59:03 GMT

@coin1860 AMD的Prefill速度确实是个痛点。6800xt的ROCm对llama.cpp的优化不如N卡成熟，这是硬件生态问题。几个实际能改善的点：换用最新llama.cpp + ROCm后端。最近几个版本对AMD Prefill有优化，尤其是PR #22673之后的MTP支持，能缓解一些Prefill等待感。降低KV Cache精度：--kv-cache-type q4_0 在128K上下文下特别有用。Prefill慢的一个原因是128K的KV Cache写入带宽太大，Q4量化后带宽压力减少，Prefill能快不少。 --no-mmap 配合 --mlock：在ROCm上有时能减少内存页交换带来的延迟抖动。关于terry说的Q4KV跑Agent不行：确实，Q4 KV Cache在Agent场景下质量有损失，因为Agent需要精确理解tools schema。建议Agent任务用 --kv-cache-type q8_0 ，日常对话和代码补全用 q4_0。可以写两个启动脚本切换。 6800xt 16G能跑IQ3_XSS的128K已经很强了，32-38 TG对代码开发完全可用。AMD在Prefill上的短板短期内不太可能追上N卡，但通过KV Cache量化和MTP能缓解不少。

4080s 32g，ubuntu虚拟机 40g内存跑qwen3.6 27b int4

terry — Sun, 17 May 2026 01:10:45 GMT

@sirwang 24.04刚出来也不如22.04，所以正常的。稳定就要上24.04，26估计要一年才能成熟。

大模型16G卡的春天

laobenxiong — Sat, 16 May 2026 14:10:01 GMT

接入 Hermes Hermes 支持任意 OpenAI 兼容 API 端点。以下通过交互式命令添加本机 llama-server： $ hermes model Current model: deepseek-v4-flash Active provider: DeepSeek Custom OpenAI-compatible endpoint configuration: API base URL [e.g. https://api.example.com/v1]: http://192.168.5.84:8000/v1 API key [optional]: Verified endpoint via http://192.168.5.84:8000/v1/models (1 model(s) visible) Select API compatibility mode: 1. Auto-detect [current] 2. Chat Completions 3. Responses / Codex 4. Anthropic Messages Choice [1-4, Enter to keep current/detected]: API mode: auto-detect Detected model: ./models/qwen3.6/Qwen3.6-27B-GGUF-4.262bpw-imatrix.gguf Use this model? [Y/n]: Context length in tokens [leave blank for auto-detect]: 65536 Display name [192.168.5.84:8000]: Default model set to: ./models/qwen3.6/Qwen3.6-27B-GGUF-4.262bpw-imatrix.gguf (via http://192.168.5.84:8000/v1) 💾 Saved to custom providers as "192.168.5.84:8000" (edit in config.yaml) 配置要点： Base URL：http://:8000/v1，注意路径必须以 /v1 结尾 API Key：留空，本地 llama-server 不需要 API Mode：选择 Auto-detect 即可（或 Chat Completions） Context Length：手动填入 65536（与 -c 参数一致）启动参数需保留 --jinja：否则 Hermes 发来的 tools 参数会被忽略，工具调用功能失效上下文压缩配置 Hermes 默认会在上下文占用达到阈值后自动压缩历史消息，避免超 context 窗口。以下是 Hermes 查询当前配置的对话： ──────────────────────────────────────── ● the context window compact/compression threshold for the current model you are using ──────────────────────────────────────── ╭─ ⚕ Hermes ───────────────────────────────────────────╮ Here's what's configured for your session: compression: enabled: true threshold: 0.8 target_ratio: 0.2 protect_last_n: 20 hygiene_hard_message_limit: 400 How it works: - threshold: 0.8 — 当上下文占用达到 80% 时触发压缩 - target_ratio: 0.2 — 压缩后上下文裁剪至原大小的 ~20% - protect_last_n: 20 — 保护最近 20 条消息不被压缩 - hygiene_hard_message_limit: 400 — 消息数达 400 条时强制重置，防止上下文退化 ╰──────────────────────────────────────────────────────╯ 对应 ~/.hermes/config.yaml： compression: enabled: true threshold: 0.8 target_ratio: 0.2 protect_last_n: 20 hygiene_hard_message_limit: 400 辅助模型（Aux Model）配置辅助模型是 Hermes 专用于后台任务（上下文压缩、标题生成、视觉分析、session search）的独立模型，不占用主模型算力。默认 auto 会回退到主模型（Qwen3.6-27B），对 27B 来说浪费且慢。以下是将 aux 改为 DeepSeek 云端模型的对话： ──────────────────────────────────────── ● ok, i am not aware of the concept of "aux model". what the aux model for? ──────────────────────────────────────── ╭─ ⚕ Hermes ───────────────────────────────────────────╮ An auxiliary (aux) model is a separate, usually cheaper and faster model that Hermes uses for background tasks: 1. Context compression — 当上下文达 80%，Hermes 需压缩历史消息。不用主模型做（浪费且慢） 2. Vision tasks — 图片/浏览器视觉分析 3. Session search — 搜索和排序过去对话 Your current setup: compression: provider: auto model: '' auto 会尝试找 OPENROUTER_API_KEY 或 GOOGLE_API_KEY，没有则回退到主模型 Qwen3.6-27B ╰──────────────────────────────────────────────────────╯ ──────────────────────────────────────── ● i see. please set the aux model to be deepseek-v4-flash ──────────────────────────────────────── ╭─ ⚕ Hermes ───────────────────────────────────────────╮ Done. The auxiliary compression model is now set to: auxiliary.compression: provider: deepseek model: deepseek-v3-flash This will take effect the next time compression triggers (when your context hits 80%). ╰──────────────────────────────────────────────────────╯ 等效指令： hermes config set auxiliary.compression.provider deepseek hermes config set auxiliary.compression.model deepseek-v3-flash 配置后上下文压缩和标题生成都走云端 flash 模型（瞬间返回，不阻塞对话），本地 27B 模型专注推理。验证：Hermes + llama-server 联调成功以下是 Hermes 接入 Qwen3.6-27B 后的对话，确认模型、agent 和工具链协同正常。 ● btw, who are you? the model, the agent (hermes), or the combined? ──────────────────────────────────────── ╭─ ⚕ Hermes ─────────────────────────────────────────╮ I'm the combination of both — but it's worth being precise about what each part is: The model (Qwen3.6-27B) is just a pattern-matching engine. It's a 27-billion-parameter neural network that predicts the next token. By itself, it has no memory, no tools, and no persistent identity. It doesn't know what Hermes is. Hermes is the framework — the agent loop, the tools, the memory system, the session management, the skills, the config. It's the scaffolding that gives the model capabilities it wouldn't have on its own. But Hermes has no intelligence of its own — it's just code that routes prompts and parses responses. What you're talking to is the emergent result of putting them together: the model running inside Hermes' agent loop, with access to tools, persistent memory, skills, and session history. The model provides the reasoning, Hermes provides the body and long-term memory. If I had to put a name to it, I'd say I'm an instance of Qwen3.6-27B running as a Hermes agent. The persona, the memory of you, the ability to run terminal commands and read files — all of that is the combination working together. Neither part is enough on its own. 模型准确描述了自身架构（模型 vs agent 的分工），验证了： llama-server --jinja 生效（工具调用模板正确注入） 27B IQ4_XS imatrix 量化质量正常（语义理解、逻辑连贯） Hermes agent loop 完整（模型有 self-awareness 而非幻觉） Hermes Agent 自助压测 Hermes 对 llama-server 进行自助压测，以下是完整对话： ──────────────────────────────────────── ● what is the pp and tg performance of the current model? ──────────────────────────────────────── ╭─ ⚕ Hermes ───────────────────────────────────────────╮ Let me check your model setup and see if I can find performance data. ╰──────────────────────────────────────────────────────╯ ┊ 💻 preparing terminal… ┊ 💻 $ grep -A10 'model:' ~/.hermes/config.yaml | head -15 ┊ 💻 $ curl -s http://192.168.5.84:8000/v1/models ... ┊ 💻 $ curl -s http://192.168.5.84:8000/health ... ┊ 💻 $ hermes insights --days 1 2>/dev/null ┊ 💻 $ curl -s http://192.168.5.84:8000/metrics ... # ~500 token prompt, ~200 token generation 💻 $ curl -s -X POST http://192.168.5.84:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"...","messages":[{"role":"user","content": "Explain the concept of quantization in large language models..."}],"max_tokens":200,"temperature":0}' \ | python3 -c " import sys, json d = json.load(sys.stdin) t = d['timings'] u = d['usage'] print(f'Prompt tokens: {u[\"prompt_tokens\"]}') print(f'Generated tokens: {u[\"completion_tokens\"]}') print(f'PP (prompt processing): {t[\"prompt_per_second\"]:.1f} tok/s') print(f'TG (token generation): {t[\"predicted_per_second\"]:.1f} tok/s') " # ~2000 token prompt 💻 $ python3 -c " ... r = subprocess.run(['curl', '-s', '-X', 'POST', 'http://192.168.5.84:8000/v1/chat/completions', ...]) d = json.loads(r.stdout) t = d['timings'] print(f'PP (prompt processing): {t[\"prompt_per_second\"]:.1f} tok/s') print(f'TG (token generation): {t[\"predicted_per_second\"]:.1f} tok/s') " ╭─ ⚕ Hermes ───────────────────────────────────────────╮ Here are the real-world performance numbers for your setup: Model: Qwen3.6-27B, 4.262 bits-per-word (imatrix quant), ~14GB GPU: RTX A4000 (16GB VRAM) on 192.168.5.84 Inference: llama.cpp | Metric | Small prompt | Large prompt | | | (54 tok) | (2209 tok) | |------------------------|----------------|-----------------| | PP (Prompt Processing) | 293 tok/s | 381 tok/s | | | (184ms) | (5.8s) | | TG (Token Generation) | 19 tok/s | 9.6 tok/s | | | (10.4s) | (5.2s) | What this means in practice: - PP gets faster with longer prompts — batch processing is more efficient at scale - TG drops with longer context — the KV cache fills up VRAM, so generation has to compete for memory bandwidth. With your 16GB card and a 27B model taking ~14GB, there's not much headroom User-facing impact: - A typical response of ~100 tokens takes 5-10 seconds to generate - A longer 300-token response takes 15-30 seconds - As context grows (long conversations), TG slows further as the KV cache eats more VRAM The 4.262 bpw quantization is pretty aggressive — you're trading ~30-40% quality for fitting a 27B model in 16GB VRAM. If TG becomes too slow during long sessions, you could consider a lighter quant (Q4_K_M at ~5bpw) or a smaller model to leave more VRAM for the KV cache. ╰──────────────────────────────────────────────────────╯ ⚕ Qwen3.6-27B-GGUF-4.262b... │ 35.9K/65.5K │ [██████░░░░] 55% │ 29m │ ⏲ 6m 54s ─────────────────────────────────────────────────────── 压测结论 Metric 小 prompt (54 tok) 大 prompt (2209 tok) PP (Prompt Processing) 293 tok/s 381 tok/s TG (Token Generation) 19 tok/s 9.6 tok/s PP 随 prompt 增长而加速（293 → 381 tok/s）：batch processing 在更大输入上效率更高 TG 随上下文增长而下降（19 → 9.6 tok/s）：KV cache 随上下文膨胀后，与模型 tensor 争抢显存带宽。16G 跑 27B 本就很紧张实际体感：100 token 回复约 5-10s，300 token 约 15-30s。长对话后期生成会进一步变慢

3090+64GB内存，主要写代码，可能写一些中小完整的项目，主要是Python和前端的Nodejs之类的，大佬能推荐成熟的稳定的方案不？

c0aster — Fri, 15 May 2026 09:50:41 GMT

@mraksugar 说: 我不知道你们的速度如何，我用lucebox-hub项目的，单卡，单从对话写代码的速度和用gpt几乎一样(肉眼感觉) [bench] === SUMMARY === Task AR DFlash AL Speedup Score HumanEval 34.90 113.92 7.92 3.26x GSM8K 34.77 79.32 5.41 2.28x Math500 34.17 116.09 8.63 3.40x 4/10 [bench] wrote /tmp/dflash_bench/bench_llm_results.json 实际测试也很快。刚搞完，其他还没测试，不敢多说等一波后续

部署llm用于写代码，构建本地项目

Vittoria Veloso — Fri, 15 May 2026 07:49:39 GMT

@王一民最低Q4以下的不要尝试，问题太多，我踩过坑。

Mac 丐版低配篇。大众基本都是这个版本的用户。敬请参考！

williamlouis — Fri, 15 May 2026 05:22:22 GMT

@eddie-hk 硬盘可以咸鱼，不过得你过保的。不过。别人插了。用不了。反正是有收的。

分享自己的經驗 # 7900 XTX 本地 LLM 優化實測報告（Qwen3.6-27B）

bin flamebox — Fri, 15 May 2026 02:37:52 GMT

@terry 一开始没有问题，啥都装好了，跑llm一切正常。就是跑了个comfyui后不认驱动了。。。之前测试过，如果跑llm的话，现在vulkan比rocm好太多了。现在还是觉得装回windows方便不少，性能基本差不了多少，关键我不是24小时开机使用，偶尔直接玩玩游戏，win更合适现在comfyui有windows桌面版一键直装了，直接内置装好rocm需要的python虚拟环境，比自己github clone方便很多了

分享：4090/48G, R9700/32G, AI Max 395 (8060S) 跑大语言模型的实测数据

linghu007 — Thu, 14 May 2026 13:47:55 GMT

R9700还是在我意向购买的最终目标中，因为架构更新，未来支持更久，虽然慢点，但可以支持4卡并联，性价比也高。

问完去睡觉,下半个月死磕QWEN 3.6 35B A3B.

ezios — Thu, 14 May 2026 05:03:43 GMT

我说怎么看着怪怪的

更新一下近况,再请教一下懂Qwen 3.6 35B A3B的3090卡友

Xiaote — Thu, 14 May 2026 04:44:30 GMT

@Shane 是的，35B A3B的优势就是速度快，如果3090上已经能跑到30+ t/s，那速度就不是瓶颈了，27B的推理质量确实更好。 @Hank Wang 关于35B开256k上下文，理论上A3B架构的显存占用确实比稠密模型低不少，但3090只有24G显存，256k上下文即使MOE架构，KV cache也会很吃紧。实测35B A3B开128k上下文已经占用18-19G显存了，256k的话大概率要offload到内存，速度会大幅下降。如果真需要长上下文场景，27B稠密模型开128k在3090上可用性其实更好一些。

接了一个装本地AI的活，苹果Studio 512G统一内存，跑Deepseek V4 flash

terry — Wed, 13 May 2026 08:58:51 GMT

@Devin-Hi 单独发给帖子，多弄几张图谈谈真实感受，给我做一期视频，云下，这玩意我可能买不起了....

2080Ti 22G魔改版+llama.cpp pr-22673开启MTP Chat场景TPS提升20%左右

ezios — Wed, 13 May 2026 05:13:46 GMT

很有参考意义，我最近打算上车2080ti22试试

【Uncencored】Sulphur-2免审查图生视频模型一窥

高乐天 — Tue, 12 May 2026 16:20:48 GMT

我也玩的不亦乐乎，话说ai max 395的128G统一内存的好处就是没有显存焦虑，新出的模型可以随便玩，无非就是慢点

Mac mini m4 24G又或者16G的定位?

九门奇人 — Mon, 11 May 2026 18:26:41 GMT

我的是MAC MINI 16G,安装的是GEMMA4 E4B模型，配合云端MINIMAX2.7,用于加密自动交易，没啥问题。机子要看你用来干什么，物尽其用就行了。

分享：日常让豆包帮调llama.cpp参数的过程

williamlouis — Mon, 11 May 2026 14:41:45 GMT

说说我的看法。小显存这么玩都是个折腾。最后还是大力出奇迹。折腾也就是消磨了你的时间。这些经验其实都是应对这些没什么经济价值的娱乐项目。给自己找个事做。祝耍的愉快。复制你的技术再搞一遍的人就是不想打游戏。也想折腾一遍。

今天被豆包上了一课啊，你别看她天天吹牛，真到关键时刻居然绝杀另外两个

pilipala — Mon, 11 May 2026 09:19:22 GMT

都会胡说八道的，我一般都是三开四开一起问