把大模型“搬进”公司我们的研发部正在被 LLM 重新定义去年年底我们研发部做了一次“豪赌”——把大模型LLM真正接到自己的业务线里来而不是继续当一个只会聊天的玩具。从前端的代码补全到后端的 Bug 定位再到技术文档的自动生成可以说现在整个部门的日常流程里LLM 的影子已经渗进了每一个环节。这篇文章就是一次复盘记录把我们从选型、部署、微调到踩坑的全过程原原本本拆给你看。如果你也正准备在公司内部给 LLM 找一个真正的落脚点建议耐心读完。我们不是算法团队也没有专门的大模型研究员背景就是一群做 Java、Python、前端出身的中后台研发硬着头皮把这套东西啃了下来。所以这里不会堆一堆听不懂的公式更多是决策层面的考量和工程上的取舍。这篇文章适合所有想在公司内部私有化部署大模型、准备用 LLM 改造研发流程但又不希望被云厂商绑定的团队参考。1. 内容整体设计与思路拆解1.1 到底是自建还是调 API先想清楚一件事为什么我们不直接用现成的云端 API非要折腾私有化原因很现实——公司的代码仓库、内部文档、架构设计资料都属于敏感资产不可能直接丢给外部接口。而且研发部用 LLM 的频率极高要是按 token 计费一个月下来这笔账也挺不好看。所以我们的目标很明确在公司内部搭建一套大模型服务模型参数不需要太大但响应速度要够快、可控性要够强。毕竟研发场景更多是代码补全、短文本分析、接口文档整理而不是需要超长上下文的复杂推理。考虑到部署成本和硬件限制我们把目光锁定在 7B 到 14B 量级的开源模型上。这类模型可以用单张消费级显卡跑起来也能通过 vLLM 这类推理加速框架做到很高的并发吞吐。至于 70B 级别的大模型一是显卡资源确实紧张二是很多内部场景根本用不满那个智力水平。提示如果你的团队没有 GPU 资源最现实的路径还是先买云 API 跑通流程验证场景确实有价值后再考虑自建。千万别一上来就搞基建否则很容易在运维泥潭里陷进去。1.2 三个关键问题数据安全、响应速度、可控性把 LLM 搬进公司的本质是要解决三个核心痛点。第一个是数据安全所有请求必须留在内网这决定了我们不可能走 SaaS 路线。第二个是响应速度研发工具链里的代码补全如果等七八秒才出结果程序员早就切换回肌肉记忆了。第三个是可控性我们要能精细调控模型的行为边界比如哪些代码可以生成、哪些敏感词需要屏蔽这些东西靠黑盒 API 是无法做到的。围绕这三个痛点我们的整体架构思路分成了三层基础设施层GPU 服务器 vLLM 推理引擎提供标准 OpenAI 风格接口中间服务层统一做 Prompt 编排、权限控制、日志审计、敏感信息过滤业务应用层IDE 插件、内部问答机器人、代码评审助手、文档生成工具这样一来模型和业务解耦如果后面换更好的模型中间层不用动所有业务方拿到的接口协议保持一致。1.3 一个容易被忽略的环节Prompt 和模型能力边界很多人以为把模型部署完就万事大吉了实际上只走了一半。LLM 是个“上限很高、下限很低”的东西同样的模型遇到会写 Prompt 的人和一个纯小白产出的效果天差地别。我们的做法是把高频场景的 Prompt 模板化沉淀成一套公司内部的“技能库”比如“代码评审助手”就是一套固定的前置指令业务方要使用直接调用不用自己琢磨怎么问。这里还要强调一个观念不是所有问题都该丢给大模型。像字符串处理、正则匹配、简单的数据清洗用传统代码就能搞定别让 LLM 干这种笨活既慢又容易出错。我们的中间服务层加了一层路由逻辑判断请求是否真的需要走 LLM从源头节省算力。2. 核心细节解析与实操要点2.1 部署选型vLLM 让我们省下了一整周的调优时间模型服务的承载能力直接决定了 LLM 能不能真正融入研发流程。我们对比过 HuggingFace 原生的 transformers 接口、FastAPI 自建服务还有专门做推理加速的 vLLM。先说结论vLLM 是目前私有化部署的最优解原因是它在吞吐性能上做了大量优化尤其是对连续批处理和 PagedAttention 的支持。原生 transformers 方案适合做实验验证一次处理一个请求简单但慢。如果要对外提供服务必须上 vLLM 或 TGIText Generation Inference这类推理框架。我们在单卡 A100 上部署了一个 13B 参数的模型用 vLLM 的 continuous batching 特性实测单机可以稳定支撑 50 个并发请求每 token 生成速度在 60 到 80 左右完全够内部几十名研发同时使用。部署命令很简洁核心就是把模型路径传给 vLLMpython -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-14B-Instruct \ --served-model-name internal-llm \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --port 8000这里有几个关键参数值得解释一下。tensor-parallel-size表示用几张卡并行推理我们的场景单张 A100 显存 80G足够跑 14B 模型所以设成 1。max-model-len是最大上下文长度设太大显卡内存不够设太小又浪费模型能力8192 对我们当前所有任务都是够用的。启动之后服务会暴露一个/v1/chat/completions接口和 OpenAI 的格式完全一致业务侧接入几乎零成本。注意上线前一定要做并发压测。我们刚开始只测了单请求的响应时间感觉很满意结果一上生产发现并发一高部分请求直接超时。后来通过调节 vLLM 的--max-num-seqs参数限制同时处理的序列数才解决了问题。2.2 硬件配置的底线显存决定模型上限聊到大模型部署硬件是绕不过去的话题。很多团队迟迟不敢动手就是被硬件门槛吓到了。我想给大家一个相对清晰的参考——显存大小直接决定了你能跑多大的模型。以目前主流的 7B 模型为例如果用 FP16 精度权重文件大约占用 14G 显存再加上 KV Cache 和推理过程中的中间变量单张 24G 显存的 3090/4090 就能跑起来。14B 模型权重约 28G推荐用 40G 以上的 A100 或两张 3090 并行跑。如果只有 8G 到 12G 显存的显卡也不是完全没戏可以考虑用 4bit 量化后的模型虽然效果有一点损失但至少能跑起来做验证。我们在实际部署时采用了 4bit 量化加 vLLM 的组合。毕竟研发过程中的代码补全和问答场景对模型的精度要求不像学术评测那么苛刻量化带来的轻微损失完全在可接受范围内。这个思路帮我们省下了近一半的显存开销也让模型可以在更小的卡上部署。2.3 理解 token、embedding 和 attention 这几个基础概念在推进项目的过程中我发现团队里很多研发第一次接触 LLM 时会被一大堆概念绕晕。这里挑三个最容易混淆的用大白话解释一遍。Token 是模型理解文本的最小单位可以粗略理解成“词的碎片”。中文里一个汉字可能对应一个或多个 token代码里一个变量名也可能被拆成好几段。所以“部署大模型”这五个字在模型眼里其实是几个 token 的序列。而这个项目的标题里要频繁提及的 LLM 大模型本质上就是一个在不断预测“下一个 token 是什么”的超大函数。Embedding 是把文本转成向量代表语义上的坐标。它解决的是“如何让计算机理解文本相似性”的问题比如“怎么部署大模型”和“大模型部署方法”这两句话字面上完全不同但 embedding 出来后的向量距离很近。这个能力在 RAG 知识库检索中非常关键。Attention 机制则是大模型的“注意力焦点”。它让模型在生成每一个词时不是平等看待前面的所有词而是根据相关性分配权重。你可以理解成人在读代码时眼睛会重点盯住变量名、方法签名而不是每个字符都一样关注。 Attention 机制正是 Transformers 架构的核心也是 GPT 这类模型能够理解长文本依赖的基石。在给团队做内部培训时我建议把这三个概念放在一起讲因为它们串起了大模型的完整工作链路文本切成 token → embedding 编码 → attention 加权计算 → 生成下一个 token。2.4 RAG 与微调两条路线如何选刚接触 LLM 应用时很多人会被“RAG”和“微调”这两个词搞糊涂。简单说RAG 是给模型配一个实时更新的知识库每次问答先去检索相关片段再交给模型组织答案微调是直接改变模型内部的权重让它掌握某种固定的行为模式或特定领域的表达风格。我们公司的内部知识库用了 RAG。原因很直接——知识库里的内容每周都在更新如果走微调路线意味着每次更新都要重新训练一次模型成本太高了。RAG 的方案则是把公司文档、API 说明、历史代码片段提前切成块向量化存入向量数据库用户提问时先检索出最相关的内容再让大模型基于检索结果作答。这样知识库的更新只需要重新跑一遍向量化流程模型本身不用动。至于微调我们仅在两个场景下使用一是让模型学会识别公司内部的代码规范比如把所有的 logger 调用统一格式二是针对特定的代码转换需求。前期我们完全用 RAG先把业务跑通再考虑微调这样风险更小、迭代更快。2.5 微调框架怎么选llama factory 的实战体验当我们确实需要微调时选了 llama factory 作为主要工具它把数据处理、训练、推理封装成了一条完整的流水线。最友好的是它支持 LoRA 这类高效微调方案只用训练一小部分参数显存需求大大降低。LoRA 的原理可以这样理解预训练好的模型权重保持不变在旁边加一个小型可训练模块训练时只调整这个小模块。这就像在一本出版好的字典上贴便利贴做批注字典本体不重印但查起来就有个人化注释了。这样微调的成本极低14B 模型用单张 24G 显卡也能跑起来。实操中我们整理了一批公司内部的代码数据格式是常见的指令-输入-输出结构。用 llama factory 的命令行工具跑 LoRA 训练大约三个小时就完成了一个基础的代码规范对齐任务。如果团队连数据标注都还没准备好我不建议急着微调先用 RAG 和精心设计的 Prompt 顶上效果不会差太多。3. 实操过程与核心环节实现3.1 从零搭建一条可用的 LLM 服务链路下面是一条完整的从零搭建流程已经在我们公司验证过多次可以直接照抄第一准备服务器。我们用的是一台带有单张 A100 80G 的 GPU 服务器操作系统 Ubuntu 22.04显卡驱动和 CUDA 环境需要提前装好。没有 GPU 服务器也没关系目前主流的云厂商都有按小时计费的 GPU 实例先用几天把链路跑通再决定是否长期租用。第二搭建 Python 环境。强烈建议用 conda 管理环境避免依赖冲突。关键依赖包括 PyTorch、transformers、vLLM、accelerate。这里有一个常见的坑transformers 和 vLLM 的版本需要匹配版本相差太大会直接报错。第三下载模型权重。从 HuggingFace 仓库把模型文件拉到本地。这块不多展开就是标准的模型下载流程。第四启动推理服务。用前面给过的 vLLM 命令模型启动后会在本机的 8000 端口暴露 OpenAI 风格接口。此时就可以进行简单的接口验证了。第五封装为企业内部 API 网关。由于 vLLM 原生接口缺少鉴权和审计能力我们在前面加了一层网关用来做身份校验、请求转发、敏感词过滤和日志记录。这样业务方拿到的是一个干净的接口底下怎么部署的他们完全不用关心。第六开发内部工具接入。第一个接入的是 IDE 插件实现代码补全和解释第二个是内部问答机器人对接 RAG 知识库。从部署到真正产生生产力我们整个流程只用了两周。3.2 打造企业知识库问答RAG 全流程实现企业内部知识库问答是我们目前使用频率最高的 LLM 应用场景。很多研发在踩坑之后问我们怎么做到的这里把核心流程拆开讲。整体链路分五步文档加载和清洗、文本切块、Embedding 向量化、向量检索、LLM 总结回答。前两步很容易被低估很多团队以为把所有 PDF 和 Word 一股脑切了扔进去就行结果出来的回答质量惨不忍睹。关键在于文档清洗这一步要把页眉页脚、目录、无意义符号全部去掉切块大小也要控制我们一般是 500 到 800 个字符一块重叠 50 个字符这样既能保证上下文完整性又不会让检索结果太碎片化。Embedding 模型我们选了国产的开源模型中文效果非常出色而且对代码文本也有不错的理解力。向量数据库用的开源方案支持本地部署。检索时通过余弦相似度找出最相关的 4 到 6 个片段然后拼接到 Prompt 里让模型基于这些上下文给出答案。最后在回答底部附上来源片段方便研发追溯原始文档。这个流程跑通之后我们内部的知识查找效率提升了非常多。以前找个老项目配置说明要翻半天文档库现在直接问机器人几秒钟就能得到带出处的答案。这也让我们更加坚定了一个判断大模型落地的第一站不一定是炫酷的 Agent先把自己内部的信息孤岛打通就已经能创造巨大价值了。3.3 代码评审助手让 LLM 成为研发流程里的一员代码评审是 LLM 在研发部最立竿见影的场景。以前代码评审靠人肉盯架构师和资深工程师的时间非常有限很多代码只是走个过场。现在我们的流程是程序员提交 Merge Request 后自动触发 LLM 代码评审输出潜在问题清单人工再针对性的看一遍。具体实现上我们写了一个脚本监听代码仓库的合并请求事件提取变更的代码片段组装成评审提示词发给部署好的大模型接口。提示词里明确规定检查代码风格、潜在空指针、SQL 注入、资源未关闭等问题每个问题必须标注文件位置和行号区间。输出格式用 JSON 结构化返回方便自动化处理。用了一段时间后我们总结出一个经验LLM 评审不能替代人但能把人从低水平问题中解放出来。现在人肉 Reviewer 主要关注架构合理性、业务逻辑正确性代码规范类的问题全部交给 LLM 把关。实测下来合并请求的平均评审周期从原来的两天缩短到半天低级 Bug 的逃逸率也有显著下降。3.4 代码补全和生成实践代码补全是研发部几乎人人都要用的功能也是最能“感知”到大模型存在感的应用。我们的做法是给 IDE 接入一个自建的代码补全插件它会将当前光标前的代码上下文发送给本地部署的 LLM让模型预测后续代码。但这里有个现实问题通用模型直接用于代码补全效果不够理想经常出现格式不对、自动补全了错误 API 的情况。我们的解决方案是组合拳在 Prompt 中强调“只补全代码不做解释”并且把项目的语言类型、相关的接口签名拼进去。实践中对于 Java 项目的模板代码、单元测试生成、SQL 编写这些场景生成质量已经达到可用水平。坦白说代码补全如果想要达到商用效果最优解是专门训练过的代码模型这是目前开源生态里已经具备的比如 CodeLlama 和 DeepSeek-Coder 系列。如果大家想在企业内部做代码补全我建议先去下载一个代码专用模型跑跑看再对比通用模型的效果差异还是很明显的。3.5 多模态模型内部图表文档处理的新思路我们当时只做了文本模型还不够研发部有大量架构图、流程图、截图形式的报错信息这类内容光靠文本模型处理不了。所以后续又扩了一条多模态的线把视觉语言模型一起部署上了。多模态模型能直接看图理解内容比如你给它一张报错日志截图它能帮你提取关键报错信息甚至指出可能的原因。对于架构图它可以按照图里的模块关系生成说明性的 Markdown 文档。这在写技术方案、做项目交接的时候非常有用省掉了很多“看图说话”的苦力活。多模态模型的部署成本和文本模型类似主要看视觉编码器和语言部分的参数规模。我们的经验是公司内部用多模态模型不需要追求极致理解能力能看懂结构图、表格和截图就够了。这种模型可以单独开一个服务端口和文本模型隔离避免相互影响性能。4. 常见问题与排查技巧实录4.1 响应太慢GPU 利用率上不去在我们刚上线时用户反馈最大宗的抱怨就是“响应慢”。第一反应是模型太大显卡跑不动但查了 GPU 利用率发现不到 30%。后来排查发现瓶颈根本不在 GPU而在 CPU 的 Token 预处理和 Python 进程切换开销上。用 vLLM 部署时如果发现 GPU 利用率上不去优先看两个地方一是--max-num-seqs是否限制了并发数二是输入序列过短导致批处理效率低。我们的解决办法是提高并发度同时把--max-model-len适当改小减少显存中 KV Cache 的浪费。另外切换到异步处理模式后整体吞吐提升非常明显。排查技巧用nvidia-smi看显存和利用率用top看 CPU 进程如果 CPU 跑满而 GPU 空闲问题十有八九在数据预处理或线程调度上如果 GPU 显存占满但利用率低则可能是模型太大、batch 太小。4.2 重复输出同一个词模型死循环了这是 LLM 部署中经典问题回答到一半开始无限重复同一个标点或同一个词语。遇到这种情况十有八九是因为采样参数中的repetition_penalty没设置或者temperature设置得过高。我们内部把temperature设为 0.7 到 0.8repetition_penalty设为 1.1 到 1.2基本告别了死循环问题。另外如果接入的是代码场景可以把top_p略微调低到 0.85这样生成的代码更稳定不会冒出一堆奇怪的变体。这属于推理层的参数调优很多人只关注模型选型忽略了这些推理参数也能决定用户体验。我们把这些参数固化在网关层业务调用方不用自己传也避免了有人乱设参数导致线上翻车。4.3 输出格式总是不听话JSON 解析老是失败很多研发接 LLM 接口时最头疼的就是让模型稳定输出 JSON 格式。有时候多加一句解释有时候少个括号反反复复折腾人。我们的经验是两个手段配合使用Prompt 强约束加解析容错。Prompt 里的强约束写法包括只输出 JSON 对象、不要 Markdown 代码块、不要添加说明性文字。但即使这样模型偶尔还是会犯傻。所以网关层我们加了智能修复逻辑如果解析失败尝试截取大括号内的内容再解析如果还是失败就自动重试一次并加强约束。这种方法不能保证 100% 成功但能把失败率从 10% 压到 1% 以下。如果你们对稳定性要求更高建议考虑用专门的结构化生成方案或者在后端做更严格的 Schema 校验和字段规整。总之任何把 LLM 输出当“函数返回值”用的团队都要做好容错的那一层。4.4 大模型部署的五大常见坑把项目踩过的坑统一整理成一张速查表方便后来者对照坑点表现解决方案模型下载失败网络中断、磁盘空间不足提前规划磁盘空间至少要留模型体积的 2 倍CUDA 版本不匹配服务启动报错严格参考框架文档匹配 CUDA、PyTorch 版本GPU 显存不足启动后 OOM改用量化模型或减少最大上下文长度并发请求雪崩请求排队响应超时设置硬性并发上限引入排队机制和熔断降级Prompt 注入用户通过恶意输入让模型执行不当指令网关层隔离系统提示词和用户输入增加关键词过滤4.5 模型权重的管理不该被忽视的基建问题大模型部署不只是技术问题还有工程管理问题。模型文件动辄几十 GB管理不善会引发混乱。我们内部用专门的文件服务管理模型权重每个版本都有清晰的命名规范类似Qwen2.5-14B-v1.2这样的格式。为什么要这么在意这件事因为模型会迭代回滚是常态。比如某次微调后模型效果反而变差了我们需要能快速切回之前的版本。如果模型文件管理混乱线上部署出错后连回滚都做不了那才是真正的灾难。服务端我们把模型路径做成可配置的切换版本只需重启服务并修改配置整个过程不用改业务代码。经验模型权重文件一定要和代码分开存储用独立的目录或对象存储服务管理。千万别把模型文件提交进 Git 仓库那会把仓库体积撑爆而且下载也慢。后记LLM 进研发部不是终点而是起点把大模型搬进公司这件事回过头来看真正困难的地方其实不在工程实现而在我们要不断“校正对 LLM 的预期”。它既不是魔法也不是玩具而是一个需要精心设计交互方式、持续维护知识库、反复调整推理参数的严肃工具。我在这个项目里最大的体会是先从小场景切入快速跑通用真实业务数据检验效果再逐步扩大覆盖范围。不要想着一口气把所有环节全上大模型那一定会被各种问题淹没。我们目前正在做的是把 Agent 能力引入自动化测试场景让 LLM 自己生成测试用例并执行验证这个过程还在打磨。最后再分享一个小技巧一定要让团队记录每一次的 Prompt 版本和对应效果哪怕是只改了一个字。大模型的输出充满不确定性你以为是玄学其实大部分时候还是有迹可循的。有了记录你才能在持续迭代中找到真正稳定的优化路径。LLM 重新定义研发部的过程刚刚开始希望我们的经验能帮你少踩几个坑。