兄弟们不知道你们团队最近有没有遇到这样的场景采购了几台高配 AI 服务器结果不同小组都来申请算力配额最后变成“人人有份、按人头平分”。表面上看很公平但实际用起来才发现资深工程师跑大模型流水线任务时算力不够用新人那边大部分时间都在做加载测试、日志调试和简单跑通占用的资源却一样多。时间一长团队整体的研发效率和模型迭代速度就被拖住了。这篇文章我想从一个实际项目复盘的角度来聊一聊 AI 算力分配、模型部署选型以及新人培养方式之间的关系。重点会拆解浮点精度对算力消耗的影响、vLLM/昇腾等环境下的模型调度思路以及如何设计一套“按角色和任务分配模型”的工程机制。适合正在做大模型应用开发、AI 平台建设或模型部署的读者参考。1. 背景为什么“所有人平分算力”不划算1.1 算力分配不均的典型场景先看一个非常常见的团队结构。假设你们团队里有几个资深算法工程师每天要做的事情包括在 7B 到 72B 规模的开源模型上做指令微调、跑 RAG 流水线里的 embedding 模型和 reranker 模型、用 vLLM 启动推理服务做性能压测。另外还有几个刚入行的新人主要任务是跑通示例代码、阅读模型源码、做简单的数据处理和脚本调试。如果平台按照人头平均分配 GPU 配额会出现什么情况资深工程师启动一个 72B 模型单卡显存放不下需要多卡并行但配额不够只能排队。新人那边跑一个 1.5B 模型其实单张消费级显卡就能完成却因为分配了同等算力而被“浪费”在简单任务上。整个团队的吞吐量看起来还行但真正关键的业务模型迭代周期变长。这种“公平”不是真正的效率公平。合理的做法应该按照任务的计算密度和模型规模来分配资源。1.2 “刷题式成长”为什么逐渐失效再聊一个新人在 AI 领域的成长问题。过去很多开发者的成长路径是刷大量题目、背诵模型结构、反复看 Transformer 论文。这种方式在早期确实有效因为那时候模型结构相对固定部署工具链也没有那么复杂。但现在的 AI 工程化环境已经变了模型参数量越来越大量化格式越来越多同样的模型在 FP16、BF16、TF32 下的行为差异很大。部署工具链更新极快vLLM、Ollama、LM Studio、vLLM 昇腾后端等工具频繁迭代光看文档已经不够。真实业务要求的不是“会背 transformer 结构”而是能解决显存溢出、推理延迟过高、并发上不去等实际问题。换句话说新人如果还是靠刷题式学习缺少对算力成本、模型资源消耗、推理服务调度这些真实工程问题的感知成长空间会被严重压缩。2. 算力与模型部署的核心基础先补充一些基础概念。这部分对新手友好有经验的同学可以直接跳到第三节。2.1 浮点精度决定“模型能跑多大、多快”模型推理和训练过程中数据通常有几种表示精度FP32、FP16、BF16、TF32。它们的核心区别在于“位宽”和“数值范围”。精度位宽指数位尾数位典型使用场景FP3232 位8 位23 位精度要求高的训练过程、小模型FP1616 位5 位10 位混合精度训练、性能较高的推理BF1616 位8 位7 位大模型训练数值范围宽精度略低TF3219 位实际存储 32 位8 位10 位NVIDIA GPU 上的矩阵运算加速这里有两个要点同样的模型参数量使用 FP16 和 FP32 部署显存占用大约差一半。推理速度上FP16 / BF16 通常比 FP32 更快但部分算子精度下降可能影响模型输出质量。所以算力分配不能只看“多少张卡”还要看精度模式。如果所有任务统一使用 FP32 加载大模型再多的算力也经不住浪费。2.2 算力卡的常见指标搜索材料中提到了一个典型配置AI 算力卡 ≥ 8 颗单颗 AI 算力卡 FP16 算力 ≥ 280 TFLOPSFP32 算力 ≥ 7 TFLOPS。这类配置常见于昇腾 910B 系列服务器。这个指标说明什么FP16 算力远高于 FP32意味着混合精度推理和训练能获得更高的吞吐。8 颗卡通常是为了满足大模型多卡并行需求比如 70B 级别模型在每卡显存有限时需要张量并行。单卡 FP32 算力偏低不适合做大规模 FP32 计算。在做模型选型时这些指标决定了你能部署什么规模的模型以及推理 QPS 能到多少。2.3 vLLM 部署中的常见卡点当前比较主流的开源推理框架是 vLLM它通过 PagedAttention 技术和 Continuous Batching 提升吞吐。但在不同硬件平台上会碰到不同问题比如昇腾 910B 系列服务器上vLLM 启动 embedding 向量模型和 reranker 模型时可能不支持。原因在于vLLM 主要面向生成式大模型优化对 embedding 和 reranker 这类非自回归任务的支持并不完整。昇腾平台的算子适配需要依赖特定版本的 CANN 工具链和 torch_npu。一些模型架构在 vLLM 昇腾后端的--task参数中还没有实现。碰到这种情况不要强行用一个框架解决所有问题。embedding 模型可以使用独立推理服务reranker 模型可以单独封装 API只有生成式对话模型才走 vLLM。3. 模型分配策略让顶级模型去服务顶级任务回到文章标题顶级模型给资深工程师才省钱。这背后是一个“任务-模型-算力”匹配模型。3.1 哪些任务需要“顶级模型”并不是所有人都需要 70B 级别的模型。我们把常见任务分成三类任务类型典型场景推荐模型规模算力需求高难度推理复杂代码生成、数学推理、长文本逻辑分析30B - 70B高常规生成日常问答、文案生成、结构化信息抽取7B - 14B中轻量检索增强embedding 向量化、rerank 重排、文本分类0.1B - 2B低如果给所有任务都分配 70B 模型成本会成倍增长。更理性的做法是搭建一个路由层根据请求类型动态选择模型。3.2 资深工程师为什么更需要大模型资深工程师处理的问题通常是“高复杂度 强上下文 需要稳定输出”。比如从几千行历史代码中定位 bug 并生成修复方案。根据系统架构设计文档自动生成核心模块代码。对长文档做多轮深度分析。这类任务需要模型具备更强的推理能力和指令遵循能力7B 模型往往会产生“看起来合理、实际上运行错误”的代码。与其让资深工程师反复校验小模型的错误输出不如直接调用大模型一次通过的性价比更高。3.3 新人的成长需要“轻量模型 任务拆解”对新人来说过早使用顶级模型反而不利于基本功训练。原因也很现实顶级模型生成结果好但新人很难判断“为什么这个结果好”也不容易理解模型的边界。刷题式成长失效之后新人需要的是“从 8B 模型开始做数据准备、微调、部署、评测再逐步切换到 32B”。大型模型的部署复杂度反而更高新人如果直接上手 70B 模型的多卡配置容易陷入环境问题而不是学到核心算法知识。所以在分配策略上我建议新人默认使用 7B-14B 模型配额有限主要用于跑通流程。新人完成一个完整的落地项目后可以申请使用更大的模型做进阶实验。资深工程师直接获取大模型的高配额但要在任务级别做审计避免资源浪费。3.4 设计一个简单的“模型路由 配额控制”方案这里提供一个简单的架构思路通过 API 网关根据请求参数路由到不同模型服务使用 Redis 做配额计数。# 文件路径model_router.py # 一个简单的模型路由与配额控制示例 import redis from flask import Flask, request, jsonify app Flask(__name__) r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) MODEL_LIST { senior: deepseek-33b-instruct, junior: qwen-14b-chat, embedding: bge-large-zh, reranker: bge-reranker-v2-m3 } # 配额表每个角色每分钟可以调用的次数 QUOTA { senior: 200, junior: 50, embedding: 1000, reranker: 1000 } def check_quota(role: str) - bool: key fquota:{role}:{request.remote_addr} current r.get(key) if current is None: r.set(key, 1, ex60) return True current int(current) if current QUOTA.get(role, 0): return False r.incr(key) return True app.route(/v1/chat, methods[POST]) def chat(): data request.get_json() role data.get(role, junior) if not check_quota(role): return jsonify({error: quota exceeded}), 429 model_name MODEL_LIST.get(role, MODEL_LIST[junior]) # 这里可以根据 model_name 转发到不同的模型服务 return jsonify({model: model_name, status: routed}) if __name__ __main__: app.run(host0.0.0.0, port8080)这个示例的逻辑很简单根据请求中的角色参数决定使用模型。使用 Redis 进行每分钟调用次数计数。超过配额直接返回 429避免单个用户拖垮整个推理服务。生产环境还需要增加鉴权、限流、审计日志这里只做演示。3.5 避免“人人平分”的工程落地很多团队觉得“按角色分配算力”太复杂实际上完全可以从模型服务层面做隔离。看下面的部署结构[客户端] ↓ [API 网关] —— 高级模型服务70B资深工程师专用8卡并行 ↓ [配额中间件] —— 中档模型服务14B常规任务 ↓ [模型服务集群] —— 轻量模型服务embedding / reranker这种结构的好处是不同模型可以部署在不同 GPU 池中资源物理隔离。即使某个模型的推理服务崩溃也不会影响其他任务。每一层模型都可以独立扩容。4. 部署实例如何在昇腾服务器上规划模型服务以常见的昇腾 910B 服务器为例。硬件配置是 8 颗 AI 算力卡每颗卡 FP16 算力较好但单卡显存可能无法直接加载超大模型。下面给出一个可行的部署规划。4.1 算力规划建议模型参数规模精度显存估算卡数建议代码生成大模型32BBF16约 64GB2 - 4 卡张量并行通用对话模型14BFP16约 28GB1 - 2 卡Embedding 模型0.5BFP16约 1GB可与 reranker 共用 1 卡Reranker 模型0.6BFP16约 1.2GB同上注意这只是显存层面的估算。实际部署还要考虑 KV Cache 的占用以及并发请求数量对显存的影响。4.2 vLLM 部署大模型示例在昇腾环境上如果 vLLM 可用可以这样启动一个 32B 模型的推理服务python -m vllm.entrypoints.openai.api_server \ --model /data/models/deepseek-32b-instruct \ --tensor-parallel-size 4 \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000参数解释--tensor-parallel-size 4使用 4 张卡并行推理。--dtype bfloat16使用 BF16 精度减少显存占用。--gpu-memory-utilization 0.9允许使用每张卡 90% 的显存。--max-model-len 8192限制最大上下文长度。如果你的环境没法使用 vLLM 的生成接口做 embedding请参考下面的独立部署方案。4.3 Embedding 和 Reranker 模型独立部署既然 vLLM 在昇腾上对 embedding 和 reranker 的支持不完善建议使用独立服务。这里给出一个基于 FastAPI sentence-transformers 的示例。# 文件路径embedding_server.py # 独立部署 embedding 和 reranker 模型服务 from fastapi import FastAPI, Request from sentence_transformers import SentenceTransformer from pydantic import BaseModel app FastAPI() # 加载 embedding 模型 embedding_model SentenceTransformer(/data/models/bge-large-zh) # 加载 reranker 模型这里使用 cross-encoder 方式 from sentence_transformers import CrossEncoder reranker_model CrossEncoder(/data/models/bge-reranker-v2-m3) class EmbeddingRequest(BaseModel): text: str class RerankerRequest(BaseModel): query: str passages: list app.post(/embedding) def get_embedding(req: EmbeddingRequest): vec embedding_model.encode(req.text, normalize_embeddingsTrue) return {vector: vec.tolist()} app.post(/rerank) def rerank(req: RerankerRequest): pairs [(req.query, passage) for passage in req.passages] scores reranker_model.predict(pairs) results sorted(zip(req.passages, scores.tolist()), keylambda x: x[1], reverseTrue) return {results: results} if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8001)这样就把 embedding 和 reranker 从 vLLM 依赖中解放出来在昇腾上通过 CANN 适配的 PyTorch 也能运行。5. 新人成长路径与算力使用的再思考如果只是把算力分配给资深工程师那新人永远得不到成长。关键在于设计一条“渐进式使用算力”的学习路线。5.1 从刷题式学习转向任务式学习现在的 AI 学习资料很多刷题、看论文、复现模型确实有必要但只靠这些远远不够。我建议新人把成长路径改成“任务式驱动”完成一个能跑通的端到端小模型部署比如 0.5B 的文本分类模型。在本地或一台单卡服务器上完成从数据标注、训练脚本编写、模型导出到 API 部署的全流程。使用量化工具把模型从 FP16 转成 INT8对比精度和速度变化。尝试用 7B 模型做一个 RAG 应用接入 embedding 和 reranker 模型。申请中型模型的训练资源完成一次 LoRA 微调。5.2 算力使用日志与复盘团队内部可以引入算力使用日志。每位开发者每次跑任务时记录模型名称、精度、卡数、实际耗时。每周做一次简单分析。-- 算力使用分析示例 SQL SELECT user_role, model_name, precision_mode, AVG(duration_seconds) AS avg_duration, COUNT(*) AS call_count FROM inference_logs WHERE created_at NOW() - INTERVAL 7 days GROUP BY user_role, model_name, precision_mode ORDER BY call_count DESC;通过这样一份日志团队可以清楚地看到哪些模型被高频调用、哪些任务占用了大量算力但产出有限从而持续优化分配策略。这个习惯对新人尤其重要。等到新人逐步积累起“不同精度、不同规模模型在真实任务中的表现差异”的直觉他们就能真正理解算力成本的含义。5.3 预留“实验算力池”我不建议把全部算力都按业务角色锁定。更好的做法是预留 10%-20% 的算力作为实验池所有开发者都可以申请但需要填写实验目的和预期消耗。实验池的价值在于新人可以用低成本方式试错。资深工程师可以快速验证新模型的效果。团队整体对算力分配策略保持弹性而不是被流程锁死。6. 常见问题与排查思路这里整理一些实际项目中的高频问题。问题现象常见原因解决思路大模型启动时显存不足模型精度过高或并行策略配置错误改用 BF16/INT8 量化增加 tensor parallel 卡数vLLM 启动 embedding 模型报错vLLM 不支持非生成类任务使用 sentence-transformers 独立部署新人拿到大模型配额但跑不出效果上下文长度设置太长或模型未做推理参数调优缩短 max-model-len调整 temperature 参数多人同时调用服务导致排队单模型服务并发能力不足增加副本数接入负载均衡昇腾服务器上算子执行慢CANN 工具链版本不匹配检查 CANN、PyTorch、torch_npu 版本兼容性如果你遇到昇腾 910B 上 vLLM 无法启动 embedding 或 reranker 模型的报错优先检查以下几点# 检查 torch_npu 是否安装成功 python -c import torch_npu; print(torch_npu.__version__) # 检查 CANN 版本 cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg如果上述命令报错说明环境适配有问题先解决工具链问题再启动模型服务。7. 最佳实践与工程建议最后总结一些可以立刻用起来的工程建议。7.1 算力分配要按“任务计算密度”做标签建议在内部平台上引入任务标签例如heavy-inference-heavy: 需要多卡大模型推理。light-inference-light: 单卡小模型即可。training-heavy: 需要长时间占用的训练任务。embeddings: 高并发低延迟的向量化任务。每个任务提交申请时强制选择标签调度平台根据标签自动匹配资源池。这样可以避免人工判断带来的误差。7.2 模型服务必须做“预热”和“压测”很多团队只关注部署不关注预热结果上线后第一个请求延迟特别高。推理框架通常会在首次请求时完成模型加载和 CUDA/CANN kernel 编译需要访问一次以触发缓存。常见做法curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: deepseek-32b-instruct, messages: [{role: user, content: hello}]}压测则是使用 locust、wrk 等工具模拟多用户请求确认服务的稳定吞吐量。环境允许的话可以接入 Grafana 和 Prometheus 监控服务。7.3 新人成长和算力分配的联动如果团队已经引入了 AI 研发平台建议做到“算力配额与技能等级挂钩”初级开发者默认可使用 7B 以下模型。完成一次完整的模型微调项目后解锁 14B 模型使用权限。能够独立排查推理性能问题后解锁 32B 以上多卡模型权限。这既保证了资源利用率也让新人的成长路径变得清晰可见。7.4 安全与合规提醒在多人共享算力平台中权限隔离非常重要。模型文件按照团队隔离不能随意跨部门加载。推理服务的 API 需要加上鉴权避免被内部或外部非法调用。涉及代码生成的场景注意模型输出可能包含敏感信息或漏洞需要增加输出过滤。生产环境任何变更都要先在测试环境验证做好备份。7.5 定期复盘算力账单算力成本不只是采购成本还包括电费、运维、租用云资源的费用。建议每个月做一次算力账单分析统计每个模型服务实际消耗的 GPU 时长和业务产出做对比。如果发现某个模型服务长期没有调用量就应该关停并释放算力。如果发现某个资深工程师的任务频繁需要用 70B 模型这说明他真的在做高价值工作可以继续加大配额。8. 总结这篇文章从“别再所有人平分 AI 算力”这个话题入手梳理了算力分配与模型选型的几个关键点除了不能把算力当作“人人有份”的资源来粗放分配外还要理解 FP16/BF16/FP32 在不同任务中的成本差异要为一个团队建立“重模型给资深工程师、轻模型给常规任务、实验池供新人试错”的分层机制。同时新人的成长方式也不能停留在刷题式学习而应该通过真实的任务、真实的数据、真实的部署环境积累工程直觉。如果你正在建设团队内部的 AI 平台或算力调度系统建议先从“模型路由 角色配额 使用日志”这三个组件开始不需要一开始就做完整的平台化。跑通一个小闭环再逐步扩展稳定性会远高于一上来做大而全的方案。
兄弟们不知道你们团队最近有没有遇到这样的场景采购了几台高配 AI 服务器结果不同小组都来申请算力配额最后变成“人人有份、按人头平分”。表面上看很公平但实际用起来才发现资深工程师跑大模型流水线任务时算力不够用新人那边大部分时间都在做加载测试、日志调试和简单跑通占用的资源却一样多。时间一长团队整体的研发效率和模型迭代速度就被拖住了。这篇文章我想从一个实际项目复盘的角度来聊一聊 AI 算力分配、模型部署选型以及新人培养方式之间的关系。重点会拆解浮点精度对算力消耗的影响、vLLM/昇腾等环境下的模型调度思路以及如何设计一套“按角色和任务分配模型”的工程机制。适合正在做大模型应用开发、AI 平台建设或模型部署的读者参考。1. 背景为什么“所有人平分算力”不划算1.1 算力分配不均的典型场景先看一个非常常见的团队结构。假设你们团队里有几个资深算法工程师每天要做的事情包括在 7B 到 72B 规模的开源模型上做指令微调、跑 RAG 流水线里的 embedding 模型和 reranker 模型、用 vLLM 启动推理服务做性能压测。另外还有几个刚入行的新人主要任务是跑通示例代码、阅读模型源码、做简单的数据处理和脚本调试。如果平台按照人头平均分配 GPU 配额会出现什么情况资深工程师启动一个 72B 模型单卡显存放不下需要多卡并行但配额不够只能排队。新人那边跑一个 1.5B 模型其实单张消费级显卡就能完成却因为分配了同等算力而被“浪费”在简单任务上。整个团队的吞吐量看起来还行但真正关键的业务模型迭代周期变长。这种“公平”不是真正的效率公平。合理的做法应该按照任务的计算密度和模型规模来分配资源。1.2 “刷题式成长”为什么逐渐失效再聊一个新人在 AI 领域的成长问题。过去很多开发者的成长路径是刷大量题目、背诵模型结构、反复看 Transformer 论文。这种方式在早期确实有效因为那时候模型结构相对固定部署工具链也没有那么复杂。但现在的 AI 工程化环境已经变了模型参数量越来越大量化格式越来越多同样的模型在 FP16、BF16、TF32 下的行为差异很大。部署工具链更新极快vLLM、Ollama、LM Studio、vLLM 昇腾后端等工具频繁迭代光看文档已经不够。真实业务要求的不是“会背 transformer 结构”而是能解决显存溢出、推理延迟过高、并发上不去等实际问题。换句话说新人如果还是靠刷题式学习缺少对算力成本、模型资源消耗、推理服务调度这些真实工程问题的感知成长空间会被严重压缩。2. 算力与模型部署的核心基础先补充一些基础概念。这部分对新手友好有经验的同学可以直接跳到第三节。2.1 浮点精度决定“模型能跑多大、多快”模型推理和训练过程中数据通常有几种表示精度FP32、FP16、BF16、TF32。它们的核心区别在于“位宽”和“数值范围”。精度位宽指数位尾数位典型使用场景FP3232 位8 位23 位精度要求高的训练过程、小模型FP1616 位5 位10 位混合精度训练、性能较高的推理BF1616 位8 位7 位大模型训练数值范围宽精度略低TF3219 位实际存储 32 位8 位10 位NVIDIA GPU 上的矩阵运算加速这里有两个要点同样的模型参数量使用 FP16 和 FP32 部署显存占用大约差一半。推理速度上FP16 / BF16 通常比 FP32 更快但部分算子精度下降可能影响模型输出质量。所以算力分配不能只看“多少张卡”还要看精度模式。如果所有任务统一使用 FP32 加载大模型再多的算力也经不住浪费。2.2 算力卡的常见指标搜索材料中提到了一个典型配置AI 算力卡 ≥ 8 颗单颗 AI 算力卡 FP16 算力 ≥ 280 TFLOPSFP32 算力 ≥ 7 TFLOPS。这类配置常见于昇腾 910B 系列服务器。这个指标说明什么FP16 算力远高于 FP32意味着混合精度推理和训练能获得更高的吞吐。8 颗卡通常是为了满足大模型多卡并行需求比如 70B 级别模型在每卡显存有限时需要张量并行。单卡 FP32 算力偏低不适合做大规模 FP32 计算。在做模型选型时这些指标决定了你能部署什么规模的模型以及推理 QPS 能到多少。2.3 vLLM 部署中的常见卡点当前比较主流的开源推理框架是 vLLM它通过 PagedAttention 技术和 Continuous Batching 提升吞吐。但在不同硬件平台上会碰到不同问题比如昇腾 910B 系列服务器上vLLM 启动 embedding 向量模型和 reranker 模型时可能不支持。原因在于vLLM 主要面向生成式大模型优化对 embedding 和 reranker 这类非自回归任务的支持并不完整。昇腾平台的算子适配需要依赖特定版本的 CANN 工具链和 torch_npu。一些模型架构在 vLLM 昇腾后端的--task参数中还没有实现。碰到这种情况不要强行用一个框架解决所有问题。embedding 模型可以使用独立推理服务reranker 模型可以单独封装 API只有生成式对话模型才走 vLLM。3. 模型分配策略让顶级模型去服务顶级任务回到文章标题顶级模型给资深工程师才省钱。这背后是一个“任务-模型-算力”匹配模型。3.1 哪些任务需要“顶级模型”并不是所有人都需要 70B 级别的模型。我们把常见任务分成三类任务类型典型场景推荐模型规模算力需求高难度推理复杂代码生成、数学推理、长文本逻辑分析30B - 70B高常规生成日常问答、文案生成、结构化信息抽取7B - 14B中轻量检索增强embedding 向量化、rerank 重排、文本分类0.1B - 2B低如果给所有任务都分配 70B 模型成本会成倍增长。更理性的做法是搭建一个路由层根据请求类型动态选择模型。3.2 资深工程师为什么更需要大模型资深工程师处理的问题通常是“高复杂度 强上下文 需要稳定输出”。比如从几千行历史代码中定位 bug 并生成修复方案。根据系统架构设计文档自动生成核心模块代码。对长文档做多轮深度分析。这类任务需要模型具备更强的推理能力和指令遵循能力7B 模型往往会产生“看起来合理、实际上运行错误”的代码。与其让资深工程师反复校验小模型的错误输出不如直接调用大模型一次通过的性价比更高。3.3 新人的成长需要“轻量模型 任务拆解”对新人来说过早使用顶级模型反而不利于基本功训练。原因也很现实顶级模型生成结果好但新人很难判断“为什么这个结果好”也不容易理解模型的边界。刷题式成长失效之后新人需要的是“从 8B 模型开始做数据准备、微调、部署、评测再逐步切换到 32B”。大型模型的部署复杂度反而更高新人如果直接上手 70B 模型的多卡配置容易陷入环境问题而不是学到核心算法知识。所以在分配策略上我建议新人默认使用 7B-14B 模型配额有限主要用于跑通流程。新人完成一个完整的落地项目后可以申请使用更大的模型做进阶实验。资深工程师直接获取大模型的高配额但要在任务级别做审计避免资源浪费。3.4 设计一个简单的“模型路由 配额控制”方案这里提供一个简单的架构思路通过 API 网关根据请求参数路由到不同模型服务使用 Redis 做配额计数。# 文件路径model_router.py # 一个简单的模型路由与配额控制示例 import redis from flask import Flask, request, jsonify app Flask(__name__) r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) MODEL_LIST { senior: deepseek-33b-instruct, junior: qwen-14b-chat, embedding: bge-large-zh, reranker: bge-reranker-v2-m3 } # 配额表每个角色每分钟可以调用的次数 QUOTA { senior: 200, junior: 50, embedding: 1000, reranker: 1000 } def check_quota(role: str) - bool: key fquota:{role}:{request.remote_addr} current r.get(key) if current is None: r.set(key, 1, ex60) return True current int(current) if current QUOTA.get(role, 0): return False r.incr(key) return True app.route(/v1/chat, methods[POST]) def chat(): data request.get_json() role data.get(role, junior) if not check_quota(role): return jsonify({error: quota exceeded}), 429 model_name MODEL_LIST.get(role, MODEL_LIST[junior]) # 这里可以根据 model_name 转发到不同的模型服务 return jsonify({model: model_name, status: routed}) if __name__ __main__: app.run(host0.0.0.0, port8080)这个示例的逻辑很简单根据请求中的角色参数决定使用模型。使用 Redis 进行每分钟调用次数计数。超过配额直接返回 429避免单个用户拖垮整个推理服务。生产环境还需要增加鉴权、限流、审计日志这里只做演示。3.5 避免“人人平分”的工程落地很多团队觉得“按角色分配算力”太复杂实际上完全可以从模型服务层面做隔离。看下面的部署结构[客户端] ↓ [API 网关] —— 高级模型服务70B资深工程师专用8卡并行 ↓ [配额中间件] —— 中档模型服务14B常规任务 ↓ [模型服务集群] —— 轻量模型服务embedding / reranker这种结构的好处是不同模型可以部署在不同 GPU 池中资源物理隔离。即使某个模型的推理服务崩溃也不会影响其他任务。每一层模型都可以独立扩容。4. 部署实例如何在昇腾服务器上规划模型服务以常见的昇腾 910B 服务器为例。硬件配置是 8 颗 AI 算力卡每颗卡 FP16 算力较好但单卡显存可能无法直接加载超大模型。下面给出一个可行的部署规划。4.1 算力规划建议模型参数规模精度显存估算卡数建议代码生成大模型32BBF16约 64GB2 - 4 卡张量并行通用对话模型14BFP16约 28GB1 - 2 卡Embedding 模型0.5BFP16约 1GB可与 reranker 共用 1 卡Reranker 模型0.6BFP16约 1.2GB同上注意这只是显存层面的估算。实际部署还要考虑 KV Cache 的占用以及并发请求数量对显存的影响。4.2 vLLM 部署大模型示例在昇腾环境上如果 vLLM 可用可以这样启动一个 32B 模型的推理服务python -m vllm.entrypoints.openai.api_server \ --model /data/models/deepseek-32b-instruct \ --tensor-parallel-size 4 \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000参数解释--tensor-parallel-size 4使用 4 张卡并行推理。--dtype bfloat16使用 BF16 精度减少显存占用。--gpu-memory-utilization 0.9允许使用每张卡 90% 的显存。--max-model-len 8192限制最大上下文长度。如果你的环境没法使用 vLLM 的生成接口做 embedding请参考下面的独立部署方案。4.3 Embedding 和 Reranker 模型独立部署既然 vLLM 在昇腾上对 embedding 和 reranker 的支持不完善建议使用独立服务。这里给出一个基于 FastAPI sentence-transformers 的示例。# 文件路径embedding_server.py # 独立部署 embedding 和 reranker 模型服务 from fastapi import FastAPI, Request from sentence_transformers import SentenceTransformer from pydantic import BaseModel app FastAPI() # 加载 embedding 模型 embedding_model SentenceTransformer(/data/models/bge-large-zh) # 加载 reranker 模型这里使用 cross-encoder 方式 from sentence_transformers import CrossEncoder reranker_model CrossEncoder(/data/models/bge-reranker-v2-m3) class EmbeddingRequest(BaseModel): text: str class RerankerRequest(BaseModel): query: str passages: list app.post(/embedding) def get_embedding(req: EmbeddingRequest): vec embedding_model.encode(req.text, normalize_embeddingsTrue) return {vector: vec.tolist()} app.post(/rerank) def rerank(req: RerankerRequest): pairs [(req.query, passage) for passage in req.passages] scores reranker_model.predict(pairs) results sorted(zip(req.passages, scores.tolist()), keylambda x: x[1], reverseTrue) return {results: results} if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8001)这样就把 embedding 和 reranker 从 vLLM 依赖中解放出来在昇腾上通过 CANN 适配的 PyTorch 也能运行。5. 新人成长路径与算力使用的再思考如果只是把算力分配给资深工程师那新人永远得不到成长。关键在于设计一条“渐进式使用算力”的学习路线。5.1 从刷题式学习转向任务式学习现在的 AI 学习资料很多刷题、看论文、复现模型确实有必要但只靠这些远远不够。我建议新人把成长路径改成“任务式驱动”完成一个能跑通的端到端小模型部署比如 0.5B 的文本分类模型。在本地或一台单卡服务器上完成从数据标注、训练脚本编写、模型导出到 API 部署的全流程。使用量化工具把模型从 FP16 转成 INT8对比精度和速度变化。尝试用 7B 模型做一个 RAG 应用接入 embedding 和 reranker 模型。申请中型模型的训练资源完成一次 LoRA 微调。5.2 算力使用日志与复盘团队内部可以引入算力使用日志。每位开发者每次跑任务时记录模型名称、精度、卡数、实际耗时。每周做一次简单分析。-- 算力使用分析示例 SQL SELECT user_role, model_name, precision_mode, AVG(duration_seconds) AS avg_duration, COUNT(*) AS call_count FROM inference_logs WHERE created_at NOW() - INTERVAL 7 days GROUP BY user_role, model_name, precision_mode ORDER BY call_count DESC;通过这样一份日志团队可以清楚地看到哪些模型被高频调用、哪些任务占用了大量算力但产出有限从而持续优化分配策略。这个习惯对新人尤其重要。等到新人逐步积累起“不同精度、不同规模模型在真实任务中的表现差异”的直觉他们就能真正理解算力成本的含义。5.3 预留“实验算力池”我不建议把全部算力都按业务角色锁定。更好的做法是预留 10%-20% 的算力作为实验池所有开发者都可以申请但需要填写实验目的和预期消耗。实验池的价值在于新人可以用低成本方式试错。资深工程师可以快速验证新模型的效果。团队整体对算力分配策略保持弹性而不是被流程锁死。6. 常见问题与排查思路这里整理一些实际项目中的高频问题。问题现象常见原因解决思路大模型启动时显存不足模型精度过高或并行策略配置错误改用 BF16/INT8 量化增加 tensor parallel 卡数vLLM 启动 embedding 模型报错vLLM 不支持非生成类任务使用 sentence-transformers 独立部署新人拿到大模型配额但跑不出效果上下文长度设置太长或模型未做推理参数调优缩短 max-model-len调整 temperature 参数多人同时调用服务导致排队单模型服务并发能力不足增加副本数接入负载均衡昇腾服务器上算子执行慢CANN 工具链版本不匹配检查 CANN、PyTorch、torch_npu 版本兼容性如果你遇到昇腾 910B 上 vLLM 无法启动 embedding 或 reranker 模型的报错优先检查以下几点# 检查 torch_npu 是否安装成功 python -c import torch_npu; print(torch_npu.__version__) # 检查 CANN 版本 cat /usr/local/Ascend/ascend-toolkit/latest/version.cfg如果上述命令报错说明环境适配有问题先解决工具链问题再启动模型服务。7. 最佳实践与工程建议最后总结一些可以立刻用起来的工程建议。7.1 算力分配要按“任务计算密度”做标签建议在内部平台上引入任务标签例如heavy-inference-heavy: 需要多卡大模型推理。light-inference-light: 单卡小模型即可。training-heavy: 需要长时间占用的训练任务。embeddings: 高并发低延迟的向量化任务。每个任务提交申请时强制选择标签调度平台根据标签自动匹配资源池。这样可以避免人工判断带来的误差。7.2 模型服务必须做“预热”和“压测”很多团队只关注部署不关注预热结果上线后第一个请求延迟特别高。推理框架通常会在首次请求时完成模型加载和 CUDA/CANN kernel 编译需要访问一次以触发缓存。常见做法curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: deepseek-32b-instruct, messages: [{role: user, content: hello}]}压测则是使用 locust、wrk 等工具模拟多用户请求确认服务的稳定吞吐量。环境允许的话可以接入 Grafana 和 Prometheus 监控服务。7.3 新人成长和算力分配的联动如果团队已经引入了 AI 研发平台建议做到“算力配额与技能等级挂钩”初级开发者默认可使用 7B 以下模型。完成一次完整的模型微调项目后解锁 14B 模型使用权限。能够独立排查推理性能问题后解锁 32B 以上多卡模型权限。这既保证了资源利用率也让新人的成长路径变得清晰可见。7.4 安全与合规提醒在多人共享算力平台中权限隔离非常重要。模型文件按照团队隔离不能随意跨部门加载。推理服务的 API 需要加上鉴权避免被内部或外部非法调用。涉及代码生成的场景注意模型输出可能包含敏感信息或漏洞需要增加输出过滤。生产环境任何变更都要先在测试环境验证做好备份。7.5 定期复盘算力账单算力成本不只是采购成本还包括电费、运维、租用云资源的费用。建议每个月做一次算力账单分析统计每个模型服务实际消耗的 GPU 时长和业务产出做对比。如果发现某个模型服务长期没有调用量就应该关停并释放算力。如果发现某个资深工程师的任务频繁需要用 70B 模型这说明他真的在做高价值工作可以继续加大配额。8. 总结这篇文章从“别再所有人平分 AI 算力”这个话题入手梳理了算力分配与模型选型的几个关键点除了不能把算力当作“人人有份”的资源来粗放分配外还要理解 FP16/BF16/FP32 在不同任务中的成本差异要为一个团队建立“重模型给资深工程师、轻模型给常规任务、实验池供新人试错”的分层机制。同时新人的成长方式也不能停留在刷题式学习而应该通过真实的任务、真实的数据、真实的部署环境积累工程直觉。如果你正在建设团队内部的 AI 平台或算力调度系统建议先从“模型路由 角色配额 使用日志”这三个组件开始不需要一开始就做完整的平台化。跑通一个小闭环再逐步扩展稳定性会远高于一上来做大而全的方案。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
