注意戴好头盔，配好前后灯。
我每个月用山地车骑河边路 500~800 公里的骑行量，匀速 22 公里，心率控制在 130~140 ，单次骑行 2~5 小时。骑行一年了，也就前半年控制饮食的时候掉了 6 斤，然后爱吃什么就吃什么，体重也没什么增长，比较稳定了。
我把我的情况和 AI 对话了之后，它建议单次骑行最好控制在 2 小时以内（否则骑行时要注意碳水和蛋白质补给，不然开始分解肌肉），加上力量训练效果更好

这种工具永远架不住有猪队友把生产的 token 等敏感信息放进去，肯定要用本地化的。
https://www.postman.com/trust/security/ postman 的安全都做到这个程度了，你搜漏洞和安全事件还是有，更何况官网连安全策略都没披露的，攻击者的最爱。

@wenkgin 内存小小，带宽小小，只能找 [激活参数 < 5B] 的模型的 4bit 量化了。

Qwen3-Next-80B-A3B 系列、Qwen3-30B-A3B-2507 系列、ERNIE-4.5-21B-A3B-Thinking 、SmallThinker-21BA3B-Instruct 这些都能在低配置玩，里面的 A3B 的意思就是激活的参数只有 3B ，4bit 量化后 DDR4-3200 双通道的带宽 50GB/s 左右也能跑个 15token/s 左右（单人勉强用），像锐龙 AI Max+ 395 的 256GB/s 的内存带宽就能跑个 55token/s 左右。

其实本地模型现在已经很能打了，从 Mixtral-8x7B 开始打 ChatGPT3.5 的时候 MoE 架构模型应该成为主流，可惜国内一直没怎么跟，直到 DeepSeek V2.5 V3 R1 这些出来国内才跟进大搞 MoE 模型，今年出的模型都是 MoE 为主的了。

而且模型越大提升的能力分数并不是线性增加的，关注现在的模型跑分就能得出结论，就像前几天的 Qwen3-Max-Preview ，1000B 的参数，比自家 Qwen3-235B-A22B-2507 多了 765B ，这个差距差不多能塞一个 DeepSeek + gpt-oss-120b 了，然而性能提升连 10%都没有，所以现在选模型有点像玩游戏选个甜品卡那样，根据你的任务难度和硬件选一个合适的模型（你的任务里跑分高的）就行了。

你这个硬件看起来像是个笔记本带个小显存的 N 卡，模型从上面 A3B 里挑一个，部署方案首选 https://github.com/kvcache-ai/ktransformers （合理分配好模型活跃的专家到 GPU 跑得快点），次选 LM Studio 这种傻瓜式部署方案

人口换轻量应用服务器呗，200MB 峰值带宽

这个太低水平了，你需要见识一下 NSFW 的顶尖生产力 https://www.reddit.com/r/unstable_diffusion/

@mewking 这个问题，首先要看不同编程语言是否有高质量的庞大的数据集，比如在 https://huggingface.co/datasets?sort=trending 搜数据集看加起来的行数，以及 github 仓库上 star 数多的各语言仓库。

结合这个榜单也能看出来 https://huggingface.co/spaces/bigcode/bigcode-models-leaderboard ，不过这个榜单很久没更新过了，现阶段只能靠自己测了。

其次看自己的水平了，使用 context7 这种 MCP Server 或者手工在上下文补全最新文档可以大幅度降低模型幻觉，加上现阶段小模型对于主流编程语言的语法没啥问题（关键词、类型、循环、判断、函数等），写出来的代码头头是道的。但是对于一些理论、概念的理解程度就不好说了。

我一般假定 Q6 级别量化已经近乎无损了，然后去模型官网比如 https://chat.qwen.ai/ 选择 Qwen3-Coder-Flash 、Qwen3-30B-A3B-2507 这种 30B 级别的问一下看看，它能写对的话那么 Q6 级别的量化也能写对，Q4 的话可能再差个 1%到 2%，大不了我给它纠正。其实上限在于用户自己，比如我 java 水平不行，它写得头头是道我也评判不出好坏，因为语法已经没问题了，甚至库也用对了，但是实际上跑起来碰到 bug 就一脸懵逼。要是 CRUD 这种还好，要是问题底层一些的话 30B 级别的解决起来很容易像是鬼打墙一样，跑了几十 k 上下文也没有个结果。

比如我自己最爱用来测大模型的一道题：“用 [x 语言] 的实现一个高性能的 HTTP Proxy ，要求支持普通 HTTP 请求转发和 HTTPS 隧道 (HTTP CONNECT)，尽可能使用标准库”，把 [x 语言] 换成你最熟悉的那个然后让模型来跑几次，先看 api 有没有用对来判断幻觉大不大，再看能不能完成需求跑起来，反正在 c#、java 、rust 这种语言就经常搞不定，能一次性写对的就成为我常用的模型。

也就是因为这个原因，我现在考虑把技术栈从 node 往 golang 转移，开源的模型写 golang 的能力挺不错，以前不想碰 golang 是因为水平差的人写起来就像是用 php 堆屎山一样，维护性、可读性太没下限了。现在有 ai ，默认就是中高级的水平，而且我本地跑 gpt-oss-120b 实在是太快了，写 golang 准确性也非常高，代码的可读性、可维护性、性能下限、资源占用都有保障了。

