GPU 显存管理：7B 模型 FP16 推理需要约 14GB 显存，70B 模型需要 140GB+，KV Cache 随并发数线性增长，显存碎片化导致实际利用率不足 60%高并发低延迟：在线服务要求 P99 延迟可控，传统静态批处理在请求长度差异大时效率低下弹性伸缩：GPU 资源昂贵（A100 单卡约 $2/h），流量波谷时需要快速缩容降本多模型管理：生产环境通常同时运行多个模型版本，需要灰度发布

GPU 显存管理：7B 模型 FP16 推理需要约 14GB 显存，70B 模型需要 140GB+，KV Cache 随并发数线性增长，显存碎片化导致实际利用率不足 60%高并发低延迟：在线服务要求 P99 延迟可控，传统静态批处理在请求长度差异大时效率低下弹性伸缩：GPU 资源昂贵（A100 单卡约 $2/h），流量波谷时需要快速缩容降本多模型管理：生产环境通常同时运行多个模型版本，需要灰度发布

1、安装插件，AnsiColor。2、选择颜色日志输出。

容器本身是无状态的，Pod重启后容器内的数据全部丢失。数据库、消息队列、文件存储这类有状态服务跑在K8s上，必须解决持久化存储问题。Kubernetes通过PersistentVolume（PV）、PersistentVolumeClaim（PVC）和StorageClass三层抽象来管理存储。实际生产中踩过的坑：开发团队直接在Pod里用hostPath挂载宿主机目录，Pod漂移到其他节点后数据就

最近搭建jenkins做持续集成，版本2.462，最低要求jdk11。构建jdk1.8的项目总是默认使用jdk11构建。后来排查是因为maven 集成插件版本问题。高版本的maven插件不支持jdk1.8。将jdk1.8的包下载解压到服务器路径下，但是不能做环境变量，因为jenkins默认要用jdk11。2.新增一个自由风格项目，不使用maven构建项目。3.在job中选择maven 构建。这样就

是最重要的参数之一。在16GB内存的服务器上，我通常设置为12GB，这样既保证了数据库性能，又为操作系统留下了足够空间。• 2：每次提交写入OS缓存，每秒刷新到磁盘（推荐的平衡选择）• 0：每秒刷新一次（性能最好，但可能丢失数据）• 1：每次事务提交都刷新（最安全，性能较差）• 复合索引字段顺序：选择性高的字段在前。• 单表索引数量控制在5个以内。

StorageClass的出现完美解决了这些问题，它就像是K8s存储的"智能调度器"。：业务增长时，存储扩容需要大量人工干预。：Pacific 16.x或更新版本。• 建议为CSI Pod设置资源限制。：手动创建PV，容易出错且效率低下。：不同业务线的存储需求无法有效区分。：每个工作节点至少4核8GB内存。• 启用Pod反亲和性确保高可用。：集群内网带宽≥1Gbps。• 配置监控告警机制。

【代码】openkylin、ubuntu22部署opencv4.8.0。

3、因国内原因，前端页面会调一些国外的域名，导致前端页面加载的很慢，需要修改下源代码。找到这个文件：backend/open_webui/utils/models.py。1、部署ollama---基于GPU；不使用GPU就去掉--gpus参数。容器启动后，进入容器拉取模型，模型根据GPU的能力来下载；如果1和2不部署在一台机器上，分离的时候使用。注释掉红框里的代码，这样前端页面会加载快的多。启动后

查了半天发现是后端服务器连接Redis的TIME_WAIT太多，把本地端口（默认32768-60999，大约2.8万个）占满了。传统的内存页是4KB，对于大内存应用（数据库、JVM）来说，页表会非常大，TLB（Translation Lookaside Buffer）命中率低。这在大多数场景下没问题，因为程序申请的内存不一定全用。在某些场景下会导致性能问题，因为它会优先回收本地内存（包括页面缓存）