[Qwen3-0.6B](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=Qwen3-0.6B&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJRd2VuMy0wLjZCIiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6MjgyMTE1NzM0LCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.YA80z8IyfofnmyevrFb2KKis7D2Vo_425ev_Q7HArCk&zhida_source=entity) 在大模型家族里属于垫底的量级，通常被认为只能跑跑 demo——能力天花板摆在那里，[复杂推理](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E5%A4%8D%E6%9D%82%E6%8E%A8%E7%90%86&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLlpI3mnYLmjqjnkIYiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.p6-kl9dxRRJTtgMBla7_SeUOwIE12NbUCb1llW4Wc4k&zhida_source=entity)、长文写作都别指望它。但在这台[海光 K100\_AI](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E6%B5%B7%E5%85%89+K100_AI&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLmtbflhYkgSzEwMF9BSSIsInpoaWRhX3NvdXJjZSI6ImVudGl0eSIsImNvbnRlbnRfaWQiOjI4MjExNTczNCwiY29udGVudF90eXBlIjoiQXJ0aWNsZSIsIm1hdGNoX29yZGVyIjoxLCJ6ZF90b2tlbiI6bnVsbH0.AWjL-3Yzsrz6b90Y9EOtW40q2UUz4j8pif48plgBcmE&zhida_source=entity)（DCU）服务器上，它恰恰是生产线上最忙的模型。这篇就讲它是怎么「上岗」的： 打开方式就是：不做生成，做分类。给 0.6B 的基座加一个分类头，微调后用 [FastAPI](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=FastAPI&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJGYXN0QVBJIiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6MjgyMTE1NzM0LCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.GVos2ERc_8RIGJSCTNFL0zAGkzhvUQ0fNk8GG2WmmpQ&zhida_source=entity) 包成服务，部署在 DCU 的 5 号卡上、8107 端口，处理内容风控的文本二分类——单条文本 \*\*46 毫秒\*\*返回。这个延迟，32B 模型连第一个 token 都还没吐出来。 ## 为什么[生成式大模型](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E7%94%9F%E6%88%90%E5%BC%8F%E5%A4%A7%E6%A8%A1%E5%9E%8B&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLnlJ_miJDlvI_lpKfmqKHlnosiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.S7b3fJ2ZQpLVETVaJ-Vag3qnsWp4YPeFgNGxQYGvl9U&zhida_source=entity)不适合这个任务 业务需求很朴素：一段文本进来，判断「是否命中风险」，命中再细分原因。用生成式 LLM 做（无论是 32B 还是 API），要面对三件事：延迟以秒计、输出需要解析（模型可能说「我认为这段文字有一定风险」这种无法直接用的答案）、以及同样输入不保证同样输出。而风控类业务恰恰要的是\*\*快、确定、可审计\*\*。 经典解法也一直存在：[BERT](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=BERT&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJCRVJUIiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6MjgyMTE1NzM0LCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.2InMp9L9kdY3gKd7gBGYMh5eoUmgbWlh7lNGjLnLGkc&zhida_source=entity) 时代就是这么干的——基座出[向量](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E5%90%91%E9%87%8F&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLlkJHph48iLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.5dsXRYNrS-HY7EEDDnxnx6Ix1tAQHKa3hBWNIcpAX8w&zhida_source=entity)，接分类头，[sigmoid](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=sigmoid&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJzaWdtb2lkIiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6MjgyMTE1NzM0LCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.ZGaiAa-CEpZrJqsbklv84qmdUBVH3dwCeYQaHnEKMTw&zhida_source=entity) 出概率。我们要做的，就是把这套范式平移到 Qwen3-0.6B 和 DCU 上。 ## 模型改造：给基座加一个分类头 模型结构是这个方案的核心，值得展开： \`\`\` 输入文本 → tokenizer → [Qwen3Model](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=Qwen3Model&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJRd2VuM01vZGVsIiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6MjgyMTE1NzM0LCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.mTM4F0NiSrr67NItXXNWJaqB_A2FGQNH76qHHuxWmK0&zhida_source=entity) 基座前向（注意：是 Qwen3Model，不带 LM head） → last\_hidden\_state → mean pooling（按 attention mask 加权平均） → [classifier\_heads.pt](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=classifier_heads.pt&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJjbGFzc2lmaWVyX2hlYWRzLnB0IiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6MjgyMTE1NzM0LCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.sECLzJ_HkDDhEpOE-F_1D2ah5wjLBdM_HgNIJwvHBs8&zhida_source=entity) 里的 bin\_head: [Linear](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=Linear&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJMaW5lYXIiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.2ZmMvOpLY4_SMJ6IK51r_3WjuoevkLfsG_-dePS1OOQ&zhida_source=entity)(1024 → 1) → sigmoid → bin\_prob ∈ (0,1) \`\`\` 三个设计决策： \*\*① 用[基座](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=5&q=%E5%9F%BA%E5%BA%A7&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLln7rluqciLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6NSwiemRfdG9rZW4iOm51bGx9.O05NUfaBKqkOPXFx_-rMba_aESAb9KkP6_-K2u-11Gk&zhida_source=entity) \`Qwen3Model\` 而不是 \`Qwen3ForCausalLM\`。\*\* 分类任务不需要语言建模头（LM head 是 hidden\_size × vocab 的[大矩阵](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E5%A4%A7%E7%9F%A9%E9%98%B5&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLlpKfnn6npmLUiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.wTrX5HaBO-yNNsCohD9416YRTcBnvrIDvmvPyKJfXgQ&zhida_source=entity)，0.6B 里它占了不小比例的参数），砍掉它既省显存又省计算——反正 next token 预测能力对分类毫无用处。 \*\*② 分类头单独存成 \`classifier\_heads.pt\`。\*\* 基座权重和任务头解耦，换任务换头，基座复用。[头文件](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E5%A4%B4%E6%96%87%E4%BB%B6&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLlpLTmlofku7YiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.z9s4USEZc4TN8sigNQwj1pZ9N9zOAzlQLdbEBapttA4&zhida_source=entity)里同时存了一份小 config（pooling 方式、标签表），加载时自描述。 \*\*③ mean pooling 而不是取 \`[CLS]\`。\*\* Qwen3 是Decoder-only架构，没有天生的句首摘要 token，对全部有效 token 做加权平均是最稳的选择。 精度上选择了 \*\*float32 推理\*\*——模型小，fp32 显存占用也才 3.2GB，换来的是推理结果和训练时数值完全一致，不用操心 bf16 的舍入漂移对阈值边缘样本的影响。 ## 服务化：FastAPI，而不是 [vLLM](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=vLLM&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJ2TExNIiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6MjgyMTE1NzM0LCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.juqYas74OXvg3GZmmQgO2CPyX7COf_ziDZh41EC-SGo&zhida_source=entity) 按惯常思路，[模型服务化](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E6%A8%A1%E5%9E%8B%E6%9C%8D%E5%8A%A1%E5%8C%96&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLmqKHlnovmnI3liqHljJYiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.ofneoKy9kQUeK3G5sGKnmGu7JMwYZjSm7Oa8hCuytGg&zhida_source=entity)就该上 vLLM，但这里 deliberately 不用。原因很直接：\*\*vLLM 是生成引擎，它的全部优化（PagedAttention、continuous batching、[prefix cache](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=prefix+cache&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJwcmVmaXggY2FjaGUiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.5zQZIdXXtorrTLcYCmmw31EyK_0nOWP16uaJn_JilZ0&zhida_source=entity)）都服务于「自回归吐 token」\*\*。而分类任务只要一次前向拿 [hidden state](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=hidden+state&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJoaWRkZW4gc3RhdGUiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.mYnNh--aq1sB1n4bgA5qN40FH1qj_Iv59J_3yyFJjJ4&zhida_source=entity)，连 [KV cache](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=KV+cache&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJLViBjYWNoZSIsInpoaWRhX3NvdXJjZSI6ImVudGl0eSIsImNvbnRlbnRfaWQiOjI4MjExNTczNCwiY29udGVudF90eXBlIjoiQXJ0aWNsZSIsIm1hdGNoX29yZGVyIjoxLCJ6ZF90b2tlbiI6bnVsbH0.VMsqECbMhkVhvo8hAs8HZcWgZ8RNAh0cRk60W2vdFgY&zhida_source=entity) 都不需要。此时 vLLM 的引擎是纯粹的累赘，反而一个朴素的 FastAPI + torch 进程最合适： - 单进程加载模型，\`/predict\` 收批量文本，for 循环过 tokenizer + 前向，返回概率； - 没有引擎子进程、没有显存池预分配、没有[多进程通信](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E5%A4%9A%E8%BF%9B%E7%A8%8B%E9%80%9A%E4%BF%A1&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLlpJrov5vnqIvpgJrkv6EiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.0EYy4mdcZWUK929oTXJBZafA-fQyQ76XHbsypbH6IbY&zhida_source=entity)——vLLM [多进程架构](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E5%A4%9A%E8%BF%9B%E7%A8%8B%E6%9E%B6%E6%9E%84&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLlpJrov5vnqIvmnrbmnoQiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.XCs38TiRZO-ggXSiDjgVONmKzdb663BuayCyPF3LBm4&zhida_source=entity)下常见的 stop 泄漏、显存回收问题，在这个形态下天然不存在； - 显存占用恒定 3.2GB，和同卡的其它服务和平共处。 接口设计贴合业务方的习惯： \`\`\`json // POST /predict { "items": [ {"id": "doc\_001", "text": "待检测文本"}, {"id": "doc\_002", "text": "另一条文本"} ], "bin\_threshold": 0.5, "reason\_threshold": 0.5 } // 响应（节选） { "code": 0, "data": [{"id": "doc\_001", "bin\_prob": 0.91, ...}], "failed\_ids": [], "elapsed\_ms": 46.2 } \`\`\` 两个细节：\*\*阈值做成了请求参数\*\*而不是写死——风控的松紧是运营决策，不该动代码；\*\*\`elapsed\_ms\` 直接返回\*\*——线上排查「为什么这批慢」时不用去猜。 ## 部署：细节都在启动脚本里 启动命令一行（\`bash api/start\_all.sh --gpu 5 --port 8107\`），但脚本里固化了三条 DCU 经验： \`\`\`bash source /opt/dtk-26.04/[env](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=env&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJlbnYiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.QXtrI9OhUx19Qe5oY9mmnt5HMUT-ijPWbA5rqpsOoTg&zhida_source=entity).sh # ① DTK 环境，不 source 连卡都看不见 export CKPT\_DIR=output/qwen3-0.6b\_binary\_v2\_retrain-xxx # ② 不设会用默认旧目录，报 OSError export CUDA\_VISIBLE\_DEVICES=5 # ③ 固定 5 号卡（0 号常驻别的服务） conda run -n dcu-train python -m uvicorn api.server\_direct:app --host 0.0.0.0 --port 8107 \`\`\` 实测表现：\`/health\` 就绪后，\*\*第一批请求 \~3.9s\*\*（HIP 算子 JIT 预热，只见一次），\*\*预热后单批 46ms\*\*。对批处理任务，预热可以忽略；对低延迟在线服务，可以在启动后主动打一批空请求把 JIT 做完。 ## 踩过的两个坑 \*\*坑一：numpy 2.x 的隐性 [ABI](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=ABI&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJBQkkiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.j2foYslVRV4E39RJmTlkHmDlukb9P5BR4syAGOq9BWw&zhida_source=entity) 冲突。\*\* 某天环境里的 numpy 被连带升级到了 2.2.6，服务代码里一处 \`.[cpu](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=cpu&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJjcHUiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.OtUhNDg8V2_uMR-b0GLhUQnlcbwKjufVj2E7X7B62Wc&zhida_source=entity)().numpy()\` 开始抛 \`RuntimeError: [Numpy](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=Numpy&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJOdW1weSIsInpoaWRhX3NvdXJjZSI6ImVudGl0eSIsImNvbnRlbnRfaWQiOjI4MjExNTczNCwiY29udGVudF90eXBlIjoiQXJ0aWNsZSIsIm1hdGNoX29yZGVyIjoxLCJ6ZF90b2tlbiI6bnVsbH0.zWCIompww5Kq3w3MJ87_IRnkKmeffk2PTFkEFmmPOzY&zhida_source=entity) is not available\`。根因是 torch 2.5.1（DCU 版）按 numpy 1.x 的 ABI 编译，numpy 2.x 卸掉了旧 \`\_ARRAY\_API\` 符号。阴就阴在：\*\*tokenizer、模型前向全都不走 numpy 互操作，服务看起来一切正常，只有显式调 \`.numpy()\` 的那一行代码炸\*\*，而且 import torch 时只给了一条容易忽略的 warning。当下修复是把那两行 numpy 互操作改成纯 list 操作（\`.tolist()\`、\`isinstance(x, list)\`），数值完全一致；根治方案是锁死 \`numpy<2\`。这也是 DCU [环境管理](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E7%8E%AF%E5%A2%83%E7%AE%A1%E7%90%86&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLnjq_looPnrqHnkIYiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.6R-gTzcz-pUzhqiqQkHNMmZer8_-sfoxM2ya48-spBY&zhida_source=entity)的通病：\*\*定制[二进制](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E4%BA%8C%E8%BF%9B%E5%88%B6&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLkuozov5vliLYiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.DZAvKdEGgC3olSJZnVBchfPR-BCkeQGu2EO-9MChPdE&zhida_source=entity)对周边库版本的绑定是隐式的，一次不经意的 [pip install](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=pip+install&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJwaXAgaW5zdGFsbCIsInpoaWRhX3NvdXJjZSI6ImVudGl0eSIsImNvbnRlbnRfaWQiOjI4MjExNTczNCwiY29udGVudF90eXBlIjoiQXJ0aWNsZSIsIm1hdGNoX29yZGVyIjoxLCJ6ZF90b2tlbiI6bnVsbH0.g_KpXSQ8kZOIYgL_fo-s7wCKHNrYsBw7DF6ZVWRtHYs&zhida_source=entity) 就能弄坏一个「跟 numpy 毫无关系」的服务\*\*。 \*\*坑二：README 和现实不符。\*\* 交付包自带的 README 写着用 \`sxmodel\` 环境，实际那个环境里没有 torch；默认 checkpoint 路径指向一个已过时的旧迭代。接手部署的人按文档走必然失败。修复之外更重要的是习惯：\*\*部署脚本里显式写出全部环境假设（source 什么、脚本里固化了三条 DCU 经验： \`\`\`bash source /opt/dtk-26.04/env.sh # ① DTK 环境，不 source 连卡都看不见 export CKPT\_DIR=output/qwen3-0.6b\_binary\_v2\_retrain-xxx # ② 不设会用默认旧目录，报 OSError export CUDA\_VISIBLE\_DEVICES=5 # ③ 固定 5 号卡（0 号常驻别的服务） conda run -n dcu-train python -m uvicorn api.server\_direct:app --host 0.0.0.0 --port 8107 \`\`\` 实测表现：\`/health\` 就绪后，\*\*第一批请求 \~3.9s\*\*（HIP 算子 JIT 预热，只见一次），\*\*预热后单批 46ms\*\*。对批处理任务，预热可以忽略；对低延迟在线服务，可以在启动后主动打一批空请求把 JIT 做完。 ## 踩过的两个坑 \*\*坑一：numpy 2.x 的隐性 ABI 冲突。\*\* 某天环境里的 numpy 被连带升级到了 2.2.6，服务代码里一处 \`.cpu().numpy()\` 开始抛 \`RuntimeError: Numpy is not available\`。根因是 torch 2.5.1（DCU 版）按 numpy 1.x 的 ABI 编译，numpy 2.x 卸掉了旧 \`\_ARRAY\_API\` 符号。阴就阴在：\*\*tokenizer、模型前向全都不走 numpy 互操作，服务看起来一切正常，只有显式调 \`.numpy()\` 的那一行代码炸\*\*，而且 import torch 时只给了一条容易忽略的 warning。当下修复是把那两行 numpy 互操作改成纯 list 操作（\`.tolist()\`、\`isinstance(x, list)\`），数值完全一致；根治方案是锁死 \`numpy<2\`。这也是 DCU 环境管理的通病：\*\*定制二进制对周边库版本的绑定是隐式的，一次不经意的 pip install 就能弄坏一个「跟 numpy 毫无关系」的服务\*\*。 \*\*坑二：README 和现实不符。\*\* 交付包自带的 README 写着用 \`sxmodel\` 环境，实际那个环境里没有 torch；默认 checkpoint 路径指向一个已过时的旧迭代。接手部署的人按文档走必然失败。修复之外更重要的是习惯：\*\*部署脚本里显式写出全部环境假设（source 什么、脚本里固化了三条 DCU 经验： ```text source /opt/dtk-26.04/env.sh # ① DTK 环境，不 source 连卡都看不见 export CKPT_DIR=output/qwen3-0.6b_binary_v2_retrain-xxx # ② 不设会用默认旧目录，报 OSError export CUDA_VISIBLE_DEVICES=5 # ③ 固定 5 号卡（0 号常驻别的服务） conda run -n dcu-train python -m uvicorn api.server_direct:app --host 0.0.0.0 --port 8107 ``` 实测表现：`/health` 就绪后，**第一批请求 \~3.9s**（HIP 算子 JIT 预热，只见一次），**预热后单批 46ms**。对批处理任务，预热可以忽略；对低延迟在线服务，可以在启动后主动打一批空请求把 JIT 做完。 ### 踩过的两个坑 **坑一：numpy 2.x 的隐性 ABI 冲突。** 某天环境里的 [numpy](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=22&q=numpy&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJudW1weSIsInpoaWRhX3NvdXJjZSI6ImVudGl0eSIsImNvbnRlbnRfaWQiOjI4MjExNTczNCwiY29udGVudF90eXBlIjoiQXJ0aWNsZSIsIm1hdGNoX29yZGVyIjoyMiwiemRfdG9rZW4iOm51bGx9.9XiWEnZAts5kLMPZ-9fOsmRCk2EDQ86Yav9meFI_v1Y&zhida_source=entity) 被连带升级到了 2.2.6，服务代码里一处 `.cpu().numpy()` 开始抛 `RuntimeError: Numpy is not available`。根因是 torch 2.5.1（DCU 版）按 numpy 1.x 的 ABI 编译，numpy 2.x 卸掉了旧 `_ARRAY_API` 符号。阴就阴在：**tokenizer、模型前向全都不走 numpy 互操作，服务看起来一切正常，只有显式调 `.numpy()` 的那一行代码炸**，而且 import torch 时只给了一条容易忽略的 warning。当下修复是把那两行 numpy 互操作改成纯 list 操作（`.tolist()`、`isinstance(x, list)`），数值完全一致；根治方案是锁死 `numpy<2`。这也是 DCU 环境管理的通病：**定制二进制对周边库版本的绑定是隐式的，一次不经意的 pip install 就能弄坏一个「跟 numpy 毫无关系」的服务**。 **坑二：README 和现实不符。** 交付包自带的 README 写着用 `sxmodel` 环境，实际那个环境里没有 torch；默认 checkpoint 路径指向一个已过时的旧迭代。接手部署的人按文档走必然失败。修复之外更重要的是习惯：\*\*部署脚本里显式写出全部环境假设（source 什么、export 什么、哪个 [conda env](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=conda+env&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJjb25kYSBlbnYiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.TzCAzAfmiqfFn4S4KCDZGk_ZFDNRT2PXOIrOTJ5RLHw&zhida_source=entity)），让脚本文档自己会说话，README 只做索引\*\*。 ## 闭环：这个小服务在大图景里的位置 8107 不是孤立的试验，它是三段流水线的最后一环——这套流水线的设计是： \`\`\` Stage 1: Qwen3-32B 全量微调（teacher，追求标注质量） Stage 2: [在线蒸馏](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E5%9C%A8%E7%BA%BF%E8%92%B8%E9%A6%8F&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLlnKjnur_okrjppo8iLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.2Teuf7TNM7sNUoDx-9WdA_cDUnBu3Yrrvx97FfQifOo&zhida_source=entity) → Qwen3-0.6B（student，teacher 出软标签） Stage 3: student 用本文的方式 FastAPI 上线服务 \`\`\` 逻辑是「大模型出知识，小模型出延迟」。训练侧还配了一套自动迭代机制：每轮从业务库里取新数据，用当前模型推理、和人工标签比对，\*\*只把「模型和标签不一致的分歧样本」喂给下一轮训练\*\*——数据效率和迭代速度都远好于[全量重训](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E5%85%A8%E9%87%8F%E9%87%8D%E8%AE%AD&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLlhajph4_ph43orq0iLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.C9xWf2Qm5zcA1ucHDyUzErFJGYNLf3xfxttdT1OXQT4&zhida_source=entity)。8107 服务里跑的 \`binary\_v2\_retrain\` checkpoint，就是这条流水线的一个产物。 也就是说，那个很多人眼里「只能用来验证链路」的 0.6B，现在既是蒸馏流水线的 student 底座，又是生产服务的[推理引擎](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E6%8E%A8%E7%90%86%E5%BC%95%E6%93%8E&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLmjqjnkIblvJXmk44iLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.XZeAMQO_oecj9N0kA4Tqo9ZI0jmFieTsTMO4Xf5QUrI&zhida_source=entity)。0.6B 的能力天花板确实存在，但\*\*分类任务的精度上限本来就不高——天花板之下，小模型的速度和成本就是纯赚的\*\*。 ## 小结 这篇也补全了「[模型选型](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E6%A8%A1%E5%9E%8B%E9%80%89%E5%9E%8B&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLmqKHlnovpgInlnosiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.vmdOIcSMKADJYLvuryg5i5-8Zj5Y03XL14q9GS-XQgA&zhida_source=entity)」的一个维度：除了「哪个模型更强」，还有「哪个模型对任务够用」。内容风控二分类选 0.6B 而不是 32B，不是妥协，是正确答案——46ms 延迟、3.2GB 显存、单卡可塞多个实例，这些是 32B 永远给不了的。 至于流水线的 Stage 1（32B 全量微调），眼下还在攻坚中——那是一段和 [DeepSpeed](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=DeepSpeed&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJEZWVwU3BlZWQiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.qtcZLe-hpAPS3-OE-GuGhGFREgs_5kjgY25jRMN-cz0&zhida_source=entity)、FSDP [缠斗](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=%E7%BC%A0%E6%96%97&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiLnvKDmlpciLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.oUbIU7yR7eQmTPLC35bKXoMe-N-X6a_nuLKsjc28dlg&zhida_source=entity)的漫长故事，等有了结果再单独成文。 --- \*环境信息：海光 K100\_AI（单卡 HCU5）/ DTK 26.04 / conda env dcu-train（torch 2.5.1 DCU + [transformers](https://zhida.zhihu.com/search?content_id=282115734&content_type=Article&match_order=1&q=transformers&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3OTE3NjkyMTMsInEiOiJ0cmFuc2Zvcm1lcnMiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyODIxMTU3MzQsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.pQlDqb9aU6ByUHtq7JwjIxedvJF8aEAhDSpmhffPL30&zhida_source=entity) 5.12.1）/ Qwen3-0.6B 基座 + classifier\_heads.pt，float32。\*