Kubernetes 与 DeepSeek：高效 Pod 部署配置与资源调度优化指南

AC赳赳老秦2026-01-21 13:29

摘要： 随着大语言模型（Large Language Model, LLM）在自然语言处理、内容生成、代码辅助等领域的广泛应用，如何高效、稳定、经济地在生产环境中部署和管理这些模型成为关键挑战。Kubernetes（K8s）作为领先的容器编排平台，结合 DeepSeek 系列模型的能力，为构建大规模 AI 服务提供了强大的基础设施。本文将深入探讨在 Kubernetes 集群中部署 DeepSeek 模型的最佳实践，涵盖 Pod 配置模板、资源请求与限制设定、调度器优化策略（包括拓扑感知调度、抢占策略、Pod 亲和/反亲和性）、自动扩缩容（HPA/VPA）配置、持久化存储方案、监控与日志收集，以及成本优化技巧。目标是实现高吞吐、低延迟的服务响应，同时最大化资源利用率并控制成本。

一、引言

DeepSeek 作为先进的大语言模型，其部署对计算资源（尤其是 GPU）、内存和网络带宽有极高要求。Kubernetes 提供了声明式配置、自动化部署、服务发现、负载均衡、弹性扩缩容等核心功能，是管理此类计算密集型工作负载的理想平台。

核心挑战：

  1. 资源密集型： 模型推理需要大量 GPU 资源，模型加载和上下文处理消耗大量内存。
  2. 延迟敏感： 用户交互场景要求低延迟响应。
  3. 高可用性： 服务需具备容错能力和快速恢复机制。
  4. 成本控制： GPU 资源昂贵，需最大化利用率，避免闲置浪费。
  5. 批处理与流式处理： 需支持推理请求的批处理优化和流式响应。

Kubernetes 通过其丰富的 API 和生态系统，为解决这些挑战提供了系统性的方案。

二、基础 Pod 部署配置

2.1 Pod 定义核心组件

一个典型的 DeepSeek 推理服务 Pod 的 Kubernetes Manifest (deepseek-inference-pod.yaml) 应包含以下核心部分：

yaml 复制代码 
apiVersion: v1
kind: Pod
metadata:
  name: deepseek-inference-pod
  labels:
    app: deepseek-inference
    model: deepseek-rl # 根据实际模型版本调整
spec:
  containers:
  - name: deepseek-container
    image: registry.example.com/deepseek-inference:latest # 替换为实际镜像地址
    imagePullPolicy: Always # 或 IfNotPresent
    ports:
    - containerPort: 8000 # 假设服务监听端口
    env:
    - name: MODEL_PATH
      value: "/models/deepseek-rl" # 模型在容器内的路径
    - name: MAX_BATCH_SIZE
      value: "32" # 最大批处理大小
    resources:
      requests:
        cpu: "4" # 请求的CPU核心数
        memory: "48Gi" # 请求的内存
        nvidia.com/gpu: "1" # 请求的GPU数量
      limits:
        cpu: "8" # CPU上限
        memory: "64Gi" # 内存上限
        nvidia.com/gpu: "1" # GPU上限
    volumeMounts:
    - name: model-storage
      mountPath: /models
  volumes:
  - name: model-storage
    persistentVolumeClaim:
      claimName: deepseek-model-pvc # 关联的PVC名称

