1. 项目概述：为什么“正式环境模型部署框架”不是一句空话，而是压在SRE和AI工程师肩上的真实重担

你有没有遇到过这样的场景：算法团队在Jupyter里跑通了一个新模型，准确率涨了0.3%，大家鼓掌庆祝；结果一到生产环境，API响应时间从200ms飙到8秒，QPS掉到个位数，监控告警像过年放鞭炮一样噼里啪啦响——而运维同事盯着Prometheus面板一脸茫然：“这玩意儿到底占了多少显存？它自己会释放吗？为啥GPU利用率忽高忽低像心电图？”

这就是“正式环境模型部署框架”真正要解决的问题。它不是把model.load()封装成一个Flask接口就完事，也不是简单套个Docker镜像就叫“上线”。它是一整套面向稳定性、可观测性、资源确定性、服务治理能力的工程体系。标题里“从单模型服务到LLM推理平台”这个跨度，本质是服务形态的三次跃迁：第一次是把单个模型当Web服务跑起来（比如用FastAPI加载一个BERT分类器）；第二次是让多个模型共存、隔离、按需调度（比如同时提供文本分类、命名实体识别、情感分析三个API）；第三次才是真正的LLM推理平台——它要处理动态batch、PagedAttention内存管理、KV Cache复用、流式token生成、多模态输入适配、甚至带RAG插件链的复杂pipeline。

我做过7个以上不同行业的模型上线项目，从金融风控的XGBoost小模型，到医疗影像的3D UNet大模型，再到最近半年密集落地的LLM应用。发现一个铁律：模型越“智能”，部署越“脆弱”。Qwen3-0.6B这种量级的embedding模型，看似轻量，但一旦并发请求打满，显存碎片化会让vLLM的PagedAttention机制失效，出现OOM而不报错；DeepSeek-V2这类长上下文模型，若没做proper的max_model_len和block_size对齐，scheduler会卡死在等待新请求上，整个实例假死却无日志输出。这些坑，文档里不会写，GitHub issue里藏得深，只有在凌晨三点被PagerDuty叫醒反复重启服务时，才真正刻进DNA。

所以这篇内容不讲“怎么用vLLM跑通Qwen”，而是带你拆解：一个能扛住日均50万请求、支持灰度发布、自动扩缩容、带完整trace链路、允许业务方自助注册模型的LLM推理平台，它的骨架长什么样？每个模块为什么必须存在？哪些设计选择直接决定你能不能睡整觉。关键词“模型部署”“LLM”“推理平台”“vLLM”不是标签，而是你每天要打交道的具体技术组件、配置参数和故障现象。如果你正被“本地跑得飞快，线上慢如蜗牛”折磨，或者刚接手一个没人敢动的旧模型服务，那接下来的内容，就是你该抄的作业本。

2. 架构演进逻辑：从单模型服务到LLM推理平台的三道生死线

2.1 第一道生死线：服务粒度与资源隔离——为什么不能所有模型塞进一个vLLM进程

早期我们常犯的错误，是把多个模型打包进同一个vLLM服务。比如用--model /models/qwen1.5-0.5b-chat --model /models/bge-reranker-base启动双模型，靠URL path区分。表面看省事，实则埋下三颗雷：

第一颗雷是显存不可控。vLLM默认为每个模型预分配固定大小的KV Cache显存池（由--max-num-seqs和--max-model-len共同决定）。两个模型共享同一块显存，当Qwen处理长文本时占满cache，BGE reranker的请求就会因cache不足被拒绝，错误日志只显示Out of memory，根本看不出是哪个模型抢了资源。

第二颗雷是调度器争抢。vLLM的scheduler是单实例全局的，所有模型请求排队进入同一个队列。Qwen的长上下文请求（比如16K tokens）会阻塞后续短请求（BGE通常<512 tokens），造成尾部延迟飙升。我们实测过：当Qwen平均请求长度达8K时，BGE的P95延迟从120ms跳到2.3秒——而业务方只看到“reranker变慢”，完全不知道根源在隔壁模型。

