在实际的大模型项目中最值得反复确认的问题不是“LLM 能做什么”而是“LLM 应该做什么”。许多团队一开始会把所有需求都堆给大模型下单计算交给 LLM、权限判断交给 LLM、数据库查询也交给 LLM结果模型输出的随机性被放大到业务逻辑里出现幻觉、格式不稳定、成本难以控制。反过来也有团队在语义理解、文档总结、意图分类这类任务上一律用规则硬写规则越堆越多准确率却始终上不去。形成这两种局面的根本原因是把 LLM 当成了“万能服务器”而不是把它当成一个有明确能力边界的组件。LLM 真正擅长的是语义相关的开放任务不擅长的是确定性计算、精确状态管理和需要访问最新数据的场景。弄清楚这条边界后面所有框架选型、架构设计、部署方式才有判断依据。下面依次解决四个问题第一LLM 的能力边界在哪里第二如何把具体任务分配到 LLM 和传统代码第三LLM 框架解决什么、不解决什么第四LLM 推理服务和 ComfyUI 这类工具服务是否必须部署在同一台电脑上。最后会给出一个最小可运行案例、常见坑排查方式和一份生产环境检查清单。1. 先理解 LLM 的能力边界它本质上是“文本预测接口”1.1 LLM 的真实能力给定上下文输出下一段文本LLM 的真实能力可以从一句话开始理解它接收一段文本输出另一段文本输出的内容在模型训练目标和采样策略下尽可能符合上文的语义和统计规律。技术实现上是预测下一个 token但工程使用上可以把 LLM 看成一个“文本到文本的条件生成器”。这个定位决定了三件事LLM 能读懂复杂指令能产生多样化表达适合处理没有标准答案的开放任务。它没有真实的知识意识也没有稳定的记忆回答依赖训练数据和上下文窗口。它不会自动执行外部操作要调用工具、查询数据、修改系统状态必须由周边代码来补足。所以LLM 适合“语义理解 文本生成”类任务不适合“精确计算 状态管理 实时查询”类任务。这里说的“适合”和“能”不是一回事。模型在技术上可以输出一段 JSON 表示计算结果但它可能算错模型也能模仿一个状态机但它无法保证每一次迁移都符合业务约束。工程决策要看的是“应该”而不是“可能”。1.2 概率性输出不能直接用于所有业务逻辑概率性输出是另一个关键约束。推理时模型的采样策略会引入随机性temperature 参数越大输出分布越随机越适合创意任务temperature 越小输出越稳定但也不代表百分之百可复现。对账号余额计算、订单金额汇总、权限控制这类任务任何一次随机出错都是不可接受的。因此这些任务不要交给 LLM 直接计算结果。LLM 至多参与“如何计算”的规划具体计算交给代码和数据库事务。如果业务必须使用 LLM 的输出通常要加一层校验或约束限制枚举输出、约束 JSON Schema、加后处理白名单、加人工复核等。这是生产项目和 Demo 的最大区别。注意不要只验证程序能启动还要验证输入、输出、异常分支和日志是否符合预期。概率性输出意味着同一段输入在不同时间可能得到不同结果必须把“校验层”当成功能的一部分来设计。1.3 一张表快速判断任务归属在写代码之前先用下面这张表做任务归属判断能避免大多数误用。任务类型典型例子是否适合 LLM核心原因规则计算订单金额、运费、税额不适合结果必须唯一且可审计状态流转订单状态机、审批流程不适合直接驱动需要精确状态迁移适合状态机精确检索按账号查用户、查库存不适合直接做模型不知道实时数据容易产生幻觉语义分类意图识别、垃圾评论识别适合规则难以覆盖复杂表达内容生成摘要、标题、文案改写适合开放性强没有唯一答案信息抽取从合同、日志中提取字段适合能结合上下文理解需配合 schema 约束代码辅助生成样板代码、解释报错适合语义理解和模式生成是强项但要人工 review这张表不是绝对的但“是否适合”和“是否应该用”之间有一个重要判断越是底线系统越要偏向传统程序。例如信息抽取适合 LLM但如果是法律合同里的金额字段就必须在 LLM 抽取后加规则校验和人工确认不能直接把模型输出写进数据库。2. 从“能做什么”到“应该做什么”任务分配决策框架2.1 五个判断维度先回答这五个问题在真实系统里分配任务不能只凭感觉。下面五个维度可以作为判断依据确定性要求输出是否必须唯一、可复现是否要能断言结果。错误容忍度一旦出错损失的是金钱、安全还是只是用户体验。成本和延迟预算一次调用消耗多少 token是否在可接受的延迟范围内。可解释性能否回答“为什么得到这个结果”。数据可达性完成任务需要的数据模型是否能看到是否需要接检索或工具接口。这五个维度中确定性和错误容忍度属于“硬约束”成本和延迟属于“软约束”可解释性与数据可达性属于“架构约束”。硬约束不满足时直接否决软约束不满足时可以优化架构约束不满足时需要先补基础设施。2.2 决策顺序先用规则排除再让 LLM 接手推荐按下面的顺序判断能减少大部分误用先排除必须用代码处理的任务凡是涉及事务、状态机、精确数值计算的一律交给传统程序。再排除数据可达性不足的任务如果任务依赖最新业务数据而你没有可靠的检索或工具接口先不要上 LLM否则模型会基于训练数据编造答案。然后排查高责任场景涉及资金、法务、医疗、公共安全等LLM 只能做草案最终必须有规则层或人工兜底。最后剩下的开放语义任务才分配给 LLM。这个顺序的核心思想是“先否定再肯定”。LLM 是最后一个接手任务的组件而不是第一个。很多项目跑偏是因为一开始就把 LLM 放在流程入口让模型决定一切导致错误从入口开始向后扩散。2.3 评分示例一个客服工单分类任务的归属判断可以做一个简化评分表。对某个任务从 0 到 5 分依次评估语义复杂度、规则可维护性、容错度、数据可达性然后相加。评估维度客服工单分类订单金额计算语义复杂度0-541规则可维护性0-525容错度0-540数据可达性0-535合计1311只看合计客服工单分类更倾向用 LLM。订单金额计算合计虽然也有 11 分但它的“错误容忍度”是 0这是一个否决项。分数可以说明倾向但硬约束维度必须单独检查。实际项目中建议把这样的评分表写进需求评审模板让产品、后端、算法在同一个维度上对齐而不是在代码写完后再争论“这里为什么用 LLM”。3. 典型落地场景LLM 在真实系统中的正确位置3.1 文本生成摘要、标题、文案改写文本生成是 LLM 最顺手的场景。关键不是一次性堆一个很长的 prompt而是把生成任务拆成“模板 变量 风格约束”。例如做商品标题改写系统提示词可以这样设计你是电商文案助手。用户会给你一段商品描述。 请输出三个备选标题每个标题不超过 30 个字。 要求 1. 保留品牌名和核心规格。 2. 突出卖点。 3. 不要编造不存在的信息。这里的重点不是让模型自由发挥而是明确告诉模型“哪些信息不能变、哪些信息可以发挥”。生成的业务要求是“可读、可用、信息准确”不是“越有创意越好”。3.2 语义理解意图识别、实体抽取、文本分类语义理解类任务非常适合 LLM尤其是规则难以覆盖的开放表达。做法上要注意输出约束避免模型返回标签之外的文字。一个典型的系统提示词模板你是客服意图识别器。只输出以下标签之一 退款, 物流查询, 商品咨询, 其他。 不要输出解释不要输出其他内容。这类任务通常配合后处理白名单把模型输出统一做 strip 和映射如果结果不在标签集合内就进入“其他”或“人工”分支。这样即使模型偶尔不遵守指令系统也不会直接报错。3.3 知识库从零散文档到 LLM Wiki“LLM wiki”是一个常见热搜词对应的是把零散文档整理成可回答问题的知识库。这里要特别强调LLM 本身不保存文档内容真正的工作发生在检索增强生成RAG链路里。一条完整的 RAG 链路至少包含四个环节把文档切分成块。对文本块做向量化。检索与问题最相关的文本块。把文本块作为上下文交给 LLM 生成回答。文本切分是最容易被忽略的环节。一个最小切分函数如下def split_documents(text: str, chunk_size: int 800, overlap: int 100): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap if end len(text): break return chunks切分时保留 overlap是为了避免句子在边界处被截断导致关键信息丢失。实际项目中还要按段落、标题结构进行切分而不是单纯按字符数切。做一个知识库核心工作量不在模型而在数据清洗、切分策略、检索质量和结果校验。3.4 Agent 编排让 LLM 做调度者不要让它做数据库Agent 是 LLM 一个重要的应用方向让模型决定调用哪个工具、传什么参数由外部代码真正执行。这里最容易犯的错是把 LLM 当成“知识库”和“事务库”。Agent 的正确姿势是LLM 负责理解目标、拆分步骤、选择工具。代码负责真正执行工具调用。数据库负责存储业务状态。规则引擎负责兜底校验。也就是说LLM 是调度中心不是存储中心。工具本身必须是确定性代码工具执行结果要记录到日志LLM 后续决定要基于真实执行结果而不是基于模型自己的想象。4. LLM 框架解决什么框架是接入层不是能力层4.1 常见框架方向与选型参考搜索“LLM 框架”会得到大量选项。按解决问题的方式可以把框架分成几类。框架类型代表方向解决的问题编排框架LangChain、LlamaIndexPrompt 组合、工具调用、记忆、链式调用应用平台Dify、Coze 一类可视化编排、插件、发布运维推理服务vLLM、TGI高并发推理、吞吐、显存管理评估与监控RAGAS、LangSmith 一类效果评估、链路追踪以上名称来自常见开源生态具体选型要依赖版本和环境落地前先查看官方文档确认兼容性。这里给的是一张选型地图不是固定答案。4.2 框架真正提供给工程的价值框架的价值在于把重复工作抽象出来减少胶水代码。实际项目中框架主要帮团队解决三件事统一接入不管是 OpenAI 兼容接口还是本地服务框架层做统一封装业务代码不直接拼 HTTP 请求。可观测把 prompt、响应、token 消耗、耗时记录到链路中定位问题时不需要去猜模型返回了什么。扩展点工具调用、记忆管理、检索接口都做成插件后续要换模型或加能力时改动集中。但框架不会改变模型的能力边界。模型算不出金额框架也算不出模型没有检索工具框架也不会凭空获得最新数据。框架只是接入和编排工具不是能力放大器。4.3 什么时候不需要框架不是所有项目都适合引入框架。出现下面这些情况时直接用 HTTP 调用可能更清晰只有一个模型调用点没有链式调用和工具编排。团队还在验证产品方向不想过早绑定抽象层。需要完全控制 prompt、重试和日志细节框架反而限制了灵活性。判断标准很简单如果代码里只有“构造 messages、发请求、解析响应”这三步就不需要框架如果出现了多轮对话、工具调用、检索、记忆、多模型切换才考虑用编排框架。5. 一个现实架构问题LLM 和 ComfyUI 必须在同一台电脑上吗5.1 先把三种服务拆开“comfyui 与 llm 必须在同一台电脑上么”这个问题很典型。要回答它先要分清三类服务LLM 推理服务负责跑大语言模型需要 GPU 显存对外提供类似/v1/chat/completions的接口。业务后端写业务逻辑的普通后端服务可以跑在 CPU 服务器上。ComfyUI 服务负责跑图像生成工作流加载 checkpoint执行采样默认提供一个 HTTP API端口通常为 8188。这三类服务本质上是互相独立的进程。它们是否需要部署在同一台电脑上取决于资源、延迟、带宽和数据安全要求而不是任何技术强制。5.2 答案不需要同机需要的是接口可达结论先行LLM 和 ComfyUI 不需要在同一台电脑上。它们之间通过 HTTP API 通信只要网络可达、鉴权配置正确、数据带宽足够就可以分别部署在不同机器上。把两个服务放在同一台机器上反而容易带来问题。LLM 推理和 ComfyUI 图像生成都需要大显存如果一块 GPU 要同时跑两个大模型会出现显存不足或互相抢占的问题。更好的做法是LLM 放在一台带 GPU 的机器上。ComfyUI 放在另一台带 GPU 的机器上。业务后端放在不带 GPU 的应用服务器上。这样每类服务的资源规划、扩缩容、故障隔离都独立。不同机器之间只需要保证 HTTP 接口可达。5.3 示例一个服务同时调用 LLM 与 ComfyUI下面用一个简化示例说明业务后端如何同时调用两个独立服务。演示环境假设 LLM 服务地址是192.168.1.10:8000ComfyUI 服务地址是192.168.1.11:8188。import requests LLM_ENDPOINT http://192.168.1.10:8000/v1/chat/completions COMFYUI_ENDPOINT http://192.168.1.11:8188/prompt # 第一步让 LLM 根据用户需求生成绘画提示词 llm_payload { model: your-llm-model, messages: [ { role: system, content: 你是一个提示词优化助手只输出图片提示词不要解释。 }, { role: user, content: 画一张包含雪山和湖水的风景图傍晚光线。 } ], temperature: 0.7, max_tokens: 200 } llm_resp requests.post(LLM_ENDPOINT, jsonllm_payload, timeout30) llm_resp.raise_for_status() prompt_text llm_resp.json()[choices][0][message][content].strip() print(LLM 生成的提示词:, prompt_text) # 第二步把提示词提交给 ComfyUI 的 workflow comfyui_payload { prompt: { 3: { class_type: KSampler, inputs: { seed: 42, steps: 20, cfg: 7, sampler_name: euler, denoise: 1.0 } }, 6: { class_type: CLIPTextEncode, inputs: { text: prompt_text, clip: [4, 0] } } }, client_id: blog-demo } comfy_resp requests.post(COMFYUI_ENDPOINT, jsoncomfyui_payload, timeout30) comfy_resp.raise_for_status() print(ComfyUI 任务已提交:, comfy_resp.json())代码的关键点在两个地方。第一业务后端不关心 LLM 和 ComfyUI 跑在哪里只关心接口地址和鉴权第二ComfyUI 的 workflow JSON 是节点结构节点 ID 和字段取决于你在 ComfyUI 中加载的工作流。注意上面的 ComfyUI workflow 是简化示例用于说明调用方式。实际项目要先从 ComfyUI 界面导出你自己的工作流模板确认节点 ID 和输入字段再替换成真实配置。5.4 什么时候才需要考虑同机部署虽然不需要同机但有些场景确实适合放在同一台电脑上离线环境或数据合规要求严格数据不能出内网。图像生成后需要立刻写本地磁盘交给 LLM 服务读取追求极低延迟。单个模型较小、显存充裕同一台 GPU 可以稳定承载多个服务。即使同机部署也不建议把两个服务揉在一个进程里而是应该用两个独立进程分别监听不同端口通过localhost互相调用。这样资源边界清晰后续迁移部署时改动最小。部署方式适用场景主要注意事项全部在同一台 GPU 服务器演示、离线、小模型测试显存不足时服务互相抢占LLM 一台、ComfyUI 一台、业务后端一台生产环境网络延迟、带宽、鉴权全部用云服务 API快速上线、小流量数据合规、成本管控6. 最小可运行案例用 LLM 做意图分类并触发动作6.1 环境准备用一个最小案例把前面的概念串起来用 LLM 对用户输入做意图分类然后根据分类触发不同动作。这里分类动作先用打印代替实际项目中可以替换成调用订单接口、物流接口或商品接口。环境要求如下依赖项说明Python 3.9运行调用代码requests发送 HTTP 请求LLM 服务OpenAI 兼容接口或本地 vLLM 等推理服务网络能访问到 LLM 服务地址如果使用本地推理服务要先确认服务地址可访问。常见方式是启动一个 OpenAI 兼容的服务端对外暴露/v1/chat/completions。6.2 代码实现import requests LLM_ENDPOINT http://127.0.0.1:8000/v1/chat/completions API_KEY # 如果服务不需要鉴权则留空 def classify_intent(text: str) - str: payload { model: your-model-name, messages: [ { role: system, content: ( 你是客服意图识别器。只输出以下标签之一 退款, 物流查询, 商品咨询, 其他。 不要输出其他内容。 ) }, { role: user, content: text } ], temperature: 0.0, max_tokens: 10 } headers {Authorization: fBearer {API_KEY}} if API_KEY else {} resp requests.post(LLM_ENDPOINT, headersheaders, jsonpayload, timeout15) resp.raise_for_status() label resp.json()[choices][0][message][content].strip() return label if __name__ __main__: samples [ 我要退货, 我的快递到哪了, 这款手机有蓝色吗 ] for sample in samples: print(sample, -, classify_intent(sample))这个例子的结构很简单但覆盖了生产代码需要的基本件系统提示词约束输出、temperature 设低让结果更稳定、max_tokens 限制输出长度、timeout 防止调用卡死。6.3 关键参数说明参数常见值作用与影响注意事项temperature0.0控制随机性越小越稳定分类任务用 0生成任务根据创意要求调到 0.7 以上max_tokens10限制输出长度太小可能截断完整标签timeout15防止请求无限等待本地冷启动可能较慢可适当调大model与部署一致决定模型能力必须与服务端部署的模型名一致temperature 设置为 0 并不保证绝对可复现但对标签约束已经足够低。真正的可靠性来自后处理校验而不是只靠参数。6.4 运行与验证运行命令python intent_demo.py正常输出应该是我要退货 - 退款 我的快递到哪了 - 物流查询 这款手机有蓝色吗 - 商品咨询如果模型返回了“标签退款”这类带前缀的内容说明指令约束没有完全生效。此时不要只改提示词推荐在后处理里加白名单映射把输出归一化到固定标签集合。这一步是生产级代码和示例代码的关键差异。7. 常见坑与排查链路7.1 高频问题现象、原因与处理问题现象可能原因检查方式处理建议分类结果里出现标签之外的文字系统提示词约束不够或模型没遵守打印模型原始返回值加白名单后处理映射到默认标签调用接口报 401/403API Key 没传、鉴权配置错误检查请求 header 和服务端日志确认鉴权方式与密钥权限本地推理延迟很高模型过大、显存不足、并发过高查看 GPU 利用率、推理吞吐指标换小模型、量化部署或使用推理框架ComfyUI 提交任务后无响应服务未启动、workflow 节点配置错误访问 ComfyUI 地址和端口检查服务状态从界面导出真实工作流相同请求两次结果不同temperature 大于 0、采样随机固定参数并多次测试关键业务加校验层或使用缓存LLM 回答引用了不存在的数据数据可达性不足模型凭记忆编造检查 prompt 是否包含真实检索上下文接入 RAG 或限制模型只能基于上下文回答这些问题的共同点在于大多数不是“模型坏了”而是调用方的输入、约束和校验不到位。7.2 一条可操作的排查顺序遇到 LLM 相关问题时按下面顺序排查效率最高检查输入。输入文本是否为空、编码是否正确、是否包含了预期信息。检查接口地址和鉴权。地址是否可达、端口是否开放、密钥是否有效。检查模型与参数。模型名是否和服务端一致temperature、max_tokens、timeout 是否合理。检查输出解析。返回的 JSON 字段路径是否正确标签是否经过后处理。检查链路日志。prompt 和 response 是否被记录token 消耗和耗时是否符合预期。检查资源和带宽。GPU 显存、网络带宽、跨机调用延迟是否成为瓶颈。大部分问题会在前四步被定位。如果前四步都正常再考虑模型本身或基础设施问题。8. 生产环境建议与可复用清单8.1 学习环境与生产环境的差异学习环境跑通 Demo 和生产环境交付系统是两回事。下面这张表列出主要差异。项目学习环境生产环境接口地址本机 localhost内网域名或云服务地址带鉴权日志print 输出结构化日志记录 prompt、response、耗时、模型版本参数配置写死在代码里配置外置按环境区分降级方案只要不报错必须有规则兜底、重试和人工处理路径数据安全忽略较多输入过滤、数据脱敏、操作审计模型版本随意更换版本固定变更走发布流程性能单请求验证评估吞吐、并发、显存和成本生产环境里LLM 调用通常不是单一函数而是一个完整链路输入校验、鉴权、检索、调用、校验、重试、日志、降级。把这几件事做全才具备上线条件。8.2 任务分配与部署检查清单下面的清单可以直接复制到团队的评审文档里上线前逐项确认。这个任务的结果是否必须确定如果是优先用代码实现而不是 LLM。这个任务是否依赖实时业务数据如果是是否已经接入检索或工具接口模型输出是否做了格式校验白名单、JSON Schema 是否就位是否设置了最大 token、timeout、重试次数是否记录了完整的调用日志包括输入、输出、模型版本、token 消耗和耗时是否有降级方案模型超时或返回异常时系统能否走规则兜底或人工流程多个 GPU 服务是否部署在同一台机器显存规划是否确认过跨机调用是否评估过延迟、带宽和数据量接口是否做了鉴权、限流和审计这份清单没有覆盖所有业务但能帮助团队在正式开工前把“模型边界、架构边界、资源边界”一次对齐。回到开头的问题“LLM 应该做什么”核心判断可以收敛成一句话LLM 应该负责语义理解、开放文本生成和任务编排不应该负责确定性计算、精确状态管理和数据库查询它应该以独立服务的形式通过 API 接入系统而不是和每个依赖它的工具挤在同一台机器上。对刚开始做 LLM 应用的团队最稳妥的起步方式不是让业务系统直接依赖模型而是先写一层薄薄的调用封装把模型接入、参数管理、日志、校验和降级都收拢到一起。这样后续更换模型、调整参数、排查问题时改动点都集中在一个地方不会牵动整条业务链路。 LLM该做什么？能力边界、任务分配与部署架构指南
在实际的大模型项目中最值得反复确认的问题不是“LLM 能做什么”而是“LLM 应该做什么”。许多团队一开始会把所有需求都堆给大模型下单计算交给 LLM、权限判断交给 LLM、数据库查询也交给 LLM结果模型输出的随机性被放大到业务逻辑里出现幻觉、格式不稳定、成本难以控制。反过来也有团队在语义理解、文档总结、意图分类这类任务上一律用规则硬写规则越堆越多准确率却始终上不去。形成这两种局面的根本原因是把 LLM 当成了“万能服务器”而不是把它当成一个有明确能力边界的组件。LLM 真正擅长的是语义相关的开放任务不擅长的是确定性计算、精确状态管理和需要访问最新数据的场景。弄清楚这条边界后面所有框架选型、架构设计、部署方式才有判断依据。下面依次解决四个问题第一LLM 的能力边界在哪里第二如何把具体任务分配到 LLM 和传统代码第三LLM 框架解决什么、不解决什么第四LLM 推理服务和 ComfyUI 这类工具服务是否必须部署在同一台电脑上。最后会给出一个最小可运行案例、常见坑排查方式和一份生产环境检查清单。1. 先理解 LLM 的能力边界它本质上是“文本预测接口”1.1 LLM 的真实能力给定上下文输出下一段文本LLM 的真实能力可以从一句话开始理解它接收一段文本输出另一段文本输出的内容在模型训练目标和采样策略下尽可能符合上文的语义和统计规律。技术实现上是预测下一个 token但工程使用上可以把 LLM 看成一个“文本到文本的条件生成器”。这个定位决定了三件事LLM 能读懂复杂指令能产生多样化表达适合处理没有标准答案的开放任务。它没有真实的知识意识也没有稳定的记忆回答依赖训练数据和上下文窗口。它不会自动执行外部操作要调用工具、查询数据、修改系统状态必须由周边代码来补足。所以LLM 适合“语义理解 文本生成”类任务不适合“精确计算 状态管理 实时查询”类任务。这里说的“适合”和“能”不是一回事。模型在技术上可以输出一段 JSON 表示计算结果但它可能算错模型也能模仿一个状态机但它无法保证每一次迁移都符合业务约束。工程决策要看的是“应该”而不是“可能”。1.2 概率性输出不能直接用于所有业务逻辑概率性输出是另一个关键约束。推理时模型的采样策略会引入随机性temperature 参数越大输出分布越随机越适合创意任务temperature 越小输出越稳定但也不代表百分之百可复现。对账号余额计算、订单金额汇总、权限控制这类任务任何一次随机出错都是不可接受的。因此这些任务不要交给 LLM 直接计算结果。LLM 至多参与“如何计算”的规划具体计算交给代码和数据库事务。如果业务必须使用 LLM 的输出通常要加一层校验或约束限制枚举输出、约束 JSON Schema、加后处理白名单、加人工复核等。这是生产项目和 Demo 的最大区别。注意不要只验证程序能启动还要验证输入、输出、异常分支和日志是否符合预期。概率性输出意味着同一段输入在不同时间可能得到不同结果必须把“校验层”当成功能的一部分来设计。1.3 一张表快速判断任务归属在写代码之前先用下面这张表做任务归属判断能避免大多数误用。任务类型典型例子是否适合 LLM核心原因规则计算订单金额、运费、税额不适合结果必须唯一且可审计状态流转订单状态机、审批流程不适合直接驱动需要精确状态迁移适合状态机精确检索按账号查用户、查库存不适合直接做模型不知道实时数据容易产生幻觉语义分类意图识别、垃圾评论识别适合规则难以覆盖复杂表达内容生成摘要、标题、文案改写适合开放性强没有唯一答案信息抽取从合同、日志中提取字段适合能结合上下文理解需配合 schema 约束代码辅助生成样板代码、解释报错适合语义理解和模式生成是强项但要人工 review这张表不是绝对的但“是否适合”和“是否应该用”之间有一个重要判断越是底线系统越要偏向传统程序。例如信息抽取适合 LLM但如果是法律合同里的金额字段就必须在 LLM 抽取后加规则校验和人工确认不能直接把模型输出写进数据库。2. 从“能做什么”到“应该做什么”任务分配决策框架2.1 五个判断维度先回答这五个问题在真实系统里分配任务不能只凭感觉。下面五个维度可以作为判断依据确定性要求输出是否必须唯一、可复现是否要能断言结果。错误容忍度一旦出错损失的是金钱、安全还是只是用户体验。成本和延迟预算一次调用消耗多少 token是否在可接受的延迟范围内。可解释性能否回答“为什么得到这个结果”。数据可达性完成任务需要的数据模型是否能看到是否需要接检索或工具接口。这五个维度中确定性和错误容忍度属于“硬约束”成本和延迟属于“软约束”可解释性与数据可达性属于“架构约束”。硬约束不满足时直接否决软约束不满足时可以优化架构约束不满足时需要先补基础设施。2.2 决策顺序先用规则排除再让 LLM 接手推荐按下面的顺序判断能减少大部分误用先排除必须用代码处理的任务凡是涉及事务、状态机、精确数值计算的一律交给传统程序。再排除数据可达性不足的任务如果任务依赖最新业务数据而你没有可靠的检索或工具接口先不要上 LLM否则模型会基于训练数据编造答案。然后排查高责任场景涉及资金、法务、医疗、公共安全等LLM 只能做草案最终必须有规则层或人工兜底。最后剩下的开放语义任务才分配给 LLM。这个顺序的核心思想是“先否定再肯定”。LLM 是最后一个接手任务的组件而不是第一个。很多项目跑偏是因为一开始就把 LLM 放在流程入口让模型决定一切导致错误从入口开始向后扩散。2.3 评分示例一个客服工单分类任务的归属判断可以做一个简化评分表。对某个任务从 0 到 5 分依次评估语义复杂度、规则可维护性、容错度、数据可达性然后相加。评估维度客服工单分类订单金额计算语义复杂度0-541规则可维护性0-525容错度0-540数据可达性0-535合计1311只看合计客服工单分类更倾向用 LLM。订单金额计算合计虽然也有 11 分但它的“错误容忍度”是 0这是一个否决项。分数可以说明倾向但硬约束维度必须单独检查。实际项目中建议把这样的评分表写进需求评审模板让产品、后端、算法在同一个维度上对齐而不是在代码写完后再争论“这里为什么用 LLM”。3. 典型落地场景LLM 在真实系统中的正确位置3.1 文本生成摘要、标题、文案改写文本生成是 LLM 最顺手的场景。关键不是一次性堆一个很长的 prompt而是把生成任务拆成“模板 变量 风格约束”。例如做商品标题改写系统提示词可以这样设计你是电商文案助手。用户会给你一段商品描述。 请输出三个备选标题每个标题不超过 30 个字。 要求 1. 保留品牌名和核心规格。 2. 突出卖点。 3. 不要编造不存在的信息。这里的重点不是让模型自由发挥而是明确告诉模型“哪些信息不能变、哪些信息可以发挥”。生成的业务要求是“可读、可用、信息准确”不是“越有创意越好”。3.2 语义理解意图识别、实体抽取、文本分类语义理解类任务非常适合 LLM尤其是规则难以覆盖的开放表达。做法上要注意输出约束避免模型返回标签之外的文字。一个典型的系统提示词模板你是客服意图识别器。只输出以下标签之一 退款, 物流查询, 商品咨询, 其他。 不要输出解释不要输出其他内容。这类任务通常配合后处理白名单把模型输出统一做 strip 和映射如果结果不在标签集合内就进入“其他”或“人工”分支。这样即使模型偶尔不遵守指令系统也不会直接报错。3.3 知识库从零散文档到 LLM Wiki“LLM wiki”是一个常见热搜词对应的是把零散文档整理成可回答问题的知识库。这里要特别强调LLM 本身不保存文档内容真正的工作发生在检索增强生成RAG链路里。一条完整的 RAG 链路至少包含四个环节把文档切分成块。对文本块做向量化。检索与问题最相关的文本块。把文本块作为上下文交给 LLM 生成回答。文本切分是最容易被忽略的环节。一个最小切分函数如下def split_documents(text: str, chunk_size: int 800, overlap: int 100): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap if end len(text): break return chunks切分时保留 overlap是为了避免句子在边界处被截断导致关键信息丢失。实际项目中还要按段落、标题结构进行切分而不是单纯按字符数切。做一个知识库核心工作量不在模型而在数据清洗、切分策略、检索质量和结果校验。3.4 Agent 编排让 LLM 做调度者不要让它做数据库Agent 是 LLM 一个重要的应用方向让模型决定调用哪个工具、传什么参数由外部代码真正执行。这里最容易犯的错是把 LLM 当成“知识库”和“事务库”。Agent 的正确姿势是LLM 负责理解目标、拆分步骤、选择工具。代码负责真正执行工具调用。数据库负责存储业务状态。规则引擎负责兜底校验。也就是说LLM 是调度中心不是存储中心。工具本身必须是确定性代码工具执行结果要记录到日志LLM 后续决定要基于真实执行结果而不是基于模型自己的想象。4. LLM 框架解决什么框架是接入层不是能力层4.1 常见框架方向与选型参考搜索“LLM 框架”会得到大量选项。按解决问题的方式可以把框架分成几类。框架类型代表方向解决的问题编排框架LangChain、LlamaIndexPrompt 组合、工具调用、记忆、链式调用应用平台Dify、Coze 一类可视化编排、插件、发布运维推理服务vLLM、TGI高并发推理、吞吐、显存管理评估与监控RAGAS、LangSmith 一类效果评估、链路追踪以上名称来自常见开源生态具体选型要依赖版本和环境落地前先查看官方文档确认兼容性。这里给的是一张选型地图不是固定答案。4.2 框架真正提供给工程的价值框架的价值在于把重复工作抽象出来减少胶水代码。实际项目中框架主要帮团队解决三件事统一接入不管是 OpenAI 兼容接口还是本地服务框架层做统一封装业务代码不直接拼 HTTP 请求。可观测把 prompt、响应、token 消耗、耗时记录到链路中定位问题时不需要去猜模型返回了什么。扩展点工具调用、记忆管理、检索接口都做成插件后续要换模型或加能力时改动集中。但框架不会改变模型的能力边界。模型算不出金额框架也算不出模型没有检索工具框架也不会凭空获得最新数据。框架只是接入和编排工具不是能力放大器。4.3 什么时候不需要框架不是所有项目都适合引入框架。出现下面这些情况时直接用 HTTP 调用可能更清晰只有一个模型调用点没有链式调用和工具编排。团队还在验证产品方向不想过早绑定抽象层。需要完全控制 prompt、重试和日志细节框架反而限制了灵活性。判断标准很简单如果代码里只有“构造 messages、发请求、解析响应”这三步就不需要框架如果出现了多轮对话、工具调用、检索、记忆、多模型切换才考虑用编排框架。5. 一个现实架构问题LLM 和 ComfyUI 必须在同一台电脑上吗5.1 先把三种服务拆开“comfyui 与 llm 必须在同一台电脑上么”这个问题很典型。要回答它先要分清三类服务LLM 推理服务负责跑大语言模型需要 GPU 显存对外提供类似/v1/chat/completions的接口。业务后端写业务逻辑的普通后端服务可以跑在 CPU 服务器上。ComfyUI 服务负责跑图像生成工作流加载 checkpoint执行采样默认提供一个 HTTP API端口通常为 8188。这三类服务本质上是互相独立的进程。它们是否需要部署在同一台电脑上取决于资源、延迟、带宽和数据安全要求而不是任何技术强制。5.2 答案不需要同机需要的是接口可达结论先行LLM 和 ComfyUI 不需要在同一台电脑上。它们之间通过 HTTP API 通信只要网络可达、鉴权配置正确、数据带宽足够就可以分别部署在不同机器上。把两个服务放在同一台机器上反而容易带来问题。LLM 推理和 ComfyUI 图像生成都需要大显存如果一块 GPU 要同时跑两个大模型会出现显存不足或互相抢占的问题。更好的做法是LLM 放在一台带 GPU 的机器上。ComfyUI 放在另一台带 GPU 的机器上。业务后端放在不带 GPU 的应用服务器上。这样每类服务的资源规划、扩缩容、故障隔离都独立。不同机器之间只需要保证 HTTP 接口可达。5.3 示例一个服务同时调用 LLM 与 ComfyUI下面用一个简化示例说明业务后端如何同时调用两个独立服务。演示环境假设 LLM 服务地址是192.168.1.10:8000ComfyUI 服务地址是192.168.1.11:8188。import requests LLM_ENDPOINT http://192.168.1.10:8000/v1/chat/completions COMFYUI_ENDPOINT http://192.168.1.11:8188/prompt # 第一步让 LLM 根据用户需求生成绘画提示词 llm_payload { model: your-llm-model, messages: [ { role: system, content: 你是一个提示词优化助手只输出图片提示词不要解释。 }, { role: user, content: 画一张包含雪山和湖水的风景图傍晚光线。 } ], temperature: 0.7, max_tokens: 200 } llm_resp requests.post(LLM_ENDPOINT, jsonllm_payload, timeout30) llm_resp.raise_for_status() prompt_text llm_resp.json()[choices][0][message][content].strip() print(LLM 生成的提示词:, prompt_text) # 第二步把提示词提交给 ComfyUI 的 workflow comfyui_payload { prompt: { 3: { class_type: KSampler, inputs: { seed: 42, steps: 20, cfg: 7, sampler_name: euler, denoise: 1.0 } }, 6: { class_type: CLIPTextEncode, inputs: { text: prompt_text, clip: [4, 0] } } }, client_id: blog-demo } comfy_resp requests.post(COMFYUI_ENDPOINT, jsoncomfyui_payload, timeout30) comfy_resp.raise_for_status() print(ComfyUI 任务已提交:, comfy_resp.json())代码的关键点在两个地方。第一业务后端不关心 LLM 和 ComfyUI 跑在哪里只关心接口地址和鉴权第二ComfyUI 的 workflow JSON 是节点结构节点 ID 和字段取决于你在 ComfyUI 中加载的工作流。注意上面的 ComfyUI workflow 是简化示例用于说明调用方式。实际项目要先从 ComfyUI 界面导出你自己的工作流模板确认节点 ID 和输入字段再替换成真实配置。5.4 什么时候才需要考虑同机部署虽然不需要同机但有些场景确实适合放在同一台电脑上离线环境或数据合规要求严格数据不能出内网。图像生成后需要立刻写本地磁盘交给 LLM 服务读取追求极低延迟。单个模型较小、显存充裕同一台 GPU 可以稳定承载多个服务。即使同机部署也不建议把两个服务揉在一个进程里而是应该用两个独立进程分别监听不同端口通过localhost互相调用。这样资源边界清晰后续迁移部署时改动最小。部署方式适用场景主要注意事项全部在同一台 GPU 服务器演示、离线、小模型测试显存不足时服务互相抢占LLM 一台、ComfyUI 一台、业务后端一台生产环境网络延迟、带宽、鉴权全部用云服务 API快速上线、小流量数据合规、成本管控6. 最小可运行案例用 LLM 做意图分类并触发动作6.1 环境准备用一个最小案例把前面的概念串起来用 LLM 对用户输入做意图分类然后根据分类触发不同动作。这里分类动作先用打印代替实际项目中可以替换成调用订单接口、物流接口或商品接口。环境要求如下依赖项说明Python 3.9运行调用代码requests发送 HTTP 请求LLM 服务OpenAI 兼容接口或本地 vLLM 等推理服务网络能访问到 LLM 服务地址如果使用本地推理服务要先确认服务地址可访问。常见方式是启动一个 OpenAI 兼容的服务端对外暴露/v1/chat/completions。6.2 代码实现import requests LLM_ENDPOINT http://127.0.0.1:8000/v1/chat/completions API_KEY # 如果服务不需要鉴权则留空 def classify_intent(text: str) - str: payload { model: your-model-name, messages: [ { role: system, content: ( 你是客服意图识别器。只输出以下标签之一 退款, 物流查询, 商品咨询, 其他。 不要输出其他内容。 ) }, { role: user, content: text } ], temperature: 0.0, max_tokens: 10 } headers {Authorization: fBearer {API_KEY}} if API_KEY else {} resp requests.post(LLM_ENDPOINT, headersheaders, jsonpayload, timeout15) resp.raise_for_status() label resp.json()[choices][0][message][content].strip() return label if __name__ __main__: samples [ 我要退货, 我的快递到哪了, 这款手机有蓝色吗 ] for sample in samples: print(sample, -, classify_intent(sample))这个例子的结构很简单但覆盖了生产代码需要的基本件系统提示词约束输出、temperature 设低让结果更稳定、max_tokens 限制输出长度、timeout 防止调用卡死。6.3 关键参数说明参数常见值作用与影响注意事项temperature0.0控制随机性越小越稳定分类任务用 0生成任务根据创意要求调到 0.7 以上max_tokens10限制输出长度太小可能截断完整标签timeout15防止请求无限等待本地冷启动可能较慢可适当调大model与部署一致决定模型能力必须与服务端部署的模型名一致temperature 设置为 0 并不保证绝对可复现但对标签约束已经足够低。真正的可靠性来自后处理校验而不是只靠参数。6.4 运行与验证运行命令python intent_demo.py正常输出应该是我要退货 - 退款 我的快递到哪了 - 物流查询 这款手机有蓝色吗 - 商品咨询如果模型返回了“标签退款”这类带前缀的内容说明指令约束没有完全生效。此时不要只改提示词推荐在后处理里加白名单映射把输出归一化到固定标签集合。这一步是生产级代码和示例代码的关键差异。7. 常见坑与排查链路7.1 高频问题现象、原因与处理问题现象可能原因检查方式处理建议分类结果里出现标签之外的文字系统提示词约束不够或模型没遵守打印模型原始返回值加白名单后处理映射到默认标签调用接口报 401/403API Key 没传、鉴权配置错误检查请求 header 和服务端日志确认鉴权方式与密钥权限本地推理延迟很高模型过大、显存不足、并发过高查看 GPU 利用率、推理吞吐指标换小模型、量化部署或使用推理框架ComfyUI 提交任务后无响应服务未启动、workflow 节点配置错误访问 ComfyUI 地址和端口检查服务状态从界面导出真实工作流相同请求两次结果不同temperature 大于 0、采样随机固定参数并多次测试关键业务加校验层或使用缓存LLM 回答引用了不存在的数据数据可达性不足模型凭记忆编造检查 prompt 是否包含真实检索上下文接入 RAG 或限制模型只能基于上下文回答这些问题的共同点在于大多数不是“模型坏了”而是调用方的输入、约束和校验不到位。7.2 一条可操作的排查顺序遇到 LLM 相关问题时按下面顺序排查效率最高检查输入。输入文本是否为空、编码是否正确、是否包含了预期信息。检查接口地址和鉴权。地址是否可达、端口是否开放、密钥是否有效。检查模型与参数。模型名是否和服务端一致temperature、max_tokens、timeout 是否合理。检查输出解析。返回的 JSON 字段路径是否正确标签是否经过后处理。检查链路日志。prompt 和 response 是否被记录token 消耗和耗时是否符合预期。检查资源和带宽。GPU 显存、网络带宽、跨机调用延迟是否成为瓶颈。大部分问题会在前四步被定位。如果前四步都正常再考虑模型本身或基础设施问题。8. 生产环境建议与可复用清单8.1 学习环境与生产环境的差异学习环境跑通 Demo 和生产环境交付系统是两回事。下面这张表列出主要差异。项目学习环境生产环境接口地址本机 localhost内网域名或云服务地址带鉴权日志print 输出结构化日志记录 prompt、response、耗时、模型版本参数配置写死在代码里配置外置按环境区分降级方案只要不报错必须有规则兜底、重试和人工处理路径数据安全忽略较多输入过滤、数据脱敏、操作审计模型版本随意更换版本固定变更走发布流程性能单请求验证评估吞吐、并发、显存和成本生产环境里LLM 调用通常不是单一函数而是一个完整链路输入校验、鉴权、检索、调用、校验、重试、日志、降级。把这几件事做全才具备上线条件。8.2 任务分配与部署检查清单下面的清单可以直接复制到团队的评审文档里上线前逐项确认。这个任务的结果是否必须确定如果是优先用代码实现而不是 LLM。这个任务是否依赖实时业务数据如果是是否已经接入检索或工具接口模型输出是否做了格式校验白名单、JSON Schema 是否就位是否设置了最大 token、timeout、重试次数是否记录了完整的调用日志包括输入、输出、模型版本、token 消耗和耗时是否有降级方案模型超时或返回异常时系统能否走规则兜底或人工流程多个 GPU 服务是否部署在同一台机器显存规划是否确认过跨机调用是否评估过延迟、带宽和数据量接口是否做了鉴权、限流和审计这份清单没有覆盖所有业务但能帮助团队在正式开工前把“模型边界、架构边界、资源边界”一次对齐。回到开头的问题“LLM 应该做什么”核心判断可以收敛成一句话LLM 应该负责语义理解、开放文本生成和任务编排不应该负责确定性计算、精确状态管理和数据库查询它应该以独立服务的形式通过 API 接入系统而不是和每个依赖它的工具挤在同一台机器上。对刚开始做 LLM 应用的团队最稳妥的起步方式不是让业务系统直接依赖模型而是先写一层薄薄的调用封装把模型接入、参数管理、日志、校验和降级都收拢到一起。这样后续更换模型、调整参数、排查问题时改动点都集中在一个地方不会牵动整条业务链路。