Nestjs 封装是有点过度了，既然是 TypeScript 这种语言加上 Node 的 runtime ，很多东西是可以做减法的。
我用的时候就做了很多减法，比如：
service 全部用 static 函数，就不需要注入了，要 mock 直接 class.method = function(){}，要是非 static 的就 class.prototype.method 重新赋值来覆盖；
Providers 直接不用，官方案例简直是神经病连 HttpClient 都封装一层，它以为自己在用.NET 上吗，还不如开个文件在里面定义个常量然后导出，不也是全局唯一的吗；
Guards 也放弃，哪来那么多策略，直接在 Middleware 里简单鉴权就行了，复杂的我宁愿单独写一个 api 网关；
Modules 只拿来做业务模块区分，里面只引入控制器；

现在，我直接换 hono 了，搞个 module 文件夹自己分层就好了

连 Linux 子系统都支持了，按这个发展说不定再迭代几个版本就把 Chrome OS 给合并完了，然后放弃 Chrome OS

@datou 看走眼了，还以为只用了腾讯云的 cos 。要是用 deno 的话在代码目录就可以没有 node_modules 了，眼不见为净。

to 楼主，node 项目我以前用 pkg 打成二进制放容器里的，整个 Docker 镜像压缩后只有 60~70MB 左右，还挺好用

已经不用 Node 了，现在小项目在选 Deno 和 Bun 。Bun 在 1.2 内置了 S3 和 Postgres 客户端，可以给项目做不少减法 https://bun.sh/blog/bun-v1.2

scrapy 出来的时候还没什么 serverless 的概念，都是靠堆机器的方式来增加抓取规模，但是它的 IO 和计算没有分离，必然造成你现在这个局面。
一旦你加入队列来把 IO 和计算分离之后，你会发现你也用不上什么 scrapy 自己的东西了。
除非你的清洗是视频转码之类的众生平等的耗时任务，如果是单纯搞搞字符串之类的，可以使用 cloudflare worker 把计算部分分离出去，甚至把 IO 部分也可以分离出去（ IO 等待不计时，deno deploy 也是）。

@dongfanga 不好说，等产品出来了有评测对比才知道。Mac 跑大模型的劣势就是到目前为止还用不上 NPU ，白白浪费了性能，纯 GPU 在那算，跑激活参数越大的模型越吃亏，72B 就已经很慢了

https://nvidianews.nvidia.com/news/nvidia-puts-grace-blackwell-on-every-desk-and-at-every-ai-developers-fingertips GB10 更有看头，跑本地大模型专用，128G 统一内存，3000 美元起售，5 月开卖，不知道国内搞到的成本要多少

茶水发霉与否，不是和细菌繁殖条件相关的吗？我做的冷泡茶基本上放冰箱 2 周还能喝，保证容器干净就行。

Cloudflare Workers 连冷启动都没有，而且 IO 等待的耗时不计在内，只算 CPU 时间，比 Serverless 好太多了

迪卡侬山地车 EXPL500 ，重新激发了对运动的喜爱，经常骑出去溜圈，身体健康了很多

@kaichen 你这个链接里恰巧说明了 Qwen2.5.1-Coder-7B-Instruct 这个 7B 的模型即使在 8bit 量化下也非常接近 gpt4 啊

后续结果不错，恭喜楼主了，送三无充电宝就是送炸弹，就算是自己要丢掉也要放那种处理有害垃圾的桶，丢街边的垃圾桶万一太阳照射下高温起火了也是很可怕的事情。

1：充电宝强制 3C 认证了
自 2023 年 8 月 1 日起，对锂离子电池和电池组、移动电源实施 3C 认证管理；自 2024 年 8 月 1 日起，未获得 3C 认证证书和标注认证标志的，不得出厂、销售、进口或者在其他经营活动中使用。

2：充电宝有国标
https://std.samr.gov.cn/gb/search/gbDetailed?id=71F772D82450D3A7E05397BE0A0AB82A
https://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=7256184719B195F1E60A1610156A1C76

里面明确提到了必须印刷的信息、材料的阻燃等级、环境适应性里不得爆炸和起火。

这些年也有不少充电宝起火和爆炸的新闻，不符合标准的充电宝连飞机都上不去，我对待电池相关产品一直都是小心翼翼的，生怕家里有电池鼓包起火，所以非常理解楼主。

@dafen7 mac book pro 能跑 70B 吗？能
带宽不足吗？不足，所以速度慢
慢多少？带宽是 Ultra 的多少，速度就是 Ultra 的多少，看 https://github.com/ggerganov/llama.cpp/discussions/4167 可以发现带宽就是首要的决定因素，而且模型越大，带宽瓶颈需求就越大，特别是 70B 这个体量，传输都不够了，算得再快都没用

