IT之家 6 月 5 日消息，腾讯混元今日宣布提出 Stem 稀疏注意力算法，已被机器学习顶会 ICML-26 收录。 官方表示，Stem 稀疏注意力算法从“因果信息流”重新审视块级稀疏，用 Token 位置衰减（TPD）和输出感知度量（OAM）两大创新， 仅用 25% 算力就逼近稠密注意力的精度 。配套的 HPC 算子库则将这份理论加速比真正转化为端到端的实测性能。 ▲ Stem 在 Hy3 preview（W8A8-FP8）上更贴近生产环境的真实落地数据 根据 Stem 算法 × HPC 算子的全栈加速方案，算法层面，Stem 通过 Token 位置衰减（TPD）和输出感知度量（OAM）实现 25% 预算下的近无损精度 ；算子层面，HPC 开源的 Stem+BSA 算子将稀疏收益转化为真实硬件加速， 128K 上下文下首字延迟降低 3.6 倍 。 ▲ 模型精度 IT之家附相关链接如下： Stem 论文链接 ： https://arxiv.org/abs/2603.06274Stem 开源地址 ： https://github.com/Tencent/AngelSlimHPC 算子开源地址 ： https://github.com/Tencent/hpc-ops
IT之家 6 月 3 日消息，在今天的 AI 云电脑体验日活动中，中兴通讯透露，公司已与腾讯达成深度战略合作，将推出 搭载腾讯原生 WorkBuddy 的 AI 云电脑 。该产品将融合腾讯云的算力和混元大模型的能力，定位为 面向学生、职场人士、小微团队的新一代生产力工具 。 该活动中，中兴通讯副总裁华新海表示， 当前我国家庭电脑拥有率为 67.5%，但 20% 设备长期闲置 。云电脑作为共享经济在算力领域的应用，实现了从“拥有设备”到“享受服务”的转变。 据IT之家了解，2025 年，中兴云电脑终端销量突破 200 万台，连续两年蝉联中国云终端市场冠军。
IT之家 5 月 28 日消息，腾讯混元宣布正式推出 Hy-Memory。据介绍，这是一个专门为 Openclaw 这类长期协作型 Agent 设计的记忆插件，能真正成为 Agent 的“第二大脑”。 官方称，Hy-Memory 用 6 层记忆框架 × System1/System2 双系统 × 演化链三层底牌，让 Agent 在长期使用中真正 " 记得住、记得对、记得轻、更懂你 "。 在权威公开测试集上，Hy-Memory 效果超过现有主流 memory 框架，可以解决记忆碎片化问题，记忆数量低 70%+，每条记忆信息密度高 45%+。在处理超长上下文方面，Hy-Memory 消耗的 token 量降低 35%，记忆更新速度快 20%。 IT之家附官方详细介绍如下： Agent 任务对长期记忆的要求远超 Chat 使用 Agent 和 Openclaw 深度用户，常常描述过一种常见的“三周轨迹”。 第一周: 蜜月期，把自己当下正在忙的事情，比如一个项目的来龙去脉、最近的决定和取舍、未来想做的方向一股脑都告诉 Openclaw。，能回答问题、能查资料、能帮你规划、能写代码、能起草文档。“这玩意儿真好用”—— 这是大多数人第一周的真实感受。 第二周: 开始不安。人们注意到每天打开 Openclaw 都得先花 3 到 5 分钟提醒它我们在做什么。它好像不太记得几天前讨论过的判断。当你对它说“按之前那个方案”，它会反问“哪个方案”，说“那个我们排除掉的选项”，它却想不起来排除的是什么、为什么排除。不是完全不记得。Openclaw 默认的记忆机制能记住一些最近的对话原文，但跨天、跨 Session、那些更深的判断，它就漂移了。 第三周: 主动降级使用，开始下意识地缩短跟它讨论的深度。不再问“这个方向我该不该走”，因为知道明天它就忘了。变成只问最具体、最即时的小问题: 搜个资料、查个语法、改一段文字。 最常见的结局是，Openclaw 在使用者眼里，慢慢从“能陪你思考的伙伴”，降级成了“一个查询工具”。这不是 Openclaw 的问题 —— 它的内核能力一直很强。问题在于：长期协作类任务对长期记忆的要求，远超过普通 Chat。 Hy-Memory 这个 Openclaw 记忆插件的初衷，就是为了把这三周轨迹的后两周抹掉 —— 让用户第一周怎么用 Openclaw，第三个月还能怎么用，而且越用越懂。 1、长期任务对记忆的挑战比想象中难 长期任务跟普通 Chat 完全是两种工作。不管你拿 Openclaw 调研一个复杂决策、写一本书、规划一次大旅行、跟进一个跨季度的项目，一次对话可能 30 轮 50 轮 100 轮，中间不停地查资料、调工具、读文档、出方案、回退、再改、再走，一个 Session 可能持续几个小时，任务可能跨越数周。 记忆系统至少要扛住 4 件事： 任何一个环节崩了，体验就崩了。 2、一个合格的 Openclaw 记忆插件要满足的 3 条标准 我们在设计 Hy-Memory 的时候围绕“什么样的记忆插件才配得上 Openclaw 这种长期协作场景”，定了 3 条硬标准。 标准一：不能丢历史。 用户跟 Agent 聊过的所有“为什么选这个、为什么否那个”—— 这些判断和因果不能丢。否则下次它推荐方案，可能直接推荐回用户已经否过的那个，白费时间。 标准二：要能演化。 人不是一个静态的存在。技术偏好、生活习惯、长期目标都会随时间变，对某件事的看法也会反复调整，这些都得被记住。不是覆盖式的“只记最新”, 也不是堆积式的“全都留下”，而是要有一个清晰的演化轨迹。 标准三：要在主链路里不仅足够快，还要有认知迭代，进化。 记忆插件不能拖慢用户当下打字、调用工具、等结果的速度。每次搜索要在毫秒级, 召回也不能成为响应瓶颈。同时还要有深层次的语义和事实理解。 接下来，我们把 Hy-Memory 满足这 3 条标准的三层底牌分别讲清楚。 Hy-Memory 的三层核心 第一层：6 层记忆框架 —— 给每种记忆找到正确位置 Hy-Memory 做的第一件事, 是没有把所有记忆塞进同一张表。 想一下 —— 用户跟 Openclaw 聊到最近在准备出国留学, 这段话里其实混着好几种东西： · “我在准备出国留学”—— 这是事实 · “我偏好北欧那种慢节奏的项目”—— 这是画像 · “我做大决策前会先列利弊清单”—— 这是心智模型 · “我下周大概率会问推荐信怎么找教授”—— 这是前瞻意图 这些东西信息形态完全不一样, 但传统记忆系统会把它们全揉成一堆向量，搜索时一锅捞。Hy-Memory 把记忆分成 6 层，每层一种职责。下面用一组多领域混合的例子，让你感受 Agent “记的是什么”： 用户问 Openclaw “我做大决策有什么习惯”, 它应该优先看 L5 心智模型, 而不是把过去 100 轮对话原文一锅塞过来。用户问 " 我现在住在哪 ",L2 一条事实就够了。问什么、走哪层、用什么样的检索权重 —— 分层让这些都变得可能。 整个 prompt 会变干净。模型的注意力不再被无关原文稀释。 第二层：双系统设计，既保障速度又具备认知迭代 Hy-Memory 把来自人脑认知科学的 System1 / System2 机制直接复刻到了 Agent 的记忆加工上 —— 就像给 Openclaw 装了一颗符合认知科学的 " 大脑 "。 Hy-Memory 把记忆加工拆成两套。 System1 (白班)：用户回车那一秒，实时地处理写入的记忆。负责写原始痕迹、抽事实、更新画像、压会话摘要 —— 也就是 L1–L4 System2 (夜班)：秒到分钟级，在后台跑。负责抽心智模型、构建知识网络、预测意图 —— 也就是 L5–L6 为什么要拆？因为深度认知很慢。抽你的“决策心智模型”、构建你的“知识网络”—— 做完一遍 LLM 可能要 5 到 20 秒。如果让你每次调用 Openclaw 都等 20 秒才能收到回复，谁都用不下去。 但你要的也不仅是“快”—— 你要的是 Agent 越用越懂你。Hy-Memory 的拆分把这两件互相打架的事变成两条独立通道： 1、发送消息后 System1 已经把“立即可用的记忆”写好了 —— 下一句对话能立刻用上 2、 System2 在后台慢慢做更深的认知 —— 把你两周的对话沉淀成“你的决策心智” 结果在对话最直接的影响：你每次说完的信息它能立马记住；而它对你的理解还在后台不断变深。 第三层：演化链 —— 记忆能改写但不丢因果 第三层是 Hy-Memory 真正的杀手锏，也是我们觉得用户长期跟 Agent 协作时最容易踩坑、也最值得做对的一件事。 一个典型的长期场景：假设一位用户跟 Openclaw 聊了大半年自己的健身计划。过去半年里他的训练方式发生过 4 次明显的态度转折： · 去年春 — 开始跑步训练有氧，效果不错，体重和精神状态都改善了，对跑步充满信心 · 去年夏 — 跟练 HIIT，强度太大，膝盖出了问题，被迫停训两周 · 去年秋 — 转向纯力量训练，只练大重量、放弃了心肺，结果跑两公里都喘, 挫败 · 上月 — 形成「力量 + 慢跑 + 瑜伽」混合方案，身体状态终于稳定下来 今天他打开 Openclaw 问它：“我下个月想再加一种新的训练方式，你建议什么？” 三种记忆系统会给出三种答案。 答案 1：覆盖派 (只记最新) 很多默认记忆系统是“用新覆盖旧”。库里只剩“用户当前用混合训练效果好”。 Agent 的回答：“你现在的力量 + 慢跑 + 瑜伽组合挺好, 可以再加一个 CrossFit 试试, 效率高。” 不算错，但很浅。它不知道用户为什么走到混合训练 —— 错过了“HIIT 伤过膝盖”、“纯力量丢了心肺”这条完整的踩坑路径。直接推荐 CrossFit 很可能让用户再伤一次膝盖。 答案 2：堆积派 (全部保留) 另一些系统是“什么都留下，搜索时按向量相似度召回”。库里 4 条事实都在, 但搜索“新训练方式”时，最近的、最相似的先被召回 —— 大概率是“跑步起步效果不错”和“混合训练稳定”。 中间的“HIIT 膝盖受伤”、“纯力量丢心肺”在语义空间里距离稍远，可能根本召不回。 Agent 的回答：“你跑步效果不错、混合训练也稳定, 可以加一个 HIIT 试试, 提升心肺效率高。” 踩雷了。它没意识到用户已经在 HIIT 上受过伤 —— 重新推荐 HIIT 等于让用户再走一次老路、再伤一次膝盖。 答案 3：Hy-Memory 演化链 Hy-Memory 在写入第 2 条记忆时，会用 supersedes 指针指向第 1 条；第 3 条指向第 2 条；第 4 条指向第 3 条。4 条记忆通过指针串成一条链。D (混合训练，链头) ↓ supersedes C (纯力量，丢心肺) ↓ supersedes B (HIIT, 膝盖受伤) ↓ supersedes A (跑步起步) 用户问“新训练方式选什么”时，搜索命中链头 D, 整条链自动展开 ——A、B、C、D 一起返回给 Agent。 Agent 拿到的不再是孤立结论而是完整的态度演变： ● 跑步起步 → ● HIIT 伤膝盖 → ● 纯力量丢心肺 → ● 混合方案稳定下来 它的回答会是这样： “你之前在训练方式上走过完整的路: 跑步起步、HIIT 伤过一次膝盖、纯力量又丢了心肺，上月才走到力量 + 慢跑 + 瑜伽这个稳定组合。 所以新方式我会建议你避开高冲击的爆发类训练（比如 CrossFit、HIIT 这类)—— 你的膝盖已经踩过一次坑。如果想再加新内容, 可以考虑游泳或骑行这种低冲击有氧, 或者爬山 / 长距离慢跑 —— 都比再回 HIIT 安全。” 这个回答的质量，不是来自模型本身，是来自记忆结构。 演化链的本质 技术上演化链做的就是两件事： 1、新记忆写入时，通过 supersedes 指针指向旧记忆, 形成一条链 2、搜索命中链上任意一节点，自动展开整条链 最新的判断在最前面（链头），但被否过的、被替代的、被废弃的旧版本不会丢 —— 只是退到链身后面，需要时随时展开。这是我们能想到的、最适合 Agent 长期陪伴用户的“长期记忆”形态。 Hy-Memory：超过同类框架 Hy-Memory 在 LongMemEval 和 PersonaMem 这两个权威的长期记忆评测上跑过。 1、LongMemEval：得分达 85.2，远超其他框架。LongMemEval 是公认很难的长期记忆评测，500 道题覆盖 6 个能力维度。 Hy-Memory 不仅打赢所有同类系统，在 6 个维度中的 4 个维度取得最高分 —— 尤其在最考验 " 演化能力 " 的偏好 (+21.11pp)、时序推理 (+9.63pp)、知识更新 (+21.37pp) 三项上领先同类产品。 2、 PersonaMem：打赢所有同类产品，PersonaMem 是 6000+ 条消息 / 589 道题的真实长期对话评测, 更贴近 " 用户用了好几个月 " 的真实场景。 3、性能：有更高的记忆密度同时，更有 8 倍写入速度 Openclaw 用户能感受到的是： · 写入快：跟 mem0 同档，是 Graphiti 的 8 倍快，不会卡 Openclaw 的对话主链路 · 存得少：记忆条数只有 mem0 的 1/3、Graphiti 的 1/4–1/5，本地嵌入式存储，不需要外部服务，内存占用低 · 密度高：单条记忆是 mem0 的 3–4 倍信息密度，每次召回的记忆更管用，prompt 不被噪声污染 最后这条对长期任务特别重要：当一次 Session 跑到 80 轮对话, 召回的每一条记忆都得是高密度的, 否则 prompt 一下就被噪声塞爆, 模型注意力被稀释。 Hy-Memory 的高密度意味着同样的 Token 预算下 Openclaw 能看到比别的记忆系统多 3-4 倍的有效信息。
5月28日，腾讯混元发布Hy-Memory，宣称是为Openclaw这类长期协作型Agent设计的记忆插件。 Hy-Memory技术主要采用的是 6层记忆框架+双系统+演化链 ，记忆框架如下图所示： 双系统翻译成 人话 就是短时记忆和长时记忆。 演化链的话可能算是新设计，就是做了一个对话指针，这边引用官方的例子： Hy-Memory 在写入第 2 条记忆时，会用 supersedes 指针指向第 1 条；第 3 条指向第 2 条；第 4 条指向第 3 条。4 条记忆通过指针串成一条链。 D (混合训练，链头) ↓ supersedes C (纯力量，丢心肺) ↓ supersedes B (HIIT,膝盖受伤) ↓ supersedes A (跑步起步) 用户问“新训练方式选什么”时，搜索命中链头 D,整条链自动展开——A、B、C、D 一起返回给 Agent。 Agent获得的信息： ● 跑步起步 → ● HIIT 伤膝盖 → ● 纯力量丢心肺 → ● 混合方案稳定下来 在权威公开测试集上，腾讯混元宣称Hy-Memory效果超过现有主流memory框架，可以解决记忆碎片化问题，记忆数量低70%+，每条记忆信息密度高45%+。在处理超长上下文方面，Hy-Memory消耗的token量降低35%，记忆更新速度快20%。指标对比如下： 有没有想法给马和虾换个大脑的 （另外吐槽一下，腾讯混元微信公众号那个文章语气太AI了，感觉纯水稿，所以人工润色了一下） 图片数据来源：微信公众号-腾讯混元 6 个帖子 - 6 位参与者 阅读完整话题
这两天闲的没事干, 又正好发现沉浸式翻译的Bing老抽风, 干脆自己部署小的 AI 模型跑翻译得了 我的配置是M1Pro 32G, 下了个混元 1.8B, 翻译时输出Token居然能干到 100tok/s, 而且翻译质量看起来还不错 最重要的是这玩意占用是真低啊, 比Idea都低, 推理时占用也很低 10 个帖子 - 8 位参与者 阅读完整话题
最近在找本地离线翻译大模型，测试了腾讯开源的 **混元翻译模型 1.8B **。 我用了几篇不同的技术文章进行深度对比， 它的翻译质量明显高于 Google 翻译和微软翻译 ，术语和语序都更符合中文习惯，1.8B 的体量能有这个效果让人非常惊喜。 这里分享一下我的部署和启动参数优化经验。 1. 模型下载 建议下载 GGUF 格式，方便用 llama.cpp / llama-server 直接跑： Hugging Face 地址： tencent/HY-MT1.5-1.8B-GGUF 2. 启动与优化指令 如果你使用的是 RTX 3060 6GB 显卡，可以使用我优化后的 llama-server 启动命令。 这里开启了 --flash-attn 以及 KV 缓存量化（ q8_0 ），基本可以把模型完全塞进显存，速度飞快： llama-server -hf tencent/Hy-MT2-1.8B-GGUF:Q8_0 \ -c 8192 \ --port 8080 \ -ngl 99 \ --flash-attn on \ -t 6 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --parallel 1 \ --jinja \ --n-predict -1 \ --verbosity 1 3. PowerShell 测试指令 服务启动后，兼容 OpenAI 的 API 格式。在 Windows 下可以用以下 PowerShell 命令直接测试： Invoke-RestMethod -Method Post -Uri "[http://127.0.0.1:8080/v1/chat/completions]( http://127.0.0.1:8080/v1/chat/completions)" ` -ContentType "application/json" ` -Body (@{ model = "gpt-3.5-turbo" messages = @( @{role = "user"; content = "Translate to Chinese: Comparing Rust and C++ performance is a topic that all software developers should consider. In this guide, they are compared in terms of memory safety, concurrency models, and compilation performance. You will understand why C++ provides the best performance, and Rust does not compromise on safety as a trade-off. Simple differentiation and real-life examples will help you be prepared to make the correct choice of the right tool 。"} ) stream = $false } | ConvertTo-Json) 4. 运行结果与性能 (RTX 3060 6GB) 在我的 3060 上，生成的 Token 速度非常理想，完全能喂饱翻译插件的并发需求： choices : {@{finish_reason=stop; index=0; message=}} created : 1779531650 model : tencent/Hy-MT2-1.8B-GGUF:Q8_0 system_fingerprint : b9294-0f3cb3fc8 object : chat.completion usage : @{completion_tokens=68; prompt_tokens=88; total_tokens=156; prompt_tokens_details=} id : chatcmpl-5XADKRfaVh7iZ1Iva7bt1P1oRJkQBr5Q # 性能耗时指标： timings : @{ cache_n=0; prompt_n=88; prompt_ms=312.969; prompt_per_token_ms=3.556; prompt_per_second=281.178; predicted_n=68; predicted_ms=555.212; predicted_per_token_ms=8.164; predicted_per_second=122.475 } 总结： predicted_per_second 达到了 122 tokens/s 。
最近在找本地离线翻译大模型，测试了腾讯开源的 **混元翻译模型 1.8B **。 我用了几篇不同的技术文章进行深度对比， 它的翻译质量明显高于 Google 翻译和微软翻译 ，术语和语序都更符合中文习惯，1.8B 的体量能有这个效果让人非常惊喜。 这里分享一下我的部署和启动参数优化经验。 1. 模型下载 建议下载 GGUF 格式，方便用 llama.cpp / llama-server 直接跑： Hugging Face 地址： tencent/HY-MT1.5-1.8B-GGUF 2. 启动与优化指令 如果你使用的是 RTX 3060 6GB 显卡，可以使用我优化后的 llama-server 启动命令。 这里开启了 --flash-attn 以及 KV 缓存量化（ q8_0 ），基本可以把模型完全塞进显存，速度飞快： llama-server -hf tencent/Hy-MT2-1.8B-GGUF:Q8_0 \ -c 8192 \ --port 8080 \ -ngl 99 \ --flash-attn on \ -t 6 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --parallel 1 \ --jinja \ --n-predict -1 \ --verbosity 1 3. PowerShell 测试指令 服务启动后，兼容 OpenAI 的 API 格式。在 Windows 下可以用以下 PowerShell 命令直接测试： Invoke-RestMethod -Method Post -Uri "[http://127.0.0.1:8080/v1/chat/completions]( http://127.0.0.1:8080/v1/chat/completions)" ` -ContentType "application/json" ` -Body (@{ model = "gpt-3.5-turbo" messages = @( @{role = "user"; content = "Translate to Chinese: Comparing Rust and C++ performance is a topic that all software developers should consider. In this guide, they are compared in terms of memory safety, concurrency models, and compilation performance. You will understand why C++ provides the best performance, and Rust does not compromise on safety as a trade-off. Simple differentiation and real-life examples will help you be prepared to make the correct choice of the right tool 。"} ) stream = $false } | ConvertTo-Json) 4. 运行结果与性能 (RTX 3060 6GB) 在我的 3060 上，生成的 Token 速度非常理想，完全能喂饱翻译插件的并发需求： choices : {@{finish_reason=stop; index=0; message=}} created : 1779531650 model : tencent/Hy-MT2-1.8B-GGUF:Q8_0 system_fingerprint : b9294-0f3cb3fc8 object : chat.completion usage : @{completion_tokens=68; prompt_tokens=88; total_tokens=156; prompt_tokens_details=} id : chatcmpl-5XADKRfaVh7iZ1Iva7bt1P1oRJkQBr5Q # 性能耗时指标： timings : @{ cache_n=0; prompt_n=88; prompt_ms=312.969; prompt_per_token_ms=3.556; prompt_per_second=281.178; predicted_n=68; predicted_ms=555.212; predicted_per_token_ms=8.164; predicted_per_second=122.475 } 总结： predicted_per_second 达到了 122 tokens/s 。
最近在找本地离线翻译大模型，测试了腾讯开源的 **混元翻译模型 1.8B **。 我用了几篇不同的技术文章进行深度对比， 它的翻译质量明显高于 Google 翻译和微软翻译 ，术语和语序都更符合中文习惯，1.8B 的体量能有这个效果让人非常惊喜。 这里分享一下我的部署和启动参数优化经验。 1. 模型下载 建议下载 GGUF 格式，方便用 llama.cpp / llama-server 直接跑： Hugging Face 地址： tencent/HY-MT1.5-1.8B-GGUF 2. 启动与优化指令 如果你使用的是 RTX 3060 6GB 显卡，可以使用我优化后的 llama-server 启动命令。 这里开启了 --flash-attn 以及 KV 缓存量化（ q8_0 ），基本可以把模型完全塞进显存，速度飞快： llama-server -hf tencent/Hy-MT2-1.8B-GGUF:Q8_0 \ -c 8192 \ --port 8080 \ -ngl 99 \ --flash-attn on \ -t 6 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --parallel 1 \ --jinja \ --n-predict -1 \ --verbosity 1 3. PowerShell 测试指令 服务启动后，兼容 OpenAI 的 API 格式。在 Windows 下可以用以下 PowerShell 命令直接测试： Invoke-RestMethod -Method Post -Uri "[http://127.0.0.1:8080/v1/chat/completions]( http://127.0.0.1:8080/v1/chat/completions)" ` -ContentType "application/json" ` -Body (@{ model = "gpt-3.5-turbo" messages = @( @{role = "user"; content = "Translate to Chinese: Comparing Rust and C++ performance is a topic that all software developers should consider. In this guide, they are compared in terms of memory safety, concurrency models, and compilation performance. You will understand why C++ provides the best performance, and Rust does not compromise on safety as a trade-off. Simple differentiation and real-life examples will help you be prepared to make the correct choice of the right tool 。"} ) stream = $false } | ConvertTo-Json) 4. 运行结果与性能 (RTX 3060 6GB) 在我的 3060 上，生成的 Token 速度非常理想，完全能喂饱翻译插件的并发需求： choices : {@{finish_reason=stop; index=0; message=}} created : 1779531650 model : tencent/Hy-MT2-1.8B-GGUF:Q8_0 system_fingerprint : b9294-0f3cb3fc8 object : chat.completion usage : @{completion_tokens=68; prompt_tokens=88; total_tokens=156; prompt_tokens_details=} id : chatcmpl-5XADKRfaVh7iZ1Iva7bt1P1oRJkQBr5Q # 性能耗时指标： timings : @{ cache_n=0; prompt_n=88; prompt_ms=312.969; prompt_per_token_ms=3.556; prompt_per_second=281.178; predicted_n=68; predicted_ms=555.212; predicted_per_token_ms=8.164; predicted_per_second=122.475 } 总结： predicted_per_second 达到了 122 tokens/s 。
最近在找本地离线翻译大模型，测试了腾讯开源的 **混元翻译模型 1.8B **。 我用了几篇不同的技术文章进行深度对比， 它的翻译质量明显高于 Google 翻译和微软翻译 ，术语和语序都更符合中文习惯，1.8B 的体量能有这个效果让人非常惊喜。 这里分享一下我的部署和启动参数优化经验。 1. 模型下载 建议下载 GGUF 格式，方便用 llama.cpp / llama-server 直接跑： Hugging Face 地址： tencent/HY-MT1.5-1.8B-GGUF 2. 启动与优化指令 如果你使用的是 RTX 3060 6GB 显卡，可以使用我优化后的 llama-server 启动命令。 这里开启了 --flash-attn 以及 KV 缓存量化（ q8_0 ），基本可以把模型完全塞进显存，速度飞快： llama-server -hf tencent/Hy-MT2-1.8B-GGUF:Q8_0 \ -c 8192 \ --port 8080 \ -ngl 99 \ --flash-attn on \ -t 6 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --parallel 1 \ --jinja \ --n-predict -1 \ --verbosity 1 3. PowerShell 测试指令 服务启动后，兼容 OpenAI 的 API 格式。在 Windows 下可以用以下 PowerShell 命令直接测试： Invoke-RestMethod -Method Post -Uri "[http://127.0.0.1:8080/v1/chat/completions]( http://127.0.0.1:8080/v1/chat/completions)" ` -ContentType "application/json" ` -Body (@{ model = "gpt-3.5-turbo" messages = @( @{role = "user"; content = "Translate to Chinese: Comparing Rust and C++ performance is a topic that all software developers should consider. In this guide, they are compared in terms of memory safety, concurrency models, and compilation performance. You will understand why C++ provides the best performance, and Rust does not compromise on safety as a trade-off. Simple differentiation and real-life examples will help you be prepared to make the correct choice of the right tool 。"} ) stream = $false } | ConvertTo-Json) 4. 运行结果与性能 (RTX 3060 6GB) 在我的 3060 上，生成的 Token 速度非常理想，完全能喂饱翻译插件的并发需求： choices : {@{finish_reason=stop; index=0; message=}} created : 1779531650 model : tencent/Hy-MT2-1.8B-GGUF:Q8_0 system_fingerprint : b9294-0f3cb3fc8 object : chat.completion usage : @{completion_tokens=68; prompt_tokens=88; total_tokens=156; prompt_tokens_details=} id : chatcmpl-5XADKRfaVh7iZ1Iva7bt1P1oRJkQBr5Q # 性能耗时指标： timings : @{ cache_n=0; prompt_n=88; prompt_ms=312.969; prompt_per_token_ms=3.556; prompt_per_second=281.178; predicted_n=68; predicted_ms=555.212; predicted_per_token_ms=8.164; predicted_per_second=122.475 } 总结： predicted_per_second 达到了 122 tokens/s 。
最近在找本地离线翻译大模型，测试了腾讯开源的 **混元翻译模型 1.8B **。 我用了几篇不同的技术文章进行深度对比， 它的翻译质量明显高于 Google 翻译和微软翻译 ，术语和语序都更符合中文习惯，1.8B 的体量能有这个效果让人非常惊喜。 这里分享一下我的部署和启动参数优化经验。 1. 模型下载 建议下载 GGUF 格式，方便用 llama.cpp / llama-server 直接跑： Hugging Face 地址： tencent/HY-MT1.5-1.8B-GGUF 2. 启动与优化指令 如果你使用的是 RTX 3060 6GB 显卡，可以使用我优化后的 llama-server 启动命令。 这里开启了 --flash-attn 以及 KV 缓存量化（ q8_0 ），基本可以把模型完全塞进显存，速度飞快： llama-server -hf tencent/Hy-MT2-1.8B-GGUF:Q8_0 \ -c 8192 \ --port 8080 \ -ngl 99 \ --flash-attn on \ -t 6 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --parallel 1 \ --jinja \ --n-predict -1 \ --verbosity 1 3. PowerShell 测试指令 服务启动后，兼容 OpenAI 的 API 格式。在 Windows 下可以用以下 PowerShell 命令直接测试： Invoke-RestMethod -Method Post -Uri "[http://127.0.0.1:8080/v1/chat/completions]( http://127.0.0.1:8080/v1/chat/completions)" ` -ContentType "application/json" ` -Body (@{ model = "gpt-3.5-turbo" messages = @( @{role = "user"; content = "Translate to Chinese: Comparing Rust and C++ performance is a topic that all software developers should consider. In this guide, they are compared in terms of memory safety, concurrency models, and compilation performance. You will understand why C++ provides the best performance, and Rust does not compromise on safety as a trade-off. Simple differentiation and real-life examples will help you be prepared to make the correct choice of the right tool 。"} ) stream = $false } | ConvertTo-Json) 4. 运行结果与性能 (RTX 3060 6GB) 在我的 3060 上，生成的 Token 速度非常理想，完全能喂饱翻译插件的并发需求： choices : {@{finish_reason=stop; index=0; message=}} created : 1779531650 model : tencent/Hy-MT2-1.8B-GGUF:Q8_0 system_fingerprint : b9294-0f3cb3fc8 object : chat.completion usage : @{completion_tokens=68; prompt_tokens=88; total_tokens=156; prompt_tokens_details=} id : chatcmpl-5XADKRfaVh7iZ1Iva7bt1P1oRJkQBr5Q # 性能耗时指标： timings : @{ cache_n=0; prompt_n=88; prompt_ms=312.969; prompt_per_token_ms=3.556; prompt_per_second=281.178; predicted_n=68; predicted_ms=555.212; predicted_per_token_ms=8.164; predicted_per_second=122.475 } 总结： predicted_per_second 达到了 122 tokens/s 。
最近在找本地离线翻译大模型，测试了腾讯开源的 **混元翻译模型 1.8B **。 我用了几篇不同的技术文章进行深度对比， 它的翻译质量明显高于 Google 翻译和微软翻译 ，术语和语序都更符合中文习惯，1.8B 的体量能有这个效果让人非常惊喜。 这里分享一下我的部署和启动参数优化经验。 1. 模型下载 建议下载 GGUF 格式，方便用 llama.cpp / llama-server 直接跑： Hugging Face 地址： tencent/HY-MT1.5-1.8B-GGUF 2. 启动与优化指令 如果你使用的是 RTX 3060 6GB 显卡，可以使用我优化后的 llama-server 启动命令。 这里开启了 --flash-attn 以及 KV 缓存量化（ q8_0 ），基本可以把模型完全塞进显存，速度飞快： llama-server -hf tencent/Hy-MT2-1.8B-GGUF:Q8_0 \ -c 8192 \ --port 8080 \ -ngl 99 \ --flash-attn on \ -t 6 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --parallel 1 \ --jinja \ --n-predict -1 \ --verbosity 1 3. PowerShell 测试指令 服务启动后，兼容 OpenAI 的 API 格式。在 Windows 下可以用以下 PowerShell 命令直接测试： Invoke-RestMethod -Method Post -Uri "[http://127.0.0.1:8080/v1/chat/completions]( http://127.0.0.1:8080/v1/chat/completions)" ` -ContentType "application/json" ` -Body (@{ model = "gpt-3.5-turbo" messages = @( @{role = "user"; content = "Translate to Chinese: Comparing Rust and C++ performance is a topic that all software developers should consider. In this guide, they are compared in terms of memory safety, concurrency models, and compilation performance. You will understand why C++ provides the best performance, and Rust does not compromise on safety as a trade-off. Simple differentiation and real-life examples will help you be prepared to make the correct choice of the right tool 。"} ) stream = $false } | ConvertTo-Json) 4. 运行结果与性能 (RTX 3060 6GB) 在我的 3060 上，生成的 Token 速度非常理想，完全能喂饱翻译插件的并发需求： choices : {@{finish_reason=stop; index=0; message=}} created : 1779531650 model : tencent/Hy-MT2-1.8B-GGUF:Q8_0 system_fingerprint : b9294-0f3cb3fc8 object : chat.completion usage : @{completion_tokens=68; prompt_tokens=88; total_tokens=156; prompt_tokens_details=} id : chatcmpl-5XADKRfaVh7iZ1Iva7bt1P1oRJkQBr5Q # 性能耗时指标： timings : @{ cache_n=0; prompt_n=88; prompt_ms=312.969; prompt_per_token_ms=3.556; prompt_per_second=281.178; predicted_n=68; predicted_ms=555.212; predicted_per_token_ms=8.164; predicted_per_second=122.475 } 总结： predicted_per_second 达到了 122 tokens/s 。
国内模型后排的比如stepfun，longcat，混元等等，以及百度的文心一言（没看懂为什么某个榜单第一），大家有亲身体验过吗？混元的我个人使用体验不如minimax 2.7，stepfun也是不如而且应该略差于混元，百度文心一眼确实没用过（但是参数看起来很大）。 6 个帖子 - 5 位参与者 阅读完整话题
今天看到 腾讯混元最新翻译模型 测试分数很强，于是马上LM Studio下了7b的模型 接上 陪读蛙 测试，实测翻译效果非常好，跟连ds v4 flash api效果差不多，可以替代了。终于在本地跑了一个有用的模型，开心～ 延迟（m4)： 6 个帖子 - 5 位参与者 阅读完整话题
你能做出陪读蛙/沉浸式翻译这样的chrome extension或者比他们更好,我就真谢谢你们了 6 个帖子 - 5 位参与者 阅读完整话题
IT之家 5 月 21 日消息，腾讯混元 21 日（今天）宣布，新一代多语言翻译模型 Hy-MT2 正式开源，腾讯 Hy 翻译小程序也同步开放体验，iOS 和安卓 App 即将推出，并支持本地推理。 Hy-MT2 包含 1.8B、7B、30B-A3B 三种尺寸，均支持 33 种语言互译及 5 种民族语言 / 方言互译 ，在多语言指令遵循、专业领域翻译和真实应用场景翻译中的表现，相比上一代 Hy-MT1.5 拥有明显提升。 其中，轻量级的 1.8B 模型也超越了微软等主流商业 API，且得益于 AngelSlim1.25-bit 极端量化， 仅需 440MB 存储空间 ，可部署在苹果、高通、联发科等手机芯片上支持本地推理，相比 Hy-MT1.5 推理速度提升 1.5 倍。 同步推出的“腾讯 Hy 翻译”小程序基于 Hy-MT2 打造，支持语音输入，并优化了 自定义翻译风格和指令 的能力。 用户不仅可以在联网环境下体验高速版的混元翻译模型，也可以通过提前下载端侧翻译模型，在无网络或者弱网络场景中 使用离线翻译 ，从而解决部分应用场景中网络条件受限的问题。 IFMTBench 也随着模型发布一并开源，这是一个翻译指令遵循测试集，测试集中的指令主要是和翻译任务相关（ 翻译风格变换、指定术语翻译 等），指令和待翻译的文本涵盖多个语种。 例如下面的例子，通过“个性化设定：翻译结果简洁精炼，去掉冗余表达，每句不超过 15 个字”，模型可以遵循指令，让翻译结果更符合要求。 据IT之家了解，该模型已在 GitHub、Hugging Face、ModelScope 等平台开放，兼容多品牌芯片与硬件环境。 HuggingFace： https://huggingface.co/collections/tencent/hy-mt2 Modelscope： https://modelscope.cn/collections/Tencent-Hunyuan/Hy-MT2 Github： https://github.com/Tencent-Hunyuan/Hy-MT2 腾讯云： https://console.cloud.tencent.com/tokenhub/text 腾讯混元官网： https://aistudio.tencent.com/llm/zh ?tabIndex=0
Hy-MT2包含3个尺寸的模型Hy-MT2-1.8B、Hy-MT2-7B、Hy-MT2-30B-A3B，三个模型均支持33个语种互译，5种民汉/方言。HF官网在 https://huggingface.co/collections/tencent/hy-mt2 官方给的跑分图： 还搞了一个小程序说是，不知道手机端推理能不能比之前快一些，上次部署了个MT-1.5-2bit量化版本在手机上跑一个几十词小翻译都得七八分钟 3 个帖子 - 3 位参与者 阅读完整话题
想试试图片生成3D的效果，但是奈何没有显卡，tencent/Hunyuan3D-2.1这个模型好像挺好的，但是看了硅基之类的都没有接口，有没有佬知道哪里可以调用。 1 个帖子 - 1 位参与者 阅读完整话题
腾讯专门为手机CPU设计的STQ内核，该方案实现了对SIMD指令集的完美适配。最终，3.3GB的原始模型被进一步压缩至440MB，轻松常驻后台，让内存紧张的普通手机也能顺滑进行高质量离线翻译。 下载链接 Huggingface https://huggingface.co/AngelSlim/Hy-MT1.5-1.8B-1.25bit-GGUF/resolve/main/Hy-MT-demo.apk 魔搭社区 https://modelscope.cn/models/AngelSlim/Hy-MT1.5-1.8B-1.25bit-GGUF/resolve/master/Hy-MT-demo.apk 5 个帖子 - 4 位参与者 阅读完整话题
https://mp.weixin.qq.com/s/IeI8zD8YmCON0BN0YCMu1Q 6 个帖子 - 5 位参与者 阅读完整话题
如图，刚才还在用呢，刷新一下直接迷失了，这是被取消掉了吗，我资产还在里面呢找都找不到了 1 个帖子 - 1 位参与者 阅读完整话题