关键配置说明：

  1. 镜像 (image): 使用包含 DeepSeek 推理代码和依赖的 Docker 镜像。建议通过 CI/CD 流程自动构建和推送。
  2. 环境变量 (env):
    • MODEL_PATH: 指定模型文件在容器内的加载路径。
    • MAX_BATCH_SIZE: 设置推理服务一次能处理的最大请求数，对吞吐量优化至关重要。
    • 其他可能变量：HUGGING_FACE_HUB_TOKEN (如需从 Hugging Face Hub 下载)，LOG_LEVEL 等。
  3. 资源请求与限制 (resources): 这是性能调优和稳定性的基石。
    • requests: Kubernetes 调度器根据此值决定将 Pod 调度到哪个节点。它表示容器运行所需的最小资源量。必须准确设置，尤其是 GPU (nvidia.com/gpu) 和内存。 低估会导致 Pod 无法调度或运行不稳定（OOMKilled）；高估会导致集群资源碎片化，利用率低下。
    • limits: 容器可以使用的资源上限。防止单个 Pod 耗尽节点资源，影响其他 Pod。CPU 限制会影响调度（CPU Throttling），内存限制超出会导致 OOMKilled，GPU 限制通常设为与请求相同。
    • DeepSeek 模型资源估算：
      • GPU: 模型加载和推理主要依赖 GPU。模型规模越大，所需 GPU 显存越大。例如，DeepSeek-RL 可能需要至少 40GB GPU 显存，因此通常需要 A100 (40GB/80GB) 或类似规格的 GPU。nvidia.com/gpu: "1" 表示请求一个完整的 GPU 卡。
      • CPU: 需要足够的 CPU 处理预处理/后处理、网络 I/O、框架开销等。建议 4-8 核。
      • 内存 (RAM): 加载模型权重需要大量内存（通常接近模型大小）。此外，处理长上下文、批处理、框架缓存等也需要额外内存。建议设置为模型参数大小的 1.5 - 2 倍。例如，一个 30B 参数的模型，权重约 60GB (FP16)，内存请求至少 90-120Gi。
  4. 持久化存储 (volumes / volumeMounts): 模型文件通常很大（几十 GB 到几百 GB），不适合打包进镜像。使用 PersistentVolume (PV) 和 PersistentVolumeClaim (PVC) 挂载模型存储卷。可以使用高性能网络存储（如 NFS、CephFS、云存储卷）或本地 SSD（需结合调度策略）。

2.2 使用 Deployment 管理副本

实际生产环境中，不会直接创建裸 Pod。使用 Deployment 来管理多个相同的 Pod 副本，提供滚动更新、回滚、副本数维护等功能。

yaml 复制代码 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deepseek-inference-deployment
spec:
  replicas: 3 # 初始副本数
  selector:
    matchLabels:
      app: deepseek-inference
  template: # Pod模板，内容与上面的Pod定义类似
    metadata:
      labels:
        app: deepseek-inference
        model: deepseek-rl
    spec:
      containers:
      - name: deepseek-container
        image: registry.example.com/deepseek-inference:latest
        ... # 环境变量、端口、资源限制、挂载卷等配置同上

replicas: 设置期望的 Pod 副本数量。副本数的确定依赖于负载预测、服务可用性要求以及成本考虑。

2.3 服务暴露 (Service)

创建 Kubernetes Service 为 Deployment 管理的 Pod 提供一个稳定的访问入口（ClusterIP、NodePort、LoadBalancer），并实现负载均衡。

yaml 复制代码 
apiVersion: v1
kind: Service
metadata:
  name: deepseek-inference-service
spec:
  selector:
    app: deepseek-inference # 匹配Deployment的Pod标签
  ports:
  - port: 80 # Service端口
    targetPort: 8000 # Pod容器端口
  type: LoadBalancer # 也可以是ClusterIP或NodePort

三、高级资源调度优化

Kubernetes 调度器 (kube-scheduler) 负责为新创建的 Pod 选择合适的节点。对于 GPU 密集型、高内存消耗的 DeepSeek Pod，需要精细化的调度策略以确保性能和稳定性。

3.1 拓扑感知调度 (Topology Awareness)

现代服务器通常包含多个 GPU、多个 CPU 插槽（NUMA 节点）、高速互连（如 NVLink）。拓扑感知调度确保 Pod 使用的资源（特别是 GPU 和 CPU）在物理上尽可能靠近，减少跨 NUMA 节点或跨 PCIe 开关的访问延迟，显著提升性能。

实现方式：

  1. 节点标签: 为节点打上描述其硬件拓扑的标签：

    bash 复制代码 
    kubectl label nodes <node-name> topology.kubernetes.io/zone=zone-a
