企业官网建设流程全解析

LLM 这个词最近几乎成了技术讨论区的默认背景音，但“LLM 该做什么”这个问题，比“LLM 能做什么”更值得先想清楚。很多人把大语言模型当成万能处理器，任何任务都往里塞，结果要么输出不稳定，要么延迟高得没法用，要么成本根本吃不消。不少新手翻各种 LLM 词条和资料，想搞明白的其实不是“什么是语言模型”，而是“这东西到底能用在哪里、不该用在哪里”。这篇文章不打算再列一轮功能清单，而是从实际落地角度拆一遍：什么任务适合交给 LLM，什么任务应该用传统代码或规则处理，框架怎么选，部署在哪里，以及把 LLM 接到 ComfyUI 这类外部应用时，是不是必须放在同一台电脑上。

我会先讲能力边界，再给一套任务判断流程，然后聊框架和部署，最后补上落地时最容易踩的坑和排查顺序。这里很多内容不是从官方文档抄来的，而是自己做本地部署、接口调用和批量任务时反复验证过的经验。如果目标只是跑通一个 Demo，默认配置通常够用；如果要拿它处理真实业务，下面的判断标准比功能列表更管用。

1. 先回答“LLM 该做什么”之前，先搞清它不该做什么

1.1 LLM 的本质是近似文本生成器，不是事实数据库

很多人把 LLM 当成一个“什么都知道的数据库”，问什么它答什么。这个理解会带来一系列错误预期。

LLM 的本质是：给定一段输入文本，根据训练时学到的概率分布，预测下一个最可能出现的 token，然后一个 token 一个 token 地把回答生成出来。它不是在“查询”一条准确记录，而是在“生成”一段看起来合理的文本。

这也是为什么 LLM 会在事实性问题上翻车。你说“帮我查一下某产品的上市时间”，它会给出一个看起来很正式的数字或日期，但那个结果可能是从海量语料里推算出来的，不一定等于官方公开信息。真正需要精确事实的场景，正确做法是让 LLM 从你提供的资料里抽取答案，或者让它生成查询条件，再由传统程序去数据库里查。

理解这一点之后，“LLM 该做什么”的答案会清晰很多：它适合做的是理解、生成、改写、归纳这类天然带有模糊性的语言任务，而不是做精确查询、精确计算和低容错的决策。

1.2 哪些任务天然适合 LLM，哪些不适合

我平时判断一个任务是否适合交给 LLM，会先把它放进下面这个表里对号入座。

这里要解释一句：说不适合，不是“完全不能用”，而是“不应该作为唯一方案”。精确计算你可以让 LLM 生成表达式，再用 Python 的计算库去算；强一致性任务你可以让 LLM 处理理解部分，再把结果交给规则代码做标准化。关键原则是让 LLM 做它擅长的模糊理解，让程序做它擅长的精确执行。

2. 判断一个任务是否该交给 LLM：先做四步拆解

2.1 先看任务是“理解生成”还是“精确计算”

最简单的判断方法：如果一个任务用三行传统代码就能写清楚，那大概率不应该用 LLM。

比如把用户输入的订单号做格式校验，正则表达式一段就搞定，延迟是微秒级，而且百分之百稳定。这种事不需要 LLM。反过来，如果任务是“从客户投诉邮件里提取出问题类型、影响范围、期望处理方式”，传统规则要列几十条关键词匹配条件，还经常漏掉新说法，这种情况就适合 LLM。

判断顺序是：先看有没有明确规则，有规则优先用规则；规则写不出来，或者维护成本太高，再看 LLM。

2.2 再看错误容忍度和可验证性

LLM 的输出天然带有随机性，所以一个关键问题是：这个任务允许多大的错误率？

如果答案是“完全不能错”，那除非你能在 LLM 输出后面接一道程序校验，否则不建议直接用。比如生成商品标题，错了顶多不太好看，人工审核能兜底；但如果生成的是银行转账指令，一条幻觉输出就可能造成事故。

