前几天一个视频标题在国内AI圈引起了讨论China doesnt need to beat US AI。单看标题很多人以为这又是一场关于谁更强的争论但视频真正抛出的其实是一个更本质的工程问题AI 竞争是不是只有做出最强模型这一种赢法我的判断更倾向于这样理解模型能力、推理成本、应用密度、工程成熟度每一条都是独立的赛道。对绝大多数开发者和企业来说真正决定 AI 项目回报的不是你在模型排行榜上追到第几而是你能否用可接受的成本把模型稳定地跑进业务流程里。这篇文章不打算重复视频里的观点而是顺着这个判断往下拆先讲清楚为什么模型能力竞赛和工程落地竞赛是两码事再给出一条从模型选型、本地部署、量化推理到 RAG 和 Agent 接入的完整落地路线最后用一组最小可运行的 Python 示例带你亲手跑通一个企业问答 Agent 的原型。读完你会发现大模型工程化这件事门槛没有很多人想象中那么高。1. 这篇文章要解决的问题先说说为什么要写这个话题。过去一年AI 圈的注意力很大程度被排行榜支配。今天你发布一个 70B 模型明天他发布一个 MoE 架构后天又有团队放出百亿参数的训练细节。这种氛围下很多做业务系统的团队会不自觉地陷入一种焦虑我们用的模型会不会已经落后了于是盲目更换底座模型从 7B 换到 72B从开源换到商业 API最后成本翻了几倍业务指标却没怎么动。如果你也遇到过类似情况这篇文章要解决的就是三个问题第一从技术判断上看为什么模型够用就好在大多数场景下是成立的而不是妥协。第二从工程路径上看一套不依赖顶级卡、不依赖顶级模型的中小团队落地路线应该怎么设计。第三从动手实践上看如何用开源模型加开源工具快速搭建一个私有知识库问答 Agent。真正值得关注的不是要不要赢过某个对手而是AI 红利到底从哪个环节兑现。我的观点很明确对绝大多数团队红利在工程侧不在训练侧。2. 模型能力竞争和工程落地的两条赛道要理解这个观点需要先把AI 竞争拆成两条不同的赛道。第一条赛道是基础模型能力竞赛。它的目标是训练出更强的预训练模型核心指标是参数量、训练数据规模、推理能力、人类偏好胜率、排行榜分数。这条赛道比拼的是算力、高质量数据、预训练算法、对齐技术和顶尖研究团队。世界上真正有能力参与这条赛道的机构其实非常有限。第二条赛道是工程落地竞赛。它的目标是把一个现有模型稳定、高效、可控地放进真实的业务系统里。核心指标变成单位请求成本、响应延迟、可用率、数据安全边界、业务转化率、迭代发布周期。参加这条赛道的是大量负责业务系统的开发者和算法工程团队。两条赛道的关键差异可以看这张表维度基础模型能力赛道工程落地赛道核心目标预训练出更强的底座模型把模型稳定、低成本地放进业务核心竞争力训练数据、算力、算法、对齐推理优化、数据工程、RAG、Agent 编排典型角色模型研究员、训练工程师后端工程师、平台工程师、算法工程团队评价指标排行榜分数、人类偏好胜率单位请求成本、p99 延迟、可用率、业务效果迭代周期以月/季度为单位按天/周持续发布资金敏感性极高中等对多数企业的意义间接影响直接决定业务回报理解这张表就能明白一个被低估的事实基础模型能力决定的是 AI 的上限工程落地能力决定的是 AI 的下限。而对大多数业务来说上限很高没有意义下限能托住才有意义。一个很常见的误区是模型不够强所以业务做不好。但实践中业务做不好的原因更多是知识库没接好、Prompt 不稳定、上下文管理混乱、推理服务频繁超时、评估体系缺失。这些问题跟排行榜上的模型分数没有直接关系。3. 模型够用就好背后的成本与场景逻辑模型够用就好这句话在朋友圈里说出来容易被当成不追求上进的托词。但在工程语境里它是一套非常理性的决策逻辑。第一层逻辑是成本。一个几十亿参数的开源模型和几百亿参数的商业模型在推理成本上的差距通常是一个数量级以上。如果你的业务每天承受大量并发请求把模型参数量从 7B 提升到 72B意味着显卡数量、显存占用、响应延迟都会明显上升。更麻烦的是这种成本上升不一定换来体验提升——因为业务短板往往不在理解能力而在知识覆盖和流程衔接。第二层逻辑是场景。企业内部知识库问答、客服辅助、工单分类、代码审查、内容摘要这些场景对模型能力的要求其实是很具体的。它们需要的是模型能理解中文业务术语能严格按照安全约束回答能稳定输出结构化结果。这些能力更多来自指令微调、RAG 检索质量和 Prompt 工程而不是无限制地增加参数量。举个例子一个 7B 级别的指令微调模型如果接上了一套高质量的企业知识库配合良好的检索策略在某个产品的故障处理流程是什么这类问题上效果往往优于一个没有检索能力的 100B 模型。原因很简单模型没有见过你的业务数据而 RAG 让它看到了。第三层逻辑是可控性。开源权重模型可以部署在内网数据不需要出域可以做针对性微调让行为更贴近业务可以做更精细的权限控制和审计。对于金融、医疗、政企类项目这种可控性往往比单点模型能力更关键。所以模型够用就好的完整表述应该是在满足业务效果的前提下选择体量更小、成本更低、更可控的模型然后把省下来的资源投入到数据工程和评测体系上。这套逻辑放到任何软件工程场景里都能成立。4. 开源权重模型带来的技术生态变量很多团队不敢选开源模型是因为觉得开源不如闭源。这个判断在某些极端能力项上可能有道理但在工程落地层面已经站不住脚。以 DeepSeek、Qwen通义千问、ChatGLM 为代表的一批开源权重模型已经把可用模型的门槛拉到了非常低的位置。它们有几个共同特点权重开放可以本地部署、内网部署数据不出域。可微调可以在业务数据上做领域适配而不是只能通过 Prompt 硬调。生态完整推理框架、量化工具、微调框架都已经适配得很成熟。工程友好多数模型原生支持 OpenAI 兼容协议意味着你几乎不用写新的客户端代码。这些特点叠加在一起产生了一个重要的生态变化竞争的焦点从谁的模型参数更多转向了谁能在特定场景里把模型用得更好。国内开源社区的活跃程度也在客观上强化了这条路线。中文模型评测基准越来越完善针对中文场景的指令微调模型不断出现工具链的文档和踩坑记录很容易搜到。这意味着一个中小团队不需要从零做大模型研发直接站在开源生态上做应用创新是可落地的路径。这里需要做一个区分选择开源权重模型不等于否定商业闭源模型。商业 API 在部分复杂推理任务上仍然有优势适合验证想法、快速跑通 POC。但进入到规模化业务阶段尤其是对成本、数据合规和定制化有要求时开源权重模型加自建部署是越来越成熟的选择。5. 从追第一到做深应用一条可执行的 AI 落地路线理解了赛道差异接下来的问题就是具体怎么做这里给出一条适合中小团队的五步路线每一步都可以在两周内完成验证。第一步定义需求与验收指标。先不要谈模型先谈业务。你的 AI 场景是什么成功标准是什么是客服解决率提升是文档检索准确率达标还是代码生成可采纳率上涨没有验收指标后续所有优化都会失去方向。第二步模型选型。从开源模型出发优先选择你的团队能跑得动的体量。第一步先上 7B 到 14B 级别的指令微调模型跑通全流程如果效果确实不够再升级到更大模型。选型时关注三点中文能力、上下文长度、生态工具链成熟度。第三步部署与推理优化。用 vLLM 或类似推理框架提供服务按需开启量化。显存不够就用 8bit 或 4bit 量化先用最低成本验证业务效果再决定是否增加资源。第四步接入 RAG。把企业知识库切成块用 Embedding 模型向量化建索引。用户问题先进检索拿到相关片段后再作为上下文交给大模型回答。这是提升业务效果最直接的手段。第五步Agent 化与业务集成。模型能稳定回答以后再考虑工具调用、任务编排让模型具备调用查询接口、写工单、更新状态等能力。这一步本质上是把 AI 从聊天窗口变成业务流程的一环。这条路线最大的价值在于它的每一步都不依赖下一个更强模型的出现每一步都能独立产生收益。6. 用一个开源模型搭建企业问答 Agent下面进入实操环节。我会用一个最小示例完整演示部署模型 调用对话 构建 RAG 拼装回答的链路。环境以 Python 为主代码可以在本地机器或一台带 GPU 的服务器上运行。6.1 方案选型与技术栈为了降低上手成本这里采用开源模型加轻量工具的组合模型Qwen2.5-7B-Instruct这是开源社区中中文能力比较均衡、生态成熟的模型。推理服务vLLM 或 Ollama两者都提供 OpenAI 兼容接口。EmbeddingBAAI/bge-small-zh-v1.5中文向量检索效果好模型体积小。向量库FAISS轻量、可直接嵌入 Python 进程适合原型验证。编排Python 脚本不引入重量级框架便于理解核心链路。首先安装依赖pip install openai transformers sentence-transformers faiss-cpu如果你的环境需要本地加载模型做推理还需要安装 PyTorch。这里要注意PyTorch 官方安装命令和 CUDA 版本强相关请访问官网选择匹配本机显卡的命令。本文不写死具体 torch 版本演示代码以通用逻辑为准。6.2 示例一启动本地模型服务并调用对话接口先启动一个本地推理服务。我这里以 vLLM 的常见命令为例不同版本的 CLI 参数可能有差异实际使用时以官方文档为准vllm serve Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b-instruct \ --port 8000启动完成后本地会监听 8000 端口并提供 OpenAI 兼容的/v1接口。接下来用 Python 客户端调用。这里有一个关键点OpenAI SDK 的base_url要指向本地服务api_key随便填一个占位值因为本地服务不会校验它。# 文件路径demo/demo_chat.py from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY, # 本地服务不校验 key ) resp client.chat.completions.create( modelqwen2.5-7b-instruct, messages[ {role: system, content: 你是一个严谨的技术助手回答尽量简洁。}, {role: user, content: 用一句话解释什么是 RAG。}, ], temperature0.3, max_tokens256, ) print(resp.choices[0].message.content)运行验证python demo/demo_chat.py如果服务启动正常你会看到模型生成的一句中文解释。这一步能跑通说明本地模型服务链路没有问题。如果运行失败优先检查服务是否真的启动成功、model参数是否与--served-model-name一致、端口是否被占用。6.3 示例二本地推理与量化加载有时候你不想单独起一个服务而是希望直接在 Python 进程里加载模型做推理。这在原型验证阶段很方便但要注意直接加载 7B 模型的 FP16 权重大约需要 14GB 显存显卡不够时可以用量化加载。下面这段代码演示了用 Transformers 加载模型并生成回复的完整流程# 文件路径demo/demo_inference.py from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name Qwen/Qwen2.5-7B-Instruct # 加载分词器和模型 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto, ) # 如果显存不足可以尝试 8bit 量化 # model AutoModelForCausalLM.from_pretrained( # model_name, # load_in_8bitTrue, # device_mapauto, # ) messages [ {role: user, content: 介绍一下向量数据库的典型使用场景。}, ] # 使用 chat template 组装输入 text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue, ) inputs tokenizer(text, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokens256, do_sampleTrue, temperature0.6, ) response tokenizer.decode( outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue, ) print(response)这里有两个需要注意的地方第一apply_chat_template会把消息列表按照模型定义的对话模板格式化这一步不能省否则模型的指令跟随效果会差很多。第二加载模型时如果没有特殊原因不需要加trust_remote_codeTrue。只有模型官方说明要求时才需要开启。开启后意味着会执行模型仓库里的自定义代码必须确保权重来源可信。6.4 示例三最小 RAG 检索增强流程RAG 的核心思路是先根据用户问题检索出最相关的资料片段再把这些片段拼进 Prompt让模型基于资料回答。下面这个示例使用 FAISS 构建最小向量索引# 文件路径demo/demo_rag.py from sentence_transformers import SentenceTransformer import faiss import numpy as np # 1. 加载中文 Embedding 模型 encoder SentenceTransformer(BAAI/bge-small-zh-v1.5) # 2. 准备一段简化的知识库 docs [ Gradio 是一个用于快速构建机器学习 Web 界面的 Python 库。, vLLM 是一个面向大模型推理的高吞吐服务框架支持 OpenAI 兼容接口。, RAG 是检索增强生成核心是先检索再回答用于缓解模型知识过时的问题。, ] # 3. 向量化并构建索引 doc_vectors encoder.encode(docs, normalize_embeddingsTrue) index faiss.IndexFlatIP(doc_vectors.shape[1]) index.add(doc_vectors.astype(float32)) # 4. 检索 query 什么是 RAG query_vec encoder.encode([query], normalize_embeddingsTrue) scores, indices index.search(query_vec.astype(float32), k1) print(检索结果:, docs[indices[0][0]]) print(相似度:, scores[0][0])运行验证python demo/demo_rag.py输出会显示检索命中第三条文档因为 RAG 的定义和用户问题语义最接近。这段代码展示了最小链路的四个环节加载 Embedding 模型、文本向量化、构建索引、相似度检索。生产环境会替换为 PostgreSQL pgvector、Milvus 或 Elasticsearch 这类正式组件但原理是一致的。6.5 把检索结果和模型调用串起来最后一步把 RAG 结果作为上下文交给模型。这样模型就不是凭空回答而是基于给定资料回答# 文件路径demo/demo_qa_agent.py from openai import OpenAI from sentence_transformers import SentenceTransformer import faiss # 知识库 docs [ Gradio 是一个用于快速构建机器学习 Web 界面的 Python 库。, vLLM 是一个面向大模型推理的高吞吐服务框架支持 OpenAI 兼容接口。, RAG 是检索增强生成核心是先检索再回答用于缓解模型知识过时的问题。, ] encoder SentenceTransformer(BAAI/bge-small-zh-v1.5) doc_vectors encoder.encode(docs, normalize_embeddingsTrue) index faiss.IndexFlatIP(doc_vectors.shape[1]) index.add(doc_vectors.astype(float32)) query 我想部署一个推理服务应该用什么框架 query_vec encoder.encode([query], normalize_embeddingsTrue) scores, indices index.search(query_vec.astype(float32), k1) context docs[indices[0][0]] client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY, ) # 把检索到的上下文拼进 Prompt prompt f请根据下面的参考资料回答问题。如果资料不足以回答请明确说明。 参考资料 {context} 问题{query} resp client.chat.completions.create( modelqwen2.5-7b-instruct, messages[{role: user, content: prompt}], temperature0.2, max_tokens256, ) print(resp.choices[0].message.content)运行这段脚本理想情况下模型会从资料中找出vLLM这个答案而不是凭空发挥。这就是 RAG 的价值把外部知识注入模型的生成过程。到这里一个最小的企业问答 Agent 原型已经跑通了。你把它替换成真实业务文档接入真实的模型服务再加上权限校验和日志链路就是一个可以进入 POC 阶段的系统。7. 常见问题与排查思路在实际操作中下面几个问题出现频率最高问题现象可能原因排查方式解决方案调用本地模型接口超时模型尚未加载完成或显卡显存不足查看服务日志执行nvidia-smi查看显存等待加载完成降低并发换更小模型或开启量化请求返回 404 或模型不存在model参数与服务端配置的模型名不一致调用GET /v1/models查看可用模型列表将代码中的model改为服务端实际注册名中文回答乱码或混入英文服务端模型不是中文模型或请求参数异常检查服务启动时的模型路径确认是中文指令模型换用 Qwen、DeepSeek 等中文生态模型检查控制台编码量化后效果下降明显4bit 量化损失过大或任务对指令遵循敏感对比量化前后同一批测试集的效果改用 8bit 量化或使用 GPTQ/AWQ 等更好的量化方案RAG 检索结果不相关分块大小不合适或 Embedding 模型与领域不匹配打印检索返回的片段人工判断语义相似度调整分块大小和重叠窗口换更强的中文 Embedding 模型加一层重排序GPU 显存不足服务频繁重启并发请求数超过显存承载能力查看服务报错日志和显存监控调低max-model-len、max-num-seqs等并发参数增加显存换量化模型排查时有一个通用原则先确认链路位置再动手改配置。看到报错先判断是客户端问题、服务端问题还是资料检索问题不要一上来就换模型。8. 最佳实践与工程建议跑通原型只是开始。要把这样一条链路放进生产环境有几个工程建议值得提前考虑。第一评测先行不要靠感觉优化。在上线前准备 50 到 200 条真实业务问题作为回归测试集。每次调整模型、提示词或检索策略都跑一遍测试集用准确率或人工评分对比效果。没有评测集的 AI 项目优化方向很快就会失控。第二从最小链路起步逐步增加复杂度。不要第一天就上多 Agent 编排、复杂工具调用。先把检索 生成跑稳再考虑加工具把核心链路跑稳定以后再去扩展边界。第三数据安全和权限控制要前置。如果模型部署在内网要确认服务端口不会被未授权访问。如果模型需要在输入中读取敏感数据要对拼接进 Prompt 的内容做脱敏处理。AI 系统的权限设计不能比普通后端系统更宽松。第四建立可观测性。记录每一次请求的 Prompt、检索结果、模型输出、耗时和 token 消耗。这些日志既能用于排查问题也是后续优化 Prompt 和评估成本的基础数据。第五注意提示词注入风险。当模型会读取外部资料时资料内容里可能藏有恶意指令。建议在 Prompt 中明确区分系统指令和参考资料并让它只使用资料内容不执行资料中的指令。对于高安全场景可以在模型输出前增加合规过滤。第六版本管理和回滚。模型权重、Prompt 模板、Embedding 模型、知识库版本都要纳入版本管理。AI 系统的行为会随模型迭代和使用者反馈而变化没有版本管理线上出问题很难回滚。第七成本控制要持续做。token 消耗、GPU 利用率和延迟要定期复盘。很多项目上线初期效果不错几个月后成本翻倍才发现是检索返回了太多无用上下文。RAG 不是查得越多越好返回片段的数量、长度都需要调优。9. 总结与后续学习方向回到开头那个视频标题。很多人把China doesnt need to beat US AI理解成放弃竞争但从工程视角看它想表达的其实是另一件事AI 竞争的维度不是单一的赛道也不止一条。与其在自家业务还没跑通的阶段就盯着模型排行榜不如先把手里的模型用起来把检索、部署、评测、可控性这些工程问题做到位。对开发者来说最实际的行动不是等下一个更强模型而是先把你手头的模型部署到一台服务器上接一个真实查询让它跑通一条 RAG 链路再把它封装成一个可以给业务复用的原子服务。这个过程中的每一步都会比看十篇排行榜分析文章更有价值。下一步你可以从这几个方向继续深入把第 6 节的示例换成你自己领域的数据跑通私有知识库问答。研究推理优化vLLM 的 PagedAttention、KV Cache、连续批处理这些概念对理解生产环境性能非常关键。学习向量数据库的正式选型Milvus、pgvector、Elasticsearch 各自适合什么场景。探索 Agent 开发模型如何调用外部工具、如何做多步任务编排。如果团队以 Java 技术栈为主可以重点关注 Spring AI 这类框架。建议把第 6 节的代码保存下来当作一个最小模板反复使用。先把一条链路真正跑通再去追求更大的模型这个顺序对绝大多数团队来说是性价比最高的路径。 模型够用就好：开源大模型工程化落地与RAG Agent实战
前几天一个视频标题在国内AI圈引起了讨论China doesnt need to beat US AI。单看标题很多人以为这又是一场关于谁更强的争论但视频真正抛出的其实是一个更本质的工程问题AI 竞争是不是只有做出最强模型这一种赢法我的判断更倾向于这样理解模型能力、推理成本、应用密度、工程成熟度每一条都是独立的赛道。对绝大多数开发者和企业来说真正决定 AI 项目回报的不是你在模型排行榜上追到第几而是你能否用可接受的成本把模型稳定地跑进业务流程里。这篇文章不打算重复视频里的观点而是顺着这个判断往下拆先讲清楚为什么模型能力竞赛和工程落地竞赛是两码事再给出一条从模型选型、本地部署、量化推理到 RAG 和 Agent 接入的完整落地路线最后用一组最小可运行的 Python 示例带你亲手跑通一个企业问答 Agent 的原型。读完你会发现大模型工程化这件事门槛没有很多人想象中那么高。1. 这篇文章要解决的问题先说说为什么要写这个话题。过去一年AI 圈的注意力很大程度被排行榜支配。今天你发布一个 70B 模型明天他发布一个 MoE 架构后天又有团队放出百亿参数的训练细节。这种氛围下很多做业务系统的团队会不自觉地陷入一种焦虑我们用的模型会不会已经落后了于是盲目更换底座模型从 7B 换到 72B从开源换到商业 API最后成本翻了几倍业务指标却没怎么动。如果你也遇到过类似情况这篇文章要解决的就是三个问题第一从技术判断上看为什么模型够用就好在大多数场景下是成立的而不是妥协。第二从工程路径上看一套不依赖顶级卡、不依赖顶级模型的中小团队落地路线应该怎么设计。第三从动手实践上看如何用开源模型加开源工具快速搭建一个私有知识库问答 Agent。真正值得关注的不是要不要赢过某个对手而是AI 红利到底从哪个环节兑现。我的观点很明确对绝大多数团队红利在工程侧不在训练侧。2. 模型能力竞争和工程落地的两条赛道要理解这个观点需要先把AI 竞争拆成两条不同的赛道。第一条赛道是基础模型能力竞赛。它的目标是训练出更强的预训练模型核心指标是参数量、训练数据规模、推理能力、人类偏好胜率、排行榜分数。这条赛道比拼的是算力、高质量数据、预训练算法、对齐技术和顶尖研究团队。世界上真正有能力参与这条赛道的机构其实非常有限。第二条赛道是工程落地竞赛。它的目标是把一个现有模型稳定、高效、可控地放进真实的业务系统里。核心指标变成单位请求成本、响应延迟、可用率、数据安全边界、业务转化率、迭代发布周期。参加这条赛道的是大量负责业务系统的开发者和算法工程团队。两条赛道的关键差异可以看这张表维度基础模型能力赛道工程落地赛道核心目标预训练出更强的底座模型把模型稳定、低成本地放进业务核心竞争力训练数据、算力、算法、对齐推理优化、数据工程、RAG、Agent 编排典型角色模型研究员、训练工程师后端工程师、平台工程师、算法工程团队评价指标排行榜分数、人类偏好胜率单位请求成本、p99 延迟、可用率、业务效果迭代周期以月/季度为单位按天/周持续发布资金敏感性极高中等对多数企业的意义间接影响直接决定业务回报理解这张表就能明白一个被低估的事实基础模型能力决定的是 AI 的上限工程落地能力决定的是 AI 的下限。而对大多数业务来说上限很高没有意义下限能托住才有意义。一个很常见的误区是模型不够强所以业务做不好。但实践中业务做不好的原因更多是知识库没接好、Prompt 不稳定、上下文管理混乱、推理服务频繁超时、评估体系缺失。这些问题跟排行榜上的模型分数没有直接关系。3. 模型够用就好背后的成本与场景逻辑模型够用就好这句话在朋友圈里说出来容易被当成不追求上进的托词。但在工程语境里它是一套非常理性的决策逻辑。第一层逻辑是成本。一个几十亿参数的开源模型和几百亿参数的商业模型在推理成本上的差距通常是一个数量级以上。如果你的业务每天承受大量并发请求把模型参数量从 7B 提升到 72B意味着显卡数量、显存占用、响应延迟都会明显上升。更麻烦的是这种成本上升不一定换来体验提升——因为业务短板往往不在理解能力而在知识覆盖和流程衔接。第二层逻辑是场景。企业内部知识库问答、客服辅助、工单分类、代码审查、内容摘要这些场景对模型能力的要求其实是很具体的。它们需要的是模型能理解中文业务术语能严格按照安全约束回答能稳定输出结构化结果。这些能力更多来自指令微调、RAG 检索质量和 Prompt 工程而不是无限制地增加参数量。举个例子一个 7B 级别的指令微调模型如果接上了一套高质量的企业知识库配合良好的检索策略在某个产品的故障处理流程是什么这类问题上效果往往优于一个没有检索能力的 100B 模型。原因很简单模型没有见过你的业务数据而 RAG 让它看到了。第三层逻辑是可控性。开源权重模型可以部署在内网数据不需要出域可以做针对性微调让行为更贴近业务可以做更精细的权限控制和审计。对于金融、医疗、政企类项目这种可控性往往比单点模型能力更关键。所以模型够用就好的完整表述应该是在满足业务效果的前提下选择体量更小、成本更低、更可控的模型然后把省下来的资源投入到数据工程和评测体系上。这套逻辑放到任何软件工程场景里都能成立。4. 开源权重模型带来的技术生态变量很多团队不敢选开源模型是因为觉得开源不如闭源。这个判断在某些极端能力项上可能有道理但在工程落地层面已经站不住脚。以 DeepSeek、Qwen通义千问、ChatGLM 为代表的一批开源权重模型已经把可用模型的门槛拉到了非常低的位置。它们有几个共同特点权重开放可以本地部署、内网部署数据不出域。可微调可以在业务数据上做领域适配而不是只能通过 Prompt 硬调。生态完整推理框架、量化工具、微调框架都已经适配得很成熟。工程友好多数模型原生支持 OpenAI 兼容协议意味着你几乎不用写新的客户端代码。这些特点叠加在一起产生了一个重要的生态变化竞争的焦点从谁的模型参数更多转向了谁能在特定场景里把模型用得更好。国内开源社区的活跃程度也在客观上强化了这条路线。中文模型评测基准越来越完善针对中文场景的指令微调模型不断出现工具链的文档和踩坑记录很容易搜到。这意味着一个中小团队不需要从零做大模型研发直接站在开源生态上做应用创新是可落地的路径。这里需要做一个区分选择开源权重模型不等于否定商业闭源模型。商业 API 在部分复杂推理任务上仍然有优势适合验证想法、快速跑通 POC。但进入到规模化业务阶段尤其是对成本、数据合规和定制化有要求时开源权重模型加自建部署是越来越成熟的选择。5. 从追第一到做深应用一条可执行的 AI 落地路线理解了赛道差异接下来的问题就是具体怎么做这里给出一条适合中小团队的五步路线每一步都可以在两周内完成验证。第一步定义需求与验收指标。先不要谈模型先谈业务。你的 AI 场景是什么成功标准是什么是客服解决率提升是文档检索准确率达标还是代码生成可采纳率上涨没有验收指标后续所有优化都会失去方向。第二步模型选型。从开源模型出发优先选择你的团队能跑得动的体量。第一步先上 7B 到 14B 级别的指令微调模型跑通全流程如果效果确实不够再升级到更大模型。选型时关注三点中文能力、上下文长度、生态工具链成熟度。第三步部署与推理优化。用 vLLM 或类似推理框架提供服务按需开启量化。显存不够就用 8bit 或 4bit 量化先用最低成本验证业务效果再决定是否增加资源。第四步接入 RAG。把企业知识库切成块用 Embedding 模型向量化建索引。用户问题先进检索拿到相关片段后再作为上下文交给大模型回答。这是提升业务效果最直接的手段。第五步Agent 化与业务集成。模型能稳定回答以后再考虑工具调用、任务编排让模型具备调用查询接口、写工单、更新状态等能力。这一步本质上是把 AI 从聊天窗口变成业务流程的一环。这条路线最大的价值在于它的每一步都不依赖下一个更强模型的出现每一步都能独立产生收益。6. 用一个开源模型搭建企业问答 Agent下面进入实操环节。我会用一个最小示例完整演示部署模型 调用对话 构建 RAG 拼装回答的链路。环境以 Python 为主代码可以在本地机器或一台带 GPU 的服务器上运行。6.1 方案选型与技术栈为了降低上手成本这里采用开源模型加轻量工具的组合模型Qwen2.5-7B-Instruct这是开源社区中中文能力比较均衡、生态成熟的模型。推理服务vLLM 或 Ollama两者都提供 OpenAI 兼容接口。EmbeddingBAAI/bge-small-zh-v1.5中文向量检索效果好模型体积小。向量库FAISS轻量、可直接嵌入 Python 进程适合原型验证。编排Python 脚本不引入重量级框架便于理解核心链路。首先安装依赖pip install openai transformers sentence-transformers faiss-cpu如果你的环境需要本地加载模型做推理还需要安装 PyTorch。这里要注意PyTorch 官方安装命令和 CUDA 版本强相关请访问官网选择匹配本机显卡的命令。本文不写死具体 torch 版本演示代码以通用逻辑为准。6.2 示例一启动本地模型服务并调用对话接口先启动一个本地推理服务。我这里以 vLLM 的常见命令为例不同版本的 CLI 参数可能有差异实际使用时以官方文档为准vllm serve Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b-instruct \ --port 8000启动完成后本地会监听 8000 端口并提供 OpenAI 兼容的/v1接口。接下来用 Python 客户端调用。这里有一个关键点OpenAI SDK 的base_url要指向本地服务api_key随便填一个占位值因为本地服务不会校验它。# 文件路径demo/demo_chat.py from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY, # 本地服务不校验 key ) resp client.chat.completions.create( modelqwen2.5-7b-instruct, messages[ {role: system, content: 你是一个严谨的技术助手回答尽量简洁。}, {role: user, content: 用一句话解释什么是 RAG。}, ], temperature0.3, max_tokens256, ) print(resp.choices[0].message.content)运行验证python demo/demo_chat.py如果服务启动正常你会看到模型生成的一句中文解释。这一步能跑通说明本地模型服务链路没有问题。如果运行失败优先检查服务是否真的启动成功、model参数是否与--served-model-name一致、端口是否被占用。6.3 示例二本地推理与量化加载有时候你不想单独起一个服务而是希望直接在 Python 进程里加载模型做推理。这在原型验证阶段很方便但要注意直接加载 7B 模型的 FP16 权重大约需要 14GB 显存显卡不够时可以用量化加载。下面这段代码演示了用 Transformers 加载模型并生成回复的完整流程# 文件路径demo/demo_inference.py from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name Qwen/Qwen2.5-7B-Instruct # 加载分词器和模型 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto, ) # 如果显存不足可以尝试 8bit 量化 # model AutoModelForCausalLM.from_pretrained( # model_name, # load_in_8bitTrue, # device_mapauto, # ) messages [ {role: user, content: 介绍一下向量数据库的典型使用场景。}, ] # 使用 chat template 组装输入 text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue, ) inputs tokenizer(text, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokens256, do_sampleTrue, temperature0.6, ) response tokenizer.decode( outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue, ) print(response)这里有两个需要注意的地方第一apply_chat_template会把消息列表按照模型定义的对话模板格式化这一步不能省否则模型的指令跟随效果会差很多。第二加载模型时如果没有特殊原因不需要加trust_remote_codeTrue。只有模型官方说明要求时才需要开启。开启后意味着会执行模型仓库里的自定义代码必须确保权重来源可信。6.4 示例三最小 RAG 检索增强流程RAG 的核心思路是先根据用户问题检索出最相关的资料片段再把这些片段拼进 Prompt让模型基于资料回答。下面这个示例使用 FAISS 构建最小向量索引# 文件路径demo/demo_rag.py from sentence_transformers import SentenceTransformer import faiss import numpy as np # 1. 加载中文 Embedding 模型 encoder SentenceTransformer(BAAI/bge-small-zh-v1.5) # 2. 准备一段简化的知识库 docs [ Gradio 是一个用于快速构建机器学习 Web 界面的 Python 库。, vLLM 是一个面向大模型推理的高吞吐服务框架支持 OpenAI 兼容接口。, RAG 是检索增强生成核心是先检索再回答用于缓解模型知识过时的问题。, ] # 3. 向量化并构建索引 doc_vectors encoder.encode(docs, normalize_embeddingsTrue) index faiss.IndexFlatIP(doc_vectors.shape[1]) index.add(doc_vectors.astype(float32)) # 4. 检索 query 什么是 RAG query_vec encoder.encode([query], normalize_embeddingsTrue) scores, indices index.search(query_vec.astype(float32), k1) print(检索结果:, docs[indices[0][0]]) print(相似度:, scores[0][0])运行验证python demo/demo_rag.py输出会显示检索命中第三条文档因为 RAG 的定义和用户问题语义最接近。这段代码展示了最小链路的四个环节加载 Embedding 模型、文本向量化、构建索引、相似度检索。生产环境会替换为 PostgreSQL pgvector、Milvus 或 Elasticsearch 这类正式组件但原理是一致的。6.5 把检索结果和模型调用串起来最后一步把 RAG 结果作为上下文交给模型。这样模型就不是凭空回答而是基于给定资料回答# 文件路径demo/demo_qa_agent.py from openai import OpenAI from sentence_transformers import SentenceTransformer import faiss # 知识库 docs [ Gradio 是一个用于快速构建机器学习 Web 界面的 Python 库。, vLLM 是一个面向大模型推理的高吞吐服务框架支持 OpenAI 兼容接口。, RAG 是检索增强生成核心是先检索再回答用于缓解模型知识过时的问题。, ] encoder SentenceTransformer(BAAI/bge-small-zh-v1.5) doc_vectors encoder.encode(docs, normalize_embeddingsTrue) index faiss.IndexFlatIP(doc_vectors.shape[1]) index.add(doc_vectors.astype(float32)) query 我想部署一个推理服务应该用什么框架 query_vec encoder.encode([query], normalize_embeddingsTrue) scores, indices index.search(query_vec.astype(float32), k1) context docs[indices[0][0]] client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY, ) # 把检索到的上下文拼进 Prompt prompt f请根据下面的参考资料回答问题。如果资料不足以回答请明确说明。 参考资料 {context} 问题{query} resp client.chat.completions.create( modelqwen2.5-7b-instruct, messages[{role: user, content: prompt}], temperature0.2, max_tokens256, ) print(resp.choices[0].message.content)运行这段脚本理想情况下模型会从资料中找出vLLM这个答案而不是凭空发挥。这就是 RAG 的价值把外部知识注入模型的生成过程。到这里一个最小的企业问答 Agent 原型已经跑通了。你把它替换成真实业务文档接入真实的模型服务再加上权限校验和日志链路就是一个可以进入 POC 阶段的系统。7. 常见问题与排查思路在实际操作中下面几个问题出现频率最高问题现象可能原因排查方式解决方案调用本地模型接口超时模型尚未加载完成或显卡显存不足查看服务日志执行nvidia-smi查看显存等待加载完成降低并发换更小模型或开启量化请求返回 404 或模型不存在model参数与服务端配置的模型名不一致调用GET /v1/models查看可用模型列表将代码中的model改为服务端实际注册名中文回答乱码或混入英文服务端模型不是中文模型或请求参数异常检查服务启动时的模型路径确认是中文指令模型换用 Qwen、DeepSeek 等中文生态模型检查控制台编码量化后效果下降明显4bit 量化损失过大或任务对指令遵循敏感对比量化前后同一批测试集的效果改用 8bit 量化或使用 GPTQ/AWQ 等更好的量化方案RAG 检索结果不相关分块大小不合适或 Embedding 模型与领域不匹配打印检索返回的片段人工判断语义相似度调整分块大小和重叠窗口换更强的中文 Embedding 模型加一层重排序GPU 显存不足服务频繁重启并发请求数超过显存承载能力查看服务报错日志和显存监控调低max-model-len、max-num-seqs等并发参数增加显存换量化模型排查时有一个通用原则先确认链路位置再动手改配置。看到报错先判断是客户端问题、服务端问题还是资料检索问题不要一上来就换模型。8. 最佳实践与工程建议跑通原型只是开始。要把这样一条链路放进生产环境有几个工程建议值得提前考虑。第一评测先行不要靠感觉优化。在上线前准备 50 到 200 条真实业务问题作为回归测试集。每次调整模型、提示词或检索策略都跑一遍测试集用准确率或人工评分对比效果。没有评测集的 AI 项目优化方向很快就会失控。第二从最小链路起步逐步增加复杂度。不要第一天就上多 Agent 编排、复杂工具调用。先把检索 生成跑稳再考虑加工具把核心链路跑稳定以后再去扩展边界。第三数据安全和权限控制要前置。如果模型部署在内网要确认服务端口不会被未授权访问。如果模型需要在输入中读取敏感数据要对拼接进 Prompt 的内容做脱敏处理。AI 系统的权限设计不能比普通后端系统更宽松。第四建立可观测性。记录每一次请求的 Prompt、检索结果、模型输出、耗时和 token 消耗。这些日志既能用于排查问题也是后续优化 Prompt 和评估成本的基础数据。第五注意提示词注入风险。当模型会读取外部资料时资料内容里可能藏有恶意指令。建议在 Prompt 中明确区分系统指令和参考资料并让它只使用资料内容不执行资料中的指令。对于高安全场景可以在模型输出前增加合规过滤。第六版本管理和回滚。模型权重、Prompt 模板、Embedding 模型、知识库版本都要纳入版本管理。AI 系统的行为会随模型迭代和使用者反馈而变化没有版本管理线上出问题很难回滚。第七成本控制要持续做。token 消耗、GPU 利用率和延迟要定期复盘。很多项目上线初期效果不错几个月后成本翻倍才发现是检索返回了太多无用上下文。RAG 不是查得越多越好返回片段的数量、长度都需要调优。9. 总结与后续学习方向回到开头那个视频标题。很多人把China doesnt need to beat US AI理解成放弃竞争但从工程视角看它想表达的其实是另一件事AI 竞争的维度不是单一的赛道也不止一条。与其在自家业务还没跑通的阶段就盯着模型排行榜不如先把手里的模型用起来把检索、部署、评测、可控性这些工程问题做到位。对开发者来说最实际的行动不是等下一个更强模型而是先把你手头的模型部署到一台服务器上接一个真实查询让它跑通一条 RAG 链路再把它封装成一个可以给业务复用的原子服务。这个过程中的每一步都会比看十篇排行榜分析文章更有价值。下一步你可以从这几个方向继续深入把第 6 节的示例换成你自己领域的数据跑通私有知识库问答。研究推理优化vLLM 的 PagedAttention、KV Cache、连续批处理这些概念对理解生产环境性能非常关键。学习向量数据库的正式选型Milvus、pgvector、Elasticsearch 各自适合什么场景。探索 Agent 开发模型如何调用外部工具、如何做多步任务编排。如果团队以 Java 技术栈为主可以重点关注 Spring AI 这类框架。建议把第 6 节的代码保存下来当作一个最小模板反复使用。先把一条链路真正跑通再去追求更大的模型这个顺序对绝大多数团队来说是性价比最高的路径。