kubectl label nodes <node-name> topology.kubernetes.io/region=region-1
# 更细粒度，例如：
kubectl label nodes <node-name> topology.nvidia.com/gpu.socket=0 # GPU 所属 CPU socket
kubectl label nodes <node-name> topology.nvidia.com/gpu.link=nvlink # GPU 互连类型

  2. Pod nodeSelector: 在 Pod Spec 中指定节点选择器，将 Pod 调度到特定拓扑域。

    yaml 复制代码 
    spec:
  nodeSelector:
    topology.kubernetes.io/zone: zone-a # 调度到特定可用区
    nvidia.com/gpu.count: "4" # 选择拥有4块GPU的节点
    accelerator: a100 # 选择配备A100 GPU的节点

  3. Pod affinity / anti-affinity:

    • 亲和性 (affinity): 将 Pod 调度到与其"喜欢"的 Pod 相同的拓扑域（节点、可用区）。例如，多个需要高速通信的推理 Pod 放在同一个节点或可用区。
    • 反亲和性 (anti-affinity): 避免将 Pod 调度到与其"排斥"的 Pod 相同的拓扑域。对于 DeepSeek 的多个副本，通常建议使用 Pod 反亲和性 (podAntiAffinity)，将它们分散到不同节点或可用区，提高容灾能力和负载均衡效果。
    yaml 复制代码 
    spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution: # 硬性要求
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - deepseek-inference
        topologyKey: "kubernetes.io/hostname" # 确保不同副本不在同一主机

3.2 GPU 资源细粒度控制 (Device Plugins & MPS)

  • 共享 GPU (Time-Slicing / MPS): Kubernetes 通过 nvidia-docker2 和 Device Plugin 支持 GPU 共享。可以为一个 GPU 卡调度多个 Pod，每个 Pod 分时复用 GPU 资源。但需注意，共享可能导致性能下降和潜在干扰。对于 DeepSeek 这类高吞吐需求的服务，通常建议独占 GPU (nvidia.com/gpu: "1")。 如果负载较低或使用较小模型，可评估共享方案。
  • GPU 类型选择: 通过 nodeSelector 或 nodeAffinity 选择特定型号的 GPU (如 accelerator: a100, accelerator: h100)。不同型号 GPU 在算力、显存、互连带宽上差异显著。
  • 显存控制: Kubernetes 目前主要通过请求整个 GPU 来控制显存。更细粒度的显存分配（如指定 nvidia.com/gpu.memory: 20Gi）需要额外的插件或运行时支持（如 NVIDIA MPS），配置较复杂且可能有性能损耗，需谨慎评估。

3.3 优先级 (Priority) 与抢占 (Preemption)

对于混合部署环境（运行 DeepSeek 推理、训练、其他服务）：

  • 设置 Pod 优先级 (priorityClassName): 为 DeepSeek 推理 Pod 分配较高的优先级 (如 system-cluster-critical 或自定义高优先级类)。确保在资源紧张时，推理服务优先获得资源。
  • 启用抢占: 如果高优先级 Pod 无法调度，调度器会驱逐（优雅终止）低优先级 Pod 以释放资源。配置抢占策略 (preemptionPolicy)，并确保低优先级工作负载有合适的容忍度 (tolerations) 和中断预算 (PDB)。
yaml 复制代码 
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: deepseek-high-priority
value: 1000000 # 数值越大优先级越高
globalDefault: false
description: "High priority for DeepSeek inference pods"

# 在Pod Spec中使用
spec:
  priorityClassName: deepseek-high-priority

3.4 污点 (Taints) 与容忍 (Tolerations)

  • 节点污点 (Taints): 标记节点，阻止一般 Pod 调度上来。常用于专用 GPU 节点。

    bash 复制代码 
    kubectl taint nodes <gpu-node> dedicated=deepseek:NoSchedule

  • Pod 容忍 (Tolerations): 允许 Pod 调度到带有特定污点的节点。

    yaml 复制代码 
    spec:
  tolerations:
  - key: "dedicated"
    operator: "Equal"
    value: "deepseek"
    effect: "NoSchedule"

    这确保 DeepSeek Pod 只会调度到标记为 dedicated=deepseek:NoSchedule 的专用 GPU 节点上。

四、自动扩缩容 (Autoscaling)

负载波动是常态。手动调整副本数效率低下。Kubernetes 提供两种主要扩缩容机制：

4.1 水平 Pod 自动扩缩容 (Horizontal Pod Autoscaler - HPA)

HPA 根据观测到的 CPU 利用率、内存利用率、或自定义指标自动调整 Deployment/StatefulSet 的副本数 (replicas)。

DeepSeek 推理 HPA 配置示例：

