GLM-4.7智能体部署实战：从模型选型到性能调优全解析

1. 项目概述从GLM-4.5到GLM-4.7一个开源智能体基座的演进之路如果你在过去一年里深度参与过AI智能体或者大语言模型的应用开发那么“GLM”这个系列对你来说一定不陌生。从GLM-4.5的横空出世到GLM-4.6的稳步提升再到最近GLM-4.7的惊艳亮相智谱AI的这套开源模型家族已经从一个“不错的选项”变成了许多团队在构建复杂AI应用时尤其是在智能体Agent场景下会优先考虑甚至深度依赖的基座。我自己的团队在过去几个项目中从早期的模型选型、到中期的性能调优、再到后期的生产部署都不同程度地使用了GLM系列模型踩过一些坑也积累了不少实战经验。今天我就以一个一线开发者的视角来为你深度拆解GLM-4.5/4.6/4.7这一系列模型特别是最新的GLM-4.7到底带来了哪些实质性的改变以及在实际部署和应用中我们该如何选择、如何避坑、如何榨干它的每一分性能。简单来说GLM-4.5系列是智谱AI专门为“智能体”场景设计的混合专家MoE模型。它最大的特点就是官方宣称的“ARC”三位一体能力Agentic智能体、Reasoning推理、Coding编程。这意味着它从设计之初就不是一个单纯的聊天模型而是为了处理多步骤规划、工具调用、代码生成与执行等复杂任务而生的。GLM-4.5拥有3550亿总参数其中活跃参数为320亿这个规模在开源MoE模型中属于第一梯队。同时它还提供了一个更轻量的“Air”版本总参1060亿活跃120亿为资源受限的场景提供了可能。到了GLM-4.6最显著的提升是将上下文长度从128K扩展到了200K这对于需要处理超长文档或维持超长对话历史的智能体任务至关重要。而GLM-4.7则是在其前辈坚实的基础上对“思考”能力进行了革命性的增强引入了“交错思考”和“持久思考”等新机制让模型在解决复杂任务时的稳定性和可控性上了一个新台阶。2. 核心能力演进与模型选型深度解析面对GLM-4.5、4.6、4.7以及它们各自的Base、FP8、Flash变体很多开发者第一反应是眼花缭乱。别急我们一层层剥开来看。选型的核心永远是基于你的具体任务场景、硬件预算和对延迟/效果的权衡。2.1 代际差异从4.5到4.7能力跃迁在哪里首先我们得搞清楚这三个主要版本的本质区别这决定了你的基线选择。GLM-4.5智能体基座的奠基者这是整个系列的起点。它的核心价值在于证明了MoE架构在复杂任务上的巨大潜力。在发布时其在多项基准测试如AgentBench、HumanEval等上的表现就足以媲美甚至超越许多闭源模型。对于大多数常规的智能体应用——比如基于自然语言操作数据库、自动编写并执行数据分析脚本、调用外部API完成工作流——GLM-4.5-Air版本往往已经足够胜任且部署成本低得多。它的“思考模式”是一个重要特性在需要复杂推理或工具调用的任务中开启模型会先输出一段“内心独白”推理链再给出最终答案或行动这大大提升了任务的可解释性和成功率。GLM-4.6长上下文与综合性能的强化GLM-4.6可以看作是4.5的“完全体”。除了基准分数上的普遍提升它最实用的升级是200K上下文窗口。在实际项目中这意味着什么假设你正在构建一个代码助手用户可以将整个中小型项目的代码库可能数万行作为上下文喂给模型让它进行全局分析、重构建议或bug查找。或者在客服场景中模型可以记住更长的对话历史避免“健忘”。另一个容易被忽略但至关重要的提升是工具调用Tool Using和搜索能力的增强。根据官方报告在τ²-Bench和BrowseComp等基准上进步显著。如果你做的智能体严重依赖准确调用各种工具搜索引擎、计算器、专业API或进行网页信息提取4.6会比4.5更可靠。GLM-4.7思考机制的质变与编码专精GLM-4.7的升级点非常集中且深刻主要围绕“如何更好地思考”。它引入了三个关键概念交错思考Interleaved Thinking的增强在4.5/4.6中思考模式是“一次性”的。而在4.7中模型可以在一次多步骤任务中在每一个动作如调用一个工具、生成一段代码之前都进行思考使得每一步的决策都更加审慎指令跟随能力更强。持久思考Preserved Thinking这是解决智能体任务中“信息丢失”痛点的利器。在传统的多轮对话中模型每轮都需要重新理解整个历史和之前的推理过程。而持久思考允许模型在对话中自动保留所有的思考块在后续轮次中直接复用而不是从头推导。这对于代码调试、分步问题解决等长视野任务来说稳定性和一致性会有质的飞跃。轮次级思考控制Turn-level Thinking你可以在会话粒度上灵活控制是否开启思考。对于简单的问答关闭思考以降低延迟和成本对于复杂任务再开启。这给了开发者精细的成本与效果调控能力。此外GLM-4.7在编码能力上提升巨大特别是在SWE-bench解决真实GitHub问题和Terminal Bench终端任务上。如果你的核心场景是AI编程助手、自动化脚本生成或者需要模型与命令行交互4.7是目前开源模型中的顶级选择。它还专门推出了一个轻量级的GLM-4.7-Flash模型300亿总参30亿活跃在性能和效率间取得了新平衡为端侧或低成本部署打开了新大门。实操心得版本选择策略我的经验是求稳且预算有限选4.5-Air要长上下文和强工具调用选4.6攻坚复杂编码与长任务智能体必上4.7。对于大多数企业内部自动化流程、知识问答机器人4.5-Air性价比极高。如果是面向开发者的重度编码工具或者需要处理超长技术文档的智能体4.6是更全面的选择。而如果你的项目类似于AutoGPT、Devin这类需要高度自主规划、执行复杂多步任务尤其是涉及代码编写和终端操作的智能体那么GLM-4.7的持久思考特性几乎是“降维打击”能显著降低任务中途“跑偏”或“失忆”的概率。2.2 模型变体详解Base、FP8、Flash都是什么确定了主版本后你还会看到一堆后缀。它们决定了模型的“形态”和部署要求。Base模型指经过预训练但未经过指令微调SFT和人类偏好对齐RLHF的“原始”模型。它的语言能力很强但在遵循指令、安全回复、对话格式上表现不佳。除非你要从头开始做领域特定的微调否则不要直接使用Base模型。它适合研究机构或大型企业进行大规模定制化训练。标准模型无后缀即经过完整SFT和RLHF对齐的聊天模型也是我们通常所说的“GLM-4.5/6/7”。它直接用于对话、推理、工具调用等任务。我们日常讨论和使用的默认就是这个版本。FP8量化版本这是用FP88位浮点数精度存储的模型权重。FP8能在几乎不损失精度的情况下对于大语言模型精度损失通常可忽略将模型的内存占用和计算量减半。这是生产部署的首选尤其是对于GLM-4.5/4.7这种大模型FP8版本能让你用一半的GPU数量达到相近的性能。例如GLM-4.5 FP8只需8张H100而BF16版本需要16张。Flash版本仅4.7有这是一个全新的、更小的模型架构300亿总参/30亿活跃并非原模型的量化版。它旨在提供接近标准版的能力但拥有更快的推理速度和低得多的硬件需求。官方称其“在性能与效率间提供了新的选择”。对于延迟敏感或计算资源紧张的应用如实时对话、边缘设备Flash版本值得重点评估。注意事项关于量化与精度很多团队会纠结于“量化会不会影响效果”。根据我们和业内的实测对于GLM系列FP8量化对最终任务效果的影响微乎其微尤其是在智能体、代码生成这类任务上差异远小于不同prompt带来的波动。因此在资源允许的情况下优先尝试FP8版本它能为你节省大量成本。只有在极端追求最高精度、且资源无限充足的科研场景下才需要考虑BF16版本。2.3 硬件需求与部署成本估算这是最现实的一环。官方给出了详细的配置表但我们需要解读其背后的含义。推理配置解读以GLM-4.5标准版BF16为例“H100 x 16”是最低配置能跑起来但可能无法充分发挥128K全部上下文的能力。而“H100 x 32”是推荐配置能保证在满上下文128K下仍有良好性能。这里的差异主要在于KV Cache键值缓存的内存占用。上下文越长KV Cache越大对显存的要求呈线性增长。对于FP8版本所需GPU数量减半这得益于FP8精度将权重和KV Cache的显存占用都减少了约50%。因此GLM-4.5 FP8用8张H100就能达到接近BF16版用16张H100的效果和上下文支持能力。GLM-4.7-Flash的吸引力GLM-4.7-FlashBF16仅需1-2张H100这个门槛就低了很多。对于很多创业团队或中等规模的业务2张H100或同等算力的A100/A800的服务器是负担得起的。这意味着一台单机服务器就能部署一个能力接近顶级大模型的智能体服务部署复杂度和管理成本大大降低。非NVIDIA硬件支持官方文档也提到了对华为昇腾Ascend NPU通过xLLM框架和AMD GPU的支持。这对于有特定国产化或多元化硬件需求的团队是个好消息。不过相关生态和优化程度可能不如NVIDIA CUDA成熟需要投入更多调优精力。避坑指南显存估算与选型不要只看GPU数量要算显存。一张80GB显存的H100实际可用显存约76GB。以GLM-4.5355B-A32BBF16为例每个参数占2字节。仅模型权重就需要约710GB通过张量并行Tensor Parallelism分摊到16张卡每卡约44.4GB。这还没算上KV Cache、激活值等开销。因此16张H100是刚够加载。如果还要开大的批处理batch size或者用更长上下文就必须要更多卡或使用FP8。一个简单的公式所需GPU数量 ≈ 模型参数量以十亿计2BF16或 * 1FP8 / 单卡可用显存GB*。然后在此基础上为KV Cache和批处理留出至少20%-30%的余量。3. 实战部署从零搭建GLM推理服务理论说再多不如动手跑起来。这里我以部署GLM-4.7-FP8为例分享最常用的两种部署方式vLLM和SGLang。我会详细解释每个参数的意义以及我们在生产环境中遇到的典型问题和解决方案。3.1 环境准备与依赖安装首先你需要一台满足硬件要求的Linux服务器。假设你已经安装好了NVIDIA驱动、CUDA12.1和conda环境。# 1. 创建并激活conda环境 conda create -n glm-serving python3.10 -y conda activate glm-serving # 2. 安装PyTorch根据你的CUDA版本 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 3. 根据你的部署框架选择安装 # 方案A: 使用vLLM以速度快、生态好著称 pip install vllm # 方案B: 使用SGLang对GLM系列思考模式、PD-Disaggregation等特性支持更原生 pip install sglang[all] # 安装全部后端包括vLLM # 4. 其他可能需要的工具 pip install huggingface-hub # 用于从Hugging Face下载模型注意sglang[all]会安装一个较大的包如果网络或环境有问题可以尝试pip install sglang安装核心包再按需安装sglang[vllm]等子组件。3.2 使用vLLM部署服务vLLM以其高效的PagedAttention内存管理和开箱即用的OpenAI兼容API而广受欢迎。部署GLM-4.7需要一些特殊参数。# 这是一个启动GLM-4.7-FP8模型的示例命令 vllm serve zai-org/GLM-4.7-FP8 \ --tensor-parallel-size 4 \ # 张量并行度根据你的GPU数量调整。4表示将模型拆分到4张GPU上。 --speculative-config.method mtp \ # 使用MTPMixture-of-Thought Prediction推测解码加速推理 --speculative-config.num_speculative_tokens 1 \ # 推测解码的token数 --tool-call-parser glm47 \ # **关键**指定使用GLM-4.7的工具调用解析器 --reasoning-parser glm45 \ # 指定推理解析器4.7兼容4.5的解析器 --enable-auto-tool-choice \ # 启用自动工具选择模型可以决定何时调用哪个工具 --served-model-name glm-4.7-fp8 \ # 服务名称客户端连接时使用 --port 8000 # 服务端口默认为8000参数深度解析--tensor-parallel-size这是模型并行的核心参数。必须等于你用于承载模型的GPU数量。例如你有4张GPU就设为4。vLLM会自动将模型均匀切分到这些卡上。对于GLM-4.7-FP8官方推荐至少4张H100。--speculative-config.*推测解码是一种推理加速技术用一个小的“草案模型”提前生成多个token再由大模型快速验证。mtp是GLM系列支持的一种高效模式。开启后能显著提升生成速度尤其是长文本生成。--tool-call-parser glm47这是GLM-4.7专属参数必须正确设置。GLM-4.7的工具调用格式可能有细微调整使用正确的解析器才能正确识别和解析模型输出的工具调用JSON。--reasoning-parser glm45推理思考输出的解析器。GLM-4.7的思考模式增强但解析格式向后兼容GLM-4.5。--enable-auto-tool-choice强烈建议开启。它允许模型在对话中自主决定是否需要调用工具以及调用哪个工具。这是构建智能体的基础。服务启动后vLLM会提供一个完全兼容OpenAI API格式的接口/v1/chat/completions你可以用任何OpenAI SDK的客户端来调用它。3.3 使用SGLang部署服务SGLang是另一个高性能推理运行时它对GLM系列的原生支持非常好特别是对持久思考Preserved Thinking模式的支持目前是独家的。如果你要充分发挥GLM-4.7在复杂智能体任务上的优势SGLang是更好的选择。python3 -m sglang.launch_server \ --model-path zai-org/GLM-4.7-FP8 \ --tp-size 8 \ # 张量并行度这里示例用8卡 --tool-call-parser glm47 \ # 同样指定GLM-4.7工具解析器 --reasoning-parser glm45 \ --speculative-algorithm EAGLE \ # 使用EAGLE算法进行推测解码 --speculative-num-steps 3 \ --speculative-eagle-topk 1 \ --speculative-num-draft-tokens 4 \ # 草案token数影响加速比 --mem-fraction-static 0.8 \ # 为KV Cache静态预留80%的显存适合长上下文 --served-model-name glm-4.7-fp8 \ --host 0.0.0.0 \ --port 8000SGLang特有优势对思考模式的精细控制在请求时可以通过extra_body参数传递chat_template_kwargs来开启或关闭思考以及控制是否清除历史思考。{ messages: [...], chat_template_kwargs: { enable_thinking: true, clear_thinking: false // 设为false即启用“持久思考” } }PD-Disaggregation预填充-解码分离这是一个高级特性可以将推理过程拆分成“预填充”Prefill处理输入提示和“解码”Decode生成输出两个阶段并分配到不同的GPU组上执行。这能极大优化高并发场景下的资源利用率和吞吐量。官方给出了一个单机多卡的示例脚本这对于构建高负载的智能体API服务非常有价值。3.4 客户端调用示例与工具调用集成服务跑起来后我们来看看如何调用。这里以Python的openai库为例演示如何调用本地vLLM/SGLang服务并处理工具调用。import openai import json # 1. 配置客户端指向本地服务 client openai.OpenAI( api_keyno-key-required, # 本地部署通常不需要key base_urlhttp://localhost:8000/v1 # vLLM或SGLang的API地址 ) # 2. 定义工具列表OpenAI格式 tools [ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气, parameters: { type: object, properties: { location: { type: string, description: 城市名例如北京上海, }, unit: {type: string, enum: [celsius, fahrenheit]}, }, required: [location], }, }, }, # ... 可以定义更多工具 ] # 3. 发起对话请求并启用思考模式 response client.chat.completions.create( modelglm-4.7-fp8, # 与 --served-model-name 一致 messages[ {role: user, content: 北京今天天气怎么样} ], toolstools, tool_choiceauto, # 让模型自动决定是否调用工具 extra_body{ # SGLang特有参数vLLM可能部分支持 chat_template_kwargs: { enable_thinking: True, # 开启思考 clear_thinking: False # 持久思考仅SGLang完全支持 } }, streamFalse # 设为True可流式输出 ) # 4. 处理响应 message response.choices[0].message print(f模型回复: {message.content}) # 5. 检查是否有工具调用 if message.tool_calls: for tool_call in message.tool_calls: func_name tool_call.function.name func_args json.loads(tool_call.function.arguments) print(f模型要求调用工具: {func_name}, 参数: {func_args}) # 在这里你需要根据func_name执行相应的函数获取结果 # 例如weather_result get_current_weather(**func_args) # 6. 将工具执行结果返回给模型继续对话 second_response client.chat.completions.create( modelglm-4.7-fp8, messages[ {role: user, content: 北京今天天气怎么样}, message, # 包含工具调用的上一条消息 { role: tool, tool_call_id: tool_call.id, content: json.dumps(weather_result), # 工具执行结果 }, ], extra_body{chat_template_kwargs: {enable_thinking: True, clear_thinking: False}}, ) print(f模型结合工具结果后的回复: {second_response.choices[0].message.content})实操心得工具调用与思考模式工具描述要清晰工具函数的description和parameters的description至关重要。GLM系列模型对工具的理解能力很强清晰、无歧义的描述能极大提高调用准确率。善用tool_choice除了auto你还可以设置为none强制不调用工具或{type: function, function: {name: xxx}}强制调用特定工具。这在构建确定性的工作流时很有用。思考模式是双刃剑开启后模型会先输出|think|...|/think|格式的思考过程再输出最终内容或工具调用。这增加了可解释性但也增加了生成token数从而增加成本和延迟。对于简单查询建议关闭思考以提升响应速度对于复杂规划、数学推理或多步任务务必开启能显著提升成功率。持久思考的妙用在SGLang中将clear_thinking设为False后模型会在整个会话中累积思考。这对于调试一个复杂bug的对话非常有用模型不会忘记上一步的推理结论。你需要确保客户端在后续请求中传递完整的消息历史包括之前的思考块。4. 高级应用与性能调优指南部署起来只是第一步要让GLM系列模型在你的业务中发挥最大价值还需要一些高级技巧和调优手段。4.1 推理性能优化策略大模型推理是资源密集型任务优化目标通常是降低延迟Latency和提高吞吐量Throughput。批处理Batching这是提高吞吐量最有效的方法。将多个用户的请求打包成一个批次batch一起推理能大幅提升GPU计算单元的利用率。vLLM和SGLang都支持动态批处理Continuous Batching可以自动将不同长度的请求组合在一起。在vLLM中可以通过--max-num-batched-tokens或--max-num-seqs来限制批次大小平衡延迟和吞吐。在客户端如果你的应用场景允许如异步任务处理可以主动收集请求进行批量发送。推测解码Speculative Decoding如前所述GLM系列支持MTP/EAGLE等推测解码算法。这通常能带来1.5倍到3倍的生成速度提升且几乎不影响输出质量。在生产环境中强烈建议开启。你需要根据模型和硬件调整num_speculative_tokens等参数找到一个速度和内存占用的平衡点。量化与精度再次强调FP8版本是你的朋友。在效果损失可接受的前提下它能直接让硬件需求减半。对于GLM-4.7-Flash这种轻量模型甚至可以考虑INT4/INT8量化以进一步降低部署门槛但需要仔细评估精度损失。KV Cache量化与分页vLLM的PagedAttention和SGLang的类似机制能高效管理变长序列的KV Cache避免内存碎片。确保你使用的版本支持这些特性。4.2 构建复杂智能体工作流GLM-4.7的持久思考特性为构建鲁棒的、多轮次复杂智能体打开了新的大门。一个典型的智能体工作流可能如下# 伪代码展示一个结合规划、工具调用、代码执行的智能体循环 class CodingAgent: def __init__(self, llm_client): self.client llm_client self.conversation_history [] self.thinking_context None # 用于保存持久思考的上下文 def solve_issue(self, issue_description): # 第一轮规划与拆解 plan_prompt f你是一个资深程序员。请分析以下问题并制定一个分步解决计划 问题{issue_description} 请一步步思考并输出你的计划。 plan_response self.client.chat.completions.create( modelglm-4.7-fp8, messages[{role: user, content: plan_prompt}], extra_body{chat_template_kwargs: {enable_thinking: True, clear_thinking: False}} ) plan plan_response.choices[0].message.content self._update_history(plan_response) # 保存历史和思考上下文 # 根据计划循环执行每一步 for step in self._parse_plan(plan): if step.type write_code: # 调用代码生成工具或直接让模型生成 code_response self.client.chat.completions.create(...) generated_code code_response.choices[0].message.content # 执行生成的代码在沙箱中 execution_result safe_execute(generated_code) # 将执行结果反馈给模型进行下一轮 self._update_history_with_result(execution_result) elif step.type search_web: # 调用搜索工具 search_result call_search_tool(step.query) self._update_history_with_result(search_result) # ... 处理其他类型的步骤 # 最终总结 final_response self.client.chat.completions.create(...) return final_response.choices[0].message.content def _update_history(self, response): 更新对话历史并保存思考上下文对于SGLang self.conversation_history.append(response.choices[0].message) # 如果是SGLang并且开启了持久思考可能需要传递一个特殊的session_id或上下文句柄 # 在实际中这可能需要使用SGLang的stateful API在这个工作流中持久思考确保了模型在“写代码-执行-报错-调试”这个长循环中不会忘记最初的问题分析和中间每一步的推理逻辑从而能更连贯、更准确地解决问题。4.3 微调Fine-tuning考量虽然GLM-4.5/6/7已经是能力极强的通用模型但在特定垂直领域如法律、医疗、金融或者需要固化某种特定风格或流程时微调仍然是必要的。微调框架官方推荐使用LLaMA-Factory或SwiftModelScope。这两个框架都对GLM系列有良好的支持且集成了LoRA、QLoRA等参数高效微调技术能大幅降低微调所需的显存。硬件需求微调比推理需要更多的显存因为它要保存优化器状态和梯度。官方给出的参考配置如GLM-4.5用16张H100做LoRA是针对全参数微调或特定配置的。对于大多数场景使用QLoRA在2-4张A100/H100上微调GLM-4.5-Air是可行的。数据准备智能体微调的数据格式很关键。你需要准备(指令 思考过程 行动/回复)这样的三元组数据。思考过程可以先用基础模型生成再进行人工修正和润色。高质量的“思考-行动”配对数据是微调出强大领域智能体的关键。注意事项微调可能会影响模型原有的通用能力和安全性。务必在微调后进行全面评估包括通用能力测试、安全性测试以及你的特定领域任务测试。5. 常见问题排查与实战经验录在实际使用中你肯定会遇到各种各样的问题。这里我总结了一些高频问题和解决方法。5.1 部署与启动问题问题现象可能原因解决方案模型加载失败提示OutOfMemoryError1. GPU显存不足。2. 张量并行度(--tp-size)设置错误。3. 未使用FP8版本但硬件不够。1. 使用nvidia-smi确认显存。尝试减小--max-model-len上下文长度或--gpu-memory-utilization。2. 确保--tp-size等于你实际用于加载模型的GPU数量。3. 换用FP8量化模型或使用更小的模型如4.5-Air, 4.7-Flash。服务启动后API调用返回404或连接错误1. 服务未成功启动。2. 端口被占用或防火墙阻止。3. 客户端连接的URL或端口错误。1. 检查服务日志是否有错误。确保vllm serve或sglang命令成功运行并进入等待请求状态。2. 使用netstat -tlnp检查端口占用更换端口或关闭冲突进程。3. 确认客户端base_url为http://服务器IP:端口/v1。工具调用不被识别返回普通文本1. 启动命令中未设置--tool-call-parser glm47对于4.7。2. 工具描述格式不符合OpenAI规范。3. 模型在生成时未触发工具调用逻辑。1.对于GLM-4.7必须添加--tool-call-parser glm47。2. 严格检查tools参数中的JSON格式确保type,function,name,parameters等字段正确。3. 在请求中确保tool_choice不为none并检查用户指令是否足够明确以触发工具使用。5.2 模型推理与效果问题问题现象可能原因解决方案生成速度非常慢1. 未开启推测解码。2. 上下文长度设置过长KV Cache巨大。3. 批处理大小太小GPU利用率低。4. 输入提示prompt过于复杂。1. 确保启动参数中包含了推测解码配置--speculative-...。2. 根据实际需要调整--max-model-len。3. 增加批处理大小如果请求量大。4. 优化prompt减少不必要的指令和上下文。模型“胡言乱语”或格式错误1. 温度temperature设置过高。2. 重复惩罚repetition_penalty设置过低。3. 在需要严格格式如JSON、代码的任务中未使用合适的约束解码。1. 对于确定性任务工具调用、代码生成将temperature设为0或接近0如0.1。2. 适当提高repetition_penalty如1.1。3. 使用vLLM/SGLang的guided_json或regex等约束生成功能强制输出格式。持久思考模式不生效SGLang1.clear_thinking参数未正确传递或设置为true。2. 未在后续请求中传递完整的会话历史。3. 客户端未正确处理和传递SGLang返回的思考上下文。1. 确认请求的extra_body中包含chat_template_kwargs: {enable_thinking: True, clear_thinking: False}。2. 确保每次请求的messages数组包含之前所有的用户消息、助手消息含思考和工具消息。3. SGLang可能需要使用有状态的会话API来维护上下文查阅最新文档。5.3 成本与资源管理监控GPU使用率使用nvtop或gpustat实时监控。理想的推理服务GPU计算单元SM利用率应在50%以上显存使用稳定。如果利用率低可能是批处理大小不足或请求间隔不均。动态伸缩对于云部署可以根据请求队列长度自动伸缩服务实例。Kubernetes 自定义指标如请求延迟是实现自动伸缩的常用方案。缓存层对于频繁出现的、结果确定的查询如某些知识问答可以在模型服务前加一层缓存如Redis直接返回缓存结果大幅降低模型调用成本和延迟。最后我想分享一点个人体会。GLM-4.7的“持久思考”特性是我近期测试过的开源模型中最令人兴奋的功能之一。它不仅仅是一个技术指标上的提升更是改变了我们设计智能体系统的范式。以前我们需要在外部用代码费力地维护“状态”和“记忆”现在模型内部就能更优雅地处理一部分。这让我们能将更多精力放在定义任务、设计工具和优化用户体验上而不是绞尽脑汁解决模型“遗忘”的问题。当然它也对我们的工程实现提出了新要求比如如何高效地管理这些带思考的会话状态。但无论如何这无疑是朝着更强大、更实用的AI智能体迈出的坚实一步。如果你正在这个领域探索强烈建议你亲自部署体验一下GLM-4.7特别是结合SGLang的持久思考模式去构建一个能真正“深思熟虑”的AI助手。