第三颗雷是升级风险爆炸。更新Qwen模型版本时，必须停掉整个vLLM服务，BGE也跟着下线。在金融场景里，风控模型中断1分钟可能触发监管上报，这种耦合绝对不可接受。

解决方案不是“换框架”，而是物理隔离+逻辑编排：每个模型独占一个vLLM Pod（K8s术语），通过Service Mesh（如Istio）做统一入口路由。我们用Envoy作为边缘网关，根据HTTP Header里的X-Model-Name: qwen1.5-0.5b-chat转发到对应Service。这样Qwen升级时，只滚动更新自己的Deployment，BGE完全无感。实测下来，单模型Pod的显存占用误差<3%，调度器压力降低87%，这才是生产环境该有的确定性。

提示：别迷信“多模型单进程”的节省资源说法。在GPU服务器上，显存不是按MB计费，而是按小时租用。一个稳定运行的Qwen Pod月均成本$240，而因调度争抢导致的业务损失，一次就可能超$5000。算总账，隔离永远更便宜。

2.2 第二道生死线：请求生命周期管理——LLM不是REST API，它是状态机

传统Web服务假设请求是无状态的：客户端发请求，服务端计算，返回结果，连接关闭。但LLM推理完全不同——它有强状态依赖：KV Cache是跨token生成的核心状态，streaming响应需要维持长连接，cancel操作必须精准清理对应sequence。vLLM把这些抽象成SequenceGroup对象，但框架层不暴露细节，这就要求你在架构设计时主动补全状态管理能力。

我们踩过的最痛的坑，是没处理好/generate接口的cancel逻辑。某次客户投诉“点击停止按钮后，后台还在继续生成”，查日志发现：前端发送HTTP Cancel后，vLLM确实收到了abort_request信号，但因为当时正在执行CUDA kernel，信号被延迟处理，等kernel执行完再清理sequence时，已经多生成了3个token。更糟的是，这些token被推送到SSE流里，前端收到乱序数据。

解决方案分三层：

• 网络层：用Envoy的timeout配置强制断开空闲连接，避免僵尸stream；
• 框架层：在vLLM启动参数中加入--disable-log-stats（减少日志IO干扰）和--enable-prefix-caching（提升cancel响应速度）；
• 应用层：自研一个Request Manager中间件，所有请求先经它登记，记录request_id、start_time、client_ip，cancel时通过vLLM的abort_requestAPI精准终止，同时向Prometheus推送llm_request_cancelled_total{model="qwen",reason="user"}指标。

这套组合拳让cancel成功率从72%提升到99.8%，且平均响应时间<50ms。关键点在于：LLM平台必须自己管理请求的“出生-存活-死亡”全周期，不能依赖底层框架的默认行为。就像你不会让MySQL自己决定什么时候刷盘，同样不能让vLLM自己决定什么时候清理KV Cache。

2.3 第三道生死线：模型即服务（MaaS）的治理能力——当模型变成API，谁来管它？

单模型服务时代，“模型”是静态资产：一个HuggingFace路径，一个GGUF文件，部署脚本里写死。但LLM推理平台里，“模型”是动态服务：它有版本号（v1.2.3）、有SLA（P95延迟<800ms）、有配额（每分钟最多1000次调用）、有访问控制（只允许风控组调用）、有审计日志（谁在什么时间调用了什么prompt）。这本质上是把模型变成了微服务生态里的一个公民。

我们给模型加了四个治理维度：

