 |
coefuV2EX 第 616381 号会员，加入于 2023-02-28 17:15:35 +08:00今日活跃度排名 1567 |
coefu 最近回复了
1 小时 20 分钟前 回复了 sqshanyao 创建的主题 › Local LLM › 求可靠本地 vibe coding，有八卡的 L20 服务器 |
先试 llama.cpp 的 8 卡 tensor parallel 。反正一年前的 8 卡 TP 模式，是有点问题的，不知道修复没有。如果不行，就上 vllm 。
1 小时 22 分钟前 回复了 sqshanyao 创建的主题 › Local LLM › 求可靠本地 vibe coding，有八卡的 L20 服务器 |
unsloth/Qwen3.5-397B-A17B-GGUF, UD-Q6_K,327G,留 50G 跑 context ，看情况；如果 context 不够，就换 UD-Q4_K_XL ，245G ，留 130G 跑 context ，肯定够的。
IDE 用开源的 continue 即可。想完全 agent ，估计够呛，你自己得盯着。local 的能力肯定不如云端 api 的。
IDE 用开源的 continue 即可。想完全 agent ，估计够呛，你自己得盯着。local 的能力肯定不如云端 api 的。
8 小时 9 分钟前 回复了 Ken1028 创建的主题 › Local LLM › 想掏一台 Mac mini M4 Pro 64G 跑 gemma4 31b Q4 接 openclaw 处理日常的问题，有人测试过速度吗？ |
agent 这条路，本身就是跑不通的。理论决定了。
每次 agent 的成功率到不了 100%，N 步之后，就会降到低于 1%，完全失败。云端无非就是用巨量资源让这个 N 长到能覆盖每个人的任务。端侧的这个 N 因为资源的限制，比云端 api 要低几个数量级。
云端 api 的体验，在 local 本地，基本上就无法体验到，理论决定了。
每次 agent 的成功率到不了 100%，N 步之后，就会降到低于 1%，完全失败。云端无非就是用巨量资源让这个 N 长到能覆盖每个人的任务。端侧的这个 N 因为资源的限制，比云端 api 要低几个数量级。
云端 api 的体验，在 local 本地，基本上就无法体验到，理论决定了。
1 天前 回复了 diudiuu 创建的主题 › Local LLM › [求助] DGX Spark 上 Ollama 推理极慢，改用 llama.cpp 部署是否更合适？ |
@enihcam #36 A16 这种，配合 LatentMAS ，实际上是当前最佳方案了。同一张卡有 4 个 gpu ，可以跑 4 个 qwen3.5 9B Q8 ，合作的好的话，能力提升是指数级的。
1 天前 回复了 RatioPattern 创建的主题 › Local LLM › 32B 本地 vibe coding 有能用的模型吗 |
要用好，需要很多绝招。比较难搞，但也并不是搞不成。
用多个 agent 并行，并且改造成隐式推理，用 LatentMAS 技术（ https://arxiv.org/abs/2511.20639 ，https://github.com/Gen-Verse/LatentMAS ），这个要改 模型的 transformer 架构，将 kvcache 流动起来，对显存也有挑战。 多个 agent 并行隐式推理，能保证速度，多个 agent 也能提升智能。
就算是 Qwen3.5-35B-A3B 的 BF16 ，也有 70GB 了，长 context 的 kvcache + LatentMAS 本身也要显存，估计单卡 128G ，可以搞。
用多个 agent 并行，并且改造成隐式推理，用 LatentMAS 技术（ https://arxiv.org/abs/2511.20639 ，https://github.com/Gen-Verse/LatentMAS ），这个要改 模型的 transformer 架构，将 kvcache 流动起来，对显存也有挑战。 多个 agent 并行隐式推理，能保证速度，多个 agent 也能提升智能。
就算是 Qwen3.5-35B-A3B 的 BF16 ，也有 70GB 了，长 context 的 kvcache + LatentMAS 本身也要显存，估计单卡 128G ，可以搞。
2 天前 回复了 diudiuu 创建的主题 › Local LLM › [求助] DGX Spark 上 Ollama 推理极慢，改用 llama.cpp 部署是否更合适？ |
@coefu #37 不过，mi50 夸张的 1.02T/s bandwidth + pcie 4.0 ，足够有吸引力了.
2 天前 回复了 diudiuu 创建的主题 › Local LLM › [求助] DGX Spark 上 Ollama 推理极慢，改用 llama.cpp 部署是否更合适？ |
@enihcam #36 还有一个极致的 hack 128G 方案，只怕你技术不行。
amd mi50 32G * 4 。 最关键是，mi50 32G 因为其折腾的门槛，海鲜市场当前 950 一张，4 张 才一张 nvidia tesla v100 32G 的价格。
但是，复杂的 rocm 配置，和多卡 tensor parallel 的技术，有点门槛的。
amd mi50 32G * 4 。 最关键是，mi50 32G 因为其折腾的门槛，海鲜市场当前 950 一张，4 张 才一张 nvidia tesla v100 32G 的价格。
但是，复杂的 rocm 配置，和多卡 tensor parallel 的技术，有点门槛的。
2 天前 回复了 diudiuu 创建的主题 › Local LLM › [求助] DGX Spark 上 Ollama 推理极慢，改用 llama.cpp 部署是否更合适？ |
@diudiuu #25 你们赚钱了没？
2 天前 回复了 diudiuu 创建的主题 › Local LLM › [求助] DGX Spark 上 Ollama 推理极慢，改用 llama.cpp 部署是否更合适？ |
@enihcam #26 你搞到技术面，还是基本面？基本面，我有大招。远超市面上的技术。
2 天前 回复了 diudiuu 创建的主题 › Local LLM › [求助] DGX Spark 上 Ollama 推理极慢，改用 llama.cpp 部署是否更合适？ |
@enihcam #22 dgx spark 纯属老黄恶心人的，喜欢搞一些非 HBM 的 消费级 gddrX 显存 搞成超算产品。
什么 A10 ，A16 ，就是 Ampere 核心 + gddrX 显存。 特别是 A16 这个奇葩，搞了 4 个 弱 Ampere 核心（只有 1280 个 cuda+40 个 tensor core ）+ 16G gddr6 ，一张卡凑了 64G 。每个 Ampere 到 gddr6 有 200GB/s 的 bandwidth ，四个 core 片上走 pcie 直通，tensor parallel inference 能搞到 800GB/s 。
什么 A10 ，A16 ，就是 Ampere 核心 + gddrX 显存。 特别是 A16 这个奇葩，搞了 4 个 弱 Ampere 核心（只有 1280 个 cuda+40 个 tensor core ）+ 16G gddr6 ，一张卡凑了 64G 。每个 Ampere 到 gddr6 有 200GB/s 的 bandwidth ，四个 core 片上走 pcie 直通，tensor parallel inference 能搞到 800GB/s 。
Select Language