发现一个企业部署GLM4.7 Flash 生成速度的优化方案 TL;DR 视频中测试 4090 48g x2 unsloth q8 用ik_llama.cpp的测试分支 128k上下文可以到37t/s 优化前是22t 这个模型非常好用 等到这些优化到可用了，我出详细测评 #claudecode #aiagent #企业AI #本地部署 #glm47

GLM4.7 模型虽性能均衡、Agent 能力强，但其长上下文生成速度慢是企业部署的痛点。一个来自社区的技术分支，通过底层优化，显著提升了其在 128k 上下文下的生成速度，使其具备了实际的落地价值。

智能速览

• GLM4.7 模型在长上下文场景下生成速度存在严重衰减问题。

• 优化前，在 128k 上下文下生成速度仅为 22 tokens/s。

• 使用 llama.cpp 的一个社区分支进行指令集优化。

• 优化后，在同等条件下速度提升至 37 tokens/s。

• 该测试基于双 4090 48G 显卡、Q8 量化环境。

精华内容

GLM4.7 的长上下文瓶颈究竟如何被打破？通过一个社区分支的优化，实测数据揭示了惊人的性能跃升。

性能瓶颈

GLM4.7 模型虽在 3B 激活尺寸上实现了性能与平衡，但其 Agent 能力强的背后，隐藏着长上下文处理的短板。该模型采用了 MLA 和 DeepSeq 技术，但社区支持尚不成熟，尤其 GQA 比例为 20 的设计，导致在长文本场景下性能衰减严重。

实测数据显示，当上下文达到 120k 时，其生成速度骤降至 22 tokens/s。在 2048 输入、512 输出的模拟任务中，输出过程耗时长达 20 秒，这对于需要快速响应的企业级应用而言，几乎是不可接受的。

社区优化

解决方案来自一位专注于 llama.cpp 指令集优化的开发者，其个人分支（ik_llama.cpp 的测试分支）提供了一种“非常规”的优化思路。具体技术细节虽未公开，但核心在于从底层指令集层面着手，针对 GLM4.7 的特殊性进行深度适配，而非依赖通用优化。

这种方法与标准的线性衰减优化路径不同，它选择在小上下文时接受一定的性能损失，以换取长上下文场景下更平缓的性能曲线。

速度跃升

优化效果十分显著。在双 4090 48G 显卡、Unsloth Q8 量化、128k 上下文的环境下，模型的生成速度从 22 tokens/s 提升至 37 tokens/s，提升了约 68%。

虽然在小上下文（如 2k）时，速度会从 77 tokens/s 开始较快衰减，但随着上下文增长，衰减速度明显放缓。这一改变使得模型在处理长文档时，从一个“几乎不可用”的状态，转变为“非常可用”的实用工具。

应用潜力

目前该优化仍以 PR（Pull Request）形式存在，社区正合力推进其成熟化。单卡 Q4 量化版本的测试也在计划中，预计效果同样值得期待。

若此优化能稳定融入主线，并达到类似千问 30B 的速度水平，GLM4.7 的前景将极为广阔。特别是考虑到其单卡 Q4 即可跑满 200k 上下文的潜力，一旦速度问题解决，它将成为企业本地化部署 AI Agent 的理想选择。

此次优化不仅是技术上的突破，更证明了开源社区的力量。GLM4.7 的实用化进程正加速，它是否能成为企业本地 AI 的主流选择？