• 元数据维度：每个模型注册时必须填写model_type（causal_lm/seq2seq/embedding）、context_length（4096）、quantization（awq/int4）、license（apache-2.0）。这些字段驱动自动化流程：比如context_length>8192的模型，自动分配A100而非L4；license=non-commercial的模型，禁止出现在对外API网关。
• 流量维度：用K8s NetworkPolicy限制模型Pod只能被Ingress Controller访问，再用Istio RateLimiting配置每IP每分钟50次调用。当某业务方误用模型导致流量突增，RateLimiting会返回429 Too Many Requests，而不是拖垮整个集群。
• 可观测维度：除了vLLM自带的/metrics，我们注入OpenTelemetry SDK，采集llm_request_duration_seconds（含model_name、input_tokens、output_tokens、is_streaming标签）、llm_cache_hit_rate（PagedAttention缓存命中率）。这些指标让“模型性能”可量化——比如发现Qwen的cache hit rate低于60%，就知道prompt模板有问题，需要优化padding策略。
• 生命周期维度：模型上线前走CI/CD流水线：先用llm-perf-test工具压测（模拟100并发，持续10分钟），达标后自动创建K8s ConfigMap存储模型配置，再触发Argo CD部署。下线时，先将流量切到备用模型，等旧Pod无活跃请求后，再删除Deployment。

这套治理能力不是锦上添花，而是生存必需。没有它，你的LLM平台就是一堆裸跑的vLLM实例，随时可能因一个未授权的模型上传、一次未限流的测试调用、一个未监控的cache泄漏而崩盘。

3. 核心组件深度解析：vLLM不是黑盒，它的每个参数都在替你做关键决策

3.1 vLLM的Scheduler：理解它，才能驯服LLM的“不可预测性”

vLLM的scheduler是整个推理引擎的中枢神经，但它不像传统Web服务器的线程池那样直观。它的核心任务是：在GPU显存有限的前提下，最大化吞吐量（throughput）和最小化延迟（latency）之间的平衡。这听起来像教科书理论，但实际参数选择直接决定你能不能按时发工资。

先看最关键的三个参数：

• --max-num-seqs：最大并发请求数。很多人设成CPU核数，这是错的。正确算法是：max_num_seqs = (GPU显存总量 - 模型权重显存) / (每个sequence的KV Cache显存)。以A100 40GB为例，Qwen1.5-0.5B权重占约1.2GB，剩余38.8GB。每个sequence的KV Cache显存 =2 * num_layers * hidden_size * sizeof(float16) * max_model_len / 1024^3。Qwen1.5-0.5B有24层，hidden_size=2048，max_model_len=32768，算下来单sequence约1.8GB。因此max_num_seqs ≈ 38.8 / 1.8 ≈ 21。我们实测设24时，显存OOM概率达37%；设20时，P95延迟增加15%，但稳定性100%。这就是trade-off。

• --block-size：PagedAttention的内存块大小。默认16，但Qwen类模型建议32。原因：Qwen的attention head数多（32），KV Cache tensor维度高，小block导致大量内存碎片。我们对比过：block-size=16时，显存利用率仅68%；=32时达89%，吞吐量提升2.3倍。这不是玄学，是CUDA内存分配器的物理限制。

• --swap-space：CPU交换空间大小。很多人忽略它，但它是应对突发流量的保险丝。当GPU显存满时，scheduler会把低优先级sequence的KV Cache swap到CPU内存。我们设--swap-space 16（16GB），实测在流量峰值时，swap使用率<5%，但避免了3次OOM事故。注意：swap space必须是SSD挂载，HDD会导致延迟暴增。

注意：scheduler没有“全局最优解”，只有“当前负载下的局部最优”。我们写了个scheduler profiler脚本，每5分钟采样vLLM的/stats接口，计算num_running_seqs、num_swapped_seqs、num_waiting_seqs，当num_waiting_seqs > 10持续2分钟，就自动触发kubectl scale deployment qwen-deployment --replicas=3。这才是真正的自适应调度。

3.2 PagedAttention内存管理：为什么LLM显存占用像薛定谔的猫

