3 months ago
- 从使用前沿模型API转向构建自己的开源大语言模型推理堆栈，通常始于财务、法律或工程方面的考量。
- 初始决策点在于选择从托管推理提供商处购买服务，还是利用开源权重和自有硬件构建解决方案。本文主要聚焦于构建路径。
- 从一个使用vLLM、SGLang或TensorRT-LLM等推理引擎的单一副本开始，通常效果不错，可以有效处理批处理和KV缓存管理。
- 副本内部的优化包括量化（例如采用FP8可提升14%的吞吐量）和推测解码（如EAGLE），但理想的默认设置仍在发展演进中。
- 随着并发量增加，延迟可能在‘拐点’处急剧恶化，需要多个副本以及考虑KV缓存的智能路由来维持性能。
- Prefill/解码解耦（如Mooncake中的设计）将计算密集型阶段与内存带宽密集型阶段分离，允许使用异构硬件以提高成本效益。
- 大小模型混合使用时，需要借助网关（如LiteLLM、RouteLLM）进行智能路由，以便在保持不同请求质量的同时管理成本。
- 跨存储层级（从HBM到NVMe）的前缀缓存和响应缓存等策略有助于减少重复计算，并在流量增长时降低成本。
- 全栈可观测性仍具挑战，指标分散在各组件中；像OpenTelemetry和Langfuse这样的工具提供了部分解决方案，但缺乏端到端的可见性。
- 关键差距包括集成的集群管理、面向工作负载的工具以及能替代经验法则的更好默认配置，同时多模态推理服务也带来了额外挑战。