Ray Serve LLM 性能大幅提升，推理吞吐量最高提升24倍
Ray团队与Google Kubernetes Engine合作，宣布Ray Serve LLM在吞吐量和延迟方面取得重大突破。通过架构层面的三大优化——直接流传输、新的vLLM Ray执行器后端和HAProxy集成，Ray Serve LLM在预填充密集型工作负载上实现了高达4.4倍的请求吞吐量提升，在解码密集型工作负载上实现了24倍的提升。优化后的系统在性能上已与基于Rust的高性能路由框架vllm-router持平。其中，Ray 2.56引入的直接流传输模式将请求路由控制平面与数据平面解耦，消除了传统架构中的中间路由瓶颈。此外，Ray 2.55还发布了基于C语言的HAProxy入口负载均衡器和高吞吐模式优化，并默认禁用Nagle算法以改善流式传输性能。这些改进使Ray Serve LLM能够更好地应对日益复杂的LLM推理部署需求。 #Ray #LLM #分布式推理 #性能优化 #AI基础设施 #vLLM #HAProxy
Ray团队与Google Kubernetes Engine合作，宣布Ray Serve LLM在吞吐量和延迟方面取得重大突破。通过架构层面的三大优化——直接流传输、新的vLLM Ray执行器后端和HAProxy集成，Ray Serve LLM在预填充密集型工作负载上实现了高达4.4倍的请求吞吐量提升，在解码密集型工作负载上实现了24倍的提升。优化后的系统在性能上已与基于Rust的高性能路由框架vllm-router持平。其中，Ray 2.56引入的直接流传输模式将请求路由控制平面与数据平面解耦，消除了传统架构中的中间路由瓶颈。此外，Ray 2.55还发布了基于C语言的HAProxy入口负载均衡器和高吞吐模式优化，并默认禁用Nagle算法以改善流式传输性能。这些改进使Ray Serve LLM能够更好地应对日益复杂的LLM推理部署需求。 #Ray #LLM #分布式推理 #性能优化 #AI基础设施 #vLLM #HAProxy
SFC 发布 FOSS 领域 LLM 生成式 AI 使用建议
软件自由保护组织（SFC）于2026年6月正式发布《FOSS贡献中使用LLM生成式AI系统的建议》。该建议历经四年政策研究，始于2022年政策研究员Bradley M. Kühn发表的相关论文。SFC随后组建专家委员会，并通过多次与成员项目贡献者的倾听会议，了解其需求与关切。2025年11月，SFC召集半数员工及FOSS政策专家组成“FOSS房间中的LLM大象”委员会，意识到完全禁止LLM生成式AI已非最佳策略，需采取多管齐下的方法。2026年初，合规总监Denver Gingerich发表相关观点与经验，SFC随后通过公开视频聊天和Fediverse平台进行更多倾听会议。该建议现已成为SFC重大倡议，未来两年内将发布大量材料，帮助FOSS贡献者谨慎且战略性地利用LLM生成式AI，以增强用户软件自由及设备维修权。 #SFC #FOSS #LLM #生成式AI #软件自由 #开源 #政策建议
软件自由保护组织（SFC）于2026年6月正式发布《FOSS贡献中使用LLM生成式AI系统的建议》。该建议历经四年政策研究，始于2022年政策研究员Bradley M. Kühn发表的相关论文。SFC随后组建专家委员会，并通过多次与成员项目贡献者的倾听会议，了解其需求与关切。2025年11月，SFC召集半数员工及FOSS政策专家组成“FOSS房间中的LLM大象”委员会，意识到完全禁止LLM生成式AI已非最佳策略，需采取多管齐下的方法。2026年初，合规总监Denver Gingerich发表相关观点与经验，SFC随后通过公开视频聊天和Fediverse平台进行更多倾听会议。该建议现已成为SFC重大倡议，未来两年内将发布大量材料，帮助FOSS贡献者谨慎且战略性地利用LLM生成式AI，以增强用户软件自由及设备维修权。 #SFC #FOSS #LLM #生成式AI #软件自由 #开源 #政策建议
AI队友Avery
BuildForever团队开发了一款名为Avery的AI工程队友，它已深度集成到公司日常使用的系统和工具中。上周，Avery独自编写了团队五名工程师交付到生产环境的31%代码——它不仅能识别问题、诊断根本原因、生成修复方案，还能自主完成代码合并。Avery运行在Slack中，使用自己的Mac mini，可访问GitHub、Linear、邮件、WhatsApp、TestFlight、App Store Connect、Mixpanel和Cloud Logging等系统。它具备持久记忆和主动调度能力，能自动处理iOS崩溃报告、监控后端API错误趋势，甚至在工程师离线时通过移动端修复bug。Avery还能实现新功能并实时验证，让整个团队通过Slack频道学习使用技巧，将每个请求转化为学习机会。 #AI #工程工具 #自动化 #代码生成 #Slack #DevOps #技术新闻
BuildForever团队开发了一款名为Avery的AI工程队友，它已深度集成到公司日常使用的系统和工具中。上周，Avery独自编写了团队五名工程师交付到生产环境的31%代码——它不仅能识别问题、诊断根本原因、生成修复方案，还能自主完成代码合并。Avery运行在Slack中，使用自己的Mac mini，可访问GitHub、Linear、邮件、WhatsApp、TestFlight、App Store Connect、Mixpanel和Cloud Logging等系统。它具备持久记忆和主动调度能力，能自动处理iOS崩溃报告、监控后端API错误趋势，甚至在工程师离线时通过移动端修复bug。Avery还能实现新功能并实时验证，让整个团队通过Slack频道学习使用技巧，将每个请求转化为学习机会。 #AI #工程工具 #自动化 #代码生成 #Slack #DevOps #技术新闻
缓存感知推理路由可大幅降低大模型调用成本
一项针对大模型推理成本的基准测试显示，即使使用相同的模型、参数、提示词和响应，不同推理服务商之间的成本差异可能高达4倍。研究团队对Auriko的缓存感知成本套利引擎进行了测试，向5家推理服务商和1家路由服务商发送了超过8万次API请求，涉及37个模型和3种工作负载类型。结果显示，Auriko相比路由服务商降低了32.8%的加权成本，相比单一服务商降低了7.7%至38.3%。成本差异主要源于令牌定价、服务商提示缓存策略和用户请求模式的不同。研究采用配对实验设计，确保所有调用使用相同提示词和参数，并同时发送以控制时间影响。编码代理工作负载的成本差异最大，单轮对话和多轮对话工作负载的差异相对接近。 #大模型 #推理成本 #缓存感知 #成本优化 #AI基础设施 #API调用 #机器学习
一项针对大模型推理成本的基准测试显示，即使使用相同的模型、参数、提示词和响应，不同推理服务商之间的成本差异可能高达4倍。研究团队对Auriko的缓存感知成本套利引擎进行了测试，向5家推理服务商和1家路由服务商发送了超过8万次API请求，涉及37个模型和3种工作负载类型。结果显示，Auriko相比路由服务商降低了32.8%的加权成本，相比单一服务商降低了7.7%至38.3%。成本差异主要源于令牌定价、服务商提示缓存策略和用户请求模式的不同。研究采用配对实验设计，确保所有调用使用相同提示词和参数，并同时发送以控制时间影响。编码代理工作负载的成本差异最大，单轮对话和多轮对话工作负载的差异相对接近。 #大模型 #推理成本 #缓存感知 #成本优化 #AI基础设施 #API调用 #机器学习