080、模型选择：不同场景下的性价比上周帮朋友调一个智能家居的Agent，设备端用的是ESP32-S3，云端跑GPT-4o，结果一晚上烧掉他两美元API额度，就为了控制一盏灯。他说“我就说了句‘把客厅灯调暗一点’，它居然先调用了三个工具，还回了段小作文”。我说你这不是模型选错了，是场景选错了。大模型不是越强越好，而是越合适越好。这个问题在Agent工程里，比模型本身的精度更致命——因为精度的代价常常是延迟、功耗和钱。先还原一下那个现场。用户指令到云端，意图识别、实体抽取、工具调用，全部丢给GPT-4o。灯是调暗了，但端到端延迟两点八秒，用户以为设备坏了。这背后的核心矛盾：我们到底需要多“聪明”的模型来理解“把灯调暗一点”？这个任务在自然语言理解上，几乎不需要什么世界知识，甚至不需要上下文记忆，只需要把“调暗”映射到设备的dimmer指令。用百亿参数模型和用千亿参数模型，效果可能只差零点几个点，但延迟和成本相差几十倍。所以模型选择的第一原则，是先把任务拆开，而不是先挑模型。一个Agent的完整链路里，至少有三个不同类型的能力需求：意图分类和槽位抽取，这是典型的判别式任务；工具调用和参数生成，这是结构化生成任务；最后是复杂推理和多轮规划，这才是“智能”的深水区。这三个任务对模型的需求完全不同。前两个，中小模型完全能扛，甚至用BERT时代的蒸馏模型都能做个七八分。第三个，才需要真正的大模型。我在实际项目里常用的分法是：把Agent拆成“快路径”和“慢路径”。快路径处理高频、低复杂度、实时性要求高的请求，比如“开灯”“关窗”“下一首”。这类请求我直接用一个小型分类器加上规则模板，或者一个7B级别的模型在本地跑CPU。慢路径处理“帮我安排一个明天下午两点的会议，如果会 080、模型选择：不同场景下的性价比
080、模型选择：不同场景下的性价比上周帮朋友调一个智能家居的Agent，设备端用的是ESP32-S3，云端跑GPT-4o，结果一晚上烧掉他两美元API额度，就为了控制一盏灯。他说“我就说了句‘把客厅灯调暗一点’，它居然先调用了三个工具，还回了段小作文”。我说你这不是模型选错了，是场景选错了。大模型不是越强越好，而是越合适越好。这个问题在Agent工程里，比模型本身的精度更致命——因为精度的代价常常是延迟、功耗和钱。先还原一下那个现场。用户指令到云端，意图识别、实体抽取、工具调用，全部丢给GPT-4o。灯是调暗了，但端到端延迟两点八秒，用户以为设备坏了。这背后的核心矛盾：我们到底需要多“聪明”的模型来理解“把灯调暗一点”？这个任务在自然语言理解上，几乎不需要什么世界知识，甚至不需要上下文记忆，只需要把“调暗”映射到设备的dimmer指令。用百亿参数模型和用千亿参数模型，效果可能只差零点几个点，但延迟和成本相差几十倍。所以模型选择的第一原则，是先把任务拆开，而不是先挑模型。一个Agent的完整链路里，至少有三个不同类型的能力需求：意图分类和槽位抽取，这是典型的判别式任务；工具调用和参数生成，这是结构化生成任务；最后是复杂推理和多轮规划，这才是“智能”的深水区。这三个任务对模型的需求完全不同。前两个，中小模型完全能扛，甚至用BERT时代的蒸馏模型都能做个七八分。第三个，才需要真正的大模型。我在实际项目里常用的分法是：把Agent拆成“快路径”和“慢路径”。快路径处理高频、低复杂度、实时性要求高的请求，比如“开灯”“关窗”“下一首”。这类请求我直接用一个小型分类器加上规则模板，或者一个7B级别的模型在本地跑CPU。慢路径处理“帮我安排一个明天下午两点的会议，如果会 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
