七猫私有化大模型的工程实践与体系化思考

今天和大家系统分享过去一段时间我们在私有化大模型落地上的完整实践。从最初小说画像场景的成本与安全痛点出发，我们从零搭建了一套覆盖模型选型、推理优化、工程交付的全链路服务体系，支撑了从离线批处理到在线交互的多类业务场景。

很多公司和团队做私有化，第一反应是“买卡、跑模型”。但真正落地后会发现：模型能不能跑通只是第一步，能不能用合理的成本承载业务规模、能不能稳定交付、能不能快速迭代，才是决定私有化能否持续跑下去的核心。这篇分享不侧重理论，主要聊我们在真实业务约束下做的决策、踩过的坑，以及沉淀下来的一套可复用的工程方法。

一、为什么要做私有化：

业务驱动下的必然选择推动私有化的直接动因，来自小说画像抽取项目的真实痛点。

早期我们使用第三方API快速验证了任务可行性：对站内小说逐章做结构化理解，沉淀角色、剧情、关键情节、故事大纲和核心冲突，为产运角色库和算法训练提供数据支撑。但进入全量处理阶段后，两个核心矛盾迅速凸显：

1、成本不可持续。几十万本存量书籍逐章处理，叠加章节长度差异、失败重试机制，Token消耗规模远超预期。按量付费模式适合小规模试验，但作为长期常态化的离线任务，成本结构完全不成立。

2、数据安全风险。画像抽取需要传输全量小说正文，核心内容数据在外部链路流转，传输、留存、审计的长期合规成本很高，也存在数据泄露的潜在风险。

基于这两项硬约束，我们确定了“双轨制”总体策略：探索期、低频的创新任务继续留在外部服务，保持业务验证效率；已经验证有效、调用规模大、涉及核心数据的任务，逐步迁移到内部私有化环境。

随着AI搜索、AI续写、生成式推荐等场景陆续落地，私有化不再是单个项目的解决方案，而是需要一套标准化的服务能力，支撑多业务的接入与迭代。接下来的所有工作，都是围绕这个目标展开的。

二、模型选型：不唯榜单，以业务效果与工程可行性为核心

确定私有化方向后，第一个核心决策就是模型选型。模型选得好不好，直接决定了后续所有工作的上限。我们的选型逻辑不看通用榜单排名，而是围绕两个核心维度：业务适配性、工程落地性。

1、业务效果是第一准则

我们拉取了七猫真实业务样本，覆盖小说长文本理解、搜索指令执行、结构化内容生成等核心场景，对国内外主流开源模型做了横向对比。我们的业务场景有三个鲜明特点：强中文语境、长文本占比高、对结构化输出稳定性要求极高——字段缺失、格式漂移、指令遗漏，都会直接导致下游任务失败，带来额外的重试成本。一轮评测下来，Qwen系列在中文长文本理解、复杂指令遵循、结构化输出稳定性三个维度上表现最稳定，能够作为统一模型底座支撑多类任务开发。

2、工程可行性是硬约束

选型不能只看效果，还要看能不能在现有硬件条件下跑起来、好不好迭代。当时我们还没有GPU集群，业务验证主要依赖租用单卡机器，且由于某些原因，可选显卡型号非常有限，单卡48GB显存是核心硬约束。Qwen从4B到27B全系列都能在48GB显存下完成部署，同时vLLM、SGLang、TensorRT-LLM等主流推理引擎适配完善，OpenAI兼容接口成熟，大幅降低了从验证到生产的适配成本。

3、家族化能力预留长期空间

另一个重要考量是模型的家族连续性。Qwen从轻量到27B+提供了完整的参数梯队，一方面可以让不同复杂度的任务在同模型家族内分工，减少跨模型适配成本；另一方面也为后续知识蒸馏、能力下沉预留了技术路径——用大模型做教师，把能力迁移到小模型上，这是后续降本的核心手段。选型不是一劳永逸的事。确定模型家族后，我们的工作重心就从“选哪个模型”转向了“不同任务该用多大的模型”，也就是模型分层组合的设计。

三、模型分层架构：4B提效率，27B保上限

1、两级分工的形成

很多团队做私有化，要么全上大模型追求效果，要么全用小模型追求成本，最后要么成本扛不住，要么效果不达标。我们的思路是：构建分层的模型组合，让合适的模型做合适的事。我们对4B、9B、27B、35B-A3B以及多个量化版本都做了全场景验证，核心评判标准不是离线打分，而是“在真实复杂指令下，能否持续输出稳定、可直接消费的结构化结果”——因为输出不稳定带来的重试、兜底、人工校验，都是隐性的真实成本。最终我们沉淀了4B+27B的两级核心架构：

中间的9B、35B以及部分量化版本，我们也做了完整验证，但最终没有纳入生产主力：9B在复杂任务上能力下滑明显，结构化输出稳定性不足，没有形成比4B显著的效果优势；35B量化版本在显存和效果的平衡上，也没有跑出比27B更优的性价比。对我们来说，显存占用、模型大小只有在业务效果达标的前提下，才有比较意义。

