业务和功能介绍
为应对 DeepSeek-V4-Pro 模型在长上下文、高并发推理场景下的性能瓶颈，我们启动了 H20 集群推理服务优化项目。原单机部署方案在解码阶段依赖 DSpark 投机解码（num_speculative_tokens=3）进行加速，但在实际业务流量（高峰约 100 req/min）下，KV Cache 显存占用成为主要限制，导致请求承载能力仅约 10% 的流量比例，大量请求因资源不足被拒绝或排队，严重影响服务可用性和用户体验。
本次项目旨在通过架构升级，将部署规模从单机扩展至双 H20 集群，并引入 LMCache KVCache Pool 池化技术，实现 KV Cache 跨实例复用，显著降低长上下文场景下重复 Prefill 计算开销，最终目标是将业务承载能力提升至 25% 以上，保障高峰流量下的服务稳定性与低延迟响应。
本次项目旨在通过架构升级，将部署规模从单机扩展至双 H20 集群，并引入 LMCache KVCache Pool 池化技术，实现 KV Cache 跨实例复用，显著降低长上下文场景下重复 Prefill 计算开销，最终目标是将业务承载能力提升至 25% 以上，保障高峰流量下的服务稳定性与低延迟响应。
项目实现
原方案为单机 H20 部署，vLLM + DSpark 投机解码（num_speculative_tokens=3）优化 Decode 阶段性能，但 KV Cache 受单机显存限制，长上下文和高并发下扩展性不足。
优化后方案采用 LMCache Server + Coordinator + vLLM Router 分布式架构，通过 KVCache Pool 池化管理，实现跨实例、跨节点的 KV Cache 复用与调度。
2.2 核心优化措施
LMCacheMPConnector 集成：在 vLLM 推理引擎中接入 LMCache 的 MPConnector，使 vLLM 能够与 LMCache KVCache Pool 无缝对接，实现 KV Cache 的读写和共享。
KV Cache 池化与持久化：每个计算节点配置 560GB L1 级 KV Cache 空间（基于 CPU 内存或高速存储），支持 KV Cache 的持久化存储和跨实例热加载，避免同一 Prompt 在不同实例上重复 Prefill。
高效传输引擎：采用 NIXL P2P 传输引擎，优化节点间 KV Cache 的数据同步效率，降低跨节点访问延迟。
调度与流控：保留 DSpark 投机解码能力（num_speculative_tokens=3），同时通过 vLLM Router 实现多实例间的流量均衡调度、限流保护及过载熔断，确保集群整体稳定性。
2.3 上线效果
部署规模：由单机 H20 扩展至 双 H20 集群，总 GPU 显存和计算能力翻倍。
承载能力：业务流量承载比例从原约 10% 提升至 25%，整体提升约 2.5 倍。
实际流量表现：在 DeepSeek-V4-Pro 高峰约 100 req/min 的总业务请求下，集群可稳定承担约 25 req/min 的推理请求，拒绝率大幅下降。
延迟表现：在 25 req/min 压测 场景下，首 Token 延迟约为 25 秒，服务整体稳定性显著提升，未出现明显的超时或抖动。
优化后方案采用 LMCache Server + Coordinator + vLLM Router 分布式架构，通过 KVCache Pool 池化管理，实现跨实例、跨节点的 KV Cache 复用与调度。
2.2 核心优化措施
LMCacheMPConnector 集成：在 vLLM 推理引擎中接入 LMCache 的 MPConnector，使 vLLM 能够与 LMCache KVCache Pool 无缝对接，实现 KV Cache 的读写和共享。
KV Cache 池化与持久化：每个计算节点配置 560GB L1 级 KV Cache 空间（基于 CPU 内存或高速存储），支持 KV Cache 的持久化存储和跨实例热加载，避免同一 Prompt 在不同实例上重复 Prefill。
高效传输引擎：采用 NIXL P2P 传输引擎，优化节点间 KV Cache 的数据同步效率，降低跨节点访问延迟。
调度与流控：保留 DSpark 投机解码能力（num_speculative_tokens=3），同时通过 vLLM Router 实现多实例间的流量均衡调度、限流保护及过载熔断，确保集群整体稳定性。
2.3 上线效果
部署规模：由单机 H20 扩展至 双 H20 集群，总 GPU 显存和计算能力翻倍。
承载能力：业务流量承载比例从原约 10% 提升至 25%，整体提升约 2.5 倍。
实际流量表现：在 DeepSeek-V4-Pro 高峰约 100 req/min 的总业务请求下，集群可稳定承担约 25 req/min 的推理请求，拒绝率大幅下降。
延迟表现：在 25 req/min 压测 场景下，首 Token 延迟约为 25 秒，服务整体稳定性显著提升，未出现明显的超时或抖动。
示例图片视频
相似推荐
医院DIP2.0按病种分值付费分组匹配系统
立项背景：为响应国家医保局DIP（按病种分值付费）支付方式改革，医院需对住院病例进行自动分组与分值测算，替代人工查表，提升医保结算准确率与效率。
核心功能：
1. 编码标准化：对诊断编码（ICD-10）和手术操作编码（ICD-9-CM3）进行自动补零、格式校验，统一为国临版与医保版2.0标准格式；
2. 编码对照映射：通过诊断对照库、手术对照库，将国临版编码自动映射为医保版2.0编码，支持23个手术操作字段批量对照；
3. DIP智能分组引擎：基于主诊断+主操作组合，实现+组合匹配、/或规则匹配、单码精准匹配、规则组匹配、编码范围匹配、s(n)/a(n)四级兜底等多层匹配策略，自动输出DIP病种ID；
4. 最优候选选择：当多个病种同时命中时，按匹配编码数量、是否包含主操作、操作位置优先级自动选优；
5. 分值计算：关联分值总表，自动计算每个病例的DIP病种分值，输出完整匹配结果表。
业务流程：原始住院病例数据 → 诊断/手术编码补零标准化 → 国临版转医保版对照 → DIP分组引擎多层匹配 → 最优病种选择 → 分值关联 → 输出结算结果。
企业级CRM数据清洗与迁移工具-DataBridge（个人演示项目）
本案例为个人演示项目，面向中小企业更换CRM或整合多来源客户资料时的数据整理需求。用户可导入Excel或CSV文件，配置字段映射规则，完成手机号、邮箱和公司名称标准化，并按组合条件识别重复记录；系统随后展示异常数据、冲突字段和处理建议，用户确认后可导出目标CRM可直接导入的数据文件及清洗报告。整个流程覆盖导入、预览、映射、去重、校验、修复和导出，重点降低人工反复核对带来的遗漏与时间成本。
基于本地化GUI的AI助手客户端-智语助手
立项背景与目标：
在日常工作与学习中，用户频繁需要获取AI辅助回答，但网页端使用需频繁切换浏览器，效率较低。本项目旨在开发一款轻量级桌面AI助手，提供一键式智能问答体验，降低使用门槛，提升日常信息获取效率。
软件功能：
用户输入问题后，点击提交或回车键，程序自动调用AI模型生成回答，并即时显示在窗口中，支持长文本自动换行。
核心功能模块：
1. 用户输入模块（Entry控件）
2. AI接口调用模块（requests + 智谱AI API）
3. 结果显示模块（Label控件 + 自动换行）
业务流程：
用户输入问题 → 点击提交 → 程序获取输入 → 调用AI接口 → 返回结果 → 窗口显示回答
功能路径：
启动程序 → 输入框输入问题 → 点击“提交”按钮 → 查看AI回答 → 输入框自动清空，等待下一次提问
AI智能体平台-AI智能体
Dify，Ragflow,langraph运行平台。
MCP展示执行平台。
RuoYi应用框架做载体。
SpringCloud alibaba 做微服务支持。实现业务系统智能体在平台运行展示结果。
使用RuoYi框架的权限体系和系统管理，支撑整个平台业务。平台实现API调用和API生成来支持执行和结果展示。用RuoYi框架的权限体系和系统管理，支撑整个平台业务。平台实现API调用和API生成来支持执行和结果展示。用RuoYi框架的权限体系和系统管理，支撑整个平台业务。平台实现API调用和API生成来支持执行和结果展示。
数据在线采集
本项目为产业数据直报系统：
1、管理端（省/市/县区三级监管）和填报端（企业、非经营单位）提供端到端的数字化数据采集、审核、统计与导出能力。
2、系统按报告期（年/季/月）驱动 10 张业务表单的填报，涵盖企业基础档案、种植、生产加工、销售、文旅、税收贸易，以及景气调查问卷（含数字选项码与多选字段）。
3、审核采用三级联审机制，支持企业撤回修改、各角色取回、县区退回需第三方评估等精细化规则。
4、管理端提供按地区维度的仪表盘统计（应填/已填/待审/退回率、部分填报识别）、填报进度追踪（按企业/表单维度）和 Excel 导出（问卷选项码转中文、密码加密、填报端仅导出本单位），形成采集-审核-分析闭环。
帮助文档
Copyright @ 2021-2024 程聚宝 | 浙ICP备2021014372号
人工客服