我一般会做两个测试。第一，把同一个输入重复跑 10 次，看输出差异有多大。第二，把输出交给一个传统逻辑模块去校验，看校验通过率有多高。如果通过率低于你能接受的水平，说明这个任务不能把 LLM 当终点，只能当中间步骤。

2.3 看输出是否需要确定性

很多业务场景要求“同一输入必须得到同一输出”。LLM 默认做不到这一点，因为它的采样过程带随机性。

影响确定性的核心参数是 temperature。温度越低，模型越倾向于选择概率最高的 token，输出越保守；温度越高，输出越发散。但把 temperature 设成 0 也不是绝对的万能解，部分模型在低温度下仍然可能因为浮点运算、硬件差异或批量推理产生微小差异。

如果你需要严格确定性，可以考虑几个组合做法：

• 固定随机种子，但注意这只能保证同一环境、同一批次的稳定。
• 把 temperature 调低，通常在 0 到 0.3 之间。
• 在 LLM 输出后加一层规则校验和标准化。
• 如果数据要落库或传输，用结构校验工具确认格式，而不是依赖模型“记住格式”。

2.4 看延迟和成本预算

LLM 的推理延迟远高于传统接口。一个简单的文本生成请求，在普通消费级显卡上可能需要几秒，在 CPU 上可能更慢。这决定了它适合放在什么环节。

交互式场景，比如聊天助手、实时问答，延迟超过 3 秒用户就能明显感觉到。异步场景，比如批量文档摘要、日志分类，单条跑 5 秒也没关系，只要总吞吐达标。设计架构时，先问自己是同步还是异步，再决定要不要引入流式输出、任务队列和批处理。

成本也一样。token 费用和模型参数规模成正比，参数越大的模型通常效果越好，但也更贵。更稳妥的做法是：先拿最小可用的模型试流程，跑通了再逐步升档。很多场景下，一个小规模开源模型经过良好的提示词设计，已经能完成大部分文本分类和抽取任务，没必要一上来就上大参数模型。

3. 选框架和部署方式前，先弄懂 LLM 的调用链路

3.1 LLM 框架到底解决什么问题

很多人搜索“LLM 框架”，以为框架就是 LLM 本身。其实框架解决的是 LLM 外围的工程问题。

裸调用一个 LLM 很简单：把文本发给模型接口，拿到回复。但真实业务要处理的事情远不止这一步：

• 多轮对话的上下文管理：哪些历史消息要保留，哪些要裁剪，怎么控制 token 长度。
• 提示词的版本管理：提示词不只是“一句话”，它本身是代码的一部分，需要能测试、能回滚。
• 输出解析：模型返回的是字符串，怎么稳定地转成 JSON 或结构化对象。
• 外部工具调用：LLM 决定要查数据库、调 API、执行代码时，谁来调度。
• 重试和降级：模型超时、限流、返回异常格式时怎么处理。
• 缓存：相同输入直接返回缓存结果，减少重复调用成本。

这些功能单独写很容易，但要做到可维护、可扩展，工作量不小。框架的价值就在这里：把重复工程封装好，让你把精力放在业务逻辑上。常见的开发框架比如 LangChain 类负责编排和工具调用，Ollama、llama.cpp 这类工具负责本地推理。一个稳定业务的 LLM 链路由这几层组合而成，而不是某一个工具包办。

3.2 本地部署、API 调用、混合方案怎么选

部署方式直接决定了你的项目能不能跑起来，以及后期怎么维护。

本地部署的优点是数据不出内网，敏感信息更可控，也没有每次请求的 token 费用。缺点是硬件门槛明确：一个能用的开源模型通常需要至少 8GB 到 16GB 显存，还要考虑显存带宽、内存、磁盘空间和散热。低配机器也能跑，但要把模型量化和并发数都降下来。