2、能力下沉：

从通用到专用的持续优化两级模型不是静态的，而是有一套动态的能力下沉机制。对于任务边界稳定、样本积累充分、调用量高的场景，我们会以27B为教师模型，生成高质量标注样本，结合真实业务数据做筛选校验，再对4B模型做专项微调，把27B的通用能力沉淀到4B专用模型中。这套机制带来的收益非常显著：专用4B模型在保持任务效果达标的前提下，推理成本可以下降一个数量级，单卡并发能力大幅提升。这也是我们后续持续降本的核心路径：随着业务场景的成熟，不断把成熟任务从27B下沉到4B，实现效果与成本的动态平衡。

四、推理优化：从单卡调优到系统级效率提升

模型组合定了之后，下一个核心问题是：有限的GPU资源，到底能承载多少符合SLO要求的业务请求？我们围绕4B和27B两个核心模型，持续开展vLLM与SGLang的引擎对比，覆盖并发调度、批处理配置、KV Cache优化、推测解码、并行拓扑、多实例路由等多个维度。这里有个很重要的原则：所有优化都用真实业务请求集做评测，固定单一变量，以SLO内的有效吞吐、长尾时延、请求成功率为核心指标，不看理论峰值，只看业务能用多少容量。两个对线上影响最大的优化实践，在这里重点展开。

1、拓扑选择：TP1与TP2，适配不同负载

以Qwen3.6-27B-FP8为例，单张RTX 5880 Ada 48GB可以完整部署。那两张GPU，应该部署两个独立的TP1实例，还是组成一个TP2实例？很多人的直觉是TP2并行度更高，性能更好，但实际结果完全取决于负载类型。我们做了严格的对照实验：

• 长Prompt短输出场景（约20.5K输入，1Token输出，无可复用前缀）：两个TP1实例的聚合Prompt吞吐达到5375 tok/s，TP2实例为4373 tok/s，双TP1方案高出22.9%。这种场景下，多实例的吞吐收益更高。
• 短Prompt长输出/长上下文场景：TP2的单请求输出速度达到33.4 tok/s，TP1仅19.6 tok/s；同时TP2可以稳定支撑接近64K的上下文，单请求的缓存容量优势明显。基于这个结果，我们沉淀了明确的拓扑选择规则：
• 中短请求、吞吐优先的业务，采用多TP1实例池；
• 长上下文、长输出、单请求容量要求高的业务，采用TP2实例；
• 两类流量同时存在时，按请求上下文长度做分池调度。核心结论很明确：没有最优的部署拓扑，只有最适配业务负载的拓扑。脱离真实请求分布谈性能，没有实际意义。

2、会话路由：用流量调度解决多轮交互的资源浪费

AI搜索等多轮交互场景上线后，我们发现了一个很典型的问题：同一会话的多轮请求，如果被随机分发到不同实例，历史上下文会被重复计算，KV Cache完全无法复用，不仅浪费算力，还导致长尾延迟居高不下。我们的解决方案是引入vllm-router，通过X-Session-Id作为会话键，基于一致性哈希算法，让同一会话的请求尽可能路由到同一个实例，保障KV Cache的局部性复用。没有会话标识的请求，则沿用常规的负载均衡策略。我们在双实例4B服务上做了三轮交叉验证（关→开→关），每轮100个会话、每个会话8轮交互，共2400个请求，压测并发150。最终结果：

• QPS从均值4.48提升到6.67，提升幅度48.9%；
• P99端到端延迟从41.91秒下降到22.82秒，下降幅度45.5%；
• 全程请求错误率为0，没有引入稳定性问题。

这个优化给我们的启发是：大模型推理的效率提升，不止有引擎层、算子层的优化，流量调度层面的系统级优化，往往能带来非常可观的收益，而且改造成本更低，见效更快。

五、工程化交付：从“能跑”到“可运营”的体系化建设

单机部署能跑通模型，不代表能支撑规模化的业务接入。项目早期我们用单机部署，确实快速完成了验证，但随着模型和业务数量增加，单机模式的问题全部暴露出来：资源固定、扩容全靠人工、监控分散、故障排查难、没有标准回滚路径，交付效率和服务稳定性都遇到了瓶颈。我们的解法是全面迁移到Kubernetes，构建一套标准化的大模型工程交付体系。这个过程不是简单把模型塞进容器里，而是从资源、接口、版本、发布四个维度完成体系化重构。

1、资源编排标准化：从人工操作到模板化交付

我们基于Helm把所有模型服务做了模板化封装，GPU数量、模型挂载路径、并行拓扑、运行参数等所有差异化配置，都通过Values统一管理。这套模板的好处是：不管是单卡TP1还是双卡TP2，不管是通用模型还是专用模型，都用同一套交付逻辑描述。扩容只需要复制标准工作负载，不用再在固定机器上重复执行人工操作；单个模型升级、扩容，也不会影响其他模型服务。资源从“绑定在固定机器上”变成了“可编排的工作负载”，这是规模化的基础。

