腾讯Hy-Memory-30B-A3B本地部署实战：记忆写入器如何碾压Opus 5

腾讯开源了一款名字里带「记忆」的模型——Hy-Memory-30B-A3B。有趣的是，它本身并不存储任何记忆，而是一个记忆写入器：一个30B参数的混合专家模型（MoE），每token约激活3B参数，专门训练来筛选哪些信息该写入外部记忆库、以及如何更新旧条目。真正的记忆数据仍然存放在你的Mem0、MemOS或Hy-Memory后端的向量数据库中。

这台模型的核心价值在于替代记忆框架中每次写入都要调用GPT/Claude的昂贵流程。据模型卡片说明，Hy-Memory-30B-A3B经过两阶段训练：记忆on-policy蒸馏和「Attributed」记忆强化学习，全程在真实记忆框架内完成。它用Apache-2.0许可证发布，商用无需额外法律沟通。

规格与硬件门槛

从模型卡片和config.json看，Hy-Memory-30B-A3B采用HYV3ForCausalLM架构，128个路由专家、每token激活8个，48层、隐藏维度2048，最大位置嵌入262,144，支持中英文。

实际部署时，A3B架构的代价需要明白：只有约3B参数参与计算，解码速度快，但路由可能选中128个专家中的任何一个，所以全部30B权重都必须驻留内存——内存按30B付，计算按3B省。

各版本体积：Q8_0 GGUF为32.0 GB，Q6_K 24.7 GB，Q5_K_M 21.4 GB，Q4_K_M 18.2 GB；MLX混合4/6比特约17 GB；原始BF16约60 GB。加上KV缓存和系统开销，现实门槛是24 GB显卡或32 GB Mac跑Q4_K_M，想上Q8_0加长上下文则需64 GB。注意262K最大上下文是配置值，GGUF上传者实测仅到32K。

混合专家模型（MoE）与 A3B 命名的含义：MoE 把前馈层拆成多个「专家」子网络，由路由器为每个 token 选 Top-K 个专家参与计算。腾讯 Hy-Memory-30B-A3B 的「30B」指全部专家参数总量，「A3B」指每 token 约激活 3B 参数（128 个路由专家中激活 8 个）。这就解释了文中那句「内存按 30B 付，计算按 3B 省」：显存/内存必须装下所有专家权重，因为任意 token 都可能路由到任意专家；而实际参与矩阵乘的只有约 3B，因此解码吞吐接近 3B 级模型。MoE 的代价还包括路由不均衡、量化时不同专家被压到不同精度可能放大误差，所以社区才会出现「Q4_K_M 能跑但严格成功率下降」的现象。

基准测试：0.87分优势的真相

腾讯公布的对比表只替换记忆写入器，答案模型、裁判和检索均固定。六项基准平均分显示，Hy-Memory-30B-A3B以55.49分略高于Claude Opus 5的54.62分，差距0.87分。但细看单项：Hy-Memory框架下0.02分、MemOS下0.01分，基本是噪声级别。这些是厂商在每项基准的20%子样本上、用自家评测框架跑出的数字。OrcaRouter的评论一语中的：这个模型「有资格被测试，但没资格被盲信」。

真正有价值的是表格下半部分：对比常被用作本地廉价提取器的Qwen3-30B-A3B，平均提升11分；在训练中从未见过的EverMemOS框架上仍有56.89分。如果你今天用Mem0配小模型做提取，这才是尝试它的理由。另外Shopping任务上所有写入器（包括Opus 5）都拿不到24分，说明某些记忆任务不是换写入器能解决的。

三种本地运行方式

llama.cpp / Ollama

hy_v3架构支持已通过PR #25395进入主线llama.cpp，随b9993版本发布。旧版本无法加载。上传者给出的命令使用Q5_K_M量化版，关键参数包括--jinja --chat-template-file和--chat-template-kwargs '{"reasoning_effort":"no_think"}'。Ollama一行搞定：ollama run hf.co/rapatsky/Hy-Memory-30B-A3B-GGUF:Q4_K_M。

需要注意两个坑：腾讯配置里moe_intermediate_size=1536但实际专家张量是768，上传者转换时已修补；社区测试（34条英文+34条俄语对话）所有量化版都能输出合法JSON（68/68），但严格成功仅23/34，失败模式是重复事实、过度存储和个别无依据推断——包着完美JSON外壳的错误。

