V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  slowgen  ›  全部回复第 6 页 / 共 28 页
回复总数  553
1 ... 2  3  4  5  6  7  8  9  10  11 ... 28  
2024 年 10 月 30 日
回复了 babyedi31996 创建的主题 程序员 本地部署大语言模型哪家强?
没有搞头,带宽太小了。影响大语言模型推理速度首要因素是带宽,目前家用最舒服的还是 M2 Ultra 。你这个预算可以搞 4 个 2080ti 22g 的服务器代替,虽然吵点和费电,但是带宽在那里,跑推理是 m4 的几倍
2024 年 9 月 18 日
回复了 humbass 创建的主题 Node.js 问一个关于 nodejs CPU 核心利用的问题
不用多进程,不用 Worker threads ,就只能吃满一个核,你直接写个 while(true)看 cpu 占用就知道了,很多脚本语言都是这样设计,包括 php 、python (有 GIL 的版本)、ruby 。
强类型语言的 ORM + 实体类,还能出现列名逃逸,真的挺好笑的。
你看它那个号称能防御 sql 注入的 SqlInjectionUtils https://github.com/baomidou/mybatis-plus/blob/3.0/mybatis-plus-core/src/main/java/com/baomidou/mybatisplus/core/toolkit/sql/SqlInjectionUtils.java ,碍于网络安全法我就不写绕过细节了,拿去问 AI“你是 sql 注入专家,审计这个 java 代码分析出可以逃逸的情况(比如哪些数据库存在它没提到的关键字)
```java
balabala 代码
```


惊喜连连
2024 年 9 月 7 日
回复了 jjxtrotter 创建的主题 硬件 感觉现在 DIY 主机性价比还不如笔记本?
笔记本要忍受这些:
* 垃圾的键盘布局和手感
* 长期通电后电池鼓包隐患
* 亮度/刷新率/分辨率/色准都不错时屏幕的大溢价
* 主板不合理的话 SSD 和无线网卡叠叠乐导致高负载随机掉盘/掉网
* 高负载的噪音,不同笔记本的风扇声音调教也不同,导致同样分贝下低频风声和高频的风声的体验也不同
2024 年 8 月 11 日
回复了 ChipWat 创建的主题 Local LLM mac mini 24g 大模型推理怎么样
大模型跑推理速度首先取决于带宽,带宽有冗余再看算力。mini 那个小水管用来跑大模型就是个电子垃圾,只有 ultra 才值得跑大模型。
速度一览: https://github.com/ggerganov/llama.cpp/discussions/4167
简单粗暴的推理速度公式计算就是:同样的量化,14B 速度不到 7B 的 1/2 ,70B 的速度不到 7B 的 1/10
2024 年 8 月 4 日
回复了 WildCat 创建的主题 Ruby on Rails 我回来了, Ruby on Rails
@superhot 选支持 128K 上下文甚至更大的模型( Phi-3-medium-128k-instruct 、CodeGeeX4-All-9B 、DeepSeek-Coder-V2-Lite-Instruct 、Llama 3.1 之类),配合 continue.dev 插件可以整个文件夹追加到上下文。模型用在线服务和本地部署都可以,这个规模的上下文,用 Mac Studio 内存占用经常到 160GB 左右。

对话时把问题相关的文段片段追加到上下文(手工追加也行,把文档搞到本地做个 RAG 或者 GraphRAG 也行,我目前用 Open WebUI ,可以很简单设置模型和知识库文档范围),然后对着大模型哔哔需求就可以了。有了文档做背景自动拼接在问题后面,准确性大大提高,最新 API 信手拈来,也不怕模型自己那些过时的知识了。

