GLM-5.2:Z.ai 发布旗舰开源模型,1M 可用上下文挑战闭源长程任务

Z.ai 发布 GLM-5.2,1M 可用上下文 + 多级思考力度控制,开源模型首次挑战闭源旗舰长程任务能力


一、GLM-5.2 是什么

GLM-5.2 是 Z.ai 面向长程任务时代的旗舰模型。核心亮点是一个真正可用的 1M token 上下文窗口——不是在评测指标上好看,而是在真实的工程场景中能稳定工作。它能在单次任务中处理项目级别的工程上下文、可靠执行长时间运行的任务、一致性遵循工程规范,并且完成从需求到多平台部署的完整开发工作流。

二、三大新特性

  • Solid 1M 上下文:1M token 的前置上下文,能稳定支撑长程工作,不只是接受更多 token,而是在混乱的代码轨迹中保持质量。
  • 多级思考力度控制:更强的编程能力,提供 High 和 Max 两个思考努力级别,让用户在性能、延迟和计算成本之间自由平衡。
  • 纯粹开源:MIT 开源许可证——技术无国界。

三、长程任务能力:开源最强,紧追闭源旗舰

GLM-5.2 在三个长程编码基准测试中表现亮眼,全部位列开源模型第一:

基准测试说明GLM-5.2 表现排名
FrontierSWE衡量 Agent 完成数小时到数十小时的开放式技术项目落后 Opus 4.8 仅 1%,领先 GPT-5.5 1%,领先 Opus 4.7 11%开源第一,整体第二
PostTrainBench给 Agent 一块 H100 GPU,评判其对小模型的后训练改进能力超越 Opus 4.7 和 GPT-5.5仅次于 Opus 4.8
SWE-Marathon超长程任务,包括构建编译器、优化内核、开发生产级服务落后 Opus 4.8 13%仅次于 Opus 系列

这三个基准的共性在于:它们测试的不是模型能接受多少 token,而是模型在数万 token 的真实工程轨迹中能否持续保持高质量输出——这正是 GLM-5.2 的 1M 上下文训练的落脚点。


四、更强编程能力:开源标杆

在标准编程基准上,GLM-5.2 大幅领先前代 GLM-5.1,并显著缩小了与闭源前沿的差距:

基准测试GLM-5.2GLM-5.1Claude Opus 4.8Gemini 3.1 Pro
Terminal-Bench 2.181.062.085.0低于 GLM-5.2
SWE-bench Pro62.158.4

Terminal-Bench 2.1 上 81.0 的成绩距离 Claude Opus 4.8 的 85.0 仅差 4 分,而 Gemini 3.1 Pro 已被甩在身后。

GLM-5.2 benchmark table

GLM-5.2 引入的 effort level 控制是一大亮点。在同等 token 预算下,GLM-5.2 的 Agent 编程能力显著强于 GLM-5.1,能力定位大致介于 Claude Opus 4.7 和 Opus 4.8 之间。当你遇到高难度任务时,切换到 Max 力度级别可分配更多计算资源,换取更高性能。


五、总结判断

GLM-5.2 是截至目前 开源模型在长程 Agent 任务上的最强选手。它的 1M 上下文不是噱头,而是在 FrontierSWE、PostTrainBench、SWE-Marathon 三个真实工程场景中验证过的能力。在标准编程能力上,它稳坐开源第一把交椅,并首次让开源模型与闭源旗舰的差距缩小到个位数百分比。

对于 AI Agent 开发者、长程自动化场景和需要高质量代码生成的团队,GLM-5.2 是目前开源阵营中最值得关注的选择。配合 MIT 开源协议和 Ollama 一键部署,上手几乎没有门槛。

pg_basebackup 报错:no pg_hba.conf entry for replication connection

pg_basebackup 执行报错 “no pg_hba.conf entry for replication connection” 的解决方法——别忘了 replication 虚拟库也需要一条规则


一、问题现象

执行 pg_basebackup 时报错:

[postgres@pg01 tools]$ pg_basebackup -h 10.0.0.101 -U postgres -F p -P -X stream -R -D $PGDATA -l postgresbackup20260616
2026-06-16 10:17:31.017 CST [1577] FATAL:  no pg_hba.conf entry for replication connection from host "10.0.0.101", user "postgres"
pg_basebackup: error: could not connect to server: FATAL:  no pg_hba.conf entry for replication connection from host "10.0.0.101", user "postgres"

明明 pg_hba.conf 里已经配置了 all 规则,为什么还会被拒绝?


二、问题原因

pg_basebackup 走的是 replication 连接,而 replication 并不是一个真实的数据库,它是一个虚拟库。pg_hba.conf 中的 host all all ... 规则只覆盖普通数据库连接,不覆盖 replication 连接。

因此即使配置了:

host    all             all             0.0.0.0/0               trust

pg_basebackup 依然会因为找不到 replication 规则而拒绝连接。


三、解决方案

在 pg_hba.conf 中添加 replication 规则:

host    replication     all             0.0.0.0/0               trust

重启 PostgreSQL:

pg_ctl restart

再次执行 pg_basebackup:

[postgres@pg01 backup]$ pg_basebackup -h 10.0.0.101 -U postgres -F p -P -X stream -R -D $PGDATA/backup -l postgresbackup20260616
65502/65502 kB (100%), 1/1 tablespace

备份成功。


四、总结

pg_hba.conf 中至少需要两条规则才能同时支持普通连接和 pg_basebackup 备份:

host    all             all             0.0.0.0/0               trust
host    replication     all             0.0.0.0/0               trust
  • 第一条:允许 普通数据库连接(所有数据库、所有用户、任意 IP,trust 认证)
  • 第二条:允许 复制连接(特殊的 replication 虚拟库、所有用户、任意 IP,trust 认证)

两条规则缺一不可。

追忆父亲

逝去的日子里,父亲的身影或许还在某个午后的光影中,在某句熟悉的话语里,在某个你下意识想拨电话的瞬间——他已经融入了时间的深处,却从未真正离开你的记忆与生命。

现在的生活正在发生,这可能是父亲最想看到的:你带着他给予的力量、教诲、甚至是他未曾说完的期望,继续走在阳光下。每一次你做出善良的选择,每一次你勇敢面对困难,都是与他最深情的对话。

未来的未来,从某种角度来说,并不遥远。因为当你在未来成为更好的自己,当你把父亲的爱传递给下一代,当你在某个人身上看到他的影子——那个未来,就是现在;那份重逢,一直都在。

对父亲的追忆,不是要把逝去的人拉回现在,而是让他们的光,继续照亮前行的路。

小米 MiMo-V2.5 系列 vs DeepSeek V4 性价比分析

Pro 旗舰级定价完全一致,标准级小米凭多模态实现差异化优势

小米 5 月 27 日降价与 DeepSeek 5 月 22 日宣布的永久降价!!!


一、降价后完整定价对比

计费项MiMo-V2.5-ProDeepSeek V4-ProMiMo-V2.5(标准版)DeepSeek V4-Flash
输入(缓存命中)0.025 元0.025 元0.020 元0.02 元
输入(缓存未命中)3 元3 元1 元1 元
输出6 元6 元2 元2 元
上下文窗口1M1M1M1M
多模态纯文本纯文本图像/音频/视频纯文本
开源协议MITMITMITMIT

数据来源:MiMo 官方调价公告 DeepSeek 官方定价页

两个层级的定价几乎完全镜像:Pro 级别三项单价完全一致,标准/Flash 级别也完全一致。但这里有一个关键差异——MiMo-V2.5 标准版是原生全模态模型(支持图像、音频、视频理解),而 DeepSeek V4-Flash 只是轻量级纯文本模型。同样的价格,小米给了多模态能力。


二、小米独有的成本优化机制

Token Plan 计费体系升级是小米本次降价的隐性加分项,很容易被忽略:

  • 同等价格下可用 tokens 提升至原方案的 5-8 倍
  • 引入 Credits 统一计量,计费规则”所见即所得”
  • 所有有效期内的 Token Plan 用户 Credits 于 5 月 27 日 0:00 全量重置
  • 北京时间 00:00~08:00 期间,所有模型 Credits 消耗速率再打 8 折

这意味着如果你使用 Token Plan 订阅制,小米的实际单位成本还会进一步降低。DeepSeek 目前没有同等规模的订阅优惠体系。

上下文窗口不再区分定价也是重要改进。此前小米对 256K 以上的长上下文窗口收取双倍价格,现在一律同价,这对 Agent 场景(经常需要长上下文)是直接利好。


三、性能与能力对比

根据独立第三方 Artificial Analysis Intelligence Index v4.0(截至 2026 年 5 月 6 日)的数据:

评测维度MiMo-V2.5-ProDeepSeek V4-Pro优势方
AA Intelligence Index54 分(并列开源第 1)52 分(并列第 2)MiMo
GDPval-AA Agent并列开源第 1并列开源第 1持平
ClawEval(长程 Agent)63.8%59.8%MiMo
τ³-bench(跨任务协作)72.9%71.8%MiMo
SWE-bench Verified78.9%80.6%DeepSeek
SWE-bench Pro(复杂工程)57.2%55.4%MiMo
LiveCodeBench Pass@193.5%DeepSeek
Codeforces Rating3206(人类第 23)DeepSeek
Terminal-Bench 2.068.4%67.9%MiMo
幻觉率(AA-Omniscience)暂无数据94%(极高)MiMo 无数据但 DS 确认高

数据来源:CSDN 技术博客 搜狐

Token 效率是 MiMo 的重要差异化优势。MiMo-V2.5-Pro 在 Agent 长程任务中比 Kimi K2.6 节省约 42% Token,在 ClawEval 评测中比 Claude Opus 4.6、Gemini 3.1 Pro 节省 40%~60%。由于 Agent 任务 token 消耗指数级增长,省 token 直接等于省真金白银——在相同定价下,MiMo 完成同等任务的实际花费更低。