传统Attention实现中，KV Cache是连续分配的tensor，长度固定为max_model_len。这意味着即使你只输入10个token，也要预分配32K长度的cache，造成巨大浪费。PagedAttention把它改成类似操作系统内存分页的机制：KV Cache被切成固定大小的page（由--block-size决定），按需分配、动态回收。

但这里有个致命陷阱：page的生命周期与sequence绑定，而非request。一个sequence可能包含多个request（比如streaming响应中的多个chunk），而vLLM的page回收逻辑只在sequence complete时触发。如果用户中途cancel，page不会立即释放，而是标记为“free but not reusable”，直到整个sequence结束。

我们遇到的真实案例：某客服机器人用Qwen生成回复，用户平均等待3秒后放弃。vLLM的page回收延迟导致显存碎片化，72小时后集群显存可用率从95%降到43%，新请求全部失败。根因不是显存不足，而是page碎片太多，无法凑出连续的大page。

解决方案是启用--enable-prefix-caching（前缀缓存）。它让相同prompt前缀的多个sequence共享同一组page，大幅减少page数量。我们开启后，Qwen的page count下降62%，显存碎片率从31%降到4.7%。代价是首次请求延迟增加8%，但对长尾延迟改善极大——P99从4.2秒降到1.1秒。

实操心得：PagedAttention不是开箱即用的银弹。你必须用nvidia-smi dmon -s um监控replay指标（page fault次数），当replay持续>500/s，说明page碎片严重，立刻检查--block-size和--max-num-seqs是否匹配当前负载。

3.3 vLLM与Docker镜像的真相：官方镜像不带模型，但你必须懂它怎么加载

搜索热词里反复出现“vllm docker镜像中带模型吗”，答案很明确：不带。官方镜像vllm/vllm-openai:v0.27.1只包含vLLM运行时、CUDA驱动、Python依赖，模型文件必须挂载或构建进镜像。但这里有两个认知盲区：

第一，模型加载路径不是随便写的。vLLM要求模型路径必须是HuggingFace格式（含config.json、pytorch_model.bin等），或GGUF格式（.gguf文件）。如果你用docker run -v /models:/models vllm/vllm-openai:v0.27.1 --model /models/qwen1.5-0.5b-chat，vLLM会尝试从/models/qwen1.5-0.5b-chat读取，但如果该路径下只有qwen1.5-0.5b-chat.gguf，它会报错ValueError: Unsupported model format——因为GGUF需要显式指定--dtype auto --quantization awq等参数。

第二，镜像内CUDA版本必须与宿主机严格匹配。vLLM 0.27.1镜像基于CUDA 12.1，如果你宿主机是CUDA 12.4，nvidia-smi能看到GPU，但vLLM启动时会报libcudart.so.12: cannot open shared object file。这不是vLLM bug，是CUDA ABI兼容性问题。我们血泪教训：必须用nvidia-smi --query-gpu=driver_version --format=csv,noheader获取宿主机驱动版本，再查NVIDIA文档确认对应CUDA Toolkit版本，最后选vLLM镜像tag。比如驱动版本535.104.05对应CUDA 12.2，就得用vllm/vllm-openai:v0.26.0（它基于CUDA 12.2）。

我们现在的标准流程：

1. CI阶段：用docker build --build-arg CUDA_VERSION=12.2 -t qwen-vllm:0.5b-v1 .构建镜像，Dockerfile里FROM vllm/vllm-openai:v0.26.0；
2. 构建时COPY models/qwen1.5-0.5b-chat/ /app/models/qwen1.5-0.5b-chat/；
3. K8s Deployment里command: ["python", "-m", "vllm.entrypoints.api_server"]，args: ["--model", "/app/models/qwen1.5-0.5b-chat", "--dtype", "auto"]。

这样既保证环境一致，又避免挂载卷的权限问题（Linux下/models挂载常因SELinux导致Permission Denied）。

4. 生产级实操手册：从零搭建一个可运维的LLM推理平台

