最近技术圈关于大模型的话题里有一个很有意思的讨论Google doesn’t need the LLM crown。这句话想表达的是Google 未必非要去抢大模型评测榜单上的“王冠”它的核心优势在于把 LLM 能力嵌进搜索、Android、Workspace 这些已经拥有海量用户的场景中。对普通开发者来说这句话其实还有另一层启示我们做技术选型时也不应该只盯着“哪个模型最强”而是要想清楚“在什么场景下用什么样的 LLM 接入方式”。这篇文章会围绕 LLM 这个概念展开先梳理大语言模型到底是什么、能做什么再对比云端 API 和本地部署两条路线接着给出两套可以跟着做的实战方案一套是通过 API 调用云端大模型另一套是本地部署开源模型并用 OpenAI 兼容接口调用。最后会专门回答一个很多人问到的问题ComfyUI 与 LLM 必须在同一台电脑上吗不管你是刚接触大模型的新手还是正在做 AI 应用落地的后端开发这篇文章都能给你一份比较完整的参考。1. LLM 到底是什么从概念到能力边界1.1 一句话理解大语言模型LLM 全称是 Large Language Model中文一般翻译成“大语言模型”。它的本质是一个基于海量文本训练的神经网络模型核心任务是预测一段文本中下一个 Token词元出现的概率。你可以把它理解成一个极其擅长“接下文”的系统你给它一句“今天的天气真不错我们一起去”它大概率会接出“公园散步”“爬山”等更自然的后续。这种“接龙”能力看起来简单但当模型参数规模达到数十亿、数百亿甚至更多并且训练语料覆盖了书籍、论文、代码、网页之后模型会涌现出很多超出“接龙”本身的能力比如文本摘要与改写代码生成与解释多轮对话基础数学推理信息抽取与分类这也是为什么 LLM 不只是一个“聊天机器人背后的模型”它正在成为很多应用的通用理解与生成引擎。1.2 LLM 能做什么不能做什么把 LLM 接入项目之前先要对它的能力边界有清晰认识。能做内容生成写邮件、写文案、生成测试用例、生成 SQL。内容理解从长文档中抽取关键信息、做情感分析、做智能客服意图识别。代码助手解释代码、补全代码、生成单元测试、辅助排查报错。知识库问答结合企业私有文档通过 RAG检索增强生成方式回答内部问题。流程自动化把自然语言指令解析成结构化操作例如“帮我把这份报表按销售额排序后发给仓库主管”。不能做保证事实绝对准确LLM 存在幻觉问题可能一本正经地编造不存在的 API、不存在的法规条款。实时感知外部世界模型训练数据有截止时间不主动连接外部系统的话它不知道当前天气、最新股价。自主执行复杂操作模型只负责“理解并输出”真正执行还要靠代码、工具链和人工流程配合。理解这条边界很重要。很多时候工程上遇到 LLM“翻车”不是模型不够聪明而是我们在设计流程时把模型当成了“全知全能的 API”没有额外加校验、兜底和上下文管理。1.3 Token、上下文窗口、温度三个必须理解的概念不管是调用云端 API 还是本地部署你都会在配置里看到这几个词。Token词元Token 是模型处理文本的最小单位。它不一定是完整单词。英文里一个单词可能被拆成多个 Token中文里一个汉字往往对应一个 Token但在不同分词器下也会有差异。API 定价、上下文长度限制都围绕 Token 计算。上下文窗口Context Window上下文窗口指模型一次能“看到”的最大 Token 数量包括用户输入、历史消息和模型输出。比如某个模型上下文窗口是 128K意味着一次请求最多能处理约 128K Token 的内容。超出后需要做截断、摘要或 RAG 检索而不是无脑把全部文本塞进去。Temperature温度Temperature 控制输出的随机性温度越低输出越保守、稳定适合代码生成、关键字段抽取。温度越高输出越发散、有创意适合头脑风暴、文案生成。一般代码和结构化输出场景建议 0.10.3通用对话建议 0.7 左右创意写作可以到 0.9 甚至更高。2. 大模型落地路线云端 API 还是本地部署很多人一开始纠结我的项目应该接 OpenAI、Gemini 这类云端 API还是自己在服务器上部署一个开源模型两种方式没有绝对优劣下面从几个维度对比。2.1 云端 API 方案云端 API 的典型代表包括 Gemini API、OpenAI API、通义千问 API、文心一言 API 等。你不需要准备 GPU 服务器只需要注册账号、拿到 API Key、按调用量付费。优点上手快拿到 Key 后几分钟就能调通。模型能力强通常是各家最新最强的版本。无需关心 GPU 显存、推理加速、模型更新。适合快速验证产品原型。缺点数据要发送到第三方服务敏感业务场景有合规风险。单次调用成本会随着用量线性增长。依赖外网连通性和服务稳定性SLA 受制于人。部分服务在高峰期可能限流。2.2 本地部署方案本地部署是指把开源模型例如 Llama、Qwen、DeepSeek下载到自己的服务器或电脑上用推理框架加载并对外提供服务。优点数据不出内网隐私可控。调用量大的时候边际成本低不按 Token 计费。可以针对业务场景做微调和定制。不受第三方 API 停服或改价影响。缺点需要准备 GPU 资源显存越大能跑的模型越大。部署门槛较高要处理推理框架、显存优化、并发请求。开源模型的能力通常比同代最强闭源模型有差距。后续升级、维护都由自己负责。2.3 决策清单场景推荐路线快速验证产品原型云端 API处理公开数据、非敏感内容云端 API企业内部知识库数据不能出内网本地部署高频调用、成本敏感本地部署需要最强推理与生成能力云端 API在边缘设备离线运行本地小型模型7B 以下实际项目里很多团队会采用混合架构先用云端 API 做 PaaS 层的核心推理再逐步把高频、敏感场景迁移到本地部署模型。3. LLM 框架与工具链不只是 LangChain说到 LLM 开发很多人第一反应是 LangChain。其实围绕大模型开发的工具链已经很丰富不同框架解决的问题是不同的。3.1 LangChain大模型应用开发框架LangChain 是目前最流行的大模型应用开发框架之一核心思想是把 LLM、提示词、外部工具、向量数据库、记忆模块等组件“链”在一起。适合场景构建多步骤对话机器人。把 LLM 和搜索、计算器、数据库查询等工具串联。实现带记忆的复杂应用。一个简单的 LangChain 示例思路# 安装pip install langchain langchain-community openai from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI # 这里的 base_url 可以根据你使用的模型服务调整 llm ChatOpenAI( modelgpt-4o-mini, temperature0.1, ) prompt ChatPromptTemplate.from_messages([ (system, 你是一个严谨的技术文档助手请用简洁的语言回答问题。), (human, {topic} 是什么), ]) chain prompt | llm result chain.invoke({topic: RAG}) print(result.content)注意不同的 LangChain 版本 API 可能略有差异实际使用时以你安装的版本为准。3.2 LlamaIndex数据索引与 RAGLlamaIndex 专注于解决“如何把私有数据接入 LLM”的问题。它提供了文档加载、切分、向量化索引、检索以及问答流水线的完整能力。如果你的场景是“基于企业文档做智能问答”LlamaIndex 比 LangChain 更聚焦。LlamaIndex 的优势支持几十种数据源接入。提供完善的索引结构如向量索引、树索引、关键词索引。与向量数据库如 Chroma、FAISS、Milvus集成方便。3.3 Hugging Face Transformers模型加载与微调Transformers 是 Hugging Face 家族的核心库负责加载、使用和微调预训练模型。它更多面向“模型级开发”而不是“应用级开发”。如果你的任务是加载一个开源模型做推理。对开源模型做 LoRA 微调。做模型评测与对比。那么 Transformers 是你绕不开的基础库。3.4 Ollama本地模型管理工具Ollama 是一个让人惊艳的本地 LLM 部署工具它把模型下载、推理服务、命令行交互打包成极简操作。你不需要手动处理 Python 环境、CUDA 依赖、推理脚本几条命令就能启动一个本地模型服务。很多团队已经在生产环境里使用 Ollama 作为内部模型的轻量推理服务因为它提供了一个 OpenAI 兼容的 HTTP API迁移成本很低。3.5 ComfyUI 是 LLM 框架吗ComfyUI 不是 LLM 框架。它是一个基于节点编辑器的 AI 绘画工作流工具主要面向 Stable Diffusion 系列图像生成模型。不过在 AI 工作流里ComfyUI 可以通过自定义节点或 API 调用 LLM常见的用途是根据用户输入生成或优化提示词。对生成的图片做自动打标。在图像生成流程中加入语义理解。所以可以理解为ComfyUI 是图像生成的工作流引擎LLM 是它可选的外部能力补充二者并不冲突。3.6 框架选型建议问题建议只是想在应用里调一次 LLM不需要框架直接用 SDK 或 HTTP 请求需要多轮对话、工具调用LangChain 或直接写服务需要私有知识库问答LlamaIndex 或自建 RAG 流程想做模型微调Hugging Face Transformers PEFT想在本地快速起一个 LLM 服务Ollama想和 ComfyUI 结合通过 HTTP API 调用 LLM不强制同一环境4. 实战一通过 API 调用云端大模型接下来进入代码环节。这个实战以 Google 的 Gemini API 为例演示一个最基础的“接入云端大模型”的流程。即使你没有用过 Google 相关服务只要理解了这个模式换成任何一家 API 服务商都很快。4.1 准备工作到 Google AI Studio 获取一个 API Key。安装 Python SDKpip install google-generativeai建议把 API Key 配置到环境变量不要硬编码到代码里。export GEMINI_API_KEY你的_API_Key4.2 用 Python 调用 Gemini API创建文件gemini_demo.py# 文件路径gemini_demo.py import os import google.generativeai as genai # 读取环境变量中的 API Key api_key os.environ.get(GEMINI_API_KEY) if not api_key: raise ValueError(请先设置环境变量 GEMINI_API_KEY) genai.configure(api_keyapi_key) # 选择一个模型以 gemini-1.5-flash 为例 model genai.GenerativeModel(gemini-1.5-flash) response model.generate_content( 用三句话解释什么是 RAG检索增强生成并给出一个实际应用场景。 ) print(response.text)运行python gemini_demo.py预期会输出一段关于 RAG 的中文解释和应用场景。4.3 流式输出与安全配置大模型接口的响应时间可能比较长为了提升体验可以使用流式输出让内容边生成边显示。# 文件路径gemini_stream_demo.py import os import google.generativeai as genai api_key os.environ.get(GEMINI_API_KEY) genai.configure(api_keyapi_key) model genai.GenerativeModel(gemini-1.5-flash) response model.generate_content( 给我介绍 5 个 Python 常用的数据分析库每个库用一句话说明。, streamTrue, ) for chunk in response: print(chunk.text, end, flushTrue)打印结果是一段流式输出的文本适合在 Web 端实现打字机效果。4.4 错误处理与超时网络调用不稳定尤其是跨地域访问云端 API 时超时和限流很常见。建议加上异常处理和重试逻辑。# 文件路径gemini_retry_demo.py import os import time import google.generativeai as genai from google.api_core import exceptions api_key os.environ.get(GEMINI_API_KEY) genai.configure(api_keyapi_key) model genai.GenerativeModel(gemini-1.5-flash) def call_llm_with_retry(prompt, max_retries3): for attempt in range(max_retries): try: response model.generate_content(prompt) return response.text except exceptions.ResourceExhausted as e: print(f触发限流第 {attempt 1} 次重试{e}) time.sleep(2 * (attempt 1)) except exceptions.DeadlineExceeded as e: print(f请求超时第 {attempt 1} 次重试{e}) time.sleep(2) return None result call_llm_with_retry(用一句话介绍大语言模型) print(result)这段代码的核心是“在异常发生时等待一段时间再重试”同时通过max_retries限制重试次数避免无限循环消耗资源。5. 实战二本地部署一个 LLM 并通过 OpenAI 兼容接口调用在一些场景里数据不能出内网或者你要高频调用但不想按 Token 付费这时本地部署就很有必要。下面用 Ollama 完成一个最小可用的本地 LLM 服务搭建。5.1 安装 OllamaOllama 支持 Linux、macOS 和 Windows。macOS / Windows直接到 Ollama 官网下载安装包。Linuxcurl -fsSL https://ollama.com/install.sh | sh安装完成后终端执行ollama --version能输出版本号就说明安装成功。5.2 拉取并运行模型以 Qwen2.5 系列为例7B 模型在显存足够的情况下能流畅运行。拉取模型ollama pull qwen2.5:7b运行模型ollama run qwen2.5:7b进入交互式聊天界面后输入“你好”模型会回复。按Ctrl D退出交互界面。注意qwen2.5:7b这类模型需要大约 68GB 显存如果你的机器只有 CPU运行速度会明显变慢但也能跑。具体尺寸可以根据机器资源选择比如qwen2.5:3b或qwen2.5:0.5b。5.3 启动本地 API 服务Ollama 默认不会在前台启动 HTTP 服务。要让其他程序调用它需要启动 API 服务。先确认 ollama 已经在后台运行ollama serve这个命令会启动一个监听在本机11434端口的服务。如果你的 ollama 是通过桌面版安装的服务可能已经自动运行。验证curl http://localhost:11434/v1/models如果返回 JSON 列表说明本地 API 服务已经就绪。5.4 用 Python 调用本地模型Ollama 提供 OpenAI 兼容接口路径是/v1/chat/completions所以你可以像调用 OpenAI API 一样调用本地模型。# 文件路径ollama_demo.py import requests import json url http://localhost:11434/v1/chat/completions payload { model: qwen2.5:7b, messages: [ {role: system, content: 你是一个乐于助人的技术助手回答要简洁准确。}, {role: user, content: 什么是上下文窗口} ], temperature: 0.2, stream: False } resp requests.post(url, jsonpayload, timeout120) resp.raise_for_status() data resp.json() print(data[choices][0][message][content])运行python ollama_demo.py脚本会输出模型对“什么是上下文窗口”的回答。5.5 流式调用本地模型流式输出在本地场景同样重要尤其当你希望用户看到“逐个字”生成过程时。# 文件路径ollama_stream_demo.py import requests url http://localhost:11434/v1/chat/completions payload { model: qwen2.5:7b, messages: [ {role: user, content: 写一段 100 字左右的自我介绍你是一个新闻写作助手。} ], stream: True } with requests.post(url, jsonpayload, streamTrue, timeout120) as resp: resp.raise_for_status() for line in resp.iter_lines(): if not line: continue line_str line.decode(utf-8) if not line_str.startswith(data:): continue json_str line_str[5:].strip() # SSE 结束时返回 [DONE] if json_str [DONE]: break import json chunk json.loads(json_str) delta chunk[choices][0][delta].get(content, ) if delta: print(delta, end, flushTrue)这段代码做了几件事通过streamTrue保持连接不断开。按行读取 SSE 格式的返回数据。过滤掉非data:开头的空闲行。遇到[DONE]结束解析。6. ComfyUI 与 LLM 必须在同一台电脑吗这是近期被频繁搜索的问题很多做 AI 绘画的人想把 LLM 接进 ComfyUI 工作流。直接回答不必须。6.1 先厘清 ComfyUI 的角色ComfyUI 是图像生成领域的工作流引擎它用节点图的方式组织 Stable Diffusion 模型的推理流程。而 LLM 主要负责文本语义处理例如优化提示词、生成图像描述、做智能对话。两者本身是独立的程序运行环境不同依赖的模型也不同。6.2 同机部署的场景如果你的机器是一台显存很大的工作站例如 RTX 4090 甚至多卡服务器那么把 ComfyUI 和 LLM 装在同一台机器上完全可行。优点本机访问延迟低。不涉及网络传输敏感数据。缺点显存和内存会被二者抢占。ComfyUI 出图时显存占用高LLM 推理可能变慢甚至显存溢出。6.3 分离部署的架构更推荐的方案是把 LLM 部署在另一台机器或者直接使用云端 API。架构如下ComfyUI绘图工作站 │ │ HTTP 请求 /v1/chat/completions ▼ LLM 服务另一台服务器 / 云端 API这种架构的好处绘图和文本生成的资源互不影响。LLM 服务可以被多个客户端复用不只是服务 ComfyUI。扩展性好可以按需升级任一端的 GPU。6.4 推荐实践方案在绘图机器上安装 ComfyUI。在另外一台带 GPU 的服务器上用 Ollama 部署 LLM。ComfyUI 中通过自定义节点调用http://服务器IP:11434/v1/chat/completions。如果本地没有 GPU就直接使用云端 LLM API。用一句话总结ComfyUI 和 LLM 是两种独立服务它们可以部署在同一台电脑上也可以跨机器、跨地域通过 HTTP 通信。选哪种方式取决于你的 GPU 资源、数据隐私要求和调用频率。7. 常见问题与排查清单无论在开发还是部署阶段大家经常遇到下面这些问题。问题现象常见原因解决思路调用 API 返回 429触发限流降低并发增加重试退避购买更高配额返回 401/403API Key 无效或没有权限检查 Key 是否拼写正确是否设置了出口 IP 白名单中文回答质量差提示词没有指定语言或模型对中文支持一般在 system prompt 中明确“用简体中文回答”必要时换中文优化模型本地模型加载后很慢显存不足模型被放到内存中计算换更小的模型或升级显卡开启量化加载Ollama 报端口被占用11434 端口已被其他进程占用修改 Ollama 服务端口或停掉占用端口的进程ComfyUI 调用 LLM 超时两台机器网络不通或 LLM 服务地址错误先用 curl 测试 LLM 服务地址是否可访问确认防火墙放行端口模型输出总是重复相同内容temperature 太低注意力退化适当提高 temperature或设置no_repeat_ngram_size之类的参数长文本被截断超出上下文窗口做文本切分、摘要或 RAG 检索减小单次输入长度排查时我建议遵循“从外到内”的顺序先确认网络连通性ping目标机器 /curl接口地址。再确认服务状态API 服务是否启动、端口是否监听。然后检查认证信息Key、Token、IP 白名单。最后检查请求内容模型名是否正确、Json 格式是否合法、参数是否超出限制。这套顺序能避免你一上来就翻模型参数浪费时间。8. LLM 工程落地最佳实践与工程建议最后一部分不讨论具体语法而是聊一聊把 LLM 接入真实项目时的工程经验。8.1 提示词工程是门槛最低、收益最高的优化手段很多人一上来就想微调模型但大多数业务场景根本不需要。先把提示词写清楚模型能力就能提升不少。好的提示词通常包含四要素角色告诉模型你希望它扮演什么。任务明确告诉模型要做什么。约束说明格式、字数、风格、是否允许猜测。上下文提供必要的背景信息或示例。示例你是一个资深 Python 开发工程师。 请审查下面这段代码重点检查内存泄漏和异常处理。 如果发现问题按“问题描述 - 风险等级 - 修改建议”的格式输出。 如果没有问题直接输出“未发现问题”。 代码 粘贴代码8.2 数据安全与隐私是必须考虑的红线不要把 API Key、模型账号写进代码仓库。涉及个人信息、商业秘密、未公开财务数据时优先考虑本地部署或私有化 API。如果使用云端 API务必在服务条款中确认数据不会被用于模型训练。所有外部输入在传给 LLM 之前要做基本过滤防止提示注入。8.3 成本控制Token 费用和并发资源消耗是主要成本来源。控制方法设置单次请求的最大响应 Token 数。多轮对话中使用摘要或截断来压缩历史消息。对高频场景使用本地小模型兜底低频高难度场景才调用云端大模型。对用户输入做长度限制防止恶意超长文本消耗 Token。8.4 可观测性与结果评估LLM 不像传统代码那样有确定性输出因此上线前必须建立评估机制。建议记录以下几类日志请求参数模型名、输入 Token 数、输出 Token 数、temperature。结果快照模型输出原文不要只存一个摘要。延迟与成本单次请求耗时、代币消耗。用户反馈点赞、点踩、复制、重新生成。只有拿到真实场景中的表现数据你才能判断某个调整到底是“变好了”还是“变差了”。8.5 版本管理与灰度发布模型升级不像普通代码升级那么简单。同一个提示词在新模型上可能结果完全不同。推荐做法固定模型版本不要使用“最新版”这样的动态标签直接上线。上线前用一组回归用例做对比。采用流量灰度先在内部或小范围内切换新模型确认效果后再全量放量。大模型的开发和应用核心不是追着榜单上的“最强模型”跑而是找到适合自己业务场景的接入方式。你可以用云端 API 快速验证想法也可以借助 Ollama 这类工具在本地构建私有推理服务还可以把 ComfyUI 和 LLM 拆开部署让各自发挥最擅长的能力。希望这篇文章能帮你少踩一些坑跑通属于你自己的第一个 LLM 实战项目。