框架的文档质量越高(特别是最佳实践、安全建议、性能优化指南这些),就越容易写出好代码。
2024 年 8 月 4 日
回复了 WildCat 创建的主题 Ruby on Rails 我回来了, Ruby on Rails
做减法挺好的,Rails 的文档非常出色,初入行的人细读之后可以提升技术品味的,配合超大上下文的大模型和 RAG 出活速度非常快。
2024 年 8 月 3 日
回复了 webeasymail 创建的主题 Java 有什么好用的轻量级搜索服务?
@FrankAdler 搜索得频繁的时候好像是五百多 MB 。创建索引的时候占用是高的,看你给的上限,有个参数 MEILI_MAX_INDEXING_MEMORY 可以设置。冷数据给高点配置,等索引创建完之后就可以降配了。
2024 年 8 月 3 日
回复了 webeasymail 创建的主题 Java 有什么好用的轻量级搜索服务?
meilisearch ,丢了一千多万数据(40 个字段,其中 2 个大文本)进去,1c1g 跑得很舒畅,闲置时候只有二十多 MB 内存占用
2024 年 7 月 29 日
回复了 yesgg 创建的主题 计算机 轻薄本,我是选苹果 air 还是戴尔灵越啊
首先排除戴尔,我当年特地选的 XPS 的纯核显本,7x24 小时开机,每个季度就要官方上门换一次风扇,每次都是 CPU 那个风扇磨损,极其不耐用,更不用说比 XPS 定位还要低的灵越系列
2024 年 7 月 19 日
回复了 javak 创建的主题 Java Java hello world 确实就要占用 30M
@sagaxu java 的并发方案,真要用起来,除了 kotlin 和新的虚拟线程,其它方案就是屎山制造机,用在项目里简直是害群的马。
换 Go 我也是能理解的,不过人家切到.net 之后,还完成了 DDD 的切换,这点应该是他们比较关注的收益,而且他们完成切换的时间节点可能还没等到 java21 的发布,这样看能选择的方案就很少了,切到.net 也可以理解。

如果你认可“大部分项目的瓶颈都不在语言本身而是数据库”类似的观念,那么应该关注的 http server 、序列化这种代码出现占比高的 case 的表现,在 https://programming-language-benchmarks.vercel.app/problem/http-server 这个测试里 kotlin 表现不算好,甚至还有超时的没跑完测试的情景,这就让人望而却步了。

而在这个 java vs csharp 的对比里 https://programming-language-benchmarks.vercel.app/java-vs-csharp 更亮眼的是开启 aot 后的表现,资源占用非常优秀,尝鲜的人多了之后,出现在技术选型里的几率就会慢慢变大。

硬切换对带头人的魄力和领导力有很强的要求,在国内很罕见,要做到精益求精也要讲生活和工作平衡。但对于开新坑的项目,切换技术栈就不难了,久而久之可能就会以绞杀者模式的形态完成了切换。
2024 年 7 月 18 日
回复了 javak 创建的主题 Java Java hello world 确实就要占用 30M
@james122333 大佬云集的公司手搓什么不行,谁不想自己团队每个人都是孙悟空呢,但可惜都是大部分虾兵蟹将,总要选一些他们能接受而且成本也能接受的方案。不是每个公司都有 Facebook 当时搞 HHVM 这种魄力的。
2024 年 7 月 18 日
回复了 javak 创建的主题 Java Java hello world 确实就要占用 30M
聊这些肯定要结合历史发展,高速增长的业务本来就是以扩张为主,加上.net core 是 2016 年中才发布的 1.0 ,之前.net framework 生态都是闭源的,肯定是市场上什么人多就招什么人,有资本的注入,招人和服务器那点费用对比业务增长的收益不值一提。

java8 当然不止有线程模型,但是其它的并发模型都是一堆坑,写起来就是掉进回调地狱的,有点技术广度了解过其它语言的并发模型都不会选。为了保证业务扩张,肯定是以其它公司踩过坑的稳定方案为主。

但是在业务放缓,经济下行之后,之前欠下的债都是要还的,预算变少了,砍人还是砍服务器,总得选一个。

在国内,换领导肯定是影响技术选型的重大因素。net8 虽然发布比 java21 晚,但是.net core 1.0 从发布到.net 8 重大变更很少,倒是兼容性和效能上不断改进,该踩的坑都踩得差不多了,反倒是 java21 在生态位是缺失的,不敢用很正常。
@haython
@sagaxu
2024 年 7 月 18 日
回复了 javak 创建的主题 Java Java hello world 确实就要占用 30M
@haython 任何的重构肯定能降低资源,因为已经熟悉了原来的业务逻辑。但是用 java8 重构肯定不能节省 3/4 ,因为 java8 的并发模型就摆在那里。
这个视频是我打游戏的时候挂着听的,有几个重点指标:
1.资源占用少,原来那个 java 服务冷启动 100 秒,能吃满一个核,高峰期 java8 服务挂掉后重启那一刻猛猛吃 cpu ,在 k8s 里属于自己搞死自己;
2.碰到了那种等慢 sql 结果搞到线程池满的 case ,就会死,迁移到.net 的异步 IO 真香。这点其实非常的重要,现实的业务逻辑到处都是等待 IO ,java8 那个线程模型就是不行;
3.分布式事务也有很好的支持;
4.迁移成本很低,几乎 0 感,这个在带团队上非常重要;
2024 年 7 月 18 日
回复了 javak 创建的主题 Java Java hello world 确实就要占用 30M
内存便宜是作为个人设备而言的,到了生产环境内存就很昂贵了,特别是一个业务群一年下来的费用。
大家都说性能瓶颈不在语言而是在数据库层,既然这样,那应用层的配置从 8c 32g 砍到 8c 16g 行不行? 4c 8g 呢? 2c 4g 呢?真正做过资源分配和预算决策就懂了。