yaml 复制代码 
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: deepseek-inference-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: deepseek-inference-deployment
  minReplicas: 2 # 最小副本数
  maxReplicas: 10 # 最大副本数
  metrics:
  - type: Resource
    resource:
      name: cpu # 基于CPU利用率
      target:
        type: Utilization
        averageUtilization: 70 # 目标CPU利用率70%
  - type: Resource
    resource:
      name: memory # 基于内存利用率
      target:
        type: Utilization
        averageUtilization: 80 # 目标内存利用率80%
  # 更重要的：基于自定义指标（如请求队列长度、QPS）
  - type: Pods
    pods:
      metric:
        name: requests_in_queue # 假设的自定义指标名
      target:
        type: AverageValue
        averageValue: 10 # 平均每个Pod队列长度目标为10

HPA 指标选择关键点：

  1. CPU/Memory: 基础指标，但可能不够灵敏。GPU 利用率通常 不 直接作为 HPA 指标，因为 GPU 利用率高通常意味着需要更多副本，但扩缩容动作本身基于 CPU/Memory 或自定义指标更直接。
  2. 自定义指标 (Custom Metrics): 这是优化 DeepSeek 扩缩容的关键。
    • 请求到达率 (QPS / RPS): 通过服务网格 (如 Istio) 或 API Gateway 收集。
    • 请求队列长度: 在推理服务内部暴露指标（如 Prometheus metrics），表示等待处理的请求数。这是非常灵敏的扩缩容依据。
    • 平均响应延迟: 超过阈值时扩容。
    • GPU 利用率: 虽然不直接用于扩缩容决策，但用于监控和分析瓶颈。
    • 需要部署 Metrics Server 和 Prometheus Adapter 来收集和暴露这些自定义指标给 HPA。

挑战与优化：

  • 冷启动延迟： 新 Pod 启动需要加载模型（可能耗时几分钟），导致扩容期间响应延迟陡增。策略：
    • 设置 minReplicas 覆盖基本负载。
    • 预热池 (通过 HPA 的 behavior 字段控制扩缩容速度，避免剧烈波动)。
    • 考虑使用 Knative 或 KFServing 等框架，支持更快的冷启动（如保留部分预加载模型的 Pod）。
  • 指标延迟： 指标采集和计算有延迟。调整 HPA 的评估窗口 (--horizontal-pod-autoscaler-sync-period 和 metrics 的 windowSeconds) 和容忍度 (tolerance)。

4.2 垂直 Pod 自动扩缩容 (Vertical Pod Autoscaler - VPA)

VPA 根据 Pod 的历史资源使用情况，自动调整 Pod 的 requests 和 limits（主要是 CPU 和 Memory）。

DeepSeek VPA 配置示例：

yaml 复制代码 
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: deepseek-inference-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: deepseek-inference-deployment
  updatePolicy:
    updateMode: "Auto" # 或 "Initial", "Recreate", "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "deepseek-container"
      minAllowed:
        cpu: "2"
        memory: "32Gi"
      maxAllowed:
        cpu: "16"
        memory: "128Gi"

VPA 在 DeepSeek 部署中的价值与注意点：

  • 价值：
    • 优化资源请求： 避免因初始 requests 设置过高导致资源浪费，或过低导致调度失败/OOM。VPA 根据实际用量推荐合适的值。
    • 应对负载变化： 不同时间、不同请求类型可能导致资源需求变化。
  • 注意点：
    • GPU： VPA 目前不支持 GPU 资源的自动调整。GPU requests 和 limits 仍需手动设置。
    • Pod 重启： 在 Auto 或 Recreate 模式下，VPA 调整资源需要重建 Pod，导致服务短暂中断。对于在线服务，这可能不可接受。 常用模式：
      • Initial 模式：只在 Pod 首次创建时设置建议值。
      • 定期分析 VPA 建议，手动更新 Deployment 模板。
    • 稳定性： 确保 minAllowed 和 maxAllowed 设置合理，防止 VPA 推荐出极端值。

HPA 与 VPA 结合： 通常同时使用。HPA 管理副本数应对流量变化，VPA 优化单个 Pod 的资源规格。注意避免冲突（例如 VPA 增加单个 Pod 资源可能减少 HPA 需要的副本数）。

五、持久化存储与数据管理

