最近大家都在聊 MCP，发现有个最重要的点被忽略了： 通过标准化协议，将工具提供方与应用研发者解耦，这一点带来的将是 AI Agent 应用研发范式的转移（类似 Web 应用研发的前后端分离）。本文以开发 Agent TARS 应用为例，尽可能详细地介绍 MCP 在开发范式、工具生态扩展上起到的作用。
抖音长期存在renderD128内存占用过多导致的虚拟内存OOM，且多次出现renderD128内存激增导致OOM指标严重劣化甚至发版熔断。因受限于闭源的GPU驱动以及现场有效信息极少，多个团队都进行过分析，但一直未能定位到问题根因，问题反馈到厂商也一直没有结论。以往发生renderD128内存激增时，解决办法往往都是通过二分法去定位导致问题的MR进行回滚(MR代码写法并无问题，仅仅是正常调用系统API)，但是回滚业务代码会影响业务正常需求的合入，也无法从根本上解决该问题，每次也会消耗我们大量人力去分析排查，因此我们有必要投入更多时间和精力定位根因并彻底解决该问题。在历经数月的深入分析和排查后，我们最终定位了问题根因并彻底解决了该问题，取得了显著的OOM收益，renderD128内存问题导致的发版熔断也未再发生。接下来，将详细介绍下我们是如何一步步分析定位到问题根因，以及最终如何将这个问题给彻底解决的。
虚拟索引技术（virtual index，也称为 hypothetical index）在数据库系统的查询优化、索引推荐等场景中扮演着关键角色。简单来说，虚拟索引可以理解为数据库的'沙盘推演'系统——无需真实构建索引，仅基于统计信息即可精准模拟不同索引方案对查询计划的优化效果。由于虚拟索引的创建/删除代价极低，使用者可以大量创建和删除索引、反复推演，确定最有效的索引方案。在AI时代，基于机器学习模型的NDV、Cardinality估计算法层出不穷，但是在MySQL落地往往遇到很大挑战：无法注入机器学习模型的预测值，变无法得到MySQL索引推荐结果。
本文详细介绍了如何通过 AIBrix 分布式推理平台实现 DeepSeek-R1 671B 的多节点部署。DeepSeek-R1 通过渐进式训练框架展现出优秀的逻辑推理能力 —— 在 6710 亿总参数量中，其动态激活的 370 亿参数与 128k 上下文窗口，使其在复杂任务处理中表现卓越。然而，如此庞大的模型规模对部署环境提出了严苛挑战，尤其是分布式推理的资源调度与性能优化。
本文将基于火山引擎托管 Prometheus 服务 VMP 与火山方舟、火山引擎智能驾驶数据服务深度合作所积累的丰富可观测经验，分享在解决 AI 大模型和智能驾驶领域高基数问题上的实践经验。
随着 LLaMA、DeepSeek、Qwen 等开源大模型的快速崛起，企业在模型部署的灵活性、成本与自主可控性方面迎来了新的机遇。然而，仅靠对模型本身的优化尚不足以将这些模型部署成高效且可扩展的生产级 API。大模型推理往往引入诸多独特的系统挑战，如GPU 弹性伸缩指标的非线性问题，长尾模型和精调模型流量过低的问题，多机推理时的角色编排以及 GPU 卡型的异构管理等，都对易用性和成本控制提出了更高要求。因此，我们需要从推理引擎到底层基础设施进行全栈系统设计，才能真正让大模型在生产环境中长期稳定且高效地运行。 AIBrix 作为首个基于 Kubernetes 的企业级推理系统项目，正好填补了业界在“系统层”上的空白。它通过优化资源调度、自适应扩缩容、缓存感知路由以及异构计算管理等多项能力，为企业级大模型的大规模部署提供高效、低成本、可扩展的解决方案。AIBrix 与 vLLM 等推理引擎深度协同，持续优化推理效率，并融合多项前沿研究成果，推动大模型推理走向更加高效、可落地的生产化阶段。
DeepSeek-R1（以下简称 DeepSeek）以其优秀的复杂问题推理能力和规划能力脱颖而出，然而其原生函数调用（Function Call）功能的缺失，无法让大模型去选择不同的工具和程序，以获取对应的信息