GGUF 与 K-quant 量化命名：GGUF 是 llama.cpp 使用的单文件模型容器格式，把权重、分词器和元数据打包在一起，便于在 CPU/GPU 混合环境下按层卸载。文件名里的 Q8_0、Q6_K、Q5_K_M、Q4_K_M 是 llama.cpp 的量化方案：Q4_K_M 表示 4 比特、K-quant 系列、Medium 混合精度——大部分张量 4 比特，部分敏感层（如注意力输出、嵌入）保留更高比特以减小精度损失。数字越小体积越小、速度越快，但困惑度上升。文中「Q4_K_M 18.2 GB」就是这种混合量化的结果，也是 24 GB 显卡能装下的关键。GGUF 上传者还常修补原 config 与实际张量形状不一致的问题，这正是文中 moe_intermediate_size 差异带来的坑。

vLLM（完整BF16）

官方文档路径，测试于vLLM v0.31.0。vllm serve tencent/Hy-Memory-30B-A3B --served-model-name hy-memory即可启动，但这是BF16检查点，权重约60 GB，需一张80 GB卡或两张48 GB卡张量并行。

张量并行（Tensor Parallelism）：vLLM 的 --tensor-parallel-size 把单层权重按维度切分到多张 GPU 上，每张卡只存一部分，前向时通过 All-Reduce 汇总结果。文中「两张 48 GB 卡张量并行」即指用 TP=2 把约 60 GB 的 BF16 权重拆到两张卡上，每卡约 30 GB 权重加 KV 缓存。张量并行要求卡间高带宽互联（NVLink 最佳，PCIe 也可但吞吐下降），且卡数通常需整除注意力头数。对 MoE 模型，vLLM 还支持专家并行，把不同专家放到不同卡上，但配置更复杂。若只有单张 80 GB 卡，直接 TP=1 加载 BF16 最省事。

MLX（Mac）

上游mlx-lm尚不认识hy_v3，但hermitdave的Mixed4-6构建自带hy_v3.py并由config指向，可直接用原版mlx-lm加载。上传者报告M3 Max 64 GB上解码约65 tok/s，困惑度与8位版本差距0.94%以内，提取测试70/70事实召回。别误下-omlx变体，专家键不同会报「Received 423 parameters not in model」。

接入记忆框架

腾讯Hy-Memory SDK（pip install hy-memory==2.0.3）通过MEMORY_LLM_BASE_URL和MEMORY_LLM_API_KEY接受任何OpenAI兼容端点，指向你的llama-server或vLLM端口即可。务必用pro模式——lite模式根本不调用LLM，写入器永远不会运行。你还需要单独的嵌入端点（MEMORY_EMBEDDER_MODEL、MEMORY_EMBEDDING_DIMS）。Mem0和MemOS同样接受OpenAI兼容base URL。

OpenAI 兼容端点与嵌入模型的分工：所谓 OpenAI 兼容端点，指服务端实现 /v1/chat/completions 等接口，客户端只需改 base_url 和 api_key 就能把任意本地推理服务（llama-server、vLLM、MLX 的 OpenAI 兼容层）当成 GPT 使用。Hy-Memory SDK 的 MEMORY_LLM_BASE_URL 走的就是这条路径，因此写入器模型可完全本地化。但记忆框架还有第二类调用：把文本转成向量做相似度检索，即嵌入（embedding）。MEMORY_EMBEDDER_MODEL 和 MEMORY_EMBEDDING_DIMS 配置的是嵌入模型及其维度，它与写入器是两套独立端点——写入器决定「写什么」，嵌入模型决定「怎么检索」。文中强调 lite 模式不调用 LLM，就是因为该模式跳过了写入器推理，只剩规则或嵌入。

为什么记忆该放在模型外面

比起把记忆烘焙进权重的隐藏状态，我更愿意让专业模型写入一个可以检查的存储。用户说「忘掉我的地址」时，我想执行一条DELETE然后看着那行消失。Hy-Memory-30B-A3B契合这个思路：把每次写入的昂贵LLM调用变成本地廉价操作，而记忆始终归你所有。

它没解决的是写入质量天花板。对Opus 5的0.87分领先来自厂商子样本，社区测试23/34的严格通过率也在说同一件事：在拿用户数据信任它之前，先用自己的对话测一遍。