5.1 模型存储

  • PersistentVolume (PV) / PersistentVolumeClaim (PVC): 如前所述，使用 PVC 挂载模型文件。选择高性能、低延迟的存储后端：

    • 云存储卷： AWS EBS (gp3/io2), GCP PD (SSD), Azure Disk (Premium SSD)。提供持久化和较高 IOPS。
    • 网络文件存储： NFS, CephFS (RBD/CephFS), GlusterFS。支持多节点共享读取，适合多副本加载同一模型。注意网络延迟和带宽。
    • 高性能本地存储： 如果节点配备高速本地 SSD (如 NVMe)，可配置 Local PV。必须结合节点亲和性或 Pod 反亲和性，确保 Pod 调度到拥有所需模型数据的节点。 提供最佳 IO 性能，但牺牲了灵活性和持久性（需额外备份）。

  • Init Containers for Model Download: 如果模型未预先存储在 PV 中，可在 Pod 启动时使用 initContainer 从远程源（如 Hugging Face Hub, S3）下载模型到 PVC 挂载的卷。

    yaml 复制代码 
    spec:
  initContainers:
  - name: download-model
    image: appropriate/downloader-image # 如 awscli, huggingface-hub
    command: ['sh', '-c', 'aws s3 cp s3://bucket/model.tar.gz /models/ && tar xzf /models/model.tar.gz -C /models']
    volumeMounts:
    - name: model-storage
      mountPath: /models

5.2 输入/输出数据与状态管理

  • 临时数据： 推理过程中的临时数据通常使用容器内的临时存储或 emptyDir 卷。生命周期与 Pod 一致。
  • 持久化输出/状态： 如果需要保存推理结果或会话状态：
    • 将结果写入数据库。
    • 使用单独的 PVC 挂载输出目录。注意并发写入问题。
    • 使用对象存储（如 S3, MinIO）。

六、监控、日志与告警

没有监控，优化无从谈起。

6.1 监控指标

  • Kubernetes 层面：
    • Pod/Container CPU/Memory/GPU 利用率 (kubectl top pod, Prometheus container_cpu_usage_seconds, container_memory_working_set_bytes, DCGM_FI_DEV_GPU_UTIL)
    • Pod 状态（Running, Pending, CrashLoopBackOff, OOMKilled）
    • Node CPU/Memory/GPU 利用率、压力情况
    • PVC 存储使用量
  • DeepSeek 应用层面 (需暴露 metrics)：
    • 请求率 (QPS/RPS)
    • 请求延迟 (P50, P90, P99)
    • 请求队列长度
    • 批处理大小
    • GPU 利用率、显存使用量 (通过 NVIDIA DCGM 或 PyTorch/TensorFlow 内置监控)
    • 错误率
  • 网络层面： 服务网格 (Istio Linkerd) 提供的流量指标。

工具栈： Prometheus (收集), Grafana (展示), Alertmanager (告警)。使用 kube-state-metrics 和 node-exporter 收集 K8s 指标。使用 NVIDIA GPU Operator 或 DCGM Exporter 收集 GPU 指标。

6.2 日志收集

  • 配置 DeepSeek 容器将日志输出到标准输出 (stdout) 和标准错误 (stderr)。
  • 部署日志收集系统：
    • EFK Stack: Elasticsearch, Fluentd/Fluent Bit, Kibana。
    • Loki Stack: Loki (日志存储), Promtail (日志采集), Grafana (展示)。Loki 对 Kubernetes 日志支持较好。
    • 云服务: AWS CloudWatch Logs, GCP Cloud Logging, Azure Monitor Logs。

6.3 告警规则

基于监控指标设置关键告警：

  • 节点/Pod CPU/Memory/GPU 持续高利用率 (>90%)
  • 节点/Pod 内存不足 (OOM 风险)
  • Pod 重启次数过多 (CrashLoopBackOff)
  • 请求延迟超过 SLA 阈值 (P99 > 500ms)
  • 请求错误率过高 (>1%)
  • 副本数达到 HPA 最大值 (HPA MaxReplicas reached)
  • 存储空间不足

七、成本优化策略

