LiteRT-LM 中 Liquid AI LFM 模型家族的提示词模板与元数据配置指南【免费下载链接】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本文以 LiteRT-LM 仓库中 models/lfm2 目录为骨架系统讲解 Liquid AI LFMLiquid Foundation Model系列模型如 LFM 2.5 1.2B Instruct / Thinking在 LiteRT-LM 中的落地方式包括规范的 Chat 提示词模板chat_template.jinja、工具调用Tool Calling的格式化约定、思考模式Thinking的通道设计以及LlmMetadataProto.pbtext元数据中每个配置字段的含义与取值。读完本文你将能够理解并复用这套 Canonical 配置把 LFM 模型正确接入 LiteRT-LM 的会话、工具调用与推理流程。一、LFM 配置的定位Canonical 模板 元数据在 LiteRT-LM 仓库中每个受支持的模型家族都有一个专门的目录用于存放官方标准Canonical的提示词模板与模型元数据。models/lfm2/README.md 明确指出该目录承载的是 Liquid AI LFM 家族的 Canonical 配置即chat_template.jinjaLFM 家族的规范 Chat 提示词模板用于把messages、tools等结构化对话数据渲染为模型真正见到的 token 序列LlmMetadataProto.pbtext模型元数据TextFormat 形式的LlmMetadataProto描述起止 token、采样参数、最大 token 数、模型类型、是否支持思考/函数调用、思考通道定义等。两者的关系在 models/lfm2/BUILD 中一目了然该文件将两个文件通过exports_files对外暴露并通过chat_template_test宏建立测试目标其中pbtext_files [LlmMetadataProto.pbtext]专门用于校验 pbtext 中内嵌的jinja_prompt_template与chat_template.jinja完全一致防止两份配置漂移。从元数据协议层面看LlmMetadataProto的定义位于 runtime/proto/llm_metadata.proto它包含start_token、stop_tokens、prompt_templates、sampler_params、max_num_tokens、llm_model_type、jinja_prompt_template、channels、supports_thinking、supports_function_calling等字段。LFM 的配置正是对该 proto 的一个具体实例。二、Chat Template 的标准化设计2.1 角色标记与 BOS TokenLFM 的提示词模板在结构上遵循 ChatML 风格并做了如下标准化见 models/lfm2/README.md 的 Features Standardization 一节BOS Token 前置模板在提示词最开头无条件输出{{- bos_token -}}即|startoftext|角色分隔符使用|im_start|与|im_end|包裹每一轮消息支持system、user、assistant、tool四种角色生成提示符当add_generation_prompt为真时在末尾追加一个空的|im_start|assistant\n告诉模型接下来该它回答。2.2 模板的渲染流程源码拆解完整实现见 models/lfm2/chat_template.jinja其渲染逻辑由三个宏与主渲染段组成format_content(content)遍历消息content数组对type text的项原样输出文本对type tool_response的项若response是对象/数组则用tojson序列化否则转为字符串format_tool_content(content)把多个工具响应项格式化后用,拼接并统一包裹在方括号[...]中若拼接结果本身已带方括号则不再重复包裹对应 tool 角色的输出格式render_tool_calls(tool_calls)把 assistant 的工具调用声明渲染为 Python 风格调用例如get_weather(locationLondon)多个调用用,连接后放入|tool_call_start|[...]|tool_call_end|之间。主渲染段的关键逻辑如下{{- bos_token -}} {%- set is_first_system messages[0][role] system -%} {%- set loop_messages messages[1:] if is_first_system else messages -%} {%- set system_content format_content(messages[0][content]) ... -%} {%- if tools -%} {%- set tools_block List of tools: [ (tools_ns.tool_strings | join(, )) ] -%} ... {%- endif -%} {%- for message in loop_messages -%} {%- if message[role] assistant -%} {{- |im_start|assistant\n -}} {%- if message[tool_calls] -%}{{- render_tool_calls(message[tool_calls]) -}}{%- endif -%} {{- format_content(message[content]) -}}{{- |im_end|\n -}} {%- elif message[role] tool -%} {{- |im_start|tool\n format_tool_content(message[content]) |im_end|\n -}} {%- else -%} {{- |im_start| message[role] \n format_content(message[content]) |im_end|\n -}} {%- endif -%} {%- endfor -%} {%- if add_generation_prompt -%}{{- |im_start|assistant\n -}}{%- endif -%}几个值得注意的实现细节首条 system 消息被特殊处理若messages[0]是 system 角色它会被移出循环单独渲染从而允许把工具声明List of tools: [...]追加到 system 内容之后assistant 消息支持 tool_calls 与文本共存先渲染工具调用声明再渲染普通文本内容工具声明放在 system 轮内这正是 README 中Function/tool signatures are enclosed inList of tools: [...]within the|im_start|systemturn的实现来源。2.3 一个完整的普通对话渲染示例以 models/lfm2/testdata/input/system_instruction.json 为输入含 system 指令、两轮 user/assistant 对话、add_generation_prompt: true、bos_token: |startoftext|模板渲染出的规范输出与 models/lfm2/testdata/golden/system_instruction.txt 完全一致|startoftext||im_start|system You are a helpful assistant.|im_end| |im_start|user Hello!|im_end| |im_start|assistant Hello! How can I help you today?|im_end| |im_start|user What is the capital of France?|im_end| |im_start|assistant三、工具调用Tool Calling的格式化约定LFM 2.5 系列原生支持函数调用supports_function_calling: true其格式化约定分为三段均有源码与 golden 测试佐证。3.1 工具声明List of tools: [...]工具声明以标准 OpenAI 风格 JSON 形式注入 system 轮。以 models/lfm2/testdata/input/tools.json 中的get_weather工具为例其被渲染进 system 内容并整体包裹|im_start|system You are a helpful assistant. List of tools: [{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]}}}]|im_end|3.2 助手工具调用|tool_call_start|[...]|tool_call_end|assistant 发起的函数调用被格式化为 Python 风格调用表达式多个调用并列在同一对标签内见render_tool_calls宏参数以namevalue形式呈现对象/数组参数用 JSON 序列化。例如|im_start|assistant |tool_call_start|[get_weather(locationLondon)]|tool_call_end||im_end|3.3 工具输出|im_start|tool\n[...]|im_end|工具执行结果在tool角色下以 JSON 对象列表形式返回整体用方括号包裹对应format_tool_content宏的拼接与补括号逻辑|im_start|tool [{location: London, temperature: 18C}]|im_end|3.4 完整工具调用往返示例将上述三段组合起来得到 models/lfm2/testdata/golden/tools.txt 所展示的完整往返流程查询伦敦与巴黎两地天气两次调用、两次返回最后汇总为自然语言答案|startoftext||im_start|system You are a helpful assistant. List of tools: [{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]}}}]|im_end| |im_start|user What is the weather in London and Paris?|im_end| |im_start|assistant |tool_call_start|[get_weather(locationLondon)]|tool_call_end||im_end| |im_start|tool [{location: London, temperature: 18C}]|im_end| |im_start|assistant |tool_call_start|[get_weather(locationParis)]|tool_call_end||im_end| |im_start|tool [{location: Paris, temperature: 22C}]|im_end| |im_start|assistant 18C and 22C.|im_end| |im_start|user Thanks!|im_end| |im_start|assistant注意当输入消息以用户提问直接开头无 system 消息时工具声明同样会被渲染进第一个 system 轮参见 models/lfm2/testdata/golden/tool_response_ending.txt 及其输入 models/lfm2/testdata/input/tool_response_ending.json。四、思考模式Thinking与思考通道LFM 2.5 对思维链Chain-of-Thought的处理与其他模型不同README 中明确了三点约束不支持动态思考开关LFM 2.5 系列不支持通过enable_thinkingAPI 动态切换思考行为需要思考 → 选用 Thinking 变体使用专门的LiquidAI/LFM2.5-1.2B-Thinking模型模型会自行输出think与/thinktoken需要禁用思考 → 选用 Instruct 变体使用LiquidAI/LFM2.5-1.2B-Instruct模型并在元数据中将supports_thinking设为false。这一点在 models/lfm2/LlmMetadataProto.pbtext 中有明确的注释佐证# Note that LFM2.5 does not support dynamic thinking toggle. # # To enable thinking, use LFM2.5-1.2B-Thinking model. To disable thinking, use # LFM2.5-1.2B-Instruct model and set supports_thinking to false. supports_thinking: true与此同时pbtext 中通过channels定义了thought思考通道channels { channel_name: thought start: think end: /think }从 runtime/proto/llm_metadata.proto 的Channel消息定义可以看出通道机制的设计意图channel_name是通道内容在结果中的键名start/end标记通道文本的起止如think//think且当is_reasoning_channel为 true 时该通道的文本还会被复制到message[reasoning_content]。也就是说运行 Thinking 变体时LiteRT-LM 会依据该通道定义从输出流中剥离出思考内容并单独存放与应用可见的回复正文区分开。仓库中的 thinking 版 golden 文件system_instruction-thinking.txt、tools-thinking.txt用于验证带思考通道的模型配置同样走同一套渲染逻辑。五、LlmMetadataProto.pbtext 元数据逐字段解析models/lfm2/LlmMetadataProto.pbtext 是 LFM 模型接入 LiteRT-LM 时实际使用的元数据文件字段含义与LlmMetadataProto协议一一对应。逐字段说明如下字段取值含义与影响start_token.token_str|startoftext|输入序列开头附加的 BOS tokenstart_token类型为TokenUnion见 runtime/proto/token.protostop_tokens[].token_str|im_end|、|endoftext|判定输出流结束的停止 token命中任一即终止生成sampler_params.typeTOP_P默认采样策略为 Top-PNucleus Samplingsampler_params.k50采样候选集上限为 50 个 tokensampler_params.p1.0Top-P 概率阈值1.0 表示几乎不裁剪累积概率质量sampler_params.temperature0.1采样温度取值很低输出更确定、更贴近 argmax 行为max_num_tokens32768模型可处理的最大 token 数上下文上限对应 proto 中的int32 max_num_tokensllm_model_type.lfm2{}声明模型类型为 LFM2LlmModelType枚举见 runtime/proto/llm_model_type.protosupports_thinkingtrue声明模型支持思考/推理对 Instruct 变体需改为falsesupports_function_callingtrue声明模型支持函数调用/工具使用jinja_prompt_template内嵌完整模板字符串默认 Jinja 提示词模板内容与chat_template.jinja完全一致channels[0]thoughtthink//think定义思考通道的键名与起止标记其中jinja_prompt_template字段值得特别说明proto 注释runtime/proto/llm_metadata.proto指出若该字段未设置LiteRT-LM 会回退到prompt_templates字段非 Jinja 的角色前缀/后缀模板以保持向后兼容若两者都未设置则输入不会被 Jinja 格式化。LFM 采用直接内嵌 Jinja 模板这一优先路径把渲染逻辑完整打包进模型元数据运行时可独立于外部.jinja文件工作。而 BUILD 中的chat_template_test通过把chat_template.jinja与LlmMetadataProto.pbtext同时传给测试宏保证磁盘上的模板文件与元数据内嵌模板永不漂移。六、配置的验证机制golden 测试与测试宏为了确保模板渲染结果稳定可控LFM 配置随附了一套完整的 golden 测试数据与测试框架输入数据models/lfm2/testdata/input/ 下的三个 JSON 文件分别覆盖三种典型场景——含 system 指令的普通对话system_instruction.json、完整工具调用往返tools.json、无 system 消息的纯工具调用tool_response_ending.json期望输出models/lfm2/testdata/golden/ 下的六个.txt文件是对应渲染结果的 golden 文本并额外提供-thinking后缀版本用于验证思考通道配置下的渲染一致性测试宏models/chat_template_test.bzl 中的chat_template_testStarlark 宏接收chat_template、input_dir、golden_dir、pbtext_files、mirror_chat_templates等参数生成一个 C 测试目标遍历输入 JSON → 渲染模板 → 与 golden 文本逐字比对同时校验 pbtext 内嵌模板与外部模板一致、镜像模板完全等同测试运行器底层渲染与比对逻辑由 models/chat_template_test_runner.cc 实现测试目标通过--chat_template、--input_dir、--golden_dir、--pbtext_files等命令行参数驱动。这套机制意味着任何对chat_template.jinja或LlmMetadataProto.pbtext的修改都必须通过 golden 比对才能合入从工程上保证了 Canonical 配置的权威性与稳定性——这正是Canonical prompt templates and metadata configuration这一命名含义的落地体现。七、小结总结而言LFM 模型家族在 LiteRT-LM 中的接入由两个文件共同决定chat_template.jinja定义消息如何被格式化成 token 序列BOS 前置、ChatML 角色标记、工具调用声明与响应包装、生成提示符追加LlmMetadataProto.pbtext定义模型运行时行为起止 token、采样参数、上下文上限、模型类型、思考与函数调用开关、思考通道。两者通过jinja_prompt_template字段在运行时绑定通过 golden 测试在开发期约束。对于想要接入 LFM 2.5 系列模型的开发者可以直接复用 models/lfm2 目录下的这套配置Instruct 变体将supports_thinking置为falseThinking 变体保留true并依赖thought通道解析思考内容如需扩展工具则按List of tools: [...]|tool_call_start|[func(argval)]|tool_call_end|tool角色[...]的三段式约定组织对话即可。【免费下载链接】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 中 Liquid AI LFM 模型家族的提示词模板与元数据配置指南
LiteRT-LM 中 Liquid AI LFM 模型家族的提示词模板与元数据配置指南【免费下载链接】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本文以 LiteRT-LM 仓库中 models/lfm2 目录为骨架系统讲解 Liquid AI LFMLiquid Foundation Model系列模型如 LFM 2.5 1.2B Instruct / Thinking在 LiteRT-LM 中的落地方式包括规范的 Chat 提示词模板chat_template.jinja、工具调用Tool Calling的格式化约定、思考模式Thinking的通道设计以及LlmMetadataProto.pbtext元数据中每个配置字段的含义与取值。读完本文你将能够理解并复用这套 Canonical 配置把 LFM 模型正确接入 LiteRT-LM 的会话、工具调用与推理流程。一、LFM 配置的定位Canonical 模板 元数据在 LiteRT-LM 仓库中每个受支持的模型家族都有一个专门的目录用于存放官方标准Canonical的提示词模板与模型元数据。models/lfm2/README.md 明确指出该目录承载的是 Liquid AI LFM 家族的 Canonical 配置即chat_template.jinjaLFM 家族的规范 Chat 提示词模板用于把messages、tools等结构化对话数据渲染为模型真正见到的 token 序列LlmMetadataProto.pbtext模型元数据TextFormat 形式的LlmMetadataProto描述起止 token、采样参数、最大 token 数、模型类型、是否支持思考/函数调用、思考通道定义等。两者的关系在 models/lfm2/BUILD 中一目了然该文件将两个文件通过exports_files对外暴露并通过chat_template_test宏建立测试目标其中pbtext_files [LlmMetadataProto.pbtext]专门用于校验 pbtext 中内嵌的jinja_prompt_template与chat_template.jinja完全一致防止两份配置漂移。从元数据协议层面看LlmMetadataProto的定义位于 runtime/proto/llm_metadata.proto它包含start_token、stop_tokens、prompt_templates、sampler_params、max_num_tokens、llm_model_type、jinja_prompt_template、channels、supports_thinking、supports_function_calling等字段。LFM 的配置正是对该 proto 的一个具体实例。二、Chat Template 的标准化设计2.1 角色标记与 BOS TokenLFM 的提示词模板在结构上遵循 ChatML 风格并做了如下标准化见 models/lfm2/README.md 的 Features Standardization 一节BOS Token 前置模板在提示词最开头无条件输出{{- bos_token -}}即|startoftext|角色分隔符使用|im_start|与|im_end|包裹每一轮消息支持system、user、assistant、tool四种角色生成提示符当add_generation_prompt为真时在末尾追加一个空的|im_start|assistant\n告诉模型接下来该它回答。2.2 模板的渲染流程源码拆解完整实现见 models/lfm2/chat_template.jinja其渲染逻辑由三个宏与主渲染段组成format_content(content)遍历消息content数组对type text的项原样输出文本对type tool_response的项若response是对象/数组则用tojson序列化否则转为字符串format_tool_content(content)把多个工具响应项格式化后用,拼接并统一包裹在方括号[...]中若拼接结果本身已带方括号则不再重复包裹对应 tool 角色的输出格式render_tool_calls(tool_calls)把 assistant 的工具调用声明渲染为 Python 风格调用例如get_weather(locationLondon)多个调用用,连接后放入|tool_call_start|[...]|tool_call_end|之间。主渲染段的关键逻辑如下{{- bos_token -}} {%- set is_first_system messages[0][role] system -%} {%- set loop_messages messages[1:] if is_first_system else messages -%} {%- set system_content format_content(messages[0][content]) ... -%} {%- if tools -%} {%- set tools_block List of tools: [ (tools_ns.tool_strings | join(, )) ] -%} ... {%- endif -%} {%- for message in loop_messages -%} {%- if message[role] assistant -%} {{- |im_start|assistant\n -}} {%- if message[tool_calls] -%}{{- render_tool_calls(message[tool_calls]) -}}{%- endif -%} {{- format_content(message[content]) -}}{{- |im_end|\n -}} {%- elif message[role] tool -%} {{- |im_start|tool\n format_tool_content(message[content]) |im_end|\n -}} {%- else -%} {{- |im_start| message[role] \n format_content(message[content]) |im_end|\n -}} {%- endif -%} {%- endfor -%} {%- if add_generation_prompt -%}{{- |im_start|assistant\n -}}{%- endif -%}几个值得注意的实现细节首条 system 消息被特殊处理若messages[0]是 system 角色它会被移出循环单独渲染从而允许把工具声明List of tools: [...]追加到 system 内容之后assistant 消息支持 tool_calls 与文本共存先渲染工具调用声明再渲染普通文本内容工具声明放在 system 轮内这正是 README 中Function/tool signatures are enclosed inList of tools: [...]within the|im_start|systemturn的实现来源。2.3 一个完整的普通对话渲染示例以 models/lfm2/testdata/input/system_instruction.json 为输入含 system 指令、两轮 user/assistant 对话、add_generation_prompt: true、bos_token: |startoftext|模板渲染出的规范输出与 models/lfm2/testdata/golden/system_instruction.txt 完全一致|startoftext||im_start|system You are a helpful assistant.|im_end| |im_start|user Hello!|im_end| |im_start|assistant Hello! How can I help you today?|im_end| |im_start|user What is the capital of France?|im_end| |im_start|assistant三、工具调用Tool Calling的格式化约定LFM 2.5 系列原生支持函数调用supports_function_calling: true其格式化约定分为三段均有源码与 golden 测试佐证。3.1 工具声明List of tools: [...]工具声明以标准 OpenAI 风格 JSON 形式注入 system 轮。以 models/lfm2/testdata/input/tools.json 中的get_weather工具为例其被渲染进 system 内容并整体包裹|im_start|system You are a helpful assistant. List of tools: [{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]}}}]|im_end|3.2 助手工具调用|tool_call_start|[...]|tool_call_end|assistant 发起的函数调用被格式化为 Python 风格调用表达式多个调用并列在同一对标签内见render_tool_calls宏参数以namevalue形式呈现对象/数组参数用 JSON 序列化。例如|im_start|assistant |tool_call_start|[get_weather(locationLondon)]|tool_call_end||im_end|3.3 工具输出|im_start|tool\n[...]|im_end|工具执行结果在tool角色下以 JSON 对象列表形式返回整体用方括号包裹对应format_tool_content宏的拼接与补括号逻辑|im_start|tool [{location: London, temperature: 18C}]|im_end|3.4 完整工具调用往返示例将上述三段组合起来得到 models/lfm2/testdata/golden/tools.txt 所展示的完整往返流程查询伦敦与巴黎两地天气两次调用、两次返回最后汇总为自然语言答案|startoftext||im_start|system You are a helpful assistant. List of tools: [{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]}}}]|im_end| |im_start|user What is the weather in London and Paris?|im_end| |im_start|assistant |tool_call_start|[get_weather(locationLondon)]|tool_call_end||im_end| |im_start|tool [{location: London, temperature: 18C}]|im_end| |im_start|assistant |tool_call_start|[get_weather(locationParis)]|tool_call_end||im_end| |im_start|tool [{location: Paris, temperature: 22C}]|im_end| |im_start|assistant 18C and 22C.|im_end| |im_start|user Thanks!|im_end| |im_start|assistant注意当输入消息以用户提问直接开头无 system 消息时工具声明同样会被渲染进第一个 system 轮参见 models/lfm2/testdata/golden/tool_response_ending.txt 及其输入 models/lfm2/testdata/input/tool_response_ending.json。四、思考模式Thinking与思考通道LFM 2.5 对思维链Chain-of-Thought的处理与其他模型不同README 中明确了三点约束不支持动态思考开关LFM 2.5 系列不支持通过enable_thinkingAPI 动态切换思考行为需要思考 → 选用 Thinking 变体使用专门的LiquidAI/LFM2.5-1.2B-Thinking模型模型会自行输出think与/thinktoken需要禁用思考 → 选用 Instruct 变体使用LiquidAI/LFM2.5-1.2B-Instruct模型并在元数据中将supports_thinking设为false。这一点在 models/lfm2/LlmMetadataProto.pbtext 中有明确的注释佐证# Note that LFM2.5 does not support dynamic thinking toggle. # # To enable thinking, use LFM2.5-1.2B-Thinking model. To disable thinking, use # LFM2.5-1.2B-Instruct model and set supports_thinking to false. supports_thinking: true与此同时pbtext 中通过channels定义了thought思考通道channels { channel_name: thought start: think end: /think }从 runtime/proto/llm_metadata.proto 的Channel消息定义可以看出通道机制的设计意图channel_name是通道内容在结果中的键名start/end标记通道文本的起止如think//think且当is_reasoning_channel为 true 时该通道的文本还会被复制到message[reasoning_content]。也就是说运行 Thinking 变体时LiteRT-LM 会依据该通道定义从输出流中剥离出思考内容并单独存放与应用可见的回复正文区分开。仓库中的 thinking 版 golden 文件system_instruction-thinking.txt、tools-thinking.txt用于验证带思考通道的模型配置同样走同一套渲染逻辑。五、LlmMetadataProto.pbtext 元数据逐字段解析models/lfm2/LlmMetadataProto.pbtext 是 LFM 模型接入 LiteRT-LM 时实际使用的元数据文件字段含义与LlmMetadataProto协议一一对应。逐字段说明如下字段取值含义与影响start_token.token_str|startoftext|输入序列开头附加的 BOS tokenstart_token类型为TokenUnion见 runtime/proto/token.protostop_tokens[].token_str|im_end|、|endoftext|判定输出流结束的停止 token命中任一即终止生成sampler_params.typeTOP_P默认采样策略为 Top-PNucleus Samplingsampler_params.k50采样候选集上限为 50 个 tokensampler_params.p1.0Top-P 概率阈值1.0 表示几乎不裁剪累积概率质量sampler_params.temperature0.1采样温度取值很低输出更确定、更贴近 argmax 行为max_num_tokens32768模型可处理的最大 token 数上下文上限对应 proto 中的int32 max_num_tokensllm_model_type.lfm2{}声明模型类型为 LFM2LlmModelType枚举见 runtime/proto/llm_model_type.protosupports_thinkingtrue声明模型支持思考/推理对 Instruct 变体需改为falsesupports_function_callingtrue声明模型支持函数调用/工具使用jinja_prompt_template内嵌完整模板字符串默认 Jinja 提示词模板内容与chat_template.jinja完全一致channels[0]thoughtthink//think定义思考通道的键名与起止标记其中jinja_prompt_template字段值得特别说明proto 注释runtime/proto/llm_metadata.proto指出若该字段未设置LiteRT-LM 会回退到prompt_templates字段非 Jinja 的角色前缀/后缀模板以保持向后兼容若两者都未设置则输入不会被 Jinja 格式化。LFM 采用直接内嵌 Jinja 模板这一优先路径把渲染逻辑完整打包进模型元数据运行时可独立于外部.jinja文件工作。而 BUILD 中的chat_template_test通过把chat_template.jinja与LlmMetadataProto.pbtext同时传给测试宏保证磁盘上的模板文件与元数据内嵌模板永不漂移。六、配置的验证机制golden 测试与测试宏为了确保模板渲染结果稳定可控LFM 配置随附了一套完整的 golden 测试数据与测试框架输入数据models/lfm2/testdata/input/ 下的三个 JSON 文件分别覆盖三种典型场景——含 system 指令的普通对话system_instruction.json、完整工具调用往返tools.json、无 system 消息的纯工具调用tool_response_ending.json期望输出models/lfm2/testdata/golden/ 下的六个.txt文件是对应渲染结果的 golden 文本并额外提供-thinking后缀版本用于验证思考通道配置下的渲染一致性测试宏models/chat_template_test.bzl 中的chat_template_testStarlark 宏接收chat_template、input_dir、golden_dir、pbtext_files、mirror_chat_templates等参数生成一个 C 测试目标遍历输入 JSON → 渲染模板 → 与 golden 文本逐字比对同时校验 pbtext 内嵌模板与外部模板一致、镜像模板完全等同测试运行器底层渲染与比对逻辑由 models/chat_template_test_runner.cc 实现测试目标通过--chat_template、--input_dir、--golden_dir、--pbtext_files等命令行参数驱动。这套机制意味着任何对chat_template.jinja或LlmMetadataProto.pbtext的修改都必须通过 golden 比对才能合入从工程上保证了 Canonical 配置的权威性与稳定性——这正是Canonical prompt templates and metadata configuration这一命名含义的落地体现。七、小结总结而言LFM 模型家族在 LiteRT-LM 中的接入由两个文件共同决定chat_template.jinja定义消息如何被格式化成 token 序列BOS 前置、ChatML 角色标记、工具调用声明与响应包装、生成提示符追加LlmMetadataProto.pbtext定义模型运行时行为起止 token、采样参数、上下文上限、模型类型、思考与函数调用开关、思考通道。两者通过jinja_prompt_template字段在运行时绑定通过 golden 测试在开发期约束。对于想要接入 LFM 2.5 系列模型的开发者可以直接复用 models/lfm2 目录下的这套配置Instruct 变体将supports_thinking置为falseThinking 变体保留true并依赖thought通道解析思考内容如需扩展工具则按List of tools: [...]|tool_call_start|[func(argval)]|tool_call_end|tool角色[...]的三段式约定组织对话即可。【免费下载链接】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），仅供参考