尧图网站建设 
LiteRT-LM 中 Qwen 2.5 的 Chat Template 与模型元数据配置深度解析【免费下载链接】LiteRT-LMLiteRT-LM is Googles production-ready, high-performance, open-source inference framework for deploying Large Language Models on edge devices.项目地址: https://gitcode.com/GitHub_Trending/li/LiteRT-LMLiteRT-LM 在 models/qwen2_5/ 目录下为 Qwen 2.5 模型家族提供了官方canonical的提示词模板Chat Template与模型元数据LlmMetadata配置。本文以该目录的 README.md 为骨架结合 chat_template.jinja、LlmMetadataProto.pbtext 及配套测试用例完整讲解这套模板的渲染规则、工具调用Tool Calling标准化格式、元数据字段含义以及如何通过 Bazel 测试验证模板与 golden 输出的一致性帮助你在端侧推理场景中正确使用并扩展 Qwen 2.5 的对话能力。一、目录结构与职责定位按照 LiteRT-LM 的模型配置规范每个受支持模型家族在 models/ 下拥有独立目录Qwen 2.5 目录内包含三类核心资产文件职责chat_template.jinja官方提示词模板基于 Jinja2 语法运行时由 Minijinja 密闭渲染负责将结构化对话轮次与工具声明转换成模型特定的提示词字符串LlmMetadataProto.pbtext模型元数据text-format protobuf描述起始/停止 token、采样参数、模型类型、是否支持函数调用并内嵌一份与chat_template.jinja内容一致的 Jinja 模板字符串BUILDBazel 构建配置通过chat_template_test宏把模板与元数据接入自动化测试这三者被统一约束为一致性关系LlmMetadataProto.pbtext中的jinja_prompt_template字段必须与chat_template.jinja逐字节一致否则测试会失败详见下文测试与验证章节。二、Chat Template 全流程逐段解析chat_template.jinja 共 68 行处理五类职责内容格式化宏、System/工具声明块、普通对话轮次、助手工具调用、工具响应合并。下面逐段说明。2.1format_content宏多模态内容归一化模板开头定义一个内容格式化宏用于把消息的content列表转成纯文本{%- macro format_content(content) -%} {%- for item in content -%} {%- if item[type] text -%} {{- item[text] -}} {%- elif item[type] tool_response -%} {%- if item[response] is mapping or item[response] is sequence -%} {{- item[response] | tojson -}} {%- else -%} {{- item[response] | string -}} {%- endif -%} {%- endif -%} {%- endfor -%} {%- endmacro -%}关键点仅处理text与tool_response两种 content parttool_response中的response若是 JSON 对象/数组则用内置tojson过滤器序列化若是标量则转字符串。这与 models/README.md 中content 是严格的多模态 part 列表的约定一致——纯文本也要包装为{type: text, text: ...}对象。模板对image、audio、video等 part 不输出文本Qwen 2.5 纯文本家族场景下通常不会出现因此这一实现是安全的。2.2 System 与工具声明块{%- set loop_messages messages[1:] if messages[0][role] system else messages -%} {#- Handle System/Tool Definitions Block -#} {%- if tools or messages[0][role] system -%} {{- |im_start|system\n -}} {%- if messages[0][role] system -%} {{- format_content(messages[0][content]) -}} {%- endif -%} {%- if tools -%} {%- if messages[0][role] system -%} {{- \n\n -}} {%- endif -%} {{- # Tools\n\nYou may call one or more functions to assist with the user query.\n\nYou are provided with function signatures within tools/tools XML tags:\ntools -}} {%- for tool in tools -%} {{- \n tool | tojson -}} {%- endfor -%} {{- \n/tools\n\nFor each function call, return a json object with function name and arguments within tool_call/tool_call XML tags:\ntool_call\n{\name\: function-name, \arguments\: args-json-object}\n/tool_call -}} {%- endif -%} {{- |im_end|\n -}} {%- endif -%}逻辑要点系统消息提前剥离若首条消息是system先取出其内容单独渲染成system角色开头的块并从后续循环中剔除messages[1:]保证系统提示只出现一次。工具签名注入当存在tools列表时每个工具声明通过tojson输出为单行 JSON整体包裹在tools.../toolsXML 标签内并附上一段固定的指令文本要求模型以tool_call内 JSON 对象的形式返回函数名与参数。这是 README 中Features Standardization第 1 点的落地实现。2.3 普通消息循环user / system / assistant{%- for message in loop_messages -%} {%- set content format_content(message[content]) -%} {%- if message[role] user or message[role] system -%} {{- |im_start| message[role] \n content |im_end|\n -}} {%- elif message[role] assistant -%} ... {%- elif message[role] tool -%} ... {%- endif -%} {%- endfor -%}Qwen 2.5 使用 ChatML 风格的分隔符每条消息以|im_start|{role}\n开头、|im_end|\n结尾。这一约定同时在元数据的prompt_templates中登记见第三节。2.4 助手工具调用tool_calls渲染{{- |im_start| message[role] \n content -}} {%- if message[tool_calls] -%} {%- for tool_call in message[tool_calls] -%} {%- if content or not loop.first -%} {{- \n -}} {%- endif -%} {%- set function tool_call[function] if function in tool_call else tool_call -%} {%- set args function[arguments] if function[arguments] is string else function[arguments] | tojson -%} {{- tool_call\n{name: function[name] , arguments: args }\n/tool_call -}} {%- endfor -%} {%- endif -%} {{- |im_end|\n -}}要点兼容两种tool_calls结构标准 OpenAI 风格含function子对象或扁平结构直接含name/arguments。arguments若已是 JSON 字符串则原样输出否则tojson序列化。每条工具调用渲染为一个tool_call.../tool_call块多条调用之间用换行分隔支持并行工具调用场景。2.5 工具响应合并到 user 角色{%- elif message[role] tool -%} {%- if loop.first or loop_messages[loop.index0 - 1][role] ! tool -%} {{- |im_start|user -}} {%- endif -%} {{- \ntool_response\n content \n/tool_response -}} {%- if loop.last or loop_messages[loop.index0 1][role] ! tool -%} {{- |im_end|\n -}} {%- endif -%} {%- endif -%}这是 README 中Multi-step tool responses are wrapped withintool_responsetags under thetoolrole的具体实现有两个巧妙设计连续tool消息合并相邻的多条tool响应会被折叠进同一个user块只有第一条前面输出|im_start|user最后一条后面才输出|im_end|避免碎片化的消息结构。角色映射最终渲染时tool响应统一以user角色承载内容外层包tool_response.../tool_response符合 Qwen 2.5 训练数据中工具结果由 user 转述的格式习惯。2.6 生成提示Generation Prompt{%- if add_generation_prompt -%} {{- |im_start|assistant\n -}} {%- endif -%}当add_generation_prompt为真时在末尾追加空的assistant起始块引导模型开始续写。该变量在 models/README.md 中登记为可选参数默认值为true。三、LlmMetadataProto.pbtext模型元数据逐字段详解LlmMetadataProto.pbtext 是对应 runtime/proto/llm_metadata.proto 中LlmMetadataProto消息的 text-format 实例头部注释明确标注了 proto 文件与消息类型。各字段含义如下字段值说明start_token\|endoftext\|序列起始 tokenstop_tokens\|im_end\|停止生成 token即 ChatML 消息结束符prompt_templates.userprefix\|im_start\|user\nsuffix\|im_end\|\n非 Jinja 路径下的 user 消息包装格式prompt_templates.modelprefix\|im_start\|assistant\nsuffix\|im_end\|\n非 Jinja 路径下的 assistant 消息包装格式sampler_paramsTOP_P类型k40p0.95temperature1.0默认采样策略top-p 采样p 值 0.95max_num_tokens4096单次推理最大生成长度默认值llm_model_typeqwen2p5 {}模型家族标记驱动引擎选择对应的计算/图执行路径supports_function_callingtrue声明该模型支持函数调用是启用工具链路的前提jinja_prompt_template整段模板字符串内嵌的 Jinja 模板与chat_template.jinja内容必须一致min_runtime_version0.18.0运行该模型配置所需的最低 LiteRT-LM 运行时版本两个值得注意的工程细节双轨模板机制元数据中既有结构化的prompt_templates简单 user/model 包装又有完整的jinja_prompt_template。运行时优先使用 Jinja 渲染复杂对话多轮、工具调用结构化模板则作为轻量兜底。为保证二者不会分叉测试会强制校验pbtext 内嵌模板 磁盘上的.jinja文件。supports_function_calling与模型类型qwen2p5类型 true声明共同构成工具调用能力的声明式契约引擎侧只有在元数据明确声明时才允许注入工具相关处理逻辑。四、Tool Calling 标准化格式速览结合 README 与 chat_template.jinja 的实现Qwen 2.5 在 LiteRT-LM 中的工具调用统一遵循以下三组 XML 标签约定工具签名声明放入 system 提示中的tools.../tools标签内每个工具以单行 JSONOpenAPI 风格表示如{type: function, function: {name: get_weather, description: Get current weather for a location., parameters: {type: object, properties: {location: {type: string, description: City name}}, required: [location]}}}助手函数调用以tool_call.../tool_call包裹 JSON 对象格式固定为{name: function-name, arguments: args-json-object}如tool_call {name: get_weather, arguments: {location: London}} /tool_call工具响应多步工具结果包裹在tool_response标签下最终承载于user角色消息中tool_response {location: London, temperature: 18C} /tool_response这套格式是模板硬编码的标准化指令模型在 system 提示中读到tools后会被引导输出严格匹配tool_call格式的 JSON从而被下游解析器稳定提取。五、输入消息结构渲染入口契约模板的输入由 LiteRT-LM 运行时构造顶层字段在 models/README.md 中给出正式定义字段类型说明messagesarray必填对话历史元素为消息对象toolsarray可选可用的工具函数声明列表enable_thinkingboolean可选是否让模型先输出推理过程add_generation_promptboolean可选是否追加模型轮次前缀默认truebos_tokenstring可选序列起始 token如bos、s消息对象的核心角色有四种system系统指令、人格与工具 schema、user用户提问、assistant模型回复可含tool_calls、tool工具执行结果content 中为tool_responsepart。arguments既可以是 JSON 对象也可以是序列化 JSON 字符串当存在tool_calls时content允许为空。六、测试与验证如何证明模板正确6.1 BUILD 中的测试接线models/qwen2_5/BUILD 通过chat_template_test宏生成测试目标load(//models:chat_template_test.bzl, chat_template_test) exports_files([ chat_template.jinja, LlmMetadataProto.pbtext, ]) chat_template_test( name chat_template_test, chat_template chat_template.jinja, pbtext_files [LlmMetadataProto.pbtext], )pbtext_files的传入意味着测试还会校验元数据内嵌模板与磁盘模板的一致性见 chat_template_test.bzl 的参数说明。6.2 测试用例与 golden 输出Qwen 2.5 提供了三组测试输入位于 testdata/input/system_instruction.json带系统指令的普通多轮对话验证|im_start|system块的渲染tools.json完整工具链路声明工具 → 两次工具调用 → 两次工具响应 → 最终文本回复验证并行/多步工具调用tool_response_ending.json以工具响应结尾的对话验证相邻 tool 消息合并进单个 user 块的边界行为。每组输入在 testdata/golden/ 下有两个期望输出*.txt普通模式与*-thinking.txtthinking 模式。以 tools.txt 为例其渲染结果完整展示了# Tools声明块、tools签名、tool_call调用、tool_response结果合并以及末尾的|im_start|assistant生成提示。6.3 测试运行器的工作原理models/chat_template_test_runner.cc 是测试的可执行主体其关键流程读取--chat_template、--input_dir、--golden_dir等命令行参数另支持--update_golden更新 golden、--pbtext_files校验元数据、--mirror_chat_templates校验镜像模板用runtime/components/prompt_template.h提供的PromptTemplate构造模板对象并调用Apply()渲染每个输入 JSON每个输入同时以enable_thinkingfalse/true两种模式渲染若存在对应 thinking golden 文件则一并比对逐字符比对渲染结果与 golden 文件EXPECT_EQ不匹配即报告输入/输出/golden 三路信息最后解析各pbtext文件中的jinja_prompt_template字段与磁盘模板逐字节比对。运行全部模型家族的模板测试只需bazel test //models/...新增测试用例时只需在testdata/input/放入输入 JSON、在testdata/golden/放入期望文本或先以--update_golden生成无需改动 C 代码。七、在推理流程中的位置与扩展建议从源码结构看这套模板与元数据在 LiteRT-LM 推理链路中的定位可以概括为运行时将多轮会话含工具声明与执行结果整理为messages/tools结构经PromptTemplate渲染为模型输入文本引擎依据LlmMetadataProto中的停止 token、采样参数与模型类型执行生成并通过supports_function_calling决定是否启用工具解析与执行回路。若你要为其他 Qwen 2.5 变体如更长上下文、带思考模式的版本复用此配置建议保持chat_template.jinja与jinja_prompt_template的镜像关系不变仅调整max_num_tokens、sampler_params、stop_tokens等生成相关字段并为本目录补齐对应的 testdata 用例确保任何改动都经过 golden 回归验证。【免费下载链接】LiteRT-LMLiteRT-LM is Googles production-ready, high-performance, open-source inference framework for deploying Large Language Models on edge devices.项目地址: https://gitcode.com/GitHub_Trending/li/LiteRT-LM创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LiteRT-LM 中 Qwen 2.5 的 Chat Template 与模型元数据配置深度解析
LiteRT-LM 中 Qwen 2.5 的 Chat Template 与模型元数据配置深度解析【免费下载链接】LiteRT-LMLiteRT-LM is Googles production-ready, high-performance, open-source inference framework for deploying Large Language Models on edge devices.项目地址: https://gitcode.com/GitHub_Trending/li/LiteRT-LMLiteRT-LM 在 models/qwen2_5/ 目录下为 Qwen 2.5 模型家族提供了官方canonical的提示词模板Chat Template与模型元数据LlmMetadata配置。本文以该目录的 README.md 为骨架结合 chat_template.jinja、LlmMetadataProto.pbtext 及配套测试用例完整讲解这套模板的渲染规则、工具调用Tool Calling标准化格式、元数据字段含义以及如何通过 Bazel 测试验证模板与 golden 输出的一致性帮助你在端侧推理场景中正确使用并扩展 Qwen 2.5 的对话能力。一、目录结构与职责定位按照 LiteRT-LM 的模型配置规范每个受支持模型家族在 models/ 下拥有独立目录Qwen 2.5 目录内包含三类核心资产文件职责chat_template.jinja官方提示词模板基于 Jinja2 语法运行时由 Minijinja 密闭渲染负责将结构化对话轮次与工具声明转换成模型特定的提示词字符串LlmMetadataProto.pbtext模型元数据text-format protobuf描述起始/停止 token、采样参数、模型类型、是否支持函数调用并内嵌一份与chat_template.jinja内容一致的 Jinja 模板字符串BUILDBazel 构建配置通过chat_template_test宏把模板与元数据接入自动化测试这三者被统一约束为一致性关系LlmMetadataProto.pbtext中的jinja_prompt_template字段必须与chat_template.jinja逐字节一致否则测试会失败详见下文测试与验证章节。二、Chat Template 全流程逐段解析chat_template.jinja 共 68 行处理五类职责内容格式化宏、System/工具声明块、普通对话轮次、助手工具调用、工具响应合并。下面逐段说明。2.1format_content宏多模态内容归一化模板开头定义一个内容格式化宏用于把消息的content列表转成纯文本{%- macro format_content(content) -%} {%- for item in content -%} {%- if item[type] text -%} {{- item[text] -}} {%- elif item[type] tool_response -%} {%- if item[response] is mapping or item[response] is sequence -%} {{- item[response] | tojson -}} {%- else -%} {{- item[response] | string -}} {%- endif -%} {%- endif -%} {%- endfor -%} {%- endmacro -%}关键点仅处理text与tool_response两种 content parttool_response中的response若是 JSON 对象/数组则用内置tojson过滤器序列化若是标量则转字符串。这与 models/README.md 中content 是严格的多模态 part 列表的约定一致——纯文本也要包装为{type: text, text: ...}对象。模板对image、audio、video等 part 不输出文本Qwen 2.5 纯文本家族场景下通常不会出现因此这一实现是安全的。2.2 System 与工具声明块{%- set loop_messages messages[1:] if messages[0][role] system else messages -%} {#- Handle System/Tool Definitions Block -#} {%- if tools or messages[0][role] system -%} {{- |im_start|system\n -}} {%- if messages[0][role] system -%} {{- format_content(messages[0][content]) -}} {%- endif -%} {%- if tools -%} {%- if messages[0][role] system -%} {{- \n\n -}} {%- endif -%} {{- # Tools\n\nYou may call one or more functions to assist with the user query.\n\nYou are provided with function signatures within tools/tools XML tags:\ntools -}} {%- for tool in tools -%} {{- \n tool | tojson -}} {%- endfor -%} {{- \n/tools\n\nFor each function call, return a json object with function name and arguments within tool_call/tool_call XML tags:\ntool_call\n{\name\: function-name, \arguments\: args-json-object}\n/tool_call -}} {%- endif -%} {{- |im_end|\n -}} {%- endif -%}逻辑要点系统消息提前剥离若首条消息是system先取出其内容单独渲染成system角色开头的块并从后续循环中剔除messages[1:]保证系统提示只出现一次。工具签名注入当存在tools列表时每个工具声明通过tojson输出为单行 JSON整体包裹在tools.../toolsXML 标签内并附上一段固定的指令文本要求模型以tool_call内 JSON 对象的形式返回函数名与参数。这是 README 中Features Standardization第 1 点的落地实现。2.3 普通消息循环user / system / assistant{%- for message in loop_messages -%} {%- set content format_content(message[content]) -%} {%- if message[role] user or message[role] system -%} {{- |im_start| message[role] \n content |im_end|\n -}} {%- elif message[role] assistant -%} ... {%- elif message[role] tool -%} ... {%- endif -%} {%- endfor -%}Qwen 2.5 使用 ChatML 风格的分隔符每条消息以|im_start|{role}\n开头、|im_end|\n结尾。这一约定同时在元数据的prompt_templates中登记见第三节。2.4 助手工具调用tool_calls渲染{{- |im_start| message[role] \n content -}} {%- if message[tool_calls] -%} {%- for tool_call in message[tool_calls] -%} {%- if content or not loop.first -%} {{- \n -}} {%- endif -%} {%- set function tool_call[function] if function in tool_call else tool_call -%} {%- set args function[arguments] if function[arguments] is string else function[arguments] | tojson -%} {{- tool_call\n{name: function[name] , arguments: args }\n/tool_call -}} {%- endfor -%} {%- endif -%} {{- |im_end|\n -}}要点兼容两种tool_calls结构标准 OpenAI 风格含function子对象或扁平结构直接含name/arguments。arguments若已是 JSON 字符串则原样输出否则tojson序列化。每条工具调用渲染为一个tool_call.../tool_call块多条调用之间用换行分隔支持并行工具调用场景。2.5 工具响应合并到 user 角色{%- elif message[role] tool -%} {%- if loop.first or loop_messages[loop.index0 - 1][role] ! tool -%} {{- |im_start|user -}} {%- endif -%} {{- \ntool_response\n content \n/tool_response -}} {%- if loop.last or loop_messages[loop.index0 1][role] ! tool -%} {{- |im_end|\n -}} {%- endif -%} {%- endif -%}这是 README 中Multi-step tool responses are wrapped withintool_responsetags under thetoolrole的具体实现有两个巧妙设计连续tool消息合并相邻的多条tool响应会被折叠进同一个user块只有第一条前面输出|im_start|user最后一条后面才输出|im_end|避免碎片化的消息结构。角色映射最终渲染时tool响应统一以user角色承载内容外层包tool_response.../tool_response符合 Qwen 2.5 训练数据中工具结果由 user 转述的格式习惯。2.6 生成提示Generation Prompt{%- if add_generation_prompt -%} {{- |im_start|assistant\n -}} {%- endif -%}当add_generation_prompt为真时在末尾追加空的assistant起始块引导模型开始续写。该变量在 models/README.md 中登记为可选参数默认值为true。三、LlmMetadataProto.pbtext模型元数据逐字段详解LlmMetadataProto.pbtext 是对应 runtime/proto/llm_metadata.proto 中LlmMetadataProto消息的 text-format 实例头部注释明确标注了 proto 文件与消息类型。各字段含义如下字段值说明start_token\|endoftext\|序列起始 tokenstop_tokens\|im_end\|停止生成 token即 ChatML 消息结束符prompt_templates.userprefix\|im_start\|user\nsuffix\|im_end\|\n非 Jinja 路径下的 user 消息包装格式prompt_templates.modelprefix\|im_start\|assistant\nsuffix\|im_end\|\n非 Jinja 路径下的 assistant 消息包装格式sampler_paramsTOP_P类型k40p0.95temperature1.0默认采样策略top-p 采样p 值 0.95max_num_tokens4096单次推理最大生成长度默认值llm_model_typeqwen2p5 {}模型家族标记驱动引擎选择对应的计算/图执行路径supports_function_callingtrue声明该模型支持函数调用是启用工具链路的前提jinja_prompt_template整段模板字符串内嵌的 Jinja 模板与chat_template.jinja内容必须一致min_runtime_version0.18.0运行该模型配置所需的最低 LiteRT-LM 运行时版本两个值得注意的工程细节双轨模板机制元数据中既有结构化的prompt_templates简单 user/model 包装又有完整的jinja_prompt_template。运行时优先使用 Jinja 渲染复杂对话多轮、工具调用结构化模板则作为轻量兜底。为保证二者不会分叉测试会强制校验pbtext 内嵌模板 磁盘上的.jinja文件。supports_function_calling与模型类型qwen2p5类型 true声明共同构成工具调用能力的声明式契约引擎侧只有在元数据明确声明时才允许注入工具相关处理逻辑。四、Tool Calling 标准化格式速览结合 README 与 chat_template.jinja 的实现Qwen 2.5 在 LiteRT-LM 中的工具调用统一遵循以下三组 XML 标签约定工具签名声明放入 system 提示中的tools.../tools标签内每个工具以单行 JSONOpenAPI 风格表示如{type: function, function: {name: get_weather, description: Get current weather for a location., parameters: {type: object, properties: {location: {type: string, description: City name}}, required: [location]}}}助手函数调用以tool_call.../tool_call包裹 JSON 对象格式固定为{name: function-name, arguments: args-json-object}如tool_call {name: get_weather, arguments: {location: London}} /tool_call工具响应多步工具结果包裹在tool_response标签下最终承载于user角色消息中tool_response {location: London, temperature: 18C} /tool_response这套格式是模板硬编码的标准化指令模型在 system 提示中读到tools后会被引导输出严格匹配tool_call格式的 JSON从而被下游解析器稳定提取。五、输入消息结构渲染入口契约模板的输入由 LiteRT-LM 运行时构造顶层字段在 models/README.md 中给出正式定义字段类型说明messagesarray必填对话历史元素为消息对象toolsarray可选可用的工具函数声明列表enable_thinkingboolean可选是否让模型先输出推理过程add_generation_promptboolean可选是否追加模型轮次前缀默认truebos_tokenstring可选序列起始 token如bos、s消息对象的核心角色有四种system系统指令、人格与工具 schema、user用户提问、assistant模型回复可含tool_calls、tool工具执行结果content 中为tool_responsepart。arguments既可以是 JSON 对象也可以是序列化 JSON 字符串当存在tool_calls时content允许为空。六、测试与验证如何证明模板正确6.1 BUILD 中的测试接线models/qwen2_5/BUILD 通过chat_template_test宏生成测试目标load(//models:chat_template_test.bzl, chat_template_test) exports_files([ chat_template.jinja, LlmMetadataProto.pbtext, ]) chat_template_test( name chat_template_test, chat_template chat_template.jinja, pbtext_files [LlmMetadataProto.pbtext], )pbtext_files的传入意味着测试还会校验元数据内嵌模板与磁盘模板的一致性见 chat_template_test.bzl 的参数说明。6.2 测试用例与 golden 输出Qwen 2.5 提供了三组测试输入位于 testdata/input/system_instruction.json带系统指令的普通多轮对话验证|im_start|system块的渲染tools.json完整工具链路声明工具 → 两次工具调用 → 两次工具响应 → 最终文本回复验证并行/多步工具调用tool_response_ending.json以工具响应结尾的对话验证相邻 tool 消息合并进单个 user 块的边界行为。每组输入在 testdata/golden/ 下有两个期望输出*.txt普通模式与*-thinking.txtthinking 模式。以 tools.txt 为例其渲染结果完整展示了# Tools声明块、tools签名、tool_call调用、tool_response结果合并以及末尾的|im_start|assistant生成提示。6.3 测试运行器的工作原理models/chat_template_test_runner.cc 是测试的可执行主体其关键流程读取--chat_template、--input_dir、--golden_dir等命令行参数另支持--update_golden更新 golden、--pbtext_files校验元数据、--mirror_chat_templates校验镜像模板用runtime/components/prompt_template.h提供的PromptTemplate构造模板对象并调用Apply()渲染每个输入 JSON每个输入同时以enable_thinkingfalse/true两种模式渲染若存在对应 thinking golden 文件则一并比对逐字符比对渲染结果与 golden 文件EXPECT_EQ不匹配即报告输入/输出/golden 三路信息最后解析各pbtext文件中的jinja_prompt_template字段与磁盘模板逐字节比对。运行全部模型家族的模板测试只需bazel test //models/...新增测试用例时只需在testdata/input/放入输入 JSON、在testdata/golden/放入期望文本或先以--update_golden生成无需改动 C 代码。七、在推理流程中的位置与扩展建议从源码结构看这套模板与元数据在 LiteRT-LM 推理链路中的定位可以概括为运行时将多轮会话含工具声明与执行结果整理为messages/tools结构经PromptTemplate渲染为模型输入文本引擎依据LlmMetadataProto中的停止 token、采样参数与模型类型执行生成并通过supports_function_calling决定是否启用工具解析与执行回路。若你要为其他 Qwen 2.5 变体如更长上下文、带思考模式的版本复用此配置建议保持chat_template.jinja与jinja_prompt_template的镜像关系不变仅调整max_num_tokens、sampler_params、stop_tokens等生成相关字段并为本目录补齐对应的 testdata 用例确保任何改动都经过 golden 回归验证。【免费下载链接】LiteRT-LMLiteRT-LM is Googles production-ready, high-performance, open-source inference framework for deploying Large Language Models on edge devices.项目地址: https://gitcode.com/GitHub_Trending/li/LiteRT-LM创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考