前阵子团队接到一个企业级知识库项目客户提了个硬性要求不接受SaaS方案所有数据和问答链路必须跑在自有环境里。我们把市面上几款开源大模型都拉出来过了一遍最后定的是 YAYI。这篇文章就借这个实战项目把从模型选型、架构理解到企业级部署上线的完整过程摊开讲清楚包含硬件预算怎么算、推理框架怎么调、知识库怎么接、Agent 怎么做以及前面几轮排查中踩过的坑。如果你也在琢磨怎么把大模型私有化落地这篇应该能帮你省下不少试错时间。1. 为什么企业场景选 YAYI选型背后的真实考量做企业级大模型部署第一步不是急着拉模型而是先回答“为什么是它”。很多团队一上来就盯着效果榜结果部署阶段发现许可证、显存、适配链路的坑一个接一个。这里我把当时的选型思路完整还原一遍。1.1 YAYI 是什么能解决什么问题YAYI雅意是中科闻歌开源的中文大语言模型系列坐标系里属于“中文原生权重 可私有化部署”的那一档。它开源了多个规格的底座模型从十几B到几十B都有适配不同预算的服务器。对企业来说直接价值有三点一是数据不出域模型和服务全跑在自有 GPU 上敏感文档、用户对话记录不会被第三方看到二是中文场景做了针对性优化法律、金融、舆情这类中文专业文本上的表现比同量级通用英文模型舒服得多三是模型权重完全开放后续微调、蒸馏、二次开发都不存在授权卡脖子的问题。当时我项目里要处理的语料以中文合同、规章制度和企业内部 FAQ 为主跑过一轮 zero-shot 测试后YAYI 在语义召回和格式生成上的稳定性明显更贴合业务需求。当然不是说它绝对优于其他模型而是说它在“私有化 中文 可商用”这三个条件的交集里正好命中。1.2 同场对比为什么不是 Llama、Qwen有朋友会问Llama 生态那么成熟Qwen 本地部署案例也不少为什么偏偏选 YAYI这里有一个容易被忽略的维度部署不只看模型效果还要看“你能不能合法合规地把它用起来”。Llama 系列模型权重和许可证更偏实验室Meta 自研的许可证对商用有额外的合规限制企业走采购流程时法务很难快速放行。Qwen 开源版本在合规上相对友好但部分规格和衍生产品在商业应用上仍需逐一核对授权条款企业采购流程走起来比较慢。相比之下YAYI 的开源授权策略更直接交付给客户时不用反复解释“这个模型能不能商用”这种让人头大的问题。此外还有部署门槛的因素。YAYI 走的是标准的 Transformer decoder-only 架构和当前主流的推理引擎vLLM、TensorRT-LLM、llama.cpp兼容性都很好社区里能直接抄作业的案例也越来越多。综合许可证、中文效果、部署生态三方权衡选 YAYI 是一个既稳妥又灵活的答案。2. 架构解析模型内部到底怎么运转的部署之前必须先把架构层面的几条关键链路理解透。很多生产事故显存溢出、并发上不去、首 token 延迟高追根溯源都是对架构的认知出了问题。2.1 标准 Transformer 底座一切推理的基础YAYI 的底座沿用当前大模型主流范式decoder-only Transformer。它的核心流程可以简化成三步输入文本先被 tokenizer 切分成 token 序列然后每个 token 通过嵌入层映射成向量接着向量经过多层 Transformer block 的自注意力与前馈网络逐层提炼上下文信息最后经输出层预测下一个 token 的概率分布再通过采样策略生成新 token。这里我建议每个做部署的人都要清楚两个核心概念token 和 KV Cache键值缓存。token 可以粗浅理解成“模型眼中的最小文字单位”中文场景下 1 个汉字在 tokenizer 里可能对应 1 到 2 个 token所以“1 万字的文档”和“1 万 token”是两回事算配额的时候别搞混。KV Cache 则是自注意力机制中为省算力而缓存的历史键值对。生成长文时KV Cache 会线性膨胀直接挤占显存。这也是为什么模型权重明明只有 26GB跑起来却经常把 40GB 的显卡撑爆——问题多半出在 KV Cache 上。2.2 推理链路的性能瓶颈解码、并发与上下文长度推理阶段的性能瓶颈通常体现在三个地方解码速度、并发吞吐、上下文长度。解码速度受限于自回归机制模型一次只能生成一个 token没法像训练那样并行。这一步主要拼算力GPU 的 FP16/BF16 算力决定上限。并发吞吐则和推理引擎的调度策略强相关传统方案里“一个请求占满整张卡”的静态批处理效率极低。vLLM 这类引擎用 continuous batching连续批处理实现动态调度请求一个接一个完成中间腾出的算力立刻补给新请求实测并发吞吐能提升数倍。上下文长度则直接决定 KV Cache 上限长度越长单请求显存占用越高能同时服务的请求数就越少。所以生产环境里设 max-model-len 不是越大越好要在业务需求和显存预算之间找平衡。2.3 显存计算的数学账不是“权重占多少”那么简单企业算 GPU 预算时经常只按模型权重大小来算这是最容易出预算偏差的地方。业内有一个通用的显存估算公式模型推理显存 模型权重 激活值 KV Cache 推理引擎预留开销。模型权重在大批次场景下通常是最大头。以 13B 模型为例BF16 精度每个参数占 2 字节权重约 26GB。KV Cache 一项粗略按每请求 2048 token 上下文估算计算公式为2 × 层数 × 头数 × 头维度 × 序列长度 × 每参数字节数。取一个常规量级100 并发请求时KV Cache 也可能吃掉十几GB 显存。所以挑选 GPU 时不能只看“权重塞不塞得下”我习惯按权重显存乘以 1.5 到 2 的系数来粗排配置再用压测结果确认最终卡数。比如 7B 模型权重 BF16 约 14GB单张 24GB 的 3090/4090 就能跑推理13B 权重约 26GB建议直接上 40GB 档位的 A100 或消费级改版卡70B 级别权重约 140GB至少需要两张 80GB 的卡还得叠加张量并行。3. 企业级部署前的准备硬件、软件栈与模型获取很多人拿到模型就急着敲命令结果 run 起来才发现缺驱动、少依赖、模型下载中断。这个阶段把地基打稳后面能少踩一半的坑。3.1 硬件评估按并发和响应要求倒推配置硬件选型没有万能答案核心是“业务指标倒推资源需求”。先明确三个数字预期并发数、每请求最大上下文长度、可接受的首 token 时延。举一个实际例子。项目初期需求是支持 20 路并发每请求上下文平均 2000 token模型用 13B BF16。权重占 26GB20 路 KV Cache 按每路约 1.5GB 估算大概是 30GB加上激活值和框架开销单台 2 卡 A100-40G 是比较稳妥的起步配置。如果业务只是内部工具并发个位数且对时延不敏感一张 3090 跑 7B 量化版也绰绰有余。记住配置不是越高越好是“够用 留 20% 余量”。磁盘方面也容易被忽略。模型权重动辄几十GB建议用 NVMe SSD至少预留权重大小两倍的可用空间因为下载压缩包、解压、转格式这些步骤都有临时文件。3.2 推理框架选型vLLM、Ollama、llama.cpp 怎么选选推理框架本质是选“性能、易用性、硬件适配性”的三元平衡。vLLM 是我在生产环境里的主力。它通过 PagedAttention 和 continuous batching 把显存利用率和吞吐提得很高接口兼容 OpenAI API 格式企业应用接入最快。缺点是依赖特定 CUDA 环境老显卡或特殊架构适配麻烦。Ollama 则非常适合个人机和快速体验一条命令就能把模型拉起来但大规模并发和精细调参能力比 vLLM 弱。llama.cpp 主打 CPU 推理和消费级显卡量化支持全面适合边缘设备和 Mac但吞吐上限低于 vLLM。给一个参考配置企业并发要求高于 10 的优先 vLLM低于 10 或者要跑在无 GPU 服务器上的优先 llama.cpp / Ollama团队研发为主、不想维护复杂依赖的先用 Ollama 做验证。3.3 模型获取与量化格式避免下载到“跑不起来”的权重YAYI 权重可以在主流开源模型社区下载这里更推荐国内团队优先用国内可直连的镜像源ModelScope下载速度稳、断点续传体验好。下载时注意看目录里是否包含 config.json、tokenizer.json、model-*.safetensors 等文件缺 tokenizer 文件的模型即使加载成功问答结果也会乱七八糟。量化格式的坑也很多需要提前知道。常见的开源大模型权重文件格式有 BF16/FP16 通用格式、GGUFllama.cpp/Ollama 用、GPTQ/AWQ自动量化推理用。企业部署时如果追求速度上限建议在 vLLM 里用 AWQ/GPTQ 量化版如果要跑在 CPU 或边缘设备上直接用 GGUF 更省心。千万不要把一个 GGUF 文件硬塞给 vLLM虽然新版 vLLM 部分支持但版本不匹配时会直接报“unsupported format”排查起来很费时间。4. 部署实操从零启动一个可对外服务的 YAYI 推理服务这个环节是全文的重头戏我会尽量保留每一步的关键命令和参数原因方便你直接“抄作业”。4.1 环境初始化驱动、CUDA、Python 一套到位我建议环境统一用 conda 管理避免不同项目之间的 Python 包冲突。基本流程如下# 查看 GPU 驱动是否正常 nvidia-smi确认驱动能识别显卡后再装 PyTorch 和推理引擎。这里最重要的一个原则先确认 PyTorch 的 CUDA 版本和本机驱动兼容再装其他依赖。GPU 型号和驱动版本五花八门网上报错有相当一部分来自 CUDA 和 PyTorch 不匹配。# 创建独立环境并指定 Python 版本 conda create -n yayi python3.10 -y conda activate yayi # 安装 PyTorch以 CUDA 12.1 为例 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完 PyTorch 后用一段小代码确认 GPU 可用import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果输出显示 True 和对应的显卡型号说明底层环境就绪可以进入推理框架安装。4.2 用 vLLM 启动兼容 OpenAI 接口的服务vLLM 的安装比较直白一条命令搞定pip install vllm启动服务时我习惯把参数写到命令行里方便保存和复现。这里是一个 13B 模型的标准启动命令vllm serve /data/models/YAYI-13B \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --max-num-seqs 64 \ --dtype bfloat16逐个参数说下原因。--gpu-memory-utilization 0.85 是让 vLLM 最多用 85% 的显存做权重和 KV Cache剩下 15% 留给 CUDA context 和突发开销设成 1.0 容易在极端并发时直接 OOM。--max-model-len 8192 表示单请求上下文最长支持 8192 token业务如果只是短问答可以调到 4096给并发让路。--max-num-seqs 64 是同一个 batch 内最大请求数这个值不是越大越好要结合显存判断设太大会导致显存不足、报错重启。服务起来后用 curl 就能测试curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /data/models/YAYI-13B, messages: [{role: user, content: 用一句话向客户介绍 YAYI 大模型}], max_tokens: 128, temperature: 0.7 }返回结构里 choices[0].message.content 就是模型生成的答案。之所以强调 OpenAI 兼容是因为企业应用后面接的 RAG、Agent 框架默认都能对接 OpenAI API格式统一意味着上游几乎不用改代码。4.3 性能压测与参数调优别凭感觉调参服务启动只是第一步能不能扛住生产流量是另一回事。我一般用 openai 客户端库写一个多线程压测脚本模拟真实调用频率。import openai import concurrent.futures client openai.OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) def ask(prompt): resp client.chat.completions.create( model/data/models/YAYI-13B, messages[{role: user, content: prompt}], max_tokens256, ) return resp.usage.completion_tokens with concurrent.futures.ThreadPoolExecutor(max_workers20) as executor: prompts [介绍自然语言处理 for _ in range(200)] results list(executor.map(ask, prompts)) total_tokens sum(results) print(f成功请求数: {len(results)}, 总生成 token 数: {total_tokens})观察两个指标GPU 利用率是否打满、平均响应时间是否稳定。如果 GPU 利用率一直低于 50%优先检查是不是 Python 侧请求等待过多网络 IO 是不是瓶颈如果并发上去后显存直接 OOM优先降低 --max-num-seqs 或 --max-model-len。调参没有银弹但有通用套路先小并发跑通再按 10、20、50 逐步加压记录每个并发档位的显存占用和时延最后把生产并发控制在“稳定拐点”的 70%——这里通常就是性能和稳定性的甜点区。5. 企业应用落地知识库、Agent 与微调进阶模型服务化只是第一步真正让 YAYI 产生业务价值的是它上面跑的 RAG、Agent 和领域微调。5.1 基于 RAG 搭建企业知识库助手企业知识库是比较典型的应用场景。传统做法是把文档喂给模型做微调效果未必好还容易“学死”更推荐的做法是 RAG把文档切片、向量化、存入向量库用户提问时先检索相关片段再让模型基于检索结果生成回答。这个链路最大的好处是文档更新时只要重灌向量库不用重新训练模型非常适合知识库频繁变化的场景。技术栈方面生产环境我推荐用 LangChain 或 LlamaIndex 做编排。文档切片是一个直接影响效果的环节固定按 500 字切片会因为文档结构复杂而切出语义不完整的片段更合理的做法是结合 Markdown 标题、段落边界做语义切分块与块之间保留重叠窗口。向量库可用 Milvus、pgvector 或轻量的 FAISS中小企业数据量在百万级以内时pgvector 往往是最省运维成本的方案。关键流程先把 PDF、Word、Markdown 等文档解析成纯文本按语义切分后调用 Embedding 模型生成向量写入向量库用户提问时将问题向量化并在向量库中检索 top-k 相关片段把片段拼进 Prompt 后交给 YAYI 生成答案。这个方案上线后客户反馈“找文档”的时间从原来的分钟级降到了秒级而且答案大多能直接引用原文出处。5.2 用 LangChain/LangGraph 打造企业 AgentRAG 之外Agent 是大模型应用的另一大热点。企业里常见的是“让 YAYI 学会调用内部工具”比如查数据库、查日历、发审批、调内部 API。基于 LangChain 或 LangGraph 做 Agent 开发时YAYI 相当于“大脑”负责理解用户意图并决定调用哪些工具工具执行结果再回传给模型进行下一步推理。架构上LangGraph 比普通 LangChain Chain 更适合复杂流程因为它能管理状态和循环。比如一个“文档归档” Agent用户上传文件Agent 先判断文件类型然后调用解析工具、分类工具、存储工具每一步的结果都作为状态传给下一步流程清晰可控。开发时需要注意 Prompt 设计明确告诉 YAYI 有哪些工具、什么场景该调用、参数怎么填。工具越多模型选错工具的概率越大所以 Agent 设计的核心原则是“能少暴露就少暴露”给用户开放三五个稳定工具比开放二十个花哨工具更可靠。5.3 LoRA 微调实战让 YAYI 更懂你的领域当 RAG 不够用时比如需要模型稳定输出特定格式、特定口吻就要考虑微调了。LoRA低秩适配是最适合企业起步的微调方式它只训练一小部分新增参数显存和训练成本都远低于全参微调。推荐用 LLaMA-Factory 这类成熟工具。以 13B 模型为例准备一份领域指令数据格式大致是[ { instruction: 根据以下医保政策回答用户问题, input: 用户关于异地就医报销的疑问, output: 标准答案文本 } ]数据质量是微调效果的决定因素。我见过很多团队拿几千条“网上爬来的问答”硬训效果反而不如 RAG。有效做法是找业务方手写 500 到 1000 条高质量种子数据再配合公开指令数据做数量扩充。训练命令里通常要指定 LoRA 秩rank、学习率和训练轮数。显存紧张时可以用 QLoRA把基座模型 4bit 量化后再做 LoRA13B 模型的微调显存能降到 12GB 左右。训练完成后把 LoRA 权重和基座权重合并导出再重新部署到 vLLM 服务里。微调后的 YAYI 在特定场景下输出稳定性会有明显提升但也要警惕“灾难性遗忘”——训练轮数过多反而会让通用能力下降。所以微调数据的轮数和学习率都要做小步快跑的验证不要一上来就练十个 epoch。6. 部署运维常见问题踩坑实录与排查手册最后这一部分我整理了这次项目里最先遇到的一批典型问题基本覆盖新人部署大模型的主流故障表格可以直接存下来当速查手册。问题现象常见原因解决方案启动即报 CUDA OOM权重显存和 KV Cache 超过 GPU 容量降低 --max-model-len、--max-num-seqs或换小规格模型服务启动慢首次加载 safetensors 权重较重设置 HF_HOME 到本地目录避免反复联网读取考虑用预转换格式响应速度越来越慢并发请求堆积KV Cache 碎片化检查 --max-num-seqs 是否过大降低单请求 max_tokens 上限中文乱码或漏字tokenizer 文件缺失或版本不匹配重新下载完整目录确保 tokenizer.json 和原始模型版本一致并发 10 以上就超时报错单卡算力不足或网络带宽瓶颈水平扩容多个服务实例前面加一层负载均衡量化后效果明显变差量化精度损失切换 AWQ/GPTQ 的校准数据或对敏感场景保留 BF16 权重除了表格里的排查路径还有几个实际操作中的细节要特别提醒。第一生产环境不要一味追求“最大上下文”。模型宣传支持 32K 上下文不等于你要把 max-model-len 开到 32K开得越大KV Cache 涨幅越夸张同卡能跑的并发数直线下降。如果没有足够长的文档分析场景老老实实把 8K 作为默认上限是性价比最高的选择。第二服务和业务之间一定要加一层代理。不要直接让业务代码连 vLLM 的 8000 端口而是用 Nginx 或 Gateway 做转发、限流和超时管理。这样推理服务重启、升级时对业务侧基本无感。我遇到过同事直接在业务代码里写死 IP:8000服务一更新前端全挂的情况这个坑真的不必踩。第三GPU 利用率不达标先别急着扩容。很多时候是并发测试脚本太粗糙请求是一个一个发出去的根本压不到模型先用正确的工具和发压方式确认瓶颈再决定是扩卡还是调参能省下不少预算。最后再多说一句在实际操作中我越来越体会到部署大模型本质上是一场“资源与需求的平衡术”。效果、速度、成本三者只能取其二先明确业务优先级再动手才不会出现模型跑起来了、业务却用不上的尴尬。如果这篇内容对你有帮助可以从自己的业务场景里挑一个最小切口比如一个智能问答页先跑通整条链路再逐步扩展大模型的落地没有想象的那么神秘关键是迈出第一步。