现在大模型支持的上下文也就百万 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 ，你就说快不快吧。

大概是 2008 年那会，对于 VMP 和 TMD 这种搞不定的壳，等程序完全加载到内存之后动态调试 + 内存补丁就通杀了，也不算难

CPU 跑大模型推理瓶颈就是在内存带宽，按 ddr4 双通道内存带宽为 30GB/s 的速度来算，7B 规格的 8bit 量化，也就 4 token/s 左右的速度，4bit 量化就速度 x2 ，14B 规格就速度除以 2 ，偏差不会太大。

先考虑一下把公司电脑的远程桌面端口暴露到公网，被弱口令爆破或者 0day 打穿之后，蔓延到公司内网中毒时，你需要负什么责任吧...

动手能力好就 tailscale 加自建 derby ，动手能力差就 WireGuard 傻瓜脚本 https://github.com/angristan/wireguard-install

我觉得我的 5900x + 128GB 内存 + 2080ti 22g 跑 Windows 10 LTSC 很好用，打开软件速度很快，不用像 Mac 那样图标弹弹弹弹弹弹弹弹才蹦出界面。
当然跑 Debian + KDE 更好用。

-- 发送自睾贵的 192GB M2 Ultra （ 24 核 cpu + 76 核 gpu 版） Mac Studio 带 AppleCare 国行非海南免税店版

@289396212 想追求更好的方案呗，做做减法。一些常用的东西，.Net 的第一方支持更好。比如表单校验规则写好了，Swagge 文档也就生成好了。而在 Nest.js 里既要用 class-validator ，又要用 @nestjs/swagger ，一共 2 套装饰器才能实现；

像 http client 这种常用的东西，got 、undici 、got-scraping 选择太多的同时它们迭代多年还小 bug 不断。

还有 AOT 可以压缩更极限：像 pkg 本质上也就是把用到的 js 文件选出来压缩到一起，运行的时候实际上还是要解压的，只是解压得少一些而已，而且跨平台编译需要用 qemu 虚拟机，很重。

还有性能分析诊断的工具、冷启动速度、资源占用等，都是 C# 可以做到更好。


现在我本地可以跑比较大的模型，可以当作是无限 token 消耗，所以也想趁机看看用 AI 把整个项目翻译成另一种语言的可行性，这样以后也能把一些别的语言流行库进行一个大翻译，搞不好以后就是世界大同。

当然，追求极致还得用 Rust ，现阶段只是在性能和开发效率之间取一个平衡，现在 AI 写 Rust 代码的准确率还是不高。等下一步 AI 进化了，一次性写对代码的几率大幅度提高了，就再迁移了，反正拆分得好可以一层一层迁移。

@Arguments AdonisJS 前面的大版本不支持 TypeScript ，而且是抄的 Laravel 的设计。然而 Laravel 抄的是 Ruby on Rails ，结果没抄到精髓，AdonisJS 这波操作属于把别人消化到一半的东西吃了过来……只能说 AdonisJS 适合 Laravel 用户去使用了。

用了好多年的 Nest.js 了，大概从 6.x 用到现在的 10.x ，也没什么大变更。
选 Nest.js 看中的是 TypeScript 优先，然后集成了 class-validator 可以开箱即用。
其它自己集成的什么 http client 、数据库、缓存、消息队列、不喜欢就自己糊一个。
至于它的依赖注入，除了控制器和模块这一层，service 层你都可以不用依赖注入，完全走静态函数，反正 js 这种脚本语言可以在运行时修改 class 的 method ，mock 起来非常简单。
最大规模试过在 30 个 4c8g 的 contabo vps 上用 k3s 部署爬虫，套个 rancher 面板，部署一年多，稳如狗，用 DaemonSet 跑网络 IO 相关的操作，全流式操作，内存占用两百多兆，每个节点每月 32T 流量吃到饱。分析计算用 Deployment ，完全的 IO 和计算分离。
至于 web api ，现在用 Nest.js + Supabase ，日常内存占用也就 90MB 左右，需要事务那就换 Prisma ，内存占用高一些，150MB 左右。
结合 pkg 可以把项目打包成单个二进制文件塞到容器里，一般就 70MB 左右，冷启动贼快，丢到 1c1g 的容器里都算是打很富裕的仗了。

至于现在，我在把 Nest.js 的程序结合 AI 迁移到.Net 上…… 现在迁移了一个应用，确实很香。

早知道，还是 angular