Dify 如何配置不同大语言模型？模型供应商和参数怎么选？

Dify 配置大语言模型时，先要分清两层：模型供应商配置和应用内模型参数配置。供应商配置解决“能不能连上”，包括 OpenAI、Azure OpenAI、Anthropic、通义千问、智谱、Ollama 或其他兼容 OpenAI API 的服务；应用参数解决“回答得好不好”，包括模型名称、temperature、max tokens、上下文长度、超时和重试策略。

基本步骤是进入 Dify 控制台的模型供应商页面，选择供应商，填写 API Key、Endpoint、API Version 或部署名称，然后保存并测试连接。Azure OpenAI 这类服务要特别注意 deployment name 和 model name 的区别，很多连接失败不是 Key 错了，而是路径和版本不匹配。本地模型则要关注网络连通性、显存、并发和响应速度，不能只看模型是否能启动。

选模型时不要只追求参数量。客服问答更看重稳定、成本和延迟，知识库问答更看重长上下文和遵循引用，代码生成更看重推理与格式控制，多语言场景还要看中文和英文混合能力。一个可落地的配置是：低风险意图识别用便宜模型，复杂回答用强模型，敏感场景加人工确认或二次校验。

追问

OpenAI、Azure OpenAI 和本地模型在 Dify 里怎么取舍？

OpenAI 接入简单，模型更新快，适合快速验证产品；Azure OpenAI 更适合已经在微软云上做权限、网络和合规管理的企业。本地模型优势是数据可控、内网可用，缺点是运维成本、显存成本和效果调优都要自己承担。边界是私有化不等于更便宜，如果并发高、模型大、响应慢，总成本可能比云模型更高。实际选型要同时看数据敏感度、预算、延迟和团队运维能力。

temperature、max tokens 和上下文长度应该怎么配置？

temperature 控制随机性，问答和流程类应用建议低一些，比如 0.1-0.3；创意文案可以高一些，但也要防止跑题。max tokens 限制输出长度，设太小会截断，设太大则增加成本并拖慢响应。上下文长度不是越大越好，塞入太多无关内容会让模型注意力分散。踩坑点是把参数当成万能开关，实际上检索质量、提示词和模型能力会一起影响结果。

兼容 OpenAI API 的模型接入时要注意什么？

很多国产模型或代理服务都宣称兼容 OpenAI API，但细节不一定完全一致。要检查 base URL、模型名、鉴权头、流式输出、函数调用和 JSON 模式是否被支持。Dify 里测试连接通过，只代表基本请求可用，不代表所有应用能力都稳定。边界是工作流里如果依赖工具调用或结构化输出，必须单独压测，否则上线后可能出现偶发字段缺失。

一个应用里能不能按任务切换不同模型？

可以，而且这通常是更经济的做法。比如意图分类节点用小模型，知识库总结用中等模型，最终面向用户的复杂回复再用强模型。这样能在效果和成本之间做平衡，但也增加了调试难度，因为错误可能来自任意一个节点。建议为每个节点保留输入输出日志，并准备固定测试样例，避免只凭一次对话判断模型好坏。

模型配置上线后如何监控质量和成本？

至少要看请求量、平均延迟、失败率、单次成本、用户追问率和人工纠错记录。模型变更前后要用同一批问题做回归测试，尤其是知识库问答、结构化 JSON 输出和多轮上下文。成本优化不要只换便宜模型，也可以通过缩短提示词、减少 Top K、缓存高频答案来实现。最容易踩的坑是模型供应商升级后行为变化，应用没有版本锁定和回滚预案。