MemPool

这个算是一个huawei的横向。但是也有颇多值得研究的地方。最后可以产出个文章试试。

背景

简单来说，是TP场景下的内存池动态调度问题。
大体上是一个一个预测任务，预测内存池分配的策略。
目前希望用LLM的方法做。
使用gaussdb。

目标和指标

  • 目标：
    落盘降低90%，性能提高x10.
    低规格内存，瞬间注入大量慢SQL，TPS抖动控制到10%。

  • 指标
    预测准确率：预测与真实workload的内存开销。
    推理速度：低延迟。
    TPS抖动：每秒钟事务数，这个要保持在一个相对稳定范围。
    内存总开销：这里是泛化考量，要不要像索引一样处理不同内存池大小？

随笔

  1. Bert vs LLM？
    对于TP动态场景，要求很 低的响应延迟。所以要对比bert或者llm的表现。llm选qwen2.5 0.5b或者qwen3 0.6b.

  2. 架构？
    直接微调一个裸llm,可能不会好用。
    现在有几个考量：首先，考虑能不能做召回，有点像LLMidx,做一个workload池，一个模型来路由，直接模糊召回一个workload模板与它对应的参数。其次，考虑要不要做RL，RL怎么做？泛化呢？或者直接就直接微调一个llm做预测，这个很轻量，可以先试试。

  3. 有一些工作提到了AP和TP分离，这里也提到了会瞬间注入大量慢SQL,可以考虑一下这个思路。

  4. 怎么划分workload？
    workload的组的大小怎么找？这个重要，必须先想清楚，或者在小模型先试试。如果用0.5以下的小模型，这里一个workload就不能大。

  5. 测试构建。tpcc/tpch/tpcds。
    想办法监测TPS，推理延迟。预测的性能可以在训练时解决。

  6. 已知的未知：
    内存池的调度也是分层的。在gaussdb而言，有ResourcePool级别，有seesion/SQL级别。以及与内存池紧耦合的shared-buffer/workmem/max_connections。这些可能要考虑一下怎么处理。
    算子级别的优化要不要实现？