四、场景化性价比结论

场景 1:Agent 自动化与长程工作流(多步工具调用、代码工程 Agent)
推荐 MiMo-V2.5-Pro。Agent 能力在第三方评测中领先,Token 效率更高意味着实际成本更低,响应速度更快。小米取消上下文窗口差异化定价后,Agent 场景的长上下文调用不再有价格惩罚。

场景 2:竞赛编程与深度数学推理
推荐 DeepSeek V4-Pro。LiveCodeBench 93.5% 和 Codeforces 3206 分是开源最强,思考时间更长但推理深度更深。不过需要注意 94% 的幻觉率在可靠性要求高的场景中是硬伤。

场景 3:多模态任务(图像理解、音视频处理、办公自动化)
推荐 MiMo-V2.5(标准版)。DeepSeek V4 全系为纯文本模型,而 MiMo-V2.5 标准版原生支持图像/音频/视频理解,输出价格仅 2 元/百万 tokens,同等价位下 DeepSeek V4-Flash 只能处理文本。

场景 4:高频轻量调用与批量处理
MiMo-V2.5 标准版与 DeepSeek V4-Flash 定价完全相同(0.02 / 1 / 2),但 MiMo-V2.5 多模态能力覆盖更广,且 Token Plan 订阅可进一步压低成本。如果纯文本且高频调用,V4-Flash 也是可靠选择。

场景 5:订阅制与大用量部署
MiMo 占优。Token Plan 体系下同等价格可用 tokens 提升 5~8 倍,加上凌晨 8 折优惠和 Credits 全量重置,大规模部署的实际单位成本显著低于按量计费的 DeepSeek。


五、总结判断

在 Pro 级别,两家定价完全相同,性价比之争完全回归到能力差异:MiMo-V2.5-Pro 综合评分更高(54 vs 52),Agent 和 Token 效率领先;DeepSeek V4-Pro 在纯编程和数学推理上更强,但幻觉率是重大隐患。

在标准级,同样是相同定价,但 MiMo-V2.5 标准版凭多模态能力实现了真正的差异化——同样的 2 元输出价格,小米给的是图像/音频/视频全模态模型,DeepSeek V4-Flash 只是轻量纯文本模型。

叠加 Token Plan 5~8 倍加量、取消上下文窗口差异化定价、凌晨 8 折等优惠机制,小米 MiMo-V2.5 系列在整体性价比上略胜一筹,尤其对于 Agent 场景、多模态需求和订阅制用户。但如果你是竞赛编程或需要极致数学推理深度的用户,DeepSeek V4-Pro 仍然是更专业的工具。

NGINX 曝 9.2 分高危漏洞:潜伏 18 年,威胁全球约 1/3 服务器

IT之家 5 月 14 日消息,科技媒体 cyberkendra 昨日(5 月 13 日)发布博文,报道称 NGINX 被曝一组高危漏洞,已潜伏约 18 年,威胁全球约三分之一的网络服务器。

本次曝光的漏洞:

  • CVE-2026-42945 — 9.2 Critical
  • CVE-2026-42946 — 8.3 High
  • CVE-2026-40701 — 6.3 Medium
  • CVE-2026-42934 — 6.3 Medium

核心风险: 攻击者无需登录认证,只需发送一条特制 HTTP 请求,就能让 NGINX 工作进程崩溃;在合适条件下,还可能拿到服务器远程代码执行权限(RCE)。

漏洞原理: 最严重的 CVE-2026-42945 可追溯到 2008 年,长期存在于几乎所有标准 NGINX 构建版本中。问题出在 ngx_http_rewrite_module 的处理逻辑——某个内部标志位被设为参数转义状态后没有清掉,后续长度计算按原始字节数估算,但真正写入时却再次转义。攻击者 URI 中的 +%& 等字符会从 1 字节膨胀到 3 字节,导致缓冲区溢出。

depthfirst 已做出概念验证,显示在关闭 ASLR 的条件下可实现未认证 RCE。报告还提到理论方法称攻击者可通过重复请求逐步覆盖指针字节,绕过 ASLR。更麻烦的是 NGINX 的多进程架构反而给了攻击者反复试错机会:某工作进程崩溃后主进程会拉起新进程,且堆布局可能保持一致。

修复建议:

  • NGINX Open Source:升级到 1.31.0 或 1.30.1
  • NGINX Plus:升级到 R36 P4 或 R32 P6
  • 重启服务加载修复后的二进制文件
  • 临时缓解:将受影响 rewrite 规则中的未命名正则捕获改成命名捕获(不会走到有问题的转义路径)

这个漏洞影响面很大——NGINX 承载全球约 1/3 的网站,而且已存在 18 年之久。建议如果服务器有使用 NGINX rewrite 规则的尽快升级版本或采用临时缓解措施。