API 调用的优点是上手快、不用管显卡驱动、推理优化好，适合快速验证产品。缺点是要考虑网络条件、数据要走第三方服务，以及长期成本会随着调用量线性上升。

混合方案在真实项目里更常见：敏感数据的处理放在本地小模型上，通用任务走 API 大模型，中间用队列把两边串起来。这个方案一开始会多写一些胶水代码，但灵活性和可控性最好。

判断标准很直接：先看数据敏感性，再看硬件预算，再看团队维护能力。三者都支持，才选本地优先；否则用 API 起步更稳妥。

3.3 ComfyUI 和 LLM 是否必须在同一台电脑上

这个问题在相关搜索里出现频率很高。先给结论：不必须。

ComfyUI 是一个图形化工作流工具，它本身负责的是节点编排、图像生成流程和前端交互。LLM 是一个独立的模型服务。两者的关系更像是“前端应用”和“后端服务”，通过 HTTP 接口或 WebSocket 通信就能协作。放在同一台电脑、同一内网的不同机器、甚至远程服务器上，都能工作。

但“能不能分开”和“建议怎么部署”是两回事。分开放置时需要关注网络延迟：如果 ComfyUI 和 LLM 服务不在同一个网段，每次调用都要多出网络往返时间；如果中间经过代理或网关，还要考虑超时和并发连接数。实际部署时要注意：

• 如果显存足够，又追求低延迟，把 LLM 服务放在本机最省事。
• 如果一张显卡跑不动两个模型，就把 LLM 单独部署到另一台机器或远程服务上，ComfyUI 通过 API 地址访问。
• 如果两者在同一台机器但显存不够，优先考虑用更小的量化模型，或者把图像生成和 LLM 推理拆成前后串行，避免同时占用显存。

一个很容易忽略的点是显存竞争。ComfyUI 跑图像生成本身就很吃显存，LLM 推理也要显存。两者在同一张卡上同时跑，很可能出现显存溢出。如果你碰到“ComfyUI 跑完图之后 LLM 变慢了”的问题，大概率不是 LLM 本身的问题，而是显存没释放或占用冲突。排查顺序是：先看显卡占用，再看任务队列，最后再怀疑模型配置。

4. 落地时最容易踩的坑：上下文、并发、输出格式和模板

4.1 上下文长度不等于处理能力

模型参数里写着支持 8K、32K、128K 上下文，不代表你可以直接塞满。上下文越长，模型的计算量越大，响应越慢，显存占用也越高。而且长上下文里，模型对中段信息的注意力会衰减，经常出现“记得开头和结尾，忘了中间”的情况。

我实际测试过一些场景：把两万字文档直接丢给长上下文模型做摘要，模型确实能接收，但输出质量明显不如分段处理后拼接的结果。更稳妥的做法是：

• 先把长文档按章节或语义切块，每块单独处理。
• 需要全局信息时，先让模型对每块做摘要，再把摘要汇总。
• 如果只是想找某个关键信息，先做检索，把相关片段拼到提示词里，而不是把所有内容都塞进去。

这种“检索 + 上下文拼接”的方式，比无脑堆上下文更省钱，也更容易保证质量。

4.2 并发和延迟的判断标准

很多人第一次用 LLM 接口，就写一个 for 循环同时发几十个请求。结果要么超时，要么报错，要么服务端限流。问题不在 LLM，而在你跳过了单任务验证。

正确顺序是：

1. 先跑一条请求，确认接口、提示词、输出格式都正常。
2. 再跑 5 到 10 条，看每条的平均延迟和成功率。
3. 最后才考虑并发，而且并发要从小到大慢慢加。

判断一个部署方案是否够用，不能只看单次推理速度，要看三个指标：单任务延迟、并发吞吐量和失败率。并发数增加后，延迟通常会上升，如果上升幅度控制在可接受范围，说明资源够用；如果延迟翻倍而且开始报错，就说明当前配置不适合这个并发量，需要降并发、换大显存或加机器。