4.1 环境准备：GPU服务器不是“装好驱动就行”，而是精密仪器校准

别跳过这一步。我们曾因一台服务器的nvidia-smi显示正常，但vLLM启动失败，折腾两天才发现是PCIe带宽问题。LLM推理对GPU-CPU通信带宽极度敏感，尤其多卡场景。

必做检查清单：

• PCIe拓扑验证：lspci -tv查看GPU是否直连CPU，避免经过PCIe switch。理想拓扑：CPU0 -- PCIe x16 --> GPU0，CPU0 -- PCIe x16 --> GPU1。如果显示PCI bridge --> GPU，带宽可能被砍半。
• CUDA可见性测试：CUDA_VISIBLE_DEVICES=0,1 python -c "import torch; print(torch.cuda.device_count())"必须输出2。曾遇过BIOS里PCIe ASPM设置为L1，导致第二张卡被系统忽略。
• 显存ECC状态：nvidia-smi -e 0临时关闭ECC（生产环境应开启，但调试时关闭可排除ECC纠错导致的延迟抖动）。vLLM对ECC非常敏感，开启状态下某些kernel会降频。
• NVLink带宽：nvidia-smi nvlink -s检查NVLink速率。A100 NVLink带宽600GB/s，若显示0 GB/s，说明NVLink未启用或线缆松动——这对多卡all-reduce至关重要。

我们给每台GPU服务器部署一个gpu-health-check.sh脚本，每次重启后自动运行，失败则发钉钉告警。这不是过度工程，而是LLM平台的基石。就像你不会在地震带上建核电站，同样不能在PCIe带宽不达标的机器上跑vLLM。

4.2 模型注册与部署：不是docker run，而是声明式交付

我们抛弃了所有手动docker run命令，全部转为K8s声明式部署。核心是三个YAML文件：

1. Model CRD（Custom Resource Definition）
定义模型元数据：

apiVersion: ai.example.com/v1 kind: LLMModel metadata: name: qwen1.5-0.5b-chat spec: modelPath: "qwen1.5-0.5b-chat" contextLength: 32768 quantization: "awq" license: "apache-2.0" sla: p95LatencyMs: 800 throughputRps: 50

2. Deployment模板
用Kustomize生成具体Deployment：

apiVersion: apps/v1 kind: Deployment metadata: name: qwen1.5-0.5b-chat spec: replicas: 2 template: spec: containers: - name: vllm image: registry.example.com/qwen-vllm:0.5b-v1 args: - "--model" - "/app/models/qwen1.5-0.5b-chat" - "--max-num-seqs" - "20" - "--block-size" - "32" resources: limits: nvidia.com/gpu: "1" requests: nvidia.com/gpu: "1"

3. Service与Ingress
统一入口：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: llm-gateway spec: rules: - host: llm-api.example.com http: paths: - path: /v1/chat/completions pathType: Prefix backend: service: name: qwen1.5-0.5b-chat port: number: 8000

这套流程的好处：模型上线只需kubectl apply -f model-qwen.yaml，平台自动完成镜像拉取、Pod调度、健康检查、流量接入。下线时kubectl delete llmmodel qwen1.5-0.5b-chat，自动触发滚动删除。比写shell脚本可靠100倍。

4.3 监控告警体系：不只看GPU利用率，要看LLM特有的“生命体征”

传统监控看gpu_utilization>90%就告警，但这对LLM毫无意义。Qwen在生成时GPU利用率常达95%，这是健康状态；反而是利用率突然掉到30%且num_waiting_seqs飙升，才预示scheduler卡死。

我们定义的LLM核心指标：

• llm_scheduler_queue_length：等待队列长度，>50持续1分钟告警（说明请求积压）
• llm_kv_cache_fragmentation_ratio：KV Cache碎片率，>25%告警（nvidia-smi dmon -s u的replay指标换算）
• llm_request_cancel_rate：取消率，>5%告警（说明用户体验差或前端bug）
• llm_output_token_per_second：实际输出token速度，低于SLA的70%告警（比如SLA要求20 token/s，实测<14就告警）

