抡锤者

Ox Alpha於上周五（21日）宣布免費無限制使用一星期後，MiniMax最新亦於社交平台X上宣布，與AI原生雲端服務供應商GMI Cloud合作，於8月24日至9月6日，可於GMI Cloud上免費無限制使用旗下模型MiniMax M3、M2.7、Speech 2.8 及 Music 3.0 。

感觉像是为GMI Cloud引流，但不妨碍大家薅羊毛用一用。

补充：使用本地小模型压缩整理记录是可以的，其实也可以考虑使用Agnes免费API，作为兜底措施。

我也是双3090。对记忆系统，我的选择是：云端的一律不考虑，免费的API也可能在你某一天积累了大量记忆后收你的钱，你就不得不乖乖掏钱。去掉云端后，主要就是自托管的几个，包括mem0,Hind，hongcho。还考虑过reme（只使用MD文档），我还自己魔改过Mempalace，让Qwen3.6 Plus防facebook在10亿照片里找到类似照片的算法，写了一个搜索。最终是落在使用字节跳动开源的OpenViking上（我怀疑字节的豆包网页版之类，搞不好就是这个框架）。
OpenViking里面有多个LLM调用，官方推荐使用豆包模型。我用过豆包内置嵌入模型，后来发现这东西居然大量消耗我的豆包模型额度，直接改自托管了。
本来是丐版Mac上自托管，以本机LMStudio默认拉起BGE模型作为服务端，提供这个嵌入模型为OpenViking提供LLM服务。后来想起来局域网有一台12G的小主机，装了飞牛NAS，属于Debian系统。就让PI Agent把本机的OpenViking直接迁移到飞牛NAS上，PI迁移过去还比较平滑。
使用OpenViking我没遇到你这种集中”总结“的时刻，问Agent一些问题，它发现需要召回记忆的时候，会主动去OpenViking里翻。貌似效果还行。
OpenViking：https://github.com/volcengine/OpenViking

软件环境：Opencode + Ox Alpha Free

目的：直接调用这个模型的免费额度，Opencode是默认安装。

直接给它服务器上SSH指令的用户名和密码，连接我的Ubuntu服务器（当前运行SGLang架构的Qwen3.8 27B FP8）。让它“探查服务器的软硬件情况，并就当前Qwen3.8 27B模型使用提出评估意见”

模型探查了CPU、GPU、PCIe 拓扑（GPU0 x16 / GPU1 x4）、内存架构与插槽数等，开始提出初步评估。评估意见初步怀疑因为我另一张GPU的PCIe插槽速度不足，可能MTP反而会拖慢推理，建议我做3个对照实验测试：

SGLang FP8（8099，TP2）——三个零成本实验优先做：

1. --no-mtp A/B：MTP 投机解码让每步前向翻倍，而 TP2 的 all-reduce 正好被 GPU1 的 x4 弱链路卡脖子——投机收益可能被链路延迟吃掉，实测见分晓
2. NCCL_P2P_DISABLE=1 对照：PHB 拓扑下强制共享内存中转有时反超
3. chunked-prefill 2048→4096：KV 余量充足（注释自证 64K 池仅 ~2GB/卡），大分块摊薄 all-reduce 固定延迟

测试结果是MTP开启能提速80%左右，另两个还没测试。

又要求其针对三大推理架构llama,vLLM和SGlang进一步评估优化可能。

结论：

1. SGLang 留任主力：混合架构补丁资产不可复制；RadixAttention 对编码代理循环（重发系统提示+清单的每轮迭代）收益远大于通用吞吐差距；FP8+131K 质量档唯一来源。弱链路之弊靠第十节 S1–S3 实验对冲。
2. llama.cpp 当辅助：唯一免疫 x4 弱链路的架构；Q4/Q5 GGUF 可单卡容身，与 SGLang 错峰共存。缺 RadixAttention 与投机解码，上限低于 FP8 档。
3. vLLM 退役：高并发吞吐优势（并发≤4 用不上）与多卡扩展性（被 x4 锁死）双双失效；int4 场景可由 GGUF 平替。仅当未来部署 vLLM 独占支持的模型时临时启用。

版本背景：llama.cpp 日更构建 b10537（2026-08-21）；

后续继续由模型自己写的脚本一轮一轮筛选参数。结束后我来通报结果。

我让Agent进行社区调研，最后它推荐了两个大牛推荐且社区热门的两个模型（基于我的双卡3090，选择了Q5精度）：
Qwen3.8-27B-Uncensored-Q5_K_M.gguf 19G
RVN-Q5_K_M.gguf 18G
实际接起来以后测试了一下，测试过程也很简单，写一篇NFSW的小说，和进行NFSW的都市职场成人RolePlay，然后我个人主观结果是RVNQ5这个更好一些。另一个会明显断流，就是输出中间会突然截断，或者发傻（比如让它写小说，写了一部分就停掉了）。不知道是模型问题，还是对中文支持不好。

看到了，在服务器上让Agent去部署了一下。但是我问Agent，它对我的双3090推荐下来最适配的模型，还只是Qwen3.6 35B A3B。那样的话我不如等Qwen3.8 35B A3B了。
双卡3090之前已经能直接跑Ornith 1.5和Nemotron 的MOE，感觉吐字已经很快了。

现在想的是，后期直接提内存到128G，试试看低精度DeepSeek V4FLash 0731能不能感受一下，Agent推测能7 Tokens/s ，说适合夜间丢一个编程任务。白天建议还是使用Dense模型，比如Qwen3.8 27B。

我发现ox在长链开发任务里很容易出现上下文截断的毛病，或者突然说“开工”然后就中止了。有点感觉像以前测试mimo code时遇到的情况。

我用LMStudio主要是在16+256的丐版MacMini M4上，指望使用小模型完成一些小任务。所以我一直认为，类似Macmini M4 16G这样的小主机，才是LMStudio之类的主战场。
但是小模型之前都一直感觉很拉胯，包括Qwen3.5 9B，可能是我水平不够，总之真的不行。后来记得有下载了一个社区蒸馏的版本，感觉跑些本地整理文件的任务才好歹能跑起来了。各种7B，9B模型尝试下来都不太成功，包括Gemma4 12B。后来就倾向于暂时放弃了。一度看到PrimL那个bonsai系列眼前一亮，号称是2Bit能复现Qwen3.5 27B，觉得可能是本地16G小主机的天花板，说不定能打。事实证明还是不行。
LMstudio我感觉直接竞争对象还是ollama那个小羊驼，降低大模型部署门槛用的。但凡会装独立Ubuntu服务器加显卡，必然就上手llama,vLLM，Sglang这些框架，就是另一个维度了。

我使用功耗墙限制180W，加外置机箱风扇以最高转速对着显卡吹，夏天的地下室，无空调，室温32度左右。能基本上压制在85以下。让Hermes Agent在Ubuntu系统中写了一个服务器端监控脚本，持续监控GPU核心温度。我这里设定是持续超过85度3分钟以上就自动关机了。