neteroster 最近的时间轴更新 neteroster 最近的时间轴更新 |
neterosterV2EX 第 191331 号会员，加入于 2016-09-11 21:01:55 +08:00今日活跃度排名 6500 |
neteroster 最近回复了
2 天前 回复了 Chicagoake 创建的主题 › Apple › Apple Music Win 端使用问题 |
Win 端我这里基本没法用，各种问题，莫名其妙连不上网络，崩溃，播放中断等等
4 天前 回复了 kizunai 创建的主题 › OpenAI › 花了钱却被 OpenAI 当傻子一样骗，从此一生黑 |
@Liftman #28 不，ChatGPT 降智是广泛验证确实存在的刻意行为，不是模型幻觉。无法搜索是因为提供给模型的工具不包含搜索（可以验证），这是降智的表现之一。除此之外还广泛验证了降智和 IP 干净程度强相关，这些都是有大量样本的结果，不是幻觉可以解释的
8 天前 回复了 PROJECT 创建的主题 › OpenAI › 大家觉得哪个 AI 现在最强？国产的 |
qwen deepseek glm
19 天前 回复了 2bNot2b 创建的主题 › OpenAI › 求教使用 gpt-4o 时，同样的输入输出结果不同的问题 |
OpenAI 的话，温度为 0 输出也不同是预期的，这一点无法避免。指定 seed 会好点，不过也不能保证确定性。
感觉你这个需求提高准确率得上点 RAG 结合 few-shot 或者直接用微调模型，啥都不用模型可能法律这方面知识不够。
感觉你这个需求提高准确率得上点 RAG 结合 few-shot 或者直接用微调模型，啥都不用模型可能法律这方面知识不够。
24 天前 回复了 wildlynx 创建的主题 › Windows › windows11 还是个半成品 |
Explorer 卡死和设备 / 驱动的关系一般会大些
33 天前 回复了 jim9606 创建的主题 › Windows › 新系统 Windows 的性能和响应不佳的原因 |
@weijancc 现在有什么方法可以稳定关闭 defender 嘛
35 天前 回复了 JiangNanLong 创建的主题 › 问与答 › 14 寸轻薄本推荐 |
> 处理器都是 ultra5 7 9 ，或者 R7-8845 处理器，这几款都不支持 ubuntu
不是，你从哪看到的？
---
Linux 的话各机器差别无非是各种设备的驱动兼容性和暗坑，这点可以自己按型号查已经购买的人的反馈
不是，你从哪看到的？
---
Linux 的话各机器差别无非是各种设备的驱动兼容性和暗坑，这点可以自己按型号查已经购买的人的反馈
40 天前 回复了 hjc4869 创建的主题 › Local LLM › Apple 统一内存适合运行 LLM？理想很丰满，现实很骨感 |
@neteroster #3 没注意都是用单卡测的，那就不涉及多卡推理的方式了。不过非要本地推理现在性价比高的方案应该还是游戏卡多来几张
40 天前 回复了 hjc4869 创建的主题 › Local LLM › Apple 统一内存适合运行 LLM？理想很丰满，现实很骨感 |
认同这篇文章的主要观点，它谈及了一些关于本地 LLM 推理很多人没注意但很重要的内容。
先不谈高 batch （毕竟日常不常用），大多数人都没意识到 M 芯片 prefill 很慢，而这个在上下文长的情况下是挺致命的。而且其实 decode 速度也会受上下文长度影响，很多测试仅仅是在很短的 prompt 下去测生成，得到一个看起来挺好看的数字，然而实际使用中很多情况下根本不是这种场景。
个人观点是，当前，本地 LLM 推理对于大多数普通用户或开发者没有显著的使用必要，除非是特殊需求（例如强隐私需求等）。个人用户花大价钱购买设备单纯只是去推理本地 LLM 在现在看起来是不太明智的，当然如果是其他需求顺便推模型或者单纯太有钱买来玩玩那倒也没什么。即使非要谈本地推理，Mac 的应用场景也是较窄的，文章中写的已经听明白了。
文章还谈到了投机解码，这个确实很有意义，特别是对于生成内容主要是代码的情况，加速应该是相当明显（ cursor 的自动补全就用了），期待未来这方面的发展。
作为补充，看起来文章测 text generation 的时候只是用了 llama.cpp ，他的多卡实现应该还是 pipeline parallel ，有一些后端支持 tensor parallel ，多卡情况下单 batch 性能应该还能进一步提高（但对 PCIe 速度有更高要求），希望有相关测试。
先不谈高 batch （毕竟日常不常用），大多数人都没意识到 M 芯片 prefill 很慢，而这个在上下文长的情况下是挺致命的。而且其实 decode 速度也会受上下文长度影响，很多测试仅仅是在很短的 prompt 下去测生成，得到一个看起来挺好看的数字，然而实际使用中很多情况下根本不是这种场景。
个人观点是，当前，本地 LLM 推理对于大多数普通用户或开发者没有显著的使用必要，除非是特殊需求（例如强隐私需求等）。个人用户花大价钱购买设备单纯只是去推理本地 LLM 在现在看起来是不太明智的，当然如果是其他需求顺便推模型或者单纯太有钱买来玩玩那倒也没什么。即使非要谈本地推理，Mac 的应用场景也是较窄的，文章中写的已经听明白了。
文章还谈到了投机解码，这个确实很有意义，特别是对于生成内容主要是代码的情况，加速应该是相当明显（ cursor 的自动补全就用了），期待未来这方面的发展。
作为补充，看起来文章测 text generation 的时候只是用了 llama.cpp ，他的多卡实现应该还是 pipeline parallel ，有一些后端支持 tensor parallel ，多卡情况下单 batch 性能应该还能进一步提高（但对 PCIe 速度有更高要求），希望有相关测试。
Select Language