GPU 资源成本是主要开销。优化策略包括：

  1. 精确资源请求 (requests): 通过 VPA 分析和监控，持续优化 CPU/Memory requests，避免过量预留。
  2. GPU 利用率最大化：
    • 批处理优化 (MAX_BATCH_SIZE): 在模型和框架支持的范围内，尽可能增大批处理大小，提高 GPU 计算单元利用率。需要平衡延迟。
    • 模型优化: 使用量化（INT8/FP16）、剪枝、蒸馏等技术减小模型尺寸和计算量，降低单次推理成本。
    • 使用 Spot 实例 / 抢占式 VM: 在云环境中，部署部分副本到价格低廉但可能被中断的 Spot 实例。必须配置 Pod 容忍中断 (tolerations) 和 PodDisruptionBudget (PDB)，并确保服务能容忍部分副本的短暂中断。
  3. 自动扩缩容: HPA 确保在低负载时减少副本数，节省资源。
  4. 集群自动扩缩容 (Cluster Autoscaler): 当集群资源不足时，自动添加节点；当节点利用率低时，自动移除节点。尤其适用于 Spot 实例池。
  5. 选择合适的 GPU 实例: 根据模型大小和吞吐/延迟要求，选择性价比最高的 GPU 型号（如 T4 vs A10 vs A100）。考虑显存、算力、互连带宽。
  6. 混合部署: 在非专用 GPU 节点上部署一些对 GPU 要求不高的辅助服务（如 API Gateway、日志收集器），提高整体集群利用率。

八、安全考虑

  1. 镜像安全: 使用可信的基础镜像，定期扫描镜像漏洞 (Trivy, Clair)。
  2. Pod 安全上下文 (securityContext): 设置非 root 用户运行容器，限制 Linux Capabilities。
  3. 网络策略 (NetworkPolicy): 控制 Pod 间的网络通信，遵循最小权限原则。
  4. API 访问控制: 对推理服务 API 实施认证 (API Key, JWT) 和授权。
  5. 密钥管理: 使用 Kubernetes Secrets 或外部密钥管理服务 (如 AWS Secrets Manager, HashiCorp Vault) 管理访问 Hugging Face Hub 或其他服务的令牌。
  6. 审计: 启用 Kubernetes API Server 审计日志。

九、总结与展望

将 DeepSeek 等大语言模型高效部署于 Kubernetes 是一个涉及多层面的系统工程。通过精心设计 Pod 资源请求、利用高级调度策略（拓扑感知、亲和/反亲和）、实施智能扩缩容（HPA/VPA）、配置高性能持久化存储、建立全面的监控告警体系，以及持续的成本优化，可以构建出高性能、高可用、高性价比的 AI 推理服务平台。

随着 Kubernetes 生态的不断发展（如 Kueue 作业队列管理、更精细的 GPU 调度支持）和 DeepSeek 模型的持续演进（更高效能的模型架构、推理引擎），未来的部署模式将更加灵活和高效。持续关注社区最佳实践，结合自身业务负载特点进行调优，是成功的关键。

相关推荐
NAGNIP6 小时前
一文搞懂深度学习中的通用逼近定理！
人工智能·算法·面试
冬奇Lab7 小时前
一天一个开源项目（第36篇）：EverMemOS - 跨 LLM 与平台的长时记忆 OS，让 Agent 会记忆更会推理
人工智能·开源·资讯
冬奇Lab7 小时前
OpenClaw 源码深度解析（一）：Gateway——为什么需要一个"中枢"
人工智能·开源·源码阅读
AngelPP11 小时前
OpenClaw 架构深度解析：如何把 AI 助手搬到你的个人设备上
人工智能
宅小年11 小时前
Claude Code 换成了Kimi K2.5后，我再也回不去了
人工智能·ai编程·claude
九狼11 小时前
Flutter URL Scheme 跨平台跳转
人工智能·flutter·github
ZFSS11 小时前
Kimi Chat Completion API 申请及使用
前端·人工智能
天翼云开发者社区13 小时前
春节复工福利就位！天翼云息壤2500万Tokens免费送，全品类大模型一键畅玩！
人工智能·算力服务·息壤
知识浅谈13 小时前
教你如何用 Gemini 将课本图片一键转为精美 PPT
人工智能
Ray Liang13 小时前
被低估的量化版模型，小身材也能干大事
人工智能·ai·ai助手·mindx
热门推荐
01GitHub 镜像站点02【OpenClaw 本地实战 Ep.3】突破瓶颈：强制修改 openclaw.json 解锁 32k 上下文记忆03OpenClaw 使用和管理 MCP 完全指南04Clawdbot部署教程：解决‘gateway token missing’授权问题的完整步骤05OpenClaw + 飞书（Feishu）环境搭建指南06Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services07Window 10部署openclaw报错node.exe : npm error code 12808AI 规范驱动开发“三剑客”深度对比：Spec-Kit、Kiro 与 OpenSpec 实战指南09AI Agent 平台横评：ZeroClaw vs OpenClaw vs Nanobot10OpenClaw优化飞书API 额度已耗尽问题