KaiWuBOSS 最近的时间轴更新 KaiWuBOSS 最近的时间轴更新 |
KaiWuBOSSV2EX 第 794716 号会员，加入于 2026-03-18 09:14:31 +08:00今日活跃度排名 2083 |
| 我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现 Local LLM • KaiWuBOSS • 3 小时 35 分钟前 • 最后回复来自 KaiWuBOSS | 84 |
KaiWuBOSS 最近回复了
3 小时 35 分钟前 回复了 KaiWuBOSS 创建的主题 › Local LLM › 我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现 |
@coefu 这个问题之前确实没想过你提示很到位，我刚搜了下，说 lammacpp 也回复说自己也没搞定。 我想了下，cpu 不应该只做存放，应该也要做运算，–– cpu-moe 是支持的。我们计划后面版本验证下，如果 cpu 计算后丢给 gpu 能不能提速，如果最小验证成功我们就上线，具体：
attention 层 → GPU （计算密集）
MoE expert → CPU （并行激活，利用多核）
KV cache 管理 → CPU 异步处理
三者同时跑，不互相等待。现在只是思路，后面看最小验证成功就能上线。
attention 层 → GPU （计算密集）
MoE expert → CPU （并行激活，利用多核）
KV cache 管理 → CPU 异步处理
三者同时跑，不互相等待。现在只是思路，后面看最小验证成功就能上线。
13 小时 38 分钟前 回复了 KaiWuBOSS 创建的主题 › Local LLM › 我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现 |
@diudiuu 你的分析基本正确：
带宽是 decode 阶段的瓶颈
31B dense bf16 理论值就是 4-5 tok/s
llama.cpp 跑到 2.5 tok/s 是正常的（未充分优化）
但有两个方向可以突破：
1. 换 Gemma 4 26B MoE 版本
同等文件大小，速度快 6 倍（实测 70 tok/s ）
因为每次 token 只激活 4B 参数
2. 降量化
BF16 → Q4_K_M：约 11 tok/s
BF16 → NVFP4 （ DGX Spark 支持）：约 52 tok/s
Kaiwu 的原理就是自动做这些判断：
识别 dense vs MoE
根据带宽选最优量化
找到速度/质量/上下文的最优平衡
对 DGX Spark 这种统一内存架构
Kaiwu 会把它当高带宽设备处理
自动选更高精度的量化（不需要 q4_0 ）
带宽是 decode 阶段的瓶颈
31B dense bf16 理论值就是 4-5 tok/s
llama.cpp 跑到 2.5 tok/s 是正常的（未充分优化）
但有两个方向可以突破：
1. 换 Gemma 4 26B MoE 版本
同等文件大小，速度快 6 倍（实测 70 tok/s ）
因为每次 token 只激活 4B 参数
2. 降量化
BF16 → Q4_K_M：约 11 tok/s
BF16 → NVFP4 （ DGX Spark 支持）：约 52 tok/s
Kaiwu 的原理就是自动做这些判断：
识别 dense vs MoE
根据带宽选最优量化
找到速度/质量/上下文的最优平衡
对 DGX Spark 这种统一内存架构
Kaiwu 会把它当高带宽设备处理
自动选更高精度的量化（不需要 q4_0 ）
14 小时 3 分钟前 回复了 KaiWuBOSS 创建的主题 › Local LLM › 我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现 |
@ravecn2014 claude 发现个方法 我马上试试:
v0.1.9 — 多卡 tensor split 优化多卡 tensor split 从纯按显存比例改为按 显存×带宽 加权。异构多卡（如 3090+4090+5060 ）分配更合理——弱卡少分层，不拖慢整体多卡显示改为逐卡列出（型号、显存、带宽、分配比例）
--fit on 现在对 full_gpu 和 moe_offload 两种模式都无条件启用（之前 fallback 路径的 moe_offload 漏了）加速特性显示新增 tensor split 比例（多卡无 NVLink 时）
老师麻烦等我 0.1.9 编译好发布再测试一遍 应该能好 如果不行告诉我我跟进
v0.1.9 — 多卡 tensor split 优化多卡 tensor split 从纯按显存比例改为按 显存×带宽 加权。异构多卡（如 3090+4090+5060 ）分配更合理——弱卡少分层，不拖慢整体多卡显示改为逐卡列出（型号、显存、带宽、分配比例）
--fit on 现在对 full_gpu 和 moe_offload 两种模式都无条件启用（之前 fallback 路径的 moe_offload 漏了）加速特性显示新增 tensor split 比例（多卡无 NVLink 时）
老师麻烦等我 0.1.9 编译好发布再测试一遍 应该能好 如果不行告诉我我跟进
14 小时 28 分钟前 回复了 KaiWuBOSS 创建的主题 › Local LLM › 我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现 |
@ravecn2014 仍然是多显卡问题 这方面还得再优化 我想想有没有更好方法
15 小时 0 分钟前 回复了 KaiWuBOSS 创建的主题 › Local LLM › 我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现 |
@ImINH 嗯 很好的建议 之前就希望有专家能给建议 我周一来整 我还不知道什么 tg 我还只会 qq.vx
15 小时 7 分钟前 回复了 KaiWuBOSS 创建的主题 › Local LLM › 我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现 |
@CFM880 url: http://127.0.0.1:11435/responses
这是 OpenAI 新版 API 的端点
Responses API （ 2025 年新增）
用于流式响应的新格式
Kaiwu 的 proxy 只实现了：
/v1/chat/completions ✅
/v1/models ✅
没有实现：
/responses ❌
用户用的客户端（可能是新版 Cursor 或 Claude Code ）
在调用新的 /responses 端点
Kaiwu proxy 不认识这个路径，返回 404 我马上来优化 麻烦看到 0.1.7 发布后再试试 谢谢了
这是 OpenAI 新版 API 的端点
Responses API （ 2025 年新增）
用于流式响应的新格式
Kaiwu 的 proxy 只实现了：
/v1/chat/completions ✅
/v1/models ✅
没有实现：
/responses ❌
用户用的客户端（可能是新版 Cursor 或 Claude Code ）
在调用新的 /responses 端点
Kaiwu proxy 不认识这个路径，返回 404 我马上来优化 麻烦看到 0.1.7 发布后再试试 谢谢了
15 小时 17 分钟前 回复了 KaiWuBOSS 创建的主题 › Local LLM › 我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现 |
@shen09darkareas 谢谢提醒 我马上把 dll 加进去 就不折腾用户了
15 小时 19 分钟前 回复了 KaiWuBOSS 创建的主题 › Local LLM › 我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现 |
@kubecoder 哥 你重新更新下 0.1.6 看看问题还在不 记得再次使用记得要 reset
17 小时 59 分钟前 回复了 KaiWuBOSS 创建的主题 › Local LLM › 我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现 |
@ImINH 嗯 ai 自己写的 没用别人的架构 一直在修 有兴趣参与管理吗
18 小时 0 分钟前 回复了 KaiWuBOSS 创建的主题 › Local LLM › 我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现 |
@diudiuu 请问是用过 kaiwu 对比过的吗
Select Language