告警策略不是简单阈值，而是复合条件：

• P1告警（立即响应）：llm_scheduler_queue_length > 100 AND llm_gpu_utilization < 40%→ 99%是scheduler deadlock，需立刻kubectl exec进Pod查/stats；
• P2告警（2小时内处理）：llm_kv_cache_fragmentation_ratio > 30% AND llm_p95_latency_ms > 2000→ 需调整--block-size或重启Pod；
• P3告警（日常优化）：llm_request_cancel_rate > 8%→ 分析前端日志，优化UI交互。

这套监控让我们把MTTR（平均修复时间）从47分钟降到8分钟。关键是：指标必须反映LLM的本质行为，而不是通用硬件状态。

4.4 故障排查实战：从“vLLM挂了”到精准定位的黄金15分钟

当告警响起，不要慌。按这个顺序查，90%问题15分钟内定位：

第1-3分钟：确认现象

• kubectl get pods -n llm：看Pod是否CrashLoopBackOff？如果是，kubectl logs -n llm qwen-xxxxx --previous看上一轮日志；
• curl -v http://llm-api.example.com/health：返回{"healthy": true}？否则是网关或Service问题；
• curl http://llm-api.example.com/metrics | grep llm_request_total：指标是否在增长？不增长说明流量没进来。

第4-8分钟：深入vLLM内部

• kubectl exec -it qwen-xxxxx -- curl http://localhost:8000/stats：看num_running_seqs、num_swapped_seqs、gpu_cache_usage_perc。如果gpu_cache_usage_perc接近100%且num_waiting_seqs高，是显存不足；如果num_running_seqs为0但num_waiting_seqs高，是scheduler卡死。

第9-12分钟：检查CUDA与GPU

• kubectl exec -it qwen-xxxxx -- nvidia-smi：看GPU温度、显存占用、compute mode；
• kubectl exec -it qwen-xxxxx -- nvidia-smi dmon -s um -d 1 -c 5：看replay是否暴增（>1000/s）；
• kubectl exec -it qwen-xxxxx -- python -c "import torch; print(torch.cuda.memory_summary())"：看CUDA内存分配详情。

第13-15分钟：决策与执行

• 显存碎片：kubectl rollout restart deployment/qwen1.5-0.5b-chat；
• scheduler卡死：kubectl delete pod qwen-xxxxx（vLLM会自动重建）；
• 模型bug：回滚到上一版镜像kubectl set image deployment/qwen1.5-0.5b-chat vllm=registry.example.com/qwen-vllm:0.5b-v0。

我们把这个流程做成SOP卡片贴在工位，新同事入职三天就能独立处理90%故障。记住：LLM故障不是玄学，是可复现、可测量、可归因的工程问题。

5. 常见问题与避坑指南：那些文档里不会写的血泪经验

5.1 “Ollama部署模型后如何可视化”——别被误导，Ollama不是生产方案

搜索热词里“ollma部署模型后如何可视化”高频出现，但必须泼冷水：Ollama是开发玩具，不是生产框架。它用llama.cpp后端，CPU推理为主，GPU支持弱（仅CUDA 11.x），且没有真正的并发控制。我们试过用Ollama跑Qwen1.5-0.5B，单请求延迟1.2秒，10并发就OOM——而vLLM同配置下延迟0.3秒，100并发稳如泰山。

可视化需求本质是“想看模型在干什么”。正确解法是：

• 用vLLM的/metrics+ Prometheus + Grafana，画出llm_request_duration_seconds_bucket直方图；
• 用OpenTelemetry导出span，用Jaeger看单个请求的token生成耗时分布；
• 自研一个/debug/trace接口，输入request_id返回该请求的完整KV Cache生命周期日志。

