计划执行与检查节点
executing-plans
按既定实施计划完成工作,保持过程检查和反馈。
coreweave-performance-tuning【效率与协作】Optimize CoreWeave GPU inference latency and throughput. Use when reducing inference latency, maximizing GPU utilization, or tuning batch sizes and concurrency. Trigger with phrases like "coreweave performance", "coreweave latency", "coreweave throughput", "optimize coreweave inference".
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
name: coreweave-performance-tuning description: 'Optimize CoreWeave GPU inference latency and throughput.
Use when reducing inference latency, maximizing GPU utilization,
or tuning batch sizes and concurrency.
Trigger with phrases like "coreweave performance", "coreweave latency",
"coreweave throughput", "optimize coreweave inference".
' allowed-tools: Read, Write, Edit, Bash(kubectl:*) version: 1.11.0 license: MIT author: Jeremy Longshore jeremy@intentsolutions.io tags:
Community-contributed. Not affiliated with, endorsed by, or sponsored by CoreWeave, Inc. CoreWeave is a registered trademark of CoreWeave, Inc.
Tune GPU inference or training only against measured throughput, latency, quality, availability, and cost targets. A higher utilization figure is not a success if it causes queueing, memory pressure, or a customer-facing SLO regression.
| Workload | Recommended GPU | Why |
|---|---|---|
| LLM inference (7-13B) | A100 80GB | Good balance of memory and cost |
| LLM inference (70B+) | 8xH100 | NVLink for tensor parallelism |
| Image generation | L40 | Good for diffusion models |
| Training (large models) | 8xH100 SXM5 | Fastest interconnect |
| Batch processing | A100 40GB | Cost-effective |
# Continuous batching with vLLM
containers:
- name: vllm
args:
- "--model=meta-llama/Llama-3.1-8B-Instruct"
- "--max-num-batched-tokens=8192"
- "--max-num-seqs=256"
- "--gpu-memory-utilization=0.90"
- "--enable-prefix-caching"
- "--dtype=float16"
# HPA based on GPU utilization
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: inference-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: inference-server
minReplicas: 2
maxReplicas: 10
metrics:
- type: Pods
pods:
metric:
name: DCGM_FI_DEV_GPU_UTIL
target:
type: AverageValue
averageValue: "70"
| Metric | A100-80GB | H100-80GB |
|---|---|---|
| Llama-8B tokens/sec | ~2,000 | ~4,500 |
| Llama-70B tokens/sec | ~200 (4x) | ~500 (4x) |
| Cold start (vLLM) | 30-60s | 20-40s |
| Condition | Safe response |
|---|---|
| GPU memory exceeds the guardrail | Restore the previous batch or memory setting and investigate the request distribution. |
| Latency rises after batching | Reduce concurrency or restore replica count; do not raise timeouts to hide the regression. |
| Evaluation quality drops | Route the canary back to the baseline configuration and preserve aggregate results. |
| Autoscaler oscillates | Restore stable bounds and tune from a longer measured window. |
Run a staging canary and save only aggregate measurements for review:
kubectl -n inference-staging apply -f inference-tuned.yaml
kubectl -n inference-staging rollout status deployment/inference-server --timeout=10m
./scripts/load-test --target staging --duration 15m --report aggregate.json
If the report breaches the signed SLO or quality threshold, apply the previous
manifest immediately and attach aggregate.json to the change record.
For cost optimization, see coreweave-cost-tuning.