TL;DR：Z.AI 的 GLM-5.3 模型卡标注 753B 参数，并称它与 GLM-5.2 使用同一基础模型，能力提升来自后训练；官方报告的 Terminal-Bench 3.0 从 4.6 升至 28.3、DeepSWE 从 46.2 升至 66.9，但这些成绩使用了特定 harness、最长 6–10 小时超时和数十万 token 上下文，不能直接换算成你的项目收益。对大多数个人和团队，更稳妥的顺序是先用云端完成 3–5 个真实任务，只有在工作流稳定、数据确实敏感且利用率足够高时，再为本地部署采购硬件。
开放权重很容易让人产生一种冲动：既然模型可以下载，不如买一台大内存机器，把版本、数据和成本都握在自己手里。GLM-5.3 又恰好把编码、终端操作和长任务成绩推高了一截，这种冲动更强。
但“能下载”“能运行”和“值得长期自托管”是三件事。GLM-5.3 的规模、评测条件和自定义许可证，都要求我们先算清技术账和业务账，再决定是否买机器。
🎬 视频版（B站） ｜ 🎧 音频版（5 分 50 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇
同一个基础模型，为什么成绩能差这么多
GLM-5.3 官方模型卡称，它与 GLM-5.2 使用同一个基础模型，所有提升都来自后训练。这里的“同一个基础模型”不等于模型完全没变，而是预训练得到的底座相同，变化集中在让模型规划、使用工具、完成长任务的后续训练阶段。
这件事值得关注，因为智能体能力不只取决于记住多少知识。模型是否会持续检查环境、修正方案、调用工具并在长任务中保持目标，同样会显著影响最终表现。换句话说，参数规模不变，不代表行为能力只能原地踏步。
不过，模型卡上的“提升全部来自后训练”仍是厂商对自家训练过程的说明；公开权重本身不足以让外部完整复现训练数据、奖励模型和全部后训练配方。
三个漂亮数字，必须连同测试条件一起看
Z.AI 在模型卡中列出了多项对比结果：
| 基准 | GLM-5.2 | GLM-5.3 | 官方测试边界 |
|---|---|---|---|
| Terminal-Bench 3.0 | 4.6 | 28.3 | Claude Code 2.1.207 harness；400K 上下文；128K 最大输出；每题最多 600 轮、10 小时；每题三次取 avg@3 |
| DeepSWE v1.1 | 46.2 | 66.9 | mini-swe-agent；400K 上下文；6 小时超时 |
| AutomationBench v1.0.6 | 26.2 | 48.2 | 使用包含 null 类型修复的 v1.0.6 |
这些数字最能支持的结论，是 GLM-5.3 在 Z.AI 披露的环境中相较 GLM-5.2 有明显进步。它们不能证明任意代码库都能获得同样幅度的提升，也不能脱离上下文长度、推理预算、工具配置和时间限制，与另一个服务商的默认 API 直接比较。
模型卡还写明，GLM-5.3 的 reasoning_effort 默认是 max；若要复现榜单，应保留这个默认值。真实项目若为控制延迟和成本改用较低推理预算，结果可能不同。
753B 参数，意味着普通桌面不是默认答案
Hugging Face 页面把 GLM-5.3 标为 753B 参数。只做一个不含运行时开销的理论计算：如果每个参数平均占 1 字节，权重本身约为 753 GB；若理想化压到 4 bit，下限约为 376.5 GB。实际部署还要加入量化元数据、运行时缓冲、KV Cache、上下文长度和并发需求，不能按这个下限直接购买内存。
模型页将 GLM-5.3 的架构标为 glm_moe_dsa，属于稀疏 MoE。每次生成只激活部分专家，有助于降低单 token 计算量，但未激活的权重仍需存储，并要能在设备或内存层级间高效调度。“激活参数少”不能自动等于“整套模型能轻松塞进消费级电脑”。
模型卡列出了 Transformers、SGLang、vLLM、TokenSpeed、KTransformers、Unsloth 和 Ascend NPU 等部署路径，却没有给出一台适用于所有精度、上下文和吞吐目标的推荐整机。网上流传的“五百多 GB 统一内存”方案只能视为特定量化和运行配置的社区实践，不是官方最低要求。
开放权重不等于采用标准开源许可证
GLM-5.3 的权重已经公开，用户可以下载、运行、微调和制作衍生版本；但模型页标注的是自定义 GLM-5.3 License，不是 MIT、Apache-2.0 等常见开源许可证。
许可证允许使用、复制、修改、发布、分发、再许可和销售，也要求保留版权与许可声明并遵守适用法律。另有一个重要条件：如果被许可方或其关联方经营“模型即服务”业务，且任意连续 12 个月总收入超过 100 亿美元，在将该模型或衍生作品用于任何商业目的之前，必须通过 Z.AI 的安全审查。
这项限制对多数个人开发者没有直接影响，却足以说明“开放权重”和“符合传统自由开源软件定义”不能混写。准备商业化，尤其是提供模型 API 或微调服务的公司，应让法务直接阅读许可证原文，不能只看模型页上的开放标签。
本地部署真正买到的是控制，不一定是便宜
云端按量付费，把硬件采购、容量扩缩、故障更换和大部分运维交给服务商。本地部署则把模型版本、日志、数据路径和停服风险放回自己手里，同时也接回了电力、散热、存储、备份、安全更新和闲置成本。
如果一天只运行少量任务，昂贵硬件大部分时间处于闲置状态，单次推理成本很难靠电费表算出优势。若负载长期稳定、设备能被多个项目复用，或者数据不能离开指定环境，本地方案才更可能显示价值。
所以应比较总拥有成本，而不是只比较“每百万 token 的 API 价格”和“机器买断价”：
总拥有成本 = 硬件 + 电力 + 散热 + 存储 + 运维 + 闲置成本 − 可复用价值
隐私问题不能只靠“本地”两个字解决
本地运行可以减少把代码、配置和研究方向发送给外部服务商的必要性，但这不代表数据自动安全。模型文件、量化包、容器镜像、插件和依赖仍可能来自外部；智能体若拥有网络权限、生产密钥和广泛文件权限，照样可能造成泄漏或破坏。
更可靠的做法是把运行边界写进系统：在容器或隔离环境里执行；限定可读写目录；默认断开不必要的网络；高风险操作要求人工确认；保留工具调用和文件变更审计；生产凭据与实验环境分离。
GLM-5.3 的安全攻防成绩也说明了同一件事。Z.AI 报告它在 CyberGym、ExploitGym 和 ExploitBench 上较上一代明显提高，但这些仍是厂商披露的特定基准结果。更强的漏洞分析能力可以帮助防守，也可能扩大误用风险；开放权重不会替部署者完成授权、隔离和审计。
图：《听懂 AI》第 025 期节目封面。
先租后买，是为了先得到自己的实测数据
采购之前，先挑 3–5 个真正会重复出现的任务，例如跨文件修复、较大重构、依赖升级或长时间自动化流程。不要只记录“感觉不错”，至少保存这些指标：
- 一次成功率，以及需要几轮人工纠正；
- 完成时间和实际 token 消耗；
- 测试失败、错误修改与回滚次数；
- 人工审查和返工时间；
- 相同任务在现有模型或人工流程中的基线。
只有当 GLM-5.3 在这些任务上持续创造价值，本地部署的成本讨论才有意义。否则，买到的只是一个昂贵的验证环境。
图：本地部署决策路径。它是编辑阶段给出的行动框架，不是厂商硬件建议。
哪些情况适合继续用云，哪些情况值得本地化
继续使用云端通常适合这些情况：负载不稳定、模型仍在频繁替换、团队没有专职推理运维、数据可以在合规协议下托管，或者只是想快速验证新工作流。
本地验证更适合数据敏感、需要固定模型版本、必须离线运行，或服务连续性不能依赖外部 API 的场景。即使如此，也应先租用可控环境或利用现有设备测试量化版本，测清速度、输出质量和并发能力，再决定硬件规格。
长期采购需要更高门槛：任务量稳定、利用率可预测、量化损失已被业务接受、电力和散热条件明确、有人负责驱动与运行时升级，并且总拥有成本在合理周期内优于替代方案。
最后的购买建议：为验证过的工作流买机器
GLM-5.3 的意义，不只在于又出现一个更强的编码模型。它让团队拥有了更多部署选择，也迫使大家更认真地区分模型能力、许可证、数据边界和基础设施成本。
开放权重给了你选择本地运行的权利，却没有替你证明本地运行更省钱。榜单给出了实验结果，也没有替你完成自己的业务评测。
因此，先让云端测试替你淘汰不稳定的想法，再让小规模本地验证确定容量和质量，最后才采购长期硬件。该买机器的理由不是“榜单很好看”，而是“自己的实测数据已经证明这套工作流值得长期运行”。
收看本期节目
原始资料与延伸阅读
本文由《听懂 AI》第 025 期访谈整理而成。本期并非基于单一新闻原文，主要依据 Z.AI 的官方模型卡与许可证；模型能力和安全结果均为厂商披露的基准成绩，适用范围受 harness、上下文、推理预算、超时和评分方法限制。753B 参数对应的存储数字是按位宽计算的理论估算，不是官方硬件配置；Hacker News 内容仅作为社区成本与部署经验的观察。
- Z.AI：GLM-5.3 官方模型卡 — 参数规模、同底座后训练说明、基准、评测脚注和本地部署入口。
- Z.AI：GLM-5.3 License — 权重、商业使用、模型即服务和安全审查条款原文。
- GLM-5 技术报告：GLM-5: from Vibe Coding to Agentic Engineering — 模型卡引用的系列技术报告；它描述 GLM-5 系列，不应当作 GLM-5.3 每项变化的独立复现。
- Z.AI：GLM-5 官方代码仓库 — 系列说明、引用与官方资源入口。
- Hacker News 讨论串 — 仅用于观察本地部署成本、隐私和硬件利用率方面的社区意见。