@mewking 这个问题要看你写什么语言的，Qwen3 30B-A3B 没必要追求 BF16 ，Q6 就差不多了，我测 unsloth 的 Q6_K_XL 那档动态量化和 mlx 的 4bit DWQ 没啥区别，接入 Roo Code 自助完成一些 Node 和 Go 的任务都差不多，但是写 Rust 的话 Qwen3 Coder 30B-A3B 会在写了 50 多 K 上下文之后决定删除所有文件重头开始一个简单的版本…丢给 GLM 4.5 Air 4bit 就能完成而且修复一些 bug 都是点一下 Fix With Roo Code 就搞定了。

我本地 192GB 的 M2 Ultra 现在常驻内存的是 GLM 4.5 Air 4bit 和 gpt-oss-120B ，再留一个 mellum 做补全和 text-embedding-nomic-embed-text-v1.5 做代码 embedding

你先明确学习的内容是什么。

首先排除训练，Llama 3.1 8B 训练使用 1024 张 H100 80G 训练了一个月也就那样；

然后就微调，显存小就跑个 gpt-oss-20b 和 Qwen3-30B-A3B 的规模，https://docs.unsloth.ai/basics/gpt-oss-how-to-run-and-fine-tune https://docs.unsloth.ai/basics/qwen3-how-to-run-and-fine-tune 大点的模型还不如去 https://www.together.ai/ 导入你的数据集点几下按钮就开始微调了。

然后是推理，推理吃的是带宽和显存，这个价格你直接在 https://apxml.com/zh/tools/vram-calculator 选你要跑的模型和设备来看模拟推理的速度心里就有数了，这个配置性价比最高的也就是跑 gpt-oss-120b 的 mxfp4 量化，其次是 GLM 4.5 Air 的 4bit 量化，速度也就那样，选择 M4 Max 看速度然后除以二就懂了。

再然后是 RAG ，说白了就是找出相关内容然后字符串拼接，你本地跑和调用 API 也没区别，看 llamaindex 代码就懂了，知识库都是围绕那三五十行代码做各种业务和 UI 的封装。
https://github.com/run-llama/llama_index/blob/81d4b871143ddd4a7cb90333a3d103fbb1f269c5/llama-index-core/llama_index/core/prompts/chat_prompts.py#L21

剩下的就是画色图、写黄文、声音转文本、文本转声音、声线克隆
@hmbb

这配置比调用 api 体验更差，没有学习的价值，除非你要跑 Huihui-GLM-4.5-Air-abliterated 写黄文

@tmkook 主要看模型能力，如果模型太小的话可能会抽卡，可以加个 context7 这个 MCP 服务 https://github.com/upstash/context7 ，对话时需要参考文档的话就在末尾加一句 use context7 ，插件检测到就会和 context7 沟通来判断要读取什么文档然后去读取

@tmkook 随手写的 https://chat.qwen.ai/s/2514668b-48cd-4046-b530-e706bb5faf4b?fev=0.0.201 ，在 vscode 里我一般结合 Roo Code 让它自己读写文件，包括参考已有的页面就直接 at 那个文件让大模型参考

@tmkook 我开发的时候体验还好，一个窗口打开 api 项目，一个窗口打开前端项目，文件跳转也不会跳错。至于 AI 写 amis ，我测试本地跑的 GLM-4.5 Air 和 Qwen Coder 30B 都能写出不错的 amis json 页面，我现在都懒得手写了。

我的一个现成也是基于 amis 做后台页面的项目结构，前后端仓库分开，pages 随意扩展也不影响 api 的开发，喜欢打包放一起（ site.json 加鉴权防止偷页面）或者前端直接丢对象存储托管都可以(方便直接顺藤摸瓜拿走所有页面，不过现阶段页面都是大模型写的也没什么价值了)

├── web-api # 后端 api
└── wwwroot # 前端 amis 项目
├── index.html # 首页
├── login.html # 登录页
   ├── site.json # 路由
├── pages # 各种后台页面
│   ├── account
│   │   ├── list.json
│   │   ├── detail.json
│   │   ├── edit.json
│   │   ├── create.json
└── public # 前端公共资源
├── history
│   └── 4.10.1
│   └── history.js
└── sdk
└── 6.7.0

@tmkook 做成文件另一个好处是发布的时候可以加个简单的压缩打包机制，加个版本号，结合浏览器缓存机制基本上页面请求一次之后就缓存在本地了，至于难不难读都是 LLM 干的事情，我现在用 amis 做页面都是让大模型做的

amis 这部分不如直接写 json 文件来得直接，在 static 目录放个 pages 之类的文件夹就行了，不然去文档里抄一个 demo 快速预览下还得转换成你那个 js 风格太蛋疼了

@jjustwin 我实测也是发现 A3B 补全效果确实拉跨，现在用 jetbrains mellum 为主，A3B 的话配合 Roo Code 自己完成一些任务还不错。现在我对于自动化完成功能的需求比补全大多了

brave 浏览器自带这个功能

怕被运营商制裁那就先传到运营商做的网盘服务，然后开个阿里云同城的 200MB 峰值带宽的轻量云机器来跑网盘客户端中转咯

比较折腾而且和模型要适配，我测了 Claude Code 结合本地的 GLM-4.5-Air 、Qwen3-235B-A22B-Instruct-2507 、Qwen3-Coder-30B-A3B-Instruct ，经常会消耗了几十 K 的 token 但是活都没开始干，不能一个 prompt 就让它“自己动”完成所有事情，连把大模型给的代码写入文件都做不好，同样的 prompt 丢到 Roo Code 就不同了，结合上面几个本地跑的模型完成度非常高，人工干预极少