Ollama的web UI只是个demo，真要可视化，得用专业可观测性工具。别被“一键部署”忽悠，生产环境里，每毫秒延迟都算钱。

5.2 “vLLM部署DeepSeek，哪个版本镜像”——版本选择不是跟风，而是CUDA对齐

“glm5.3 使用vLLM哪个版本的镜像”这类问题，核心不是vLLM版本，而是CUDA Toolkit与GPU驱动的三角匹配。vLLM 0.27.1要求CUDA 12.1，但你的A100驱动可能只支持CUDA 12.2。强行用0.27.1会报错undefined symbol: __cudaRegisterFatBinaryEnd。

我们的版本决策树：

• 查nvidia-smi输出的Driver Version；
• 查NVIDIA官网《CUDA Compatibility Guide》，找到对应CUDA Toolkit版本；
• 查vLLM GitHub Releases，找基于该CUDA版本的tag（比如CUDA 12.2对应vLLM 0.26.0）；
• 再看该vLLM版本是否支持你要的模型（DeepSeek-V2在0.26.0+才支持）。

别信“最新版最好”，vLLM 0.28.0虽新，但对AWQ量化支持有bug，我们退回0.26.0。生产环境，稳定压倒一切。

5.3 “Docker部署vLLM模型教程”——挂载卷的权限地狱，这样破

新手常卡在Permission denied。根本原因是：vLLM容器以非root用户（UID 1001）运行，而宿主机/models目录属主是root。docker run -v /models:/models时，容器内UID 1001无权读取root文件。

正确解法只有两个：

• 方案A（推荐）：构建镜像时COPY模型，避免挂载。Dockerfile里RUN chown -R 1001:1001 /app/models；
• 方案B：宿主机chown -R 1001:1001 /models，再docker run --user 1001:1001。

别用--privileged或--user root，这是安全红线。我们曾因--privileged被安全团队勒令下线，代价是重做所有CI/CD流水线。

5.4 “LLM Wiki知识库”——别造轮子，用现有本体框架

“llm wiki知识库”“llm ontology”这些词，本质是想给模型加结构化知识。但自己从零设计本体（ontology）是巨坑。我们试过用OWL定义医疗本体，三个月只覆盖了10%常见病，而业务方要的是“明天就能用”。

正确姿势是：

• 用Wikidata或UMLS作为基础本体，它们已覆盖百万级概念；
• 用RAG框架（LlamaIndex）对接，把Wiki dump转成vector store；
• 在vLLM的--enable-lora基础上，加一层Prompt Router：当用户问“高血压用药”，Router识别意图，自动注入UMLS中C0020538（Hypertension）的关联知识片段。

这样既利用了成熟本体，又保持LLM的灵活性。自己造本体，不如优化Prompt Engineering。

6. 经验总结：LLM推理平台不是终点，而是AI工程化的起点

写完这篇，我翻出三年前的笔记，那时我们为部署一个BERT模型写了27页SOP，现在vLLM一行命令搞定。技术在进化，但核心矛盾没变：算法的不确定性 vs 工程的确定性要求。LLM推理平台的价值，不在于它多酷炫，而在于它把这种矛盾压缩到可控范围内——让算法同学专注模型效果，让运维同学不用半夜爬起来杀进程，让业务方相信“今天能用，明天还能用”。

最后分享一个真实案例：某银行用我们的平台上线“智能尽调助手”，初期日均调用量2000次。三个月后，业务方自己用低代码平台搭了12个新场景，调用量涨到15万次/日。他们没找我们改一行代码，因为所有模型注册、流量分配、监控告警都通过UI自助完成。那一刻我才明白，所谓“LLM推理平台”，终极目标不是技术多先进，而是让AI能力像水电一样，无声无息流进业务毛细血管。

这条路没有银弹，只有一个个填平的坑。希望这篇内容，能帮你少踩几个。