https://www.bilibili.com/video/BV1Qe411k7H6 .NET Conf China 2023 的分享,从 Java8 到 .NET8 ,团队升级工作汇报 》可以看下别人的历程,迁移完了服务器资源降低了 3/4 。等自己到了带团队做决策分配预算的位置,就会自然而然做出类似的决定,毕竟省下来的钱自己人分掉不香吗。
@huangcjmail GitHub Copilot 也有 embedding 的逻辑,很显然的例子就是一段你删除了的代码,还可以补全出来,就是已经入库了做了向量化,在输入的时候做了相似搜索做上下文补全。

我 5 月份开始在 VSCode 禁用 GitHub Copilot 改用 Continue 来适应完全本地化 AI ,体验上来说很接近了,细节在于一些 if 语句判断还是 Copilot 严谨一些。但是大模型每个月都有新成果,在 14B 以下的尺寸卷疯了,这个尺寸很适合新出的 CPU 里那 NPU 和游戏显卡这种家用 24G 以下显存的设备推理。
@beginor 快和慢取决于带宽和算力,我测试 2080ti 22g / 7900xtx / m2 ultra 都很快,7B 模型 4bit 量化都超过 70token/s ,打开项目之后等几分钟插件做 embedding 入库就好了。
还可以配置个 embedding 模型,把代码向量化到本地,方便 RAG 和补全出相似逻辑。向量化和代码片段数据保存在~/.continue/index/index.sqlite

附一份我本地的配置
```json
{
"models": [
{
"title": "Ollama",
"provider": "ollama",
"model": "codestral:22b-v0.1-q8_0",
"apiBase": "http://10.6.6.240:11435/"
}
],
"customCommands": [
{
"name": "test",
"prompt": "{{{ input }}}\n\nWrite a comprehensive set of unit tests for the selected code. It should setup, run tests that check for correctness including important edge cases, and teardown. Ensure that the tests are complete and sophisticated. Give the tests just as chat output, don't edit any file.",
"description": "Write unit tests for highlighted code"
}
],
"allowAnonymousTelemetry": false,
"tabAutocompleteModel": {
"title": "deepseek-coder-v2:16b-lite-base-q8_0",
"apiBase": "http://10.6.6.240:11435",
"provider": "ollama",
"model": "deepseek-coder-v2:16b-lite-base-q8_0"
},
"embeddingsProvider": {
"provider": "ollama",
"apiBase": "http://10.6.6.240:11435",
"model": "mxbai-embed-large:latest"
}
}
```
其实性价比最高的定时器,应该是各个云厂商的 serverless ,配个触发器,然后选个 curl 镜像,里面扔个 curl 命令请求你的系统,请求头搞个 token 做鉴权就够了。
优先赛博菩萨 cloudflare
https://developers.cloudflare.com/workers/examples/multiple-cron-triggers/


其次国内云
https://help.aliyun.com/zh/functioncompute/user-guide/time-triggers
https://cloud.tencent.com/document/product/583/9708


人家云服务的后台有账户管理、日志记录、失败可以重试、有告警,以前的那种额度够你免费用一年,现在一年也就十几二十块,比你自己搭建部署整天修漏洞打补丁还要搞多节点做高可用靠谱多了。

你还要做性价比高的延时任务?计算好触发时间,动态创建/修改/删除函数,把触发器时间设定为触发时间就行了,反正小系统也没多少条任务吧。
1 ... 2  3  4  5  6  7  8  9  10  11 ... 28  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   1390 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 30ms · UTC 17:04 · PVG 01:04 · LAX 10:04 · JFK 13:04
♥ Do have faith in what you're doing.