送三无充电宝和送炸弹有什么区别，肯定要较真啊，不保留好证据万一起火爆炸时起诉都麻烦

P40 很垃圾的，10 张 P40 加一起速度还没到 M2 Ultra 的 1/3

@LaTero 是的，更多的优质数据训练出来的模型就是底大一级压死人，roll 到好的回答的几率高很多。但是大的模型对硬件的要求也很高，本地难部署，期待未来会有个更好的架构，基础模型是个智商和学习能力都很强的白纸，然后选择外挂要用到的知识库进行对话，那样就爽了。

@babyedi31996 我当时是买官方翻新的，不到 4.5w 。现在肯定不买，按刚出的 M4 Max 内存带宽推断 M4 Ultra 内存带宽应该能超过 1000GB/s 了，跑推理的速度比 M2 Ultra 要快 1/4 ，不急的话还可以等官方翻新 + 员工优惠叠加更便宜。教育优惠貌似不能在 studio 上使用

@babyedi31996 是的，我也是反复对比计算衡量过后，才直接上了顶配的 Mac Studio ，有 apple care 加持可以大胆拿来高强度推理，开箱即用很省心，电费也省下不少，还很安静

@babyedi31996 带宽指的是推理介质的带宽，如果你用显卡进行推理，带宽指的就是显卡的带宽；用 Mac 推理，带宽指的就是它那个统一内存架构的带宽；如果你用显卡 + CPU 跑，那么带宽指的就是就是显卡带宽 + 内存带宽（这个是最垃圾的组合，我愿称之为拖后腿）。目前来说苹果最屌的带宽还得是 ultra 系列的，能有 800GB/s ，用苹果跑推理的速度（每一秒可以输出的 token 数量）可以无脑看作和带宽大小是正比关系，M4 Pro 的内存带宽是 273GB/s ，推理速度可以无脑看作只有 ultra 的 1/3 。

本地跑大模型不一定要追求模型的参数量，我高强度用 192GB 的 M2 Ultra 跑推理也有快 1 年了，全网也没几个人这么干的，光是每个月下载新出的模型都要下载几百 G ，以前也追求过大参数的模型，但是无论多强的模型，甚至是 GPT4 ，照样会胡言乱语无中生有给出错误的答案，不要指望一个模型能解决所有问题，所以我现在已经更换方案了，还得是 RAG 靠谱。

RAG 说白了就是在对话后面拼接类似这样的一段话“下面是额外补充的上下文信息-----start{插入一些联网搜索或者数据库里近似搜索和排序后的前几名文章内容再或者是你手工硬塞的文本}----end”。和代码仓库对话也是这样的形式，没啥特别的。因为大语言模型就是根据 prompt 不断计算下一个 token 出现的概率，在对话里强插入上下文就极大提高了相关 token 的权重，也就不怎么会胡言乱语无中生有了。

基于这个思路和你的目的，去找那一些上下文支持足够大的（ 128k 以上）、审查少、特定领域擅长的小模型或者是 MoE 架构的模型（跑起来吃显存较大但是计算 token 时需要的带宽很小）就合适了，量化选个 4bit 就行了（反正有 RAG 强干预，损失可以忽略不计）。再或者等 Mamba 架构的模型再出来多一点，这个架构的模型开再多的上下文也不会让内存暴涨而且推理速度也不会变慢。

到了这里就会发现 64G 真的太小了，我之前测试用 Phi-3 Medium （ 14B 的模型）开 128K 上下文直接塞整个项目进去换语言重构（类比直接塞一本瑟瑟小说进去续写仿写），光显存就要吃 100 多 G 了。哦，目前我测试下来搞瑟瑟最强的还得是 c4ai-command-r-plus 这个 104B 的模型（ 8bit 量化下速度大概是 5token/s ），显存占用也要 100G 左右。

所以 Mac 跑大语言模型推理，只有 Ultra 系列的大带宽 + 大内存这样的顶配合适，而且跑相同参数量的模型，速度基本上是多张 2080ti 22g 组成相同显存的服务器跑推理速度的 1/3 ~ 1/2 ，当然优点也非常明显，很省电很不占空间，甚至还能通过雷电口串联 4 个 Mac Studio 来跑分布式推理，可以跑更大的模型。

如果这都拦不住你要买 64G 的 M4 ，那你就用 lmstudio 吧，它最近的更新集成了 mlx 框架，也就是 M 系列 Mac 跑推理的优化方案，mlx 迭代了一年现在也稳定了，每个版本也会稍微提升一下性能让推理速度加快。