2、接口契约化：解耦底层实现与上层业务

我们对外统一提供OpenAI兼容协议，作为业务调用的标准契约。底层的模型权重、精度、并行拓扑、副本数，甚至推理引擎是vLLM还是SGLang，所有这些变化对业务侧完全透明。算法团队更新模型，平台团队调优引擎，都不需要业务侧修改接入代码。稳定的接口契约，是模型和引擎能够持续快速迭代，同时不影响业务的核心保障。

3、版本全链路可追溯：模型不止是权重文件

很多团队（如早期的我们）发布模型，就是换个权重文件，最后经常出现“同一个模型，两次跑出来效果不一样”的问题，排查起来非常困难。我们的做法是：把模型权重、推理镜像、引擎版本、上下文长度、缓存精度、并行拓扑、批处理参数，所有影响运行结果和性能的要素，打包成一个完整的“运行版本”。每次发布都对应一个完整的版本快照，所有配置可追溯、可复现。这样一来，线上出现任何问题，我们都可以精准定位是模型本身的问题，还是引擎参数调整带来的变化，故障排查效率大幅提升。

4、发布流程体系化：带门禁、可灰度、可回滚

我们基于Argo把训练产物、离线评估、版本发布、推理部署、线上验收全链路串了起来，形成了标准化的发布流程。这里讲两个我们踩过坑后重点加的机制：

• 启动预热门禁。早期我们只要端口起来了就切流量，结果发现模型加载完成不代表推理能力就绪，首条请求要承担首次生成的开销，延迟会额外增加10秒左右，严重影响用户体验。后来我们加了真实推理预热检查，实例必须完成一次完整的推理调用、验证输出正常，才会接入业务流量。
• 灰度发布与一键回滚。新版本上线先切小流量，同时监控请求量、时延、队列、错误率、GPU水位，以及业务输出质量。旧版本会完整保留到灰度验证结束，一旦出现错误率上升、长尾恶化、输出异常，立刻切回稳定版本，再定位问题。回滚不是去机器上改配置，而是恢复一组已经验证过的运行配置，分钟级即可完成。做完这一系列改造，我们才真正把“单机上能跑的模型”，变成了“生产环境可运营的服务”。这套体系也是我们后续能够快速接入多个业务、持续扩缩容的核心支撑。

六、业务落地与当前规模

目前这套私有化大模型体系，已经全面支撑了公司的多类业务场景，覆盖不同的负载类型：

• 离线批处理：小说画像抽取，5个节点满负荷运行，持续处理全量书籍数据，为角色库和内容运营提供数据底座；
• 在线工作流：C端AI搜索，LangGraph全链路采用4B+27B分层调度，多轮对话通过会话路由优化性能；
• 通用内容生成：AI金句、AI词典、AI续写等场景，统一复用27B通用生成能力；
• 专用推理场景：生成式推荐以Qwen 1.7B为底座，结合专用训练与约束解码，独立部署，复用同一套工程交付体系。

截至目前，私有化推理集群已有35个节点、44张GPU，同时承载离线批处理、在线交互、通用生成、约束生成等多种混合负载。

比资源规模更重要的是，我们已经形成了一套可复制的落地路径：新的模型版本可以沿着这套体系完成评测、优化、上线；新的业务场景接入，也不需要从零搭建生产链路，大幅降低了创新的工程成本。

七、总结与后续思考

回顾整个私有化落地的过程，我们最大的感受是：私有化大模型的核心挑战从来不是“把模型跑起来”，而是围绕业务价值，构建一套效果、成本、稳定性三者平衡的工程体系。

沉淀下来的核心经验有三点：

第一，业务价值是所有技术决策的出发点。模型选型不唯参数论，性能优化不唯峰值论，所有决策都要回到真实业务场景里验证。脱离业务的技术优化，都是自嗨。

第二，分层协同是性价比最优的路径。不要试图用一个大模型解决所有问题，通过“大模型保上限+小模型提效率+能力持续下沉”的组合，才能在效果和成本之间找到最优解。

第三，工程体系是规模化的基石。从单机验证到规模化服务，真正的门槛是标准化的交付流程、可观测的运行状态、可追溯的版本管理、可快速回滚的发布机制。没有这套体系，GPU越多，管理成本越高，故障越难排查。

后续我们会继续沿着几个方向深化：一是持续优化推理调度策略，探索更智能的流量分发与资源复用；二是完善模型蒸馏与能力下沉的工具链，让更多成熟任务实现低成本迁移；三是进一步完善全链路观测与运维体系，提升大规模集群的运营效率。也欢迎各个业务团队和我们一起探索更多大模型落地场景，把这套基建的价值充分释放出来。