Zing 论坛

正文

基于K3s的自托管LLM平台:GPU推理、多模型切换与云原生Agent工具链

一个完整的概念验证项目,展示如何在单节点K3s集群上搭建生产级LLM推理平台,支持vLLM后端、LiteLLM网关、多模型动态切换和完整的可观测性体系。

LLM平台K3svLLMLiteLLMGPU推理云原生Kubernetes多模型切换自托管AI
发布时间 2026/06/15 22:13最近活动 2026/06/15 22:22预计阅读 4 分钟
基于K3s的自托管LLM平台:GPU推理、多模型切换与云原生Agent工具链
1

章节 01

基于K3s的自托管LLM平台核心概览

基于K3s的自托管LLM平台是由bitnik维护的概念验证项目(POC),发布于2026年6月15日(GitHub链接:https://github.com/bitnik/llm-platform)。该项目展示如何在单节点K3s集群上搭建生产级LLM推理平台,核心特性包括:

  • 使用vLLM作为推理后端
  • 通过LiteLLM网关实现统一API访问
  • 支持多模型动态切换
  • 内置完整的可观测性体系(Prometheus+Grafana+OTel)

本帖将分楼层解析该平台的背景、架构、关键机制、部署流程及技术选型等内容。

2

章节 02

项目背景与目标

随着LLM在开发工作流中的渗透,越来越多团队探索私有基础设施部署方案。自托管LLM带来数据隐私、成本控制、模型选择灵活性等优势,但也面临架构复杂、运维门槛高、资源管理难等挑战。

本项目旨在提供一套单节点K3s上的完整生产级LLM推理平台POC,不仅验证模型运行能力,更覆盖GPU调度、Operator管理、Kubernetes清单编排等关键生产部署环节。

3

章节 03

平台架构分层解析

平台采用分层解耦的云原生架构,各组件职责清晰:

外部客户端层

开发者可通过Claude Code(HTTPS接入)、kubectl-ai(K8s命令行助手)、k8sgpt CLI(K8s诊断工具)与平台交互。

网关层

LiteLLM Proxy作为统一API网关,负责:

  • 按模型名称路由请求
  • 用户级API密钥管理、预算控制和速率限制
  • 统一日志与监控
  • Anthropic与OpenAI协议自动转换

推理层

vLLM为核心推理引擎,部署于单张物理GPU。平台支持多模型部署,但任意时刻仅一个模型处于活跃状态(ACTIVE),其余休眠。

存储与可观测性层

  • local-path PVC:基于NVMe本地存储持久化模型权重
  • Prometheus + Grafana + OTel:完整监控、告警和链路追踪体系
4

章节 04

多模型动态切换机制详解

多模型动态切换是平台特色设计,采用‘休眠-唤醒’策略:

状态定义

状态 描述 显存占用
ACTIVE 模型加载到GPU显存,可立即响应 ~20GB VRAM
SLEEPING (L1) 权重从显存卸载到系统内存(保持映射) 0 VRAM
COLD 权重仅存于磁盘,需重新加载 0 VRAM, 0 RAM

切换控制器

内置切换控制器通过POST /sleepPOST /wake_up端点管理状态转换:

  • 切换时,当前活跃模型执行L1休眠(显存→内存)
  • 目标模型从内存/磁盘加载到显存成为新活跃模型

价值

适用于:

  • 代码助手与聊天机器人混用场景
  • 多租户环境(按需切换而非预留GPU)
  • 成本敏感场景(最大化单GPU利用率)
5

章节 05

部署流程与可观测性体系

部署流程关键步骤

  1. 基础环境准备:选择Ubuntu 24.04 LTS(NVIDIA驱动/CUDA支持完善),安装NVIDIA驱动、Container Toolkit(容器访问GPU的桥梁)。
  2. K3s集群搭建:单节点K3s(轻量,内置Traefik和local-path),部署NVIDIA GPU Operator(转化GPU为Pod可申请资源)。
  3. 模型服务部署:vLLM配置需请求nvidia.com/gpu:1资源,调整显存利用率参数,启用休眠模式;通过local-path PVC持久化模型权重(避免重复下载)。
  4. 网关与入口配置:LiteLLM作为唯一前向入口;Traefik Ingress + cert-manager实现HTTPS安全接入。
  5. 客户端接入:不同工具配置方式不同(如kagent设置baseUrl指向LiteLLM,Claude Code设置ANTHROPIC_BASE_URL环境变量)。

可观测性体系

核心指标包括GPU利用率(DCGM导出)、KV缓存压力(vLLM特有)、抢占率、P95延迟;可选集成OpenTelemetry实现全链路追踪。

6

章节 06

技术选型思考

为什么选择vLLM?

  • PagedAttention算法:提升显存利用率和吞吐率
  • 连续批处理:支持多用户并发流水线处理
  • OpenAI兼容API:降低客户端迁移成本
  • 活跃社区:快速迭代与新模型支持

为什么选择LiteLLM?

  • 多后端统一:对接vLLM、OpenAI、Azure OpenAI等
  • 预算管控:细粒度用量限制与成本控制
  • 协议转换:自动处理不同厂商API差异

为什么选择K3s?

  • 资源占用低:适合边缘/POC环境
  • 内置组件齐全:默认包含存储、Ingress、DNS
  • 标准K8s兼容:POC模式可迁移到生产集群
7

章节 07

当前局限与扩展方向

当前局限

  • 单节点架构:无高可用能力
  • 手动模型切换:需显式调用API,无自动负载驱动切换
  • 存储限制:local-path不支持跨节点迁移

扩展方向

  • 多节点扩展:支持多GPU分布式推理
  • 自动扩缩容:基于请求队列长度扩缩vLLM副本
  • 模型缓存优化:引入共享存储或模型仓库加速冷启动
  • 多租户隔离:通过Namespace和NetworkPolicy实现更强隔离
8

章节 08

总结与启示

本项目为自托管LLM基础设施团队提供扎实起点,其价值不仅在于代码,更在于设计思想:

  1. 云原生优先:利用K8s编排能力,避免自建调度
  2. 分层解耦:网关、推理、存储各司其职,便于升级替换
  3. 资源效率:休眠机制最大化单GPU利用率
  4. 可观测性内置:监控为一等公民

对于评估自托管LLM方案的团队,该项目提供可运行参考实现,帮助理解从裸机到服务的完整路径及技术权衡。