这是我的第一个版本的需求，你已经完成了大部分，请你结合代码现状进行检查：
  
  总体需求，是基于Tesla T4 GPU，用开源的基座大模型（3-6b级别），做query分类。prompt和分类词可配置。
  先专注于推理的优化，不用考虑服务化，先支持cli模式读取query即可，在程序启动之初，确保所有该加载的全部加载好，不要做任何懒加载，确保真实请求发生时得到极致的响应时间。cli每得到一个query输入，则进行推理输出各个label的打分，以及预测的总耗时（如果能输出各个阶段的耗时更好，如果好做就支持一下）。
  
  示例prompt和对应的9个分类词：
  Analyze the category intent of the given query. Output exactly one label from: dress, jeans, shirt, trench, skirt, tee, hoodie, knit, other. Output nothing else query:{query}
  
  做专用执行路径，不是在通用生成引擎上做配置优化，追求绝对最低的分类延迟以及每个标签的精确得分。
  
  使用Tesla T4，因此：
  1. 使用FP16。不用 BF16 作为主路径
  2. 不用 FlashAttention-3 作为主路径。选用testla T4上最佳的attention
  3. 多搜集资料，参考开源的适合于tesla T4的推理优化项目和能用于T4的推理优化实践。包括但不限于Python/C++ runtime 与 TensorRT engine 的工具包；注意硬件支持矩阵覆盖 Turing/T4。
  
  
  主要考虑优化方向为：
  hidden_last -> N-class scorer -> argmax
  参考vLLM 的自动 prefix caching 复用相同前缀，并基于 block hash 管理 KV
  去 full vocab logits
  去 decode / constrained decode
  query长度分桶 + 小微批，只为少数 batch 模式 capture（batch= 1 2 4 8）
  专用 tail kernel（输出 N 类原始分数）
  
  以下仅供参考，具体怎么做还请你自己基于搜索的开源项目作为baseline进行优化：
  15.1 预分配
  对每个 bucket 预分配：
  input ids buffer
  attention scratch buffer
  output hidden buffer
  class id buffer
  15.2 Graph capture
  
  每个 bucket 预先 capture 一张图：
  embedding
  transformer 主干
  compact last-state
  9-way tail kernel
  
  注意多参考Triton / CUDA C++针对这类单步decode且固定词表打分获取的极致优化方法及其开源项目，找到合适的baseline并进行针对性的开发。
  
  你有sudo权限，你可以执行为本项目安装自己的环境
  
  使用qwen3:4b-instruct-2507-q4_K_M模型。（因为qwen3:4b不能关闭思考模式，所以使用qwen3:4b-instruct-2507-q4_K_M模型）
  或者，请你在huggingface上面查找其他模型，完成部署，并进行推理耗时的测试。
  
  
  请深度分析各阶段耗时，继续查找相关资料，看是否在性能上面做到极致。
  使用qwen3:4b-instruct-2507-q4_K_M模型。（因为qwen3:4b不能关闭思考模式，所以使用qwen3:4b-instruct-2507-q4_K_M模型），完成部署，并进行推理耗时的测试。
  注意使用fp16版本，不要使用量化版本。
  
  上面的需求你已经满足了大部分，
  但是一个重要的、还未处理好的问题：目前的版本应该是针对decode 单token来做的，但是，一些分类词并不是单token（虽然看起来是一个单词），所以，要考虑一些分类词并不是单token的情况，不需要为单 token 设计，但是每个分类词仍然是少数token。
  需要通过多 token 标签做极致的性能优化，避免串行decode。
  一个考虑的方向是：
  将 HF 的多 token candidate_reduce 路径，改为 融合/向量化实现、向量化方案（batch padding，一次模型 forward，处理整个 batch）
  
  只做一次模型 forward，输入长度为 total_tokens（通常远小于 batch_size * max_label_len 的循环总和）。
  
  所有后续聚合均为向量化操作（GPU 上几乎不花时间）。
  
  也请你仔细搜寻相关资料，特别是技术框架所用到的Triton / Ollama / CUDA C++ 在该场景上的最佳实践，进行实践，找到在T4上面query分类需求的sota、做到极致的性能优化。
  
  参考文档：
  
  vLLM Automatic Prefix Caching: https://docs.vllm.ai/en/stable/design/prefix_caching/
  PyTorch SDPA / memory-efficient attention: https://pytorch.org/blog/out-of-the-box-acceleration/
  TensorRT-LLM Support Matrix: https://nvidia.github.io/TensorRT-LLM/reference/support-matrix.html
  Ollama Modelfile / Generate / FAQ: https://docs.ollama.com/modelfile , https://docs.ollama.com/api/generate , https://docs.ollama.com/faq