4.3 输出格式不稳定时的处理方式

让 LLM 输出 JSON 或固定结构是开发中最常见的需求，也是翻车率最高的地方。模型可能会在 JSON 前后加解释性文字，也可能把双引号、反斜杠转义搞乱。

处理方式按稳定度从低到高排列：

• 提示词强制：“只输出 JSON，不要解释”，这种最基础但最不稳。
• 输出解析器：由框架帮你从模型回复里提取 JSON 片段，能处理大部分情况。
• 约束解码：部分推理框架支持限制输出只能从合法 JSON 的 token 里选，这种最可靠，但支持范围有限。
• 后处理校验：拿到输出先做格式解析，失败就重试一次或两次，并告诉模型“上次输出格式不合法，请重新输出”。

我一般会在后处理校验这一步设置重试上限，连试两次还不合法，就记录日志并返回默认结果。这样至少不会让任务流程卡死。

5. 从“能跑”到“好用”：验收清单和排查顺序

5.1 LLM 任务的验收清单

我自己在把任何一个 LLM 任务交付之前，会按下面的清单过一遍：

• 输入覆盖：测试样例是否覆盖了正常输入、边界输入和异常输入。
• 输出一致性：同一输入多次运行，结果差异是否在可接受范围。
• 格式稳定性：需要结构化输出的任务，格式解析成功率是否达到要求。
• 延迟指标：单任务、并发场景下的平均延迟和最大延迟是否满足业务要求。
• 失败处理：请求超时、模型报错、输出非法时，是否有重试和降级。
• 日志可读性：任务失败时，能不能从日志里看出是输入问题、资源问题还是模型问题。
• 安全与隐私：日志里是否记录了不该记录的敏感内容，输出内容是否做了必要过滤。

这个清单看起来基础，但大多数线上事故都不是模型能力不够，而是上面某一项没做。

5.2 遇到问题时的排查顺序

LLM 相关项目的问题排查，最容易犯的错是一上来就怀疑模型。实际排查顺序应该是：

1. 先看现象：是报错、卡住、无输出，还是输出异常。
2. 再看输入：输入文本的长度、编码、格式是否正常，是否包含特殊字符。
3. 再看环境：依赖版本、显存占用、端口、网络连接、权限。
4. 再看参数：temperature、max_tokens、模型路径、批量大小、超时时间。
5. 最后看模型：换一个更可靠的模型或 API 对比验证。

一个典型的场景是“请求返回空白”。新手经常认为是模型出问题了，但实际一查，是 max_tokens 设置太短，模型还没生成完就被截断了。另一个高频问题是“报没有某个模块”，不一定是代码问题，很可能是虚拟环境没激活，或者安装的依赖版本和项目要求不一致。

还有一个容易被忽略的点：本地模型加载后的启动日志。很多推理框架会在启动时打印显存占用、加载时间和警告信息。这些信息看起来不起眼，但排查时往往第一条线索就在里面。

5.3 什么时候应该放弃 LLM 方案

这个标题听起来有点反直觉，但它是“LLM 该做什么”真正重要的一半。如果满足以下任何一种情况，你要认真考虑是否换个方案：

• 规则已经写得很清楚，只是没人维护，那不如先做规则代码，再用 LLM 兜底。
• 延迟要求是毫秒级，LLM 根本做不到，架构上应该让 LLM 异步预生成结果，而不是在线调用。
• 成本已经超出预期，而且任务本身只是简单的文本替换或格式化，传统代码就能解决。
• 输出正确性要求极高，又没有程序化校验手段，LLM 的幻觉会成为不可控风险。

做过几个项目之后你会发现，放弃 LLM 不代表失败。它更像是一个决策结果：在一个具体场景里，传统方案的风险更低、成本更可控、结果更可预测。真正专业的选择不是“什么都要用 LLM”，而是“知道该在什么地方用 LLM，在什么地方用传统代码，并且能说清楚依据”。