@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 后的表现，资源占用非常优秀，尝鲜的人多了之后，出现在技术选型里的几率就会慢慢变大。

硬切换对带头人的魄力和领导力有很强的要求，在国内很罕见，要做到精益求精也要讲生活和工作平衡。但对于开新坑的项目，切换技术栈就不难了，久而久之可能就会以绞杀者模式的形态完成了切换。

@james122333 大佬云集的公司手搓什么不行，谁不想自己团队每个人都是孙悟空呢，但可惜都是大部分虾兵蟹将，总要选一些他们能接受而且成本也能接受的方案。不是每个公司都有 Facebook 当时搞 HHVM 这种魄力的。

聊这些肯定要结合历史发展，高速增长的业务本来就是以扩张为主，加上.net core 是 2016 年中才发布的 1.0 ，之前.net framework 生态都是闭源的，肯定是市场上什么人多就招什么人，有资本的注入，招人和服务器那点费用对比业务增长的收益不值一提。

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

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

在国内，换领导肯定是影响技术选型的重大因素。net8 虽然发布比 java21 晚，但是.net core 1.0 从发布到.net 8 重大变更很少，倒是兼容性和效能上不断改进，该踩的坑都踩得差不多了，反倒是 java21 在生态位是缺失的，不敢用很正常。
@haython
@sagaxu

@haython 任何的重构肯定能降低资源，因为已经熟悉了原来的业务逻辑。但是用 java8 重构肯定不能节省 3/4 ，因为 java8 的并发模型就摆在那里。
这个视频是我打游戏的时候挂着听的，有几个重点指标：
1.资源占用少，原来那个 java 服务冷启动 100 秒，能吃满一个核，高峰期 java8 服务挂掉后重启那一刻猛猛吃 cpu ，在 k8s 里属于自己搞死自己；
2.碰到了那种等慢 sql 结果搞到线程池满的 case ，就会死，迁移到.net 的异步 IO 真香。这点其实非常的重要，现实的业务逻辑到处都是等待 IO ，java8 那个线程模型就是不行；
3.分布式事务也有很好的支持；
4.迁移成本很低，几乎 0 感，这个在带团队上非常重要；

内存便宜是作为个人设备而言的，到了生产环境内存就很昂贵了，特别是一个业务群一年下来的费用。
大家都说性能瓶颈不在语言而是在数据库层，既然这样，那应用层的配置从 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


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

你还要做性价比高的延时任务？计算好触发时间，动态创建/修改/删除函数，把触发器时间设定为触发时间就行了，反正小系统也没多少条任务吧。

现在大模型支持的上下文也就百万 token （ Llama-3-8B-Instruct-Gradient-1048k 、glm-4-9b-chat-1m 、internlm2_5-7b-chat-1m ）到 4 百万 token(Llama-3-8B-Instruct-Gradient-4194k)，想在对话里塞进中小型项目可能够用，如果不够用那只能用 RAG 或者 GraphRAG 的形式。

付一个简单的 RAG 例子，不到 20 行就可以和代码仓库对话
```python
from llama_index.core import SimpleDirectoryReader
from llama_index.embeddings.ollama import OllamaEmbedding
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
from llama_index.llms.ollama import Ollama

ollama_embedding = OllamaEmbedding(
model_name="mxbai-embed-large:latest",
base_url="http://10.6.6.240:11435",
)
llm = Ollama(model="deepseek-coder-v2:16b-lite-instruct-fp16", request_timeout=240.0, base_url='http://10.6.6.18:9090',
context_window=32000,
system_prompt="你是一个专业的架构师，接下来的问题请以架构师的角度回答，如果涉及到代码输出，则代码要充分利用异步非阻塞特性，注释丰富，多打印日志，容错性好，对外部输入进行充分校验。")
Settings.llm = llm
Settings.embed_model = ollama_embedding

documents = SimpleDirectoryReader(input_dir="代码目录", recursive=True, required_exts=['.扩展名']).load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine()
response = query_engine.query(
"这个项目都有什么功能？")

print(response)

```
RAG 说白了就是在你问的问题之前，用相似搜索来把 [和问题关键字近似的代码片段] 追加到你问题后面，在提示词里 [加几句话让模型参考追加的内容] ，前置步骤切分代码片段创建向量这个步骤容易切碎导致丢失代码。更有碰到宏观问题就歇逼的现象，比如上面例子的“这个项目”，近似搜索压根不知道你指的是哪些代码。

