“All-in LLM”创业潮里真正值得押注的到底是什么如果你最近关注科技新闻会频繁看到同一个判断大模型创业正在进入下半场。上半场是“做一个大模型”下半场是“用大模型做出一个真正有人用的产品”。这背后的转变非常明显。过去一年融资和热度都集中在预训练大模型本身仿佛参数规模就是护城河。但到了现在这个叙事正在松动。越来越多的创业公司开始意识到底座模型的能力差距在快速缩小真正决定生死的是能不能在模型之上找到一套别人抄不走、用户离不开的应用逻辑。这篇文章想聊的不是哪个模型跑分更高也不是某个框架的 API 怎么调。我想聊一个更实际的问题当所有人都在追“LLM 的下一件大事”时真正值得注意的方向是什么以及一个普通开发者或技术决策者应该用什么样的判断标准去看待这波机会。我会从几个角度展开先看看这波“LLM 创业”到底在争什么再拆一下创业公司做 LLM 应用时的典型技术路径然后结合真实工程中的问题比如模型选型、RAG、Agent 框架、ComfyUI 这类工具链的集成方式讲清楚哪些地方是机会哪些地方是坑最后给出一套可以用来筛项目的评估框架。如果你正在考虑用 LLM 做产品或者在纠结要不要追这波创业浪潮这篇文章值得收藏后慢慢看。技术只是起点真正的难点在技术之外的工程决策和产品判断。1. 为什么“下一个大事件”不再是训练一个更大的模型先给一个明确判断对绝大多数创业公司来说把资源押在自研底座大模型上已经不是最优选择。这不是说大模型不重要而是说它正在变成基础设施。就像 2010 年前后没人会自己写一个数据库引擎来支撑自己的网站2024 年之后也很少有创业公司有理由从零开始训练自己的千亿参数模型。原因不复杂就三点第一训练成本太高。一次完整的大规模预训练算力消耗以千万美元级别计算而且试错成本极高。一个参数和数据的组合没调好几百万美元就没了。这个成本结构决定了它只适合少数有巨额融资或云厂商背景的团队。第二开源模型的进步速度太快。从 Llama 系列到 Qwen、DeepSeek、Mistral开源模型的能力一直在快速逼近闭源模型。对大多数应用场景来说开源模型已经足够支撑产品落地而且可以私有化部署数据可控性更符合企业客户的要求。第三底座模型之间的能力差距正在压缩。你用一个 70B 的开源模型和调用一个顶级闭源 API在普通任务上的差距可能只有几个百分点。但对用户来说他们感知不到这 5% 的差异他们感知到的是产品好不好用、响应快不快、价格贵不贵。所以创业公司真正应该盯着的不是“再做一个模型”而是“在模型之上做出什么”。模型是新的水电煤但水电煤本身不产生差异化价值怎么用电、怎么用水来创造出新的体验和经济价值才是创业公司该研究的命题。这个判断同样适用于开发者个人。你不需要掌握大模型的预训练技术才能参与这波浪潮你更需要理解怎么把模型能力嵌入到具体的业务流程里设计好上下文、设计好工具、设计好反馈链路。这些能力恰恰不是模型训练者的核心技能而是应用层工程团队的核心技能。2. LLM 创业潮中真正在发生的变化从表面看这波创业潮的标签是“AI 原生应用”。但深入看变化发生在三个层次。2.1 交互层从“搜索”到“对话式任务完成”传统软件的逻辑是让用户自己在界面里找功能LLM 应用第一次让“对话”本身成为产品的主交互方式。用户不再需要记住复杂的菜单和按钮只需要用自然语言描述目标系统负责拆解和执行。这个变化看起来简单但对产品架构的影响是深远的。原来的软件设计是“界面 数据库”现在变成了“模型 上下文 工具”。原本由用户完成的任务拆解现在一部分转移到了模型和 Agent 身上。2.2 工程层从“规则引擎”到“模型编排”传统业务系统里如果你想要流程自动化靠的是写死状态机和规则。这种做法的优点是可控缺点是碰到非结构化输入时非常脆弱。LLM 应用改变了这个局面。现在你可以让模型理解一份合同、一封邮件、一段对话然后把它转成结构化数据再交给下游系统去执行。这就是过去几年里“文档智能”“智能客服”“流程自动化”重新火起来的原因。它们的底层能力升级了不再依赖固定模板而是靠模型的理解能力。2.3 商业层从“软件订阅”到“按效果付费”大模型带来的另一个变化是计费模式。API 按 token 计费意味着 AI 产品的边际成本不再趋近于零。这迫使创业公司从一开始就要思考单位经济模型一次调用赚多少钱、花多少钱、毛利是多少。这在传统 SaaS 里并不常见因为 SaaS 的边际交付成本几乎为零。但 LLM 应用不行每一次对话都是成本。如何通过缓存、模型分层、小模型兜底等方式控制成本变成了每个 LLM 创业公司都必须掌握的工程能力。这三个层次的变化决定了一个 LLM 创业公司的核心竞争力绝对不会只是一个模型权重文件而是产品体验、工程效率和单位经济模型三者的乘积。3. 创业公司做 LLM 应用的标准技术栈讲完趋势落到工程层面。现在一个创业公司想用 LLM 做产品标准技术栈是什么样的这里给你拆一下方便你对照评估自己的项目。3.1 模型层模型层的选择核心是在“闭源 API、开源模型私有化部署、托管开源模型服务”三者之间做权衡。闭源 API 上手最快效果最稳但存在数据出境、成本不可控、依赖厂商的问题。开源模型私有化部署数据安全最好但需要 GPU 资源和运维能力。托管开源模型服务则是一个折中方案比如各种 Model-as-a-Service 平台让你不用自建 GPU 集群就能以比较低的成本使用开源模型。创业公司在冷启动阶段我更推荐先用闭源 API 或托管服务把产品跑通等商业模式验证之后再考虑私有化部署。千万不要一上来就想着自己买卡训模型那是把风险前置了。3.2 框架层框架层的选择决定了你的应用开发和迭代速度。目前主流的 LLM 应用开发框架包括 LangChain、LlamaIndex、Spring AI 等。如果你的团队以 Java 为主Spring AI 会比较合适因为它深度整合了 Spring Boot 生态如果你的团队以 Python 为主LangChain 和 LlamaIndex 是更灵活的选择。但这里要提醒你一个容易踩的坑框架只是辅助不是核心竞争力。框架帮你把模型调用、Prompt 管理、工具调用这些样板代码封装好但真正决定产品体验的还是你的业务逻辑和 Prompt 设计。不要迷信某个框架也不要频繁换框架选定一个把业务跑通比什么都重要。3.3 数据层LLM 应用的数据层核心是 RAGRetrieval-Augmented Generation检索增强生成。RAG 解决的核心问题是“模型不知道自己不知道什么”。模型训练完后知识就冻结了但你的业务数据一直在更新。RAG 的思路是用户提出问题后先从一个向量数据库中检索最相关的文档片段把这些片段拼进上下文再让模型基于这些片段生成回答。这意味着你需要处理文档切分、向量化、向量数据库选型、检索策略、重排等一系列问题。在实际项目里RAG 的效果好坏往往不是模型决定的而是你的数据处理链路决定的。常见的坑包括切分粒度过大导致上下文超限、检索结果噪声太多、召回率低。这些都需要靠工程手段去调优。3.4 工具层工具层是 LLM 应用从“聊天机器人”进化为“数字员工”的关键。工具Tool/Function Calling让模型可以调用外部 API比如查天气、下单、查数据库、执行代码。工具调用的本质是让模型输出一个结构化的“意图 参数”然后由你的业务系统去真正执行。这就引出了 Agent智能体的概念Agent 不只是调用一次模型而是通过“思考 - 行动 - 观察”的循环自主完成一个多步骤任务。在工程实现上Agent 框架通常包括规划模块、记忆模块、工具模块和执行模块。看似很酷但如果你真的要在生产环境跑 Agent会发现可控性和准确性是最头疼的问题。所以我的建议是Agent 的能力要逐步放开先用“人工确认”兜底等准确率足够高再自动化。4. 模型选型为什么开源模型是创业公司更稳妥的切入点客观说开源模型这波浪潮直接改写了创业公司的技术经济学。过去你要做一个 AI 产品只能调用闭源 API每百万 token 的价格虽然一直在降但用户量一大成本就很可观。而开源模型让你可以用几块消费级显卡甚至一张中高端显卡就跑起来一个能完成基础任务的模型。对于很多垂直场景这是一个决定性的变量。以目前常见的开源模型家族为例Qwen通义千问系列、DeepSeek 系列、Llama 系列、Mistral 系列各自有不同的参数规模和擅长方向。你在选型时主要看这几个维度模型尺寸一般 7B、8B 适合边缘设备和轻量任务14B、32B 适合有 1 到 4 张显卡的单机部署70B 及以上适合要求更高推理质量但预算充足的团队。上下文长度你需要根据业务场景选择。如果只是普通问答8K 到 32K 就够如果要做长文档分析至少需要 128K。工具调用能力如果你要做 Agent一定要选择在函数调用上经过专门训练的模型否则模型经常会把参数格式写错。许可证不同模型的开源许可证不一样商用前一定要看仔细。只要是商用项目这一点怎么强调都不为过。在成本策略上一个更成熟的思路是“模型分层”简单任务走小模型复杂任务走大模型最难的才走闭源 API。这样既保证效果又控制成本。这个策略值得每个 LLM 创业团队内置到自己的路由逻辑里。5. RAG 与行业知识库落地的完整思路如果让我给 LLM 创业项目排一个优先级我会把“基于 RAG 的行业知识库”排在第一位。原因很简单它是离钱最近、最容易落地、用户感知最强的 LLM 应用之一。5.1 RAG 解决什么业务问题假设你在做法律行业的 AI 产品用户问“劳动合同到期不续签公司需要提前多少天通知”模型如果凭训练知识回答很可能给出一个普适但不精确的答案。如果把这个回答接入到具体的法条库、判例库和客户自己的合同库就必须用 RAG。RAG 的流程可以归纳为四步文档加载读取 PDF、Word、Markdown 等格式的业务文档。文档切分按语义或固定长度切成片段切分策略直接影响检索质量。向量化与存储用 Embedding 模型把片段向量化存入向量数据库。检索与生成用户提问时检索最相关的片段拼入 Prompt送给 LLM 生成回答。5.2 一个最小可用的 RAG 流程下面用一个非常精简的示例来展示 RAG 的完整链路。这个示例用的是 Python LangChain 风格的思路重点在于理解流程而不是端到端可复制代码。如果你想跑通可以基于这段逻辑换成你熟悉的库和模型。# 文件路径rag_demo.py from sentence_transformers import SentenceTransformer import chromadb from openai import OpenAI # 1. 加载本地文档并切分 documents [ 劳动合同到期不续签公司需要提前三十日书面通知劳动者。, 公司未提前通知而终止合同的应当支付经济补偿金。, ] chunk_size 50 chunks [doc[i:ichunk_size] for doc in documents for i in range(0, len(doc), chunk_size)] # 2. 向量化 embed_model SentenceTransformer(BAAI/bge-small-zh-v1.5) vectors embed_model.encode(chunks).tolist() # 3. 存入向量数据库 client chromadb.Client() collection client.create_collection(legal_kb) for idx, (chunk, vector) in enumerate(zip(chunks, vectors)): collection.add(ids[str(idx)], embeddings[vector], documents[chunk]) # 4. 检索 生成 query 公司不续签合同需要提前多久通知 query_vec embed_model.encode([query]).tolist() results collection.query(query_embeddingsquery_vec, n_results2) context \n.join([doc for doc in results[documents][0]]) client_llm OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) prompt f请基于以下资料回答问题\n{context}\n\n问题{query}\n回答 response client_llm.chat.completions.create( modelqwen2.5-7b-instruct, messages[{role: user, content: prompt}] ) print(response.choices[0].message.content)这段代码演示了三件事文本切分、向量检索、上下文增强生成。实际项目中你还需要加入文档解析、清洗、元数据过滤、重排模型、反馈闭环等环节但最小链路已经足够帮你理解 RAG 的运转逻辑。5.3 实际落地时的三个关键决策第一检索粒度怎么定。切分太粗片段之间的噪音会很多切分太细上下文信息不完整。一般建议结合文档结构和业务语义来切分比如按章节、按条款、按段落。第二向量库选哪个。常见的有 Chroma、Qdrant、Milvus、pgvector。小项目先用 Chroma 或 pgvector数据量上来以后再引入 Milvus。第三怎么让答案更准确。RAG 的答案不是一次性生成的你可以加入“重排”Rerank环节先把向量检索出的结果用重排模型重新排序再给 LLM 生成。这个操作通常能明显提升答案质量。6. Agent 与工具调用下半场最大的变量如果说 RAG 是 LLM 应用的基本盘那 Agent 就是下一阶段最大的变量。为什么这么说因为 RAG 说到底还是“检索 生成”的静态模式而 Agent 是“目标驱动的自主循环”。它不只是回答问题它能帮你完成任务。6.1 Agent 和普通 Chatbot 的区别普通 Chatbot 的交互是单轮的用户问一句模型答一句。 Agent 的交互是多轮的它会先把一个大目标拆解成多个子任务然后逐个调用工具完成这些子任务最后把结果汇总返回给用户。举个例子。你让普通 Chatbot“帮我查一下昨天的销售数据并生成一份摘要”它可能只能告诉你“我无法直接访问数据库”。但一个接入了数据库工具的 Agent可以完成生成 SQL、查询数据库、分析结果、生成摘要、以指定格式输出。6.2 Agent 框架的工程结构从工程视角看Agent 的完整结构包含以下部分规划模块决定下一步做什么。记忆模块保存历史信息分为短期记忆当前会话和长期记忆跨会话。工具模块定义 Agent 可以调用的函数集合。执行模块调用工具并处理结果。下面是一个精简的工具调用示例演示模型如何输出结构化的工具参数# 文件路径agent_tool_demo.py def get_weather(city: str) - str: 模拟查询天气的工具 return f{city} 今天晴气温 22 摄氏度。 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } } ] # 用户请求 user_message 北京明天适合出门吗 # 实际项目中这里会将 messages tools 发给 LLM # LLM 返回的结构应为 # { # name: get_weather, # arguments: {\city\: \北京\} # } # 然后业务系统解析参数调用 get_weather再把结果追加进 messages print(工具定义已就绪等待 LLM 返回调用意图)在实际工程中你还需要处理错误重试、工具调用超时、权限校验、结果截断等一系列问题。Agent 越强大出错的边界也越大所以生产环境一定要加护栏。6.3 做 Agent 的冷启动建议我的建议是不要一开始就做一个完全自主的 Agent。更稳妥的路线是先做“单步工具调用”用户问一句模型决定调用哪个工具。再做“固定流程 Agent”把流程写成多步状态机每一步由模型决定参数。最后才做“完全自主 Agent”让模型自己规划步骤自己决定执行顺序。核心原则是用越多的人工确定性去约束模型的随机性系统就越可控。这个原则在 Agent 落地时尤其重要。7. ComfyUI 与 LLM 的集成必须同一台电脑吗在相关热搜词里有一个很有意思的问题ComfyUI 与 LLM 必须在同一台电脑上么这个问题看起来很小但它背后是很多做多模态应用的开发者都会遇到的真实困惑。先说明一下背景。ComfyUI 是一个基于节点式工作流的 AI 绘图工具主要面向 Stable Diffusion 这类扩散模型的图像生成。它本身不是 LLM 工具但在多模态 Agent 或内容生成工作流里经常需要把 LLM 和 ComfyUI 串联起来让 LLM 负责理解用户意图并生成提示词ComfyUI 负责最终生成图像。7.1 直接回答不需要必须在同一台电脑上ComfyUI 和 LLM 不需要安装在同一台电脑上它们之间本质上只是服务之间的网络调用关系。常见做法有几种LLM 调用远程 APIComfyUI 在本地运行这是最轻量的组合LLM 负责生成提示词ComfyUI 负责画图。LLM 本地部署ComfyUI 本地部署两者都在同一台机器通过 localhost 访问适合单机演示和开发调试。LLM 和 ComfyUI 都分别部署成独立服务通过 HTTP API 互相调用这种方式最灵活适合生产环境。如果你要在工作流里打通两者最常见的方式是先让 LLM 生成一个结构化的 JSON里面包含正向提示词、反向提示词、采样参数等然后调用 ComfyUI 的 HTTP API 提交工作流。7.2 ComfyUI 的工作流调用逻辑ComfyUI 支持通过 API 方式提交工作流。工作流本质上是一个 JSON 文件描述了节点之间的连接关系。你需要在 ComfyUI 的 Web UI 中把工作流设计好然后导出为 API 格式的 JSON再通过 HTTP 请求提交。下面是一个用 Python 调用 ComfyUI API 的最小示例# 文件路径comfyui_client.py import json import random from urllib import request # 1. 读取导出的工作流 JSON with open(workflow_api.json, r, encodingutf-8) as f: workflow json.load(f) # 2. 修改工作流中的提示词节点 # 实际节点 ID 和字段名需要根据你的工作流 JSON 调整 for node_id, node in workflow.items(): if node.get(class_type) CLIPTextEncode: if node[inputs].get(text, ).startswith(positive): node[inputs][text] a beautiful mountain landscape, high quality elif node[inputs].get(text, ).startswith(negative): node[inputs][text] blurry, low quality # 3. 提交到 ComfyUI 服务 data json.dumps({prompt: workflow, client_id: my-client}).encode(utf-8) req request.Request( http://127.0.0.1:8188/prompt, datadata, headers{Content-Type: application/json} ) with request.urlopen(req) as resp: print(resp.status) # 4. 通过 WebSocket 或轮询接口获取生成结果这个示例说明了关键点ComfyUI 和 LLM 之间是服务调用关系不是进程内依赖。只要网络可达它们可以部署在不同的机器、不同的容器、甚至是不同的云环境里。至于具体网络拓扑怎么设计取决于你的延迟要求、数据安全要求和资源成本。8. LLM 创业项目的评估框架用这套标准筛掉伪需求聊完了技术最后聊聊判断力。技术能力决定你能不能做出来判断力决定你做的这个东西值不值得做。我建议用下面的评估框架来判断一个 LLM 创业项目是否值得投入评估维度关键问题判断标准需求真实性用户是真的需要还是你“觉得”他需要能找到付费意愿数据或已有手工流程在验证需求模型依赖度模型能力提升后你的产品价值会被削弱吗产品价值应该来自数据和流程而不是模型本身数据壁垒你的数据能持续积累并形成复利吗用户用得越久产品越聪明迁移成本越高成本结构每个付费用户的毛利是正的吗算清楚单次交互成本不要把成本后置工程可控性模型输出出错时你的系统能兜底吗有校验机制、人工确认、回退路径市场时机为什么是现在模型能力刚跨过某个阈值或成本刚降到合理区间用这套框架去筛很多项目都会露出原型纯套壳应用只是调 API 加 Prompt模型能力升级后用户可以直接用原生产品没有数据沉淀没有留存淘汰。垂直行业知识库有客户私有数据有行业术语库有历史反馈样本模型越强它越强这是好生意。自动化工作流工具只要把客户内部的工具链打通形成流程沉淀更换成本高这是好生意。通用聊天助手没有数据壁垒没有特定场景没有替代成本竞争激烈不建议入场。一个比较残酷的现实是在这波浪潮里模型本身会持续降价、持续变强这会不断碾压“薄应用”的生存空间。只有那些能把业务数据、用户行为、反馈闭环沉淀成资产的项目才能跑出来。9. LLM 创业的常见问题与应对建议这里整理几个 LLM 创业和技术落地中的高频问题按可操作顺序给出建议。问题现象可能原因排查方向解决方案RAG 检索结果不相关文档切分粒度不合理或向量化模型不匹配检查召回结果反馈查看检索片段与问题的相关性调整切分策略引入重排模型换用更适合中文的 Embedding 模型Agent 频繁工具调用出错模型工具调用能力不足或参数格式不稳定查看模型输出的工具参数是否能被正确解析换用专攻函数调用的模型增加参数校验和错误重试模型回答幻觉严重上下文信息不足或模型温度参数过高检查 Prompt 中提供的上下文是否足够降低温度加入“没有资料就回答不知道”的约束强化 RAG 上下文API 调用成本高所有请求都走大模型统计各类型请求的 token 消耗实现模型路由简单任务走小模型复杂任务才走大模型推理速度慢模型参数量过大或 GPU 部署方式不合理查看单次推理延迟和吞吐瓶颈使用量化模型、蒸馏模型开启 vLLM 等推理加速框架或用多卡切分用户认为回答不够专业领域知识不足只靠通用模型检查是否有足够的行业语料进入知识库构建行业知识库 RAG添加术语表和问答样本进行微调这些问题的解决不是一次性的而是一个持续调优的过程。LLM 应用上线只是开始数据回流和效果优化才是长期工作。10. 给创业者和开发者的几个具体建议最后落到行动层面。10.1 对创业者第一把“卖模型”这个念头忘掉。你卖的是用户愿意付费的解决方案不是模型本身。第二从一个小而具体的场景切入。不要做“帮所有人解决所有问题的 AI”要做“帮某类人解决一个高频问题的 AI”。比如“帮电商运营自动生成商品描述”“帮律师检索类案并生成分析摘要”这类场景需求明确付费意愿强而且模型能力已经足够。第三成本要放在商业模式里去设计。你可以在产品里把模型调用成本降下来但更要紧的是用户付的钱能不能覆盖模型调用成本。如果答案是否那就需要重新考虑定价策略或者用更便宜的模型方案。10.2 对开发者第一把 RAG 和 Agent 这两个技术方向吃透。它们是目前 LLM 应用工程化最核心的两个能力。第二动手跑通一个最小项目。不用大而全就从“读文档、向量化、检索、生成”开始把链路跑通比看一百篇教程都有用。第三保持对模型更新的敏感度。开源模型每隔几个月就有新版本但不要追新选一个稳定的版本把业务跑深比频繁换模型更重要。第四学会用推理加速工具。如果你做私有化部署vLLM、TensorRT-LLM 这类推理框架是绕不过去的它们能显著提升吞吐、降低成本。11. 总结LLM 创业的本质是“用模型能力重构一个具体行业”回头看这波“Startups are chasing the next big thing in LLMs”的浪潮我的结论是真正值得称得上“next big thing”的不是又一个参数更大的模型而是那些把模型能力嵌入到真实生产流程、真实用户场景中从而创造新的效率增量和体验增量的应用。模型能力会继续迭代开源模型会继续进化API 价格会继续下降。这些条件对一个应用型创业公司来说都是利好。这意味着你可以用更低成本获得更好的底座能力也更考验你在数据、流程、体验和成本上的差异化能力。如果你现在正在做 LLM 相关的项目建议把精力放在这几个方向把 RAG 的知识库效果调到最优。把 Agent 工具调用的稳定性和可控性做到位。把单位交互成本算清楚。把用户反馈的数据回流机制建立起来。做对这几件事即使模型底座换了一轮又一轮你的产品依然有价值。这轮浪潮里技术是入场券但真正的护城河永远是你围绕具体场景创造的那一层别人难以复制的价值。 LLM创业下半场：从模型竞赛到应用落地的真正机会
“All-in LLM”创业潮里真正值得押注的到底是什么如果你最近关注科技新闻会频繁看到同一个判断大模型创业正在进入下半场。上半场是“做一个大模型”下半场是“用大模型做出一个真正有人用的产品”。这背后的转变非常明显。过去一年融资和热度都集中在预训练大模型本身仿佛参数规模就是护城河。但到了现在这个叙事正在松动。越来越多的创业公司开始意识到底座模型的能力差距在快速缩小真正决定生死的是能不能在模型之上找到一套别人抄不走、用户离不开的应用逻辑。这篇文章想聊的不是哪个模型跑分更高也不是某个框架的 API 怎么调。我想聊一个更实际的问题当所有人都在追“LLM 的下一件大事”时真正值得注意的方向是什么以及一个普通开发者或技术决策者应该用什么样的判断标准去看待这波机会。我会从几个角度展开先看看这波“LLM 创业”到底在争什么再拆一下创业公司做 LLM 应用时的典型技术路径然后结合真实工程中的问题比如模型选型、RAG、Agent 框架、ComfyUI 这类工具链的集成方式讲清楚哪些地方是机会哪些地方是坑最后给出一套可以用来筛项目的评估框架。如果你正在考虑用 LLM 做产品或者在纠结要不要追这波创业浪潮这篇文章值得收藏后慢慢看。技术只是起点真正的难点在技术之外的工程决策和产品判断。1. 为什么“下一个大事件”不再是训练一个更大的模型先给一个明确判断对绝大多数创业公司来说把资源押在自研底座大模型上已经不是最优选择。这不是说大模型不重要而是说它正在变成基础设施。就像 2010 年前后没人会自己写一个数据库引擎来支撑自己的网站2024 年之后也很少有创业公司有理由从零开始训练自己的千亿参数模型。原因不复杂就三点第一训练成本太高。一次完整的大规模预训练算力消耗以千万美元级别计算而且试错成本极高。一个参数和数据的组合没调好几百万美元就没了。这个成本结构决定了它只适合少数有巨额融资或云厂商背景的团队。第二开源模型的进步速度太快。从 Llama 系列到 Qwen、DeepSeek、Mistral开源模型的能力一直在快速逼近闭源模型。对大多数应用场景来说开源模型已经足够支撑产品落地而且可以私有化部署数据可控性更符合企业客户的要求。第三底座模型之间的能力差距正在压缩。你用一个 70B 的开源模型和调用一个顶级闭源 API在普通任务上的差距可能只有几个百分点。但对用户来说他们感知不到这 5% 的差异他们感知到的是产品好不好用、响应快不快、价格贵不贵。所以创业公司真正应该盯着的不是“再做一个模型”而是“在模型之上做出什么”。模型是新的水电煤但水电煤本身不产生差异化价值怎么用电、怎么用水来创造出新的体验和经济价值才是创业公司该研究的命题。这个判断同样适用于开发者个人。你不需要掌握大模型的预训练技术才能参与这波浪潮你更需要理解怎么把模型能力嵌入到具体的业务流程里设计好上下文、设计好工具、设计好反馈链路。这些能力恰恰不是模型训练者的核心技能而是应用层工程团队的核心技能。2. LLM 创业潮中真正在发生的变化从表面看这波创业潮的标签是“AI 原生应用”。但深入看变化发生在三个层次。2.1 交互层从“搜索”到“对话式任务完成”传统软件的逻辑是让用户自己在界面里找功能LLM 应用第一次让“对话”本身成为产品的主交互方式。用户不再需要记住复杂的菜单和按钮只需要用自然语言描述目标系统负责拆解和执行。这个变化看起来简单但对产品架构的影响是深远的。原来的软件设计是“界面 数据库”现在变成了“模型 上下文 工具”。原本由用户完成的任务拆解现在一部分转移到了模型和 Agent 身上。2.2 工程层从“规则引擎”到“模型编排”传统业务系统里如果你想要流程自动化靠的是写死状态机和规则。这种做法的优点是可控缺点是碰到非结构化输入时非常脆弱。LLM 应用改变了这个局面。现在你可以让模型理解一份合同、一封邮件、一段对话然后把它转成结构化数据再交给下游系统去执行。这就是过去几年里“文档智能”“智能客服”“流程自动化”重新火起来的原因。它们的底层能力升级了不再依赖固定模板而是靠模型的理解能力。2.3 商业层从“软件订阅”到“按效果付费”大模型带来的另一个变化是计费模式。API 按 token 计费意味着 AI 产品的边际成本不再趋近于零。这迫使创业公司从一开始就要思考单位经济模型一次调用赚多少钱、花多少钱、毛利是多少。这在传统 SaaS 里并不常见因为 SaaS 的边际交付成本几乎为零。但 LLM 应用不行每一次对话都是成本。如何通过缓存、模型分层、小模型兜底等方式控制成本变成了每个 LLM 创业公司都必须掌握的工程能力。这三个层次的变化决定了一个 LLM 创业公司的核心竞争力绝对不会只是一个模型权重文件而是产品体验、工程效率和单位经济模型三者的乘积。3. 创业公司做 LLM 应用的标准技术栈讲完趋势落到工程层面。现在一个创业公司想用 LLM 做产品标准技术栈是什么样的这里给你拆一下方便你对照评估自己的项目。3.1 模型层模型层的选择核心是在“闭源 API、开源模型私有化部署、托管开源模型服务”三者之间做权衡。闭源 API 上手最快效果最稳但存在数据出境、成本不可控、依赖厂商的问题。开源模型私有化部署数据安全最好但需要 GPU 资源和运维能力。托管开源模型服务则是一个折中方案比如各种 Model-as-a-Service 平台让你不用自建 GPU 集群就能以比较低的成本使用开源模型。创业公司在冷启动阶段我更推荐先用闭源 API 或托管服务把产品跑通等商业模式验证之后再考虑私有化部署。千万不要一上来就想着自己买卡训模型那是把风险前置了。3.2 框架层框架层的选择决定了你的应用开发和迭代速度。目前主流的 LLM 应用开发框架包括 LangChain、LlamaIndex、Spring AI 等。如果你的团队以 Java 为主Spring AI 会比较合适因为它深度整合了 Spring Boot 生态如果你的团队以 Python 为主LangChain 和 LlamaIndex 是更灵活的选择。但这里要提醒你一个容易踩的坑框架只是辅助不是核心竞争力。框架帮你把模型调用、Prompt 管理、工具调用这些样板代码封装好但真正决定产品体验的还是你的业务逻辑和 Prompt 设计。不要迷信某个框架也不要频繁换框架选定一个把业务跑通比什么都重要。3.3 数据层LLM 应用的数据层核心是 RAGRetrieval-Augmented Generation检索增强生成。RAG 解决的核心问题是“模型不知道自己不知道什么”。模型训练完后知识就冻结了但你的业务数据一直在更新。RAG 的思路是用户提出问题后先从一个向量数据库中检索最相关的文档片段把这些片段拼进上下文再让模型基于这些片段生成回答。这意味着你需要处理文档切分、向量化、向量数据库选型、检索策略、重排等一系列问题。在实际项目里RAG 的效果好坏往往不是模型决定的而是你的数据处理链路决定的。常见的坑包括切分粒度过大导致上下文超限、检索结果噪声太多、召回率低。这些都需要靠工程手段去调优。3.4 工具层工具层是 LLM 应用从“聊天机器人”进化为“数字员工”的关键。工具Tool/Function Calling让模型可以调用外部 API比如查天气、下单、查数据库、执行代码。工具调用的本质是让模型输出一个结构化的“意图 参数”然后由你的业务系统去真正执行。这就引出了 Agent智能体的概念Agent 不只是调用一次模型而是通过“思考 - 行动 - 观察”的循环自主完成一个多步骤任务。在工程实现上Agent 框架通常包括规划模块、记忆模块、工具模块和执行模块。看似很酷但如果你真的要在生产环境跑 Agent会发现可控性和准确性是最头疼的问题。所以我的建议是Agent 的能力要逐步放开先用“人工确认”兜底等准确率足够高再自动化。4. 模型选型为什么开源模型是创业公司更稳妥的切入点客观说开源模型这波浪潮直接改写了创业公司的技术经济学。过去你要做一个 AI 产品只能调用闭源 API每百万 token 的价格虽然一直在降但用户量一大成本就很可观。而开源模型让你可以用几块消费级显卡甚至一张中高端显卡就跑起来一个能完成基础任务的模型。对于很多垂直场景这是一个决定性的变量。以目前常见的开源模型家族为例Qwen通义千问系列、DeepSeek 系列、Llama 系列、Mistral 系列各自有不同的参数规模和擅长方向。你在选型时主要看这几个维度模型尺寸一般 7B、8B 适合边缘设备和轻量任务14B、32B 适合有 1 到 4 张显卡的单机部署70B 及以上适合要求更高推理质量但预算充足的团队。上下文长度你需要根据业务场景选择。如果只是普通问答8K 到 32K 就够如果要做长文档分析至少需要 128K。工具调用能力如果你要做 Agent一定要选择在函数调用上经过专门训练的模型否则模型经常会把参数格式写错。许可证不同模型的开源许可证不一样商用前一定要看仔细。只要是商用项目这一点怎么强调都不为过。在成本策略上一个更成熟的思路是“模型分层”简单任务走小模型复杂任务走大模型最难的才走闭源 API。这样既保证效果又控制成本。这个策略值得每个 LLM 创业团队内置到自己的路由逻辑里。5. RAG 与行业知识库落地的完整思路如果让我给 LLM 创业项目排一个优先级我会把“基于 RAG 的行业知识库”排在第一位。原因很简单它是离钱最近、最容易落地、用户感知最强的 LLM 应用之一。5.1 RAG 解决什么业务问题假设你在做法律行业的 AI 产品用户问“劳动合同到期不续签公司需要提前多少天通知”模型如果凭训练知识回答很可能给出一个普适但不精确的答案。如果把这个回答接入到具体的法条库、判例库和客户自己的合同库就必须用 RAG。RAG 的流程可以归纳为四步文档加载读取 PDF、Word、Markdown 等格式的业务文档。文档切分按语义或固定长度切成片段切分策略直接影响检索质量。向量化与存储用 Embedding 模型把片段向量化存入向量数据库。检索与生成用户提问时检索最相关的片段拼入 Prompt送给 LLM 生成回答。5.2 一个最小可用的 RAG 流程下面用一个非常精简的示例来展示 RAG 的完整链路。这个示例用的是 Python LangChain 风格的思路重点在于理解流程而不是端到端可复制代码。如果你想跑通可以基于这段逻辑换成你熟悉的库和模型。# 文件路径rag_demo.py from sentence_transformers import SentenceTransformer import chromadb from openai import OpenAI # 1. 加载本地文档并切分 documents [ 劳动合同到期不续签公司需要提前三十日书面通知劳动者。, 公司未提前通知而终止合同的应当支付经济补偿金。, ] chunk_size 50 chunks [doc[i:ichunk_size] for doc in documents for i in range(0, len(doc), chunk_size)] # 2. 向量化 embed_model SentenceTransformer(BAAI/bge-small-zh-v1.5) vectors embed_model.encode(chunks).tolist() # 3. 存入向量数据库 client chromadb.Client() collection client.create_collection(legal_kb) for idx, (chunk, vector) in enumerate(zip(chunks, vectors)): collection.add(ids[str(idx)], embeddings[vector], documents[chunk]) # 4. 检索 生成 query 公司不续签合同需要提前多久通知 query_vec embed_model.encode([query]).tolist() results collection.query(query_embeddingsquery_vec, n_results2) context \n.join([doc for doc in results[documents][0]]) client_llm OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) prompt f请基于以下资料回答问题\n{context}\n\n问题{query}\n回答 response client_llm.chat.completions.create( modelqwen2.5-7b-instruct, messages[{role: user, content: prompt}] ) print(response.choices[0].message.content)这段代码演示了三件事文本切分、向量检索、上下文增强生成。实际项目中你还需要加入文档解析、清洗、元数据过滤、重排模型、反馈闭环等环节但最小链路已经足够帮你理解 RAG 的运转逻辑。5.3 实际落地时的三个关键决策第一检索粒度怎么定。切分太粗片段之间的噪音会很多切分太细上下文信息不完整。一般建议结合文档结构和业务语义来切分比如按章节、按条款、按段落。第二向量库选哪个。常见的有 Chroma、Qdrant、Milvus、pgvector。小项目先用 Chroma 或 pgvector数据量上来以后再引入 Milvus。第三怎么让答案更准确。RAG 的答案不是一次性生成的你可以加入“重排”Rerank环节先把向量检索出的结果用重排模型重新排序再给 LLM 生成。这个操作通常能明显提升答案质量。6. Agent 与工具调用下半场最大的变量如果说 RAG 是 LLM 应用的基本盘那 Agent 就是下一阶段最大的变量。为什么这么说因为 RAG 说到底还是“检索 生成”的静态模式而 Agent 是“目标驱动的自主循环”。它不只是回答问题它能帮你完成任务。6.1 Agent 和普通 Chatbot 的区别普通 Chatbot 的交互是单轮的用户问一句模型答一句。 Agent 的交互是多轮的它会先把一个大目标拆解成多个子任务然后逐个调用工具完成这些子任务最后把结果汇总返回给用户。举个例子。你让普通 Chatbot“帮我查一下昨天的销售数据并生成一份摘要”它可能只能告诉你“我无法直接访问数据库”。但一个接入了数据库工具的 Agent可以完成生成 SQL、查询数据库、分析结果、生成摘要、以指定格式输出。6.2 Agent 框架的工程结构从工程视角看Agent 的完整结构包含以下部分规划模块决定下一步做什么。记忆模块保存历史信息分为短期记忆当前会话和长期记忆跨会话。工具模块定义 Agent 可以调用的函数集合。执行模块调用工具并处理结果。下面是一个精简的工具调用示例演示模型如何输出结构化的工具参数# 文件路径agent_tool_demo.py def get_weather(city: str) - str: 模拟查询天气的工具 return f{city} 今天晴气温 22 摄氏度。 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名} }, required: [city] } } } ] # 用户请求 user_message 北京明天适合出门吗 # 实际项目中这里会将 messages tools 发给 LLM # LLM 返回的结构应为 # { # name: get_weather, # arguments: {\city\: \北京\} # } # 然后业务系统解析参数调用 get_weather再把结果追加进 messages print(工具定义已就绪等待 LLM 返回调用意图)在实际工程中你还需要处理错误重试、工具调用超时、权限校验、结果截断等一系列问题。Agent 越强大出错的边界也越大所以生产环境一定要加护栏。6.3 做 Agent 的冷启动建议我的建议是不要一开始就做一个完全自主的 Agent。更稳妥的路线是先做“单步工具调用”用户问一句模型决定调用哪个工具。再做“固定流程 Agent”把流程写成多步状态机每一步由模型决定参数。最后才做“完全自主 Agent”让模型自己规划步骤自己决定执行顺序。核心原则是用越多的人工确定性去约束模型的随机性系统就越可控。这个原则在 Agent 落地时尤其重要。7. ComfyUI 与 LLM 的集成必须同一台电脑吗在相关热搜词里有一个很有意思的问题ComfyUI 与 LLM 必须在同一台电脑上么这个问题看起来很小但它背后是很多做多模态应用的开发者都会遇到的真实困惑。先说明一下背景。ComfyUI 是一个基于节点式工作流的 AI 绘图工具主要面向 Stable Diffusion 这类扩散模型的图像生成。它本身不是 LLM 工具但在多模态 Agent 或内容生成工作流里经常需要把 LLM 和 ComfyUI 串联起来让 LLM 负责理解用户意图并生成提示词ComfyUI 负责最终生成图像。7.1 直接回答不需要必须在同一台电脑上ComfyUI 和 LLM 不需要安装在同一台电脑上它们之间本质上只是服务之间的网络调用关系。常见做法有几种LLM 调用远程 APIComfyUI 在本地运行这是最轻量的组合LLM 负责生成提示词ComfyUI 负责画图。LLM 本地部署ComfyUI 本地部署两者都在同一台机器通过 localhost 访问适合单机演示和开发调试。LLM 和 ComfyUI 都分别部署成独立服务通过 HTTP API 互相调用这种方式最灵活适合生产环境。如果你要在工作流里打通两者最常见的方式是先让 LLM 生成一个结构化的 JSON里面包含正向提示词、反向提示词、采样参数等然后调用 ComfyUI 的 HTTP API 提交工作流。7.2 ComfyUI 的工作流调用逻辑ComfyUI 支持通过 API 方式提交工作流。工作流本质上是一个 JSON 文件描述了节点之间的连接关系。你需要在 ComfyUI 的 Web UI 中把工作流设计好然后导出为 API 格式的 JSON再通过 HTTP 请求提交。下面是一个用 Python 调用 ComfyUI API 的最小示例# 文件路径comfyui_client.py import json import random from urllib import request # 1. 读取导出的工作流 JSON with open(workflow_api.json, r, encodingutf-8) as f: workflow json.load(f) # 2. 修改工作流中的提示词节点 # 实际节点 ID 和字段名需要根据你的工作流 JSON 调整 for node_id, node in workflow.items(): if node.get(class_type) CLIPTextEncode: if node[inputs].get(text, ).startswith(positive): node[inputs][text] a beautiful mountain landscape, high quality elif node[inputs].get(text, ).startswith(negative): node[inputs][text] blurry, low quality # 3. 提交到 ComfyUI 服务 data json.dumps({prompt: workflow, client_id: my-client}).encode(utf-8) req request.Request( http://127.0.0.1:8188/prompt, datadata, headers{Content-Type: application/json} ) with request.urlopen(req) as resp: print(resp.status) # 4. 通过 WebSocket 或轮询接口获取生成结果这个示例说明了关键点ComfyUI 和 LLM 之间是服务调用关系不是进程内依赖。只要网络可达它们可以部署在不同的机器、不同的容器、甚至是不同的云环境里。至于具体网络拓扑怎么设计取决于你的延迟要求、数据安全要求和资源成本。8. LLM 创业项目的评估框架用这套标准筛掉伪需求聊完了技术最后聊聊判断力。技术能力决定你能不能做出来判断力决定你做的这个东西值不值得做。我建议用下面的评估框架来判断一个 LLM 创业项目是否值得投入评估维度关键问题判断标准需求真实性用户是真的需要还是你“觉得”他需要能找到付费意愿数据或已有手工流程在验证需求模型依赖度模型能力提升后你的产品价值会被削弱吗产品价值应该来自数据和流程而不是模型本身数据壁垒你的数据能持续积累并形成复利吗用户用得越久产品越聪明迁移成本越高成本结构每个付费用户的毛利是正的吗算清楚单次交互成本不要把成本后置工程可控性模型输出出错时你的系统能兜底吗有校验机制、人工确认、回退路径市场时机为什么是现在模型能力刚跨过某个阈值或成本刚降到合理区间用这套框架去筛很多项目都会露出原型纯套壳应用只是调 API 加 Prompt模型能力升级后用户可以直接用原生产品没有数据沉淀没有留存淘汰。垂直行业知识库有客户私有数据有行业术语库有历史反馈样本模型越强它越强这是好生意。自动化工作流工具只要把客户内部的工具链打通形成流程沉淀更换成本高这是好生意。通用聊天助手没有数据壁垒没有特定场景没有替代成本竞争激烈不建议入场。一个比较残酷的现实是在这波浪潮里模型本身会持续降价、持续变强这会不断碾压“薄应用”的生存空间。只有那些能把业务数据、用户行为、反馈闭环沉淀成资产的项目才能跑出来。9. LLM 创业的常见问题与应对建议这里整理几个 LLM 创业和技术落地中的高频问题按可操作顺序给出建议。问题现象可能原因排查方向解决方案RAG 检索结果不相关文档切分粒度不合理或向量化模型不匹配检查召回结果反馈查看检索片段与问题的相关性调整切分策略引入重排模型换用更适合中文的 Embedding 模型Agent 频繁工具调用出错模型工具调用能力不足或参数格式不稳定查看模型输出的工具参数是否能被正确解析换用专攻函数调用的模型增加参数校验和错误重试模型回答幻觉严重上下文信息不足或模型温度参数过高检查 Prompt 中提供的上下文是否足够降低温度加入“没有资料就回答不知道”的约束强化 RAG 上下文API 调用成本高所有请求都走大模型统计各类型请求的 token 消耗实现模型路由简单任务走小模型复杂任务才走大模型推理速度慢模型参数量过大或 GPU 部署方式不合理查看单次推理延迟和吞吐瓶颈使用量化模型、蒸馏模型开启 vLLM 等推理加速框架或用多卡切分用户认为回答不够专业领域知识不足只靠通用模型检查是否有足够的行业语料进入知识库构建行业知识库 RAG添加术语表和问答样本进行微调这些问题的解决不是一次性的而是一个持续调优的过程。LLM 应用上线只是开始数据回流和效果优化才是长期工作。10. 给创业者和开发者的几个具体建议最后落到行动层面。10.1 对创业者第一把“卖模型”这个念头忘掉。你卖的是用户愿意付费的解决方案不是模型本身。第二从一个小而具体的场景切入。不要做“帮所有人解决所有问题的 AI”要做“帮某类人解决一个高频问题的 AI”。比如“帮电商运营自动生成商品描述”“帮律师检索类案并生成分析摘要”这类场景需求明确付费意愿强而且模型能力已经足够。第三成本要放在商业模式里去设计。你可以在产品里把模型调用成本降下来但更要紧的是用户付的钱能不能覆盖模型调用成本。如果答案是否那就需要重新考虑定价策略或者用更便宜的模型方案。10.2 对开发者第一把 RAG 和 Agent 这两个技术方向吃透。它们是目前 LLM 应用工程化最核心的两个能力。第二动手跑通一个最小项目。不用大而全就从“读文档、向量化、检索、生成”开始把链路跑通比看一百篇教程都有用。第三保持对模型更新的敏感度。开源模型每隔几个月就有新版本但不要追新选一个稳定的版本把业务跑深比频繁换模型更重要。第四学会用推理加速工具。如果你做私有化部署vLLM、TensorRT-LLM 这类推理框架是绕不过去的它们能显著提升吞吐、降低成本。11. 总结LLM 创业的本质是“用模型能力重构一个具体行业”回头看这波“Startups are chasing the next big thing in LLMs”的浪潮我的结论是真正值得称得上“next big thing”的不是又一个参数更大的模型而是那些把模型能力嵌入到真实生产流程、真实用户场景中从而创造新的效率增量和体验增量的应用。模型能力会继续迭代开源模型会继续进化API 价格会继续下降。这些条件对一个应用型创业公司来说都是利好。这意味着你可以用更低成本获得更好的底座能力也更考验你在数据、流程、体验和成本上的差异化能力。如果你现在正在做 LLM 相关的项目建议把精力放在这几个方向把 RAG 的知识库效果调到最优。把 Agent 工具调用的稳定性和可控性做到位。把单位交互成本算清楚。把用户反馈的数据回流机制建立起来。做对这几件事即使模型底座换了一轮又一轮你的产品依然有价值。这轮浪潮里技术是入场券但真正的护城河永远是你围绕具体场景创造的那一层别人难以复制的价值。