GraphRAG ( https://github.com/microsoft/graphrag )和 https://docs.llamaindex.ai/en/stable/examples/index_structs/knowledge_graph/Neo4jKGIndexDemo/ 又进了一步，用知识图谱的方式来找代码追加到上下文，在应对相对宏观的问题上有优势。比如“这个项目都有什么功能？”这种问题，对于“这些代码”可能给你找全一点，比如“下单流程有哪些步骤”可能把什么优惠券、会员积分、秒杀啥的都找出来，而不是仅仅搜索 order 相关的代码。

Win10 也有类似的 bug ，128G 内存，长时间不关机就出现。虚拟机都关完了，Chrome 关剩下几个窗口，还搁着占用 75G ，找来找去都找不出是谁，只能重启

@cinlen 2080ti 22g 我手头有 2 张，分别 24 小时开机 1 年和 1 年半，没啥问题。不建议买水冷版，单张的话建议买 2~3 风扇的。
涡轮卡适合挤多张但是噪音大，把功耗限制在 70%左右，风扇拉一下可以得到很好的噪音/性能表现，跑 AI 性能下降在 10%左右。买了一张就会买第二张，迟早走上 4 卡/8 卡的道路。

@Champa9ne P40 太老了，带宽小，算力差，朋友拿 10 张去跑 Command R Plus 104B 8bit 推理，速度不到 2 token/s ，拿 M2 Ultra 192GB 跑起码还有 5.x token/s ，各种意义上的电子垃圾。

测试了下 27B 的，废话巨多，写代码能力差，还很敏感，等微调吧。

@lrigi 好久没跑 7B 这么小的模型了，刚刚又跑了一次来弄点数据，量化方式都是 GGUF ，推理后端都是 llama.cpp 。
Codeqwen-1_5-7b-chat 模型，q4_k_m 量化，单张 2080ti 22g 下推理速度是 70.54 token/s ，在 M2 Ultra 上速度是 75.34 token/s 。
Mistral-7B-Instruct-v0.1 模型，q8 量化，单张 2080ti 22g 下推理速度是 51.72 token/s ，在 M2 Ultra 上速度是 61.24 token/s 。

@lrigi 我测过啊，我有 2 张 2080ti 22g ，1 张 7900xtx ，1 个 Mac Studio M2 ultra 76 核 192G 内存。
你发的那个已经是 10 个月前的数据了，也不知道怎么测的，最近编码能力很牛的 Codestral 22B 6bit 量化在 2080ti 22g 都能跑 22 token/s 。而且 10 个月前海外还买不到 22g 的魔改 2080ti

跑大模型推理吃的是内存带宽和核心数，连频率都不怎么吃，显卡降低 30%的功耗也就少个 10%左右的速度。Max 那个带宽才 400GB/s ，只有 Ultra 一半， [用来跑大模型就是个垃圾] 。

买 Mac 跑大模型，优势是比买超大显存（指的是单张 48G 和以上显存）的显卡方便。你这才 64G 的配置，无论是二手魔改 2080TI 22G X3 的价格，还是全新 7900XTX 24G x3 的价格，加上其它硬件的费用，除了电费和体积没优势，推理速度和扩展性都能把 Max 按在地上摩擦。

具体被摩擦到什么程度呢？ Ultra 推理速度是 Max 的 2 倍，而多张 2080TI 22G 的速度是 Ultra 的 2~3 倍，这个波动是随着模型占用越大优势越小，毕竟多卡之间走 pcie 通讯也是有点损耗的。

要看历史发展的，十年前接的项目大部分是各种商城、CMS 、论坛，很多开源项目可以利用，套个模板加个插件改一改就上线了。
上线部署也很粗糙，大部分是 FTP 上传后刷新，版本控制都少。给客户演示时还能当场上服务器改代码，保存立马生效。
大部分人都不会断点调试，就在代码里 var_dump 变量然后 exit 结束脚本，然后回浏览器按一下 F5 看输出结果然后继续写。
密码加密不是 md5 就是 sha1 ，这些都是内置函数。
写 Java 的还在纠结 json 库用哪个，选了 Fastjson 就有福了，一部分人整天在升级版本修漏洞，另一部分连自己系统被干了都不知道，而 JSON 处理在 PHP 里也是内置函数。
写 Java 的还在头疼日期和时间戳之间的处理，PHP 一个万能 date 函数就解决 99%的场景了。
写 Java 的还在头疼 url 参数编解码、特殊字符转义，PHP 内置函数又搞定了。
写的代码运行出错，一行配置或者代码前面加个 @ 就能抑制错误继续跑，try/catch 都不用，要是写 Java 还在挠头哪来的空指针。
前后端没分离的项目，还在纠结模板引擎选什么，写 PHP 的在包含 HTML 文本 PHP 的代码中改得飞快。
写 Python 的还在吵 Django 和 Flask 到底要用哪个，吵完了发现怎么上线还要套 Gunicorn 之类好麻烦。
写 Ruby 的表示 Ruby on Rails 非常牛逼，就是语言小众招不到人。
写 Node.js 的还在回调地狱里出不来。

在那个年代写 PHP ，你就说快不快吧。