企业官网建设流程全解析

这次我们看一个比较特别的方向：vLLM-iOS。从项目标题看，这套方案的目标很直接——把 vLLM 的推理加速能力带到 iOS 端，再针对 Multi-Agent 场景做调度优化，宣称可以把多智能体推理延迟压掉 88%。先别急着信这个数字，更值得关注的是“能不能复现”“怎么部署”“适合哪类应用”。这类问题如果不在动手前摸清楚，后面大概率会卡在环境、显存和接口三个地方。

先说一个容易误解的点。vLLM 本身是典型的数据中心推理框架，核心是 PagedAttention、Continuous Batching 和 OpenAI 兼容 API，正常情况下跑在 Linux + CUDA 环境里。iOS 端要想用它，通常不是把 vLLM 源码直接塞进 App，而是走两条路：一条是 iOS 客户端通过网络访问远端 vLLM 服务，另一条是在设备端用 Core ML / Metal 做推理，由一层中间逻辑处理多 Agent 的调度和上下文复用。从项目标题的定位看，vLLM-iOS 更像是在这两条路径之上，专门为多智能体任务做“推理编排 + 加速”的方案。

这篇文章会围绕这个方向，拆解四件事：第一，这个项目到底能解决什么问题、适用边界在哪；第二，本地部署时该准备哪些环境和硬件；第三，从单 Agent 到多 Agent 的完整功能测试怎么设计；第四，接口 API、批量任务、性能观察和排错方法。文章里给出的命令和代码，一部分是通用 vLLM 用法，一部分是 iOS 端接入的示例模板，具体实现要以你拿到的 vLLM-iOS 版本为准。

1. 核心能力速览

需要注意，上表中的“快速推理”“批量任务”是 vLLM 体系本就具备的能力，但 vLLM-iOS 具体实现了哪一层、是否原生支持设备端推理，取决于项目源码和文档。没有 Material 支撑的细节，不要默认它一定存在。

1.1 能力项细节说明

第一，多智能体推理的加速空间通常来自三个部分：重复的 system prompt、长历史上下文的重复 KV 计算、多个 Agent 请求造成的排队等待。vLLM-iOS 如果围绕这三处做优化，88% 的提速并非不可能，但前提是测试基准里包含了大量“共享上下文”的多 Agent 任务。

第二，这个项目最容易被误解的地方是“iOS 端跑 vLLM”。技术上更稳妥的判断是：iOS 作为边缘客户端，远端跑 vLLM 服务，中间由 Agent 调度层做请求合并和结果分发。即便项目支持端侧推理，常见的做法也是把模型量化为 Core ML 格式，再通过 Metal 执行，而不是直接复用 vLLM 的 CUDA 内核。

第三，批量任务和多 Agent 是高度相关的。一个 Agent 在一次任务中可能需要多次调用模型，例如“先调用工具，再根据工具结果总结”，这些调用在服务端看就是多个推理请求。如果调度层能把这些请求合并进同一个 batch，同时复用系统提示词的 Prefix Cache，那么端到端延迟会有明显下降。

2. 适用场景与使用边界

2.1 适合谁用

• iOS App 开发工程师：正在做智能助手、聊天机器人、Agent 类应用，需要稳定接入大模型推理服务。
• 大模型应用工程师：需要把 vLLM 的并发推理能力开放给移动端，并处理多 Agent 调度。
• Multi-Agent 研究者与开发者：本地需要一套可复现的多智能体并发推理测试环境，验证加速效果。
• 端云协同项目团队：模型部分放服务端、业务和控制逻辑放 iOS 端，希望降低请求延迟和流量成本。

2.2 能解决什么问题

• 多个 Agent 并发调用大模型时，服务端排队导致的高延迟。
• 多 Agent 共享相同 system prompt / 工具定义时，重复计算带来的额外开销。
• iOS 端直接请求大模型接口时，缺少批量策略、重试逻辑和上下文管理，导致交互卡顿。
• 从“Demo 能跑”到“线上真机稳定运行”之间缺少的工程化能力。

2.3 不适合什么场景

• 需要最大化隐私保护的场景：用户敏感数据不应上传到远端 vLLM 服务，应优先考虑端侧推理或数据脱敏。
• 无 GPU 环境的小规模测试：纯 CPU 跑大模型也能出结果，但延迟和吞吐未必能体现“88% 加速”的效果。
• 需要离线运行的场景：如果网络不可用，远端 vLLM 方案直接失效，必须转端侧 Core ML 方案。
• 对延迟要求到毫秒级的实时控制任务：端侧模型量化后精度下降，服务端网络 RTT 又无法忽略。

2.4 合规与安全边界

无论是远端 vLLM 还是 iOS 端侧推理，只要涉及大模型生成，就必须注意：

• 模型授权：确认模型权重和项目代码的开源协议是否允许商用和二次分发。
• 数据隐私：iOS 端涉及个人数据的请求建议走 HTTPS，并明确数据是否会被服务端记录。
• 用户授权：如果 Agent 涉及人脸、声音、照片、通讯录等敏感信息，必须在采集和上传前取得明确授权。
• 版权合规：多智能体任务中的工具调用、文档解析、图像生成都不得绕过版权保护，也不要用于生成违规内容。
• 苹果审核要求：App 内集成模型推理和远程 API 时，需要遵守 App Store 关于隐私标签、数据收集和使用说明的规定。

3. 技术背景：vLLM、iOS 推理与 Multi-Agent 有什么关系

3.1 vLLM 给多智能体推理提供了什么

vLLM 的核心不只是一个推理引擎，它还提供了三种对 Multi-Agent 场景非常有用的能力：

• PagedAttention：把 KV Cache 切成小块按需分配，多个 Agent 的长对话可以更高效地占用显存。
• Continuous Batching：模型不用等一个 batch 全部结束再处理下一个，而是动态插队，这对多个 Agent 交替发出请求的场景非常友好。
• Prefix Caching：当多个 Agent 共享相同前缀（例如同样的系统提示词、工具定义）时，前缀部分的 KV Cache 可以复用，直接省掉重复计算。

所以 vLLM-iOS 如果真的是围绕“iOS 多智能体推理加速”做文章，那么底层大概率是在利用 vLLM 的这些机制，把多 Agent 请求合并到同一个服务实例，减少重复计算。

3.2 iOS 端大模型推理的常用路径

iOS 上跑大模型，业界常用的方案有四种：

1. 远端 API：iOS 通过URLSession请求 OpenAI 兼容接口，模型在服务端运行。
2. Core ML：将 PyTorch 模型转为.mlpackage，使用MLModel和MLModelLoader在设备端运行。
3. Metal Performance Shaders：基于 GPU 做高性能计算，适合自研推理层。
4. llama.cpp / MLX：社区方案，可以在 Apple Silicon 设备上运行量化模型，内存占用相对可控。

从项目标题看，vLLM-iOS 的“iOS 端”部分大概率属于第一种或第四种形态，前端的多 Agent 调度层负责把任务拆解成若干模型调用，然后交给远端服务或本地推理引擎执行。

3.3 Multi-Agent 推理为什么慢

一个多 Agent 任务通常包含多次模型调用。例如：

用户提问 -> Agent A 解析意图 -> Agent A 调用搜索工具 -> Agent B 阅读搜索结果并总结 -> Agent C 生成最终回复

这个过程中，每个 Agent 都携带相似的 system prompt、工具描述和会话历史。如果每次调用都从头计算 KV Cache，等到模型真正开始生成时，输入部分的计算已经占了大量时间。多 Agent 并发时，还会因为请求排队进一步放大延迟。vLLM-iOS 这类方案的价值，就是用批处理、前缀缓存和请求调度来压掉这部分浪费。

4. 部署架构与前置条件

4.1 推荐部署架构

从工程可落地角度看，推荐的架构如下：

iOS App / 多 Agent 调度层 | | HTTPS / WebSocket v vLLM 服务端（OpenAI 兼容 API） | | CUDA v GPU 推理实例（7B / 14B / 72B 根据显存选择）

在这个架构里，iOS 端不直接管理模型权重，而是由调度层负责：

• 多 Agent 请求的分组和优先级排序；
• 共享 system prompt 的裁剪与复用；
• 对 vLLM 返回结果做流式处理和错误重试。

如果你更关心离线推理，则把远端服务换成 Core ML 本地推理，架构变成：

iOS App / 多 Agent 调度层 | | Core ML / Metal v 本机量化模型（.mlpackage）

但端侧推理能跑的模型规模有限，通常以 3B、7B 量化模型为主，显存和内存压力也更大。建议第一阶段优先跑远端 vLLM，先把链路和效果验证清楚，再评估端侧方案。

4.2 远端 vLLM 服务端环境清单

4.3 iOS 端环境清单

4.4 端口与防火墙准备

vLLM 服务默认监听8000端口。如果本机端口被占用，启动时需要加--port参数。iOS 设备访问远程服务时，还要确认防火墙没有拦截8000端口，否则请求会直接超时。

# 查看端口占用 ss -lntp | grep 8000 # 或者 lsof -i :8000

如果遇到端口冲突，启动 vLLM 时换一个端口即可：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/your-model \ --port 8010

5. 安装部署与启动方式

5.1 服务端安装 vLLM

以下命令是 vLLM 服务端的通用部署方式，vLLM-iOS 的远端服务部分可以直接复用。

# 创建 Python 虚拟环境（建议） python3 -m venv vllm-env source vllm-env/bin/activate # 安装 vLLM，CPU 版与 GPU 版安装方式不同，务必参考官方文档 pip install vllm

安装后可以先启动一个轻量模型验证依赖：

python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --dtype half \ --gpu-memory-utilization 0.6 \ --port 8000

注意：Qwen/Qwen2.5-7B-Instruct只是示例，实际模型名称和路径要根据你能拿到的权重替换。启动日志出现Uvicorn running on http://0.0.0.0:8000即表示服务端正常。

5.2 iOS 端接入远端 vLLM 服务

iOS 端用URLSession请求远端 vLLM 服务，是最通用的接入方式。下面是一个简单的 Swift 调用示例，适用于 OpenAI 兼容的/v1/chat/completions接口：

import Foundation func sendChatRequest(prompt: String, baseURL: String) async throws -> String { let url = URL(string: baseURL + "/v1/chat/completions")! var request = URLRequest(url: url) request.httpMethod = "POST" request.setValue("application/json", forHTTPHeaderField: "Content-Type") // 如果服务端开了鉴权，需要加上 Authorization 头 request.setValue("Bearer YOUR_API_KEY", forHTTPHeaderField: "Authorization") let body: [String: Any] = [ "model": "Qwen/Qwen2.5-7B-Instruct", "messages": [ ["role": "system", "content": "You are a helpful assistant."], ["role": "user", "content": prompt] ], "max_tokens": 512, "stream": false ] request.httpBody = try JSONSerialization.data(withJSONObject: body) let (data, response) = try await URLSession.shared.data(for: request) guard let httpResponse = response as? HTTPURLResponse, httpResponse.statusCode == 200 else { throw URLError(.badServerResponse) } let json = try JSONSerialization.jsonObject(with: data) as? [String: Any] let choices = json?["choices"] as? [[String: Any]] let message = choices?.first?["message"] as? [String: Any] return message?["content"] as? String ?? "" }

这段代码是通用示例，生产环境还需要补充：超时控制、错误处理、流式解析和取消机制。

5.3 端侧 Core ML 推理流程

如果 vLLM-iOS 支持端侧推理，一种可行的转换路径是：

1. 用 Python 把 PyTorch 模型转换成 Core ML 格式；
2. 将生成的.mlpackage打包进 iOS App；
3. 在 App 内通过MLModel加载并执行推理。

转换模型属于通用流程，不同模型的转换脚本差异很大，这里只给模板：

# 通用示例，实际参数需要按模型和工具链版本调整 python convert_llm_to_coreml.py \ --model-id Qwen/Qwen2.5-7B-Instruct \ --output-dir ./output_mlpackage

端侧推理的优势是离线可用、数据不出设备；劣势是模型大小、内存占用、推理速度都受设备限制。如果你没有拿到 vLLM-iOS 的端侧 SDK，建议暂时不要投入端侧路线，先把远端路径跑通。

6. 功能测试与效果验证

6.1 测试目标

验证 vLLM-iOS 方案是否真的能完成多智能体推理，并且观察在单 Agent 和 Multi-Agent 场景下的延迟差异。建议把测试分为三层：

1. 接口层：远端 vLLM 服务是否正常响应，返回内容是否符合 OpenAI 格式。
2. 多智能体调度层：多个 Agent 任务的上下文是否按预期传递，工具结果是否正确注入。
3. 性能层：对比单 Agent 和多 Agent 场景下的首 Token 延迟、端到端延迟和 Tokens/s。

6.2 单 Agent 基线测试

先用最简单的方式确认链路，不涉及多智能体调度。

import requests url = "http://127.0.0.1:8000/v1/chat/completions" payload = { "model": "Qwen/Qwen2.5-7B-Instruct", "messages": [ {"role": "system", "content": "You are a concise assistant."}, {"role": "user", "content": "用一句话介绍 Multi-Agent 推理。"} ], "max_tokens": 128, "stream": False } response = requests.post(url, json=payload, timeout=60) print(response.status_code) print(response.json())

预期结果：status_code为 200，返回体中包含choices[0].message.content，且包含usage.prompt_tokens和usage.completion_tokens。这一步通过后，说明 vLLM 服务端没问顾，iOS 端接入才有意义。

6.3 多智能体工具调用测试

多 Agent 测试的核心是验证“工具结果能否被正确拼接到下一轮上下文”，以及“多轮调用是否有明显重复计算”。

下面用 Python 模拟一个简单流程：先由“规划 Agent”决定调用天气工具，再把工具结果交给“总结 Agent”生成回复。

import requests import json base_url = "http://127.0.0.1:8000/v1/chat/completions" headers = {"Content-Type": "application/json"} system_prompt = "你是一个旅游助手，负责规划行程。" plan_payload = { "model": "Qwen/Qwen2.5-7B-Instruct", "messages": [ {"role": "system", "content": system_prompt}, {"role": "user", "content": "北京明天适合户外活动吗？"} ], "max_tokens": 128 } plan_response = requests.post(base_url, json=plan_payload, headers=headers, timeout=60).json() plan_content = plan_response["choices"][0]["message"]["content"] # 模拟工具返回结果 tool_result = "北京明天晴，温度5-15度，西北风3级，阳光充足。" final_payload = { "model": "Qwen/Qwen2.5-7B-Instruct", "messages": [ {"role": "system", "content": system_prompt}, {"role": "assistant", "content": plan_content}, {"role": "tool", "name": "weather", "content": tool_result}, {"role": "user", "content": "请基于工具结果给出最终建议。"} ], "max_tokens": 256 } final_response = requests.post(base_url, json=final_payload, headers=headers, timeout=60).json() print(json.dumps(final_response, ensure_ascii=False, indent=2))

这里要注意，vLLM 的 OpenAI 兼容接口对/v1/chat/completions中tool角色消息的处理版本各不相同，如果你的 vLLM 版本不识别tool角色，可以把工具结果合并到user消息里，先保证链路是通的。

6.4 并发多 Agent 批量测试

要验证 88% 的加速效果，必须做并发测试。多 Agent 场景下常见的方式是让多个 Agent 同时发起独立请求，并记录整体完成时间。

import requests import time import concurrent.futures url = "http://127.0.0.1:8000/v1/chat/completions" def send_agent_call(agent_id): payload = { "model": "Qwen/Qwen2.5-7B-Instruct", "messages": [ {"role": "system", "content": "你是多个独立智能体之一，请分别回答用户问题。"}, {"role": "user", "content": f"Task for agent {agent_id}: 用一句话总结你的职责。"} ], "max_tokens": 64 } start = time.time() resp = requests.post(url, json=payload, timeout=120) elapsed = time.time() - start return agent_id, elapsed, resp.status_code agents = list(range(8)) # 模拟 8 个 Agent 并发请求 with concurrent.futures.ThreadPoolExecutor(max_workers=8) as executor: results = list(executor.map(send_agent_call, agents)) for result in results: print(f"Agent {result[0]}: {result[1]:.2f}s, status={result[2]}")

判断标准：

• 所有请求都返回200；
• 单个请求平均延迟没有因为并发而线性恶化；
• 如果服务端开启了 Continuous Batching，多个 Agent 请求的整体完成时间应明显低于串行执行时间。

6.5 判断成功与失败

7. 接口 API 与批量任务

7.1 OpenAI 兼容接口位置

vLLM 服务端默认提供三个关键接口：

7.2 curl 调用示例

curl http://127.0.0.1:8000/v1/models

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "Qwen/Qwen2.5-7B-Instruct", "messages": [ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Hello!"} ], "max_tokens": 128 }'

7.3 批量任务与失败重试建议

多 Agent 场景的批量任务建议采用“输入目录 + 任务清单 + 结果目录”的结构：

agent_tasks/ task_001.json task_002.json ... outputs/ result_001.json result_002.json

每个任务文件记录agent_id、session_id、messages和max_tokens。批量任务脚本只需遍历目录，将每个任务发送到 vLLM 服务，并把结果写回输出目录。

批量任务要注意三个问题：

1. 失败重试：单次请求超时不能直接放弃，建议做 3 次重试，每次重试间隔递增。
2. 限流：并发数不要一次性拉满，建议从 4 到 8 个并发开始，观察显存和响应时间再调。
3. 结果追踪：每个任务的响应要绑定session_id，方便后续分析是哪一步失败。

下面是批量任务脚本的通用模板：

import requests import json import time import os base_url = "http://127.0.0.1:8000/v1/chat/completions" task_dir = "agent_tasks" output_dir = "outputs" max_retries = 3 os.makedirs(output_dir, exist_ok=True) def process_task(task_file): with open(os.path.join(task_dir, task_file), "r", encoding="utf-8") as f: task = json.load(f) payload = { "model": task.get("model", "Qwen/Qwen2.5-7B-Instruct"), "messages": task["messages"], "max_tokens": task.get("max_tokens", 512) } for attempt in range(max_retries): try: resp = requests.post(base_url, json=payload, timeout=120) resp.raise_for_status() result = resp.json() output_path = os.path.join(output_dir, task_file.replace(".json", "_result.json")) with open(output_path, "w", encoding="utf-8") as f: json.dump(result, f, ensure_ascii=False, indent=2) return task_file, True, result.get("usage", {}) except Exception as e: if attempt == max_retries - 1: return task_file, False, str(e) time.sleep(2 ** attempt) for task_file in os.listdir(task_dir): if not task_file.endswith(".json"): continue print(process_task(task_file))

7.4 iOS 端批量任务设计

iOS 端一般不适合在后台无限循环跑批量任务，更合理的做法是：

• 把批量任务列表放在服务端或云端队列；
• iOS 端一次只请求一个任务；
• 多 Agent 并发逻辑放在服务端调度层，而不是让 App 同时开大量请求。

这样既能减少设备电量消耗，也能避免 iOS 后台线程被系统回收导致任务中断。

8. 资源占用与性能观察

8.1 如何观察显存与推理延迟

服务端性能观察是验证 vLLM-iOS 效果的关键。即使 vLLM-iOS 本身不做性能监控，你仍然需要通过以下方式收集指标：

8.2 影响性能的关键因素

• 模型大小：7B 量化模型和 70B 全精度模型的推理延迟差异极大，88% 的加速比例只对同一模型同一硬件有意义。
• 上下文长度：多 Agent 场景下，重复的 system prompt 越长，Prefix Caching 的收益越明显；但如果前缀不一致，缓存无法命中，延迟会上升。
• 并发批大小：vLLM 的 Continuous Batching 在适中的并发下收益最大，并发过低或过高都会影响吞吐。
• 量化精度：AWQ/GPTQ 量化模型占用显存更低，推理更快，但生成质量可能有轻微下降。
• 网络 RTT：iOS 到服务端的距离不能忽略，局域网测试和公网测试的延迟差异可能超过模型推理耗时。
• 流式与整段返回：流式返回可以大幅改善用户体感，但对整体吞吐优化帮助有限。

8.3 降低显存占用的常用方法

如果服务端显存不足，可以先尝试以下调整：

# 降低显存利用率上限，给其他进程预留空间 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your-model \ --dtype half \ --gpu-memory-utilization 0.5

# 关闭前台自动过程，减少额外显存开销，具体效果以 vLLM 版本为准 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your-model \ --enforce-eager

注意，--enforce-eager会关闭 CUDA Graph 优化，显存占用可能下降，但推理速度也可能下降。这是“用速度换显存”的选项，不是默认最优解。

8.4 iOS 端资源观察

iOS 端接入远端 vLLM 时，资源消耗主要不在模型推理，而在网络请求和 JSON 解析。多 Agent 场景如果频繁发送大体积上下文，App 内存会被 JSON 序列化数据占住，建议：

• 对历史消息做裁剪，只保留最近 N 轮对话；
• 使用URLSession的流式解析或增量解析，不要一次性加载全部响应；
• 在真机上用 Instruments 的 Memory 面板观察内存曲线，确认没有无限增长。

9. 常见问题与排查方法

9.1 一个重要的排查思路

遇到问题先别急着找人问，按照下面顺序排查：

1. 确认服务端能访问：curl http://127.0.0.1:8000/v1/models；
2. 确认 iOS 设备能访问服务端：用 Safari 访问同一个接口；
3. 确认请求体格式正确：对比 OpenAI 官方格式；
4. 确认错误发生在服务端还是客户端：看 vLLM 日志和 Xcode 控制台日志；
5. 最后再考虑是不是 vLLM-iOS 调度层的问题。

大多数多 Agent 链路问题都出在“工具消息格式不一致”和“上下文过长”，而不是项目本身无法运行。

10. 最佳实践与使用建议

10.1 先小后大，分阶段验证

第一次部署不要直接上一个大模型。建议先用 3B 或 7B 规模的模型把链路跑通，确认服务端、iOS 端和多 Agent 调度三个环节正常，再切换到目标模型。这样可以避免“模型太大导致显存不足”和“代码逻辑错误”两种问题混在一起，排查难度会小很多。

10.2 为多 Agent 请求设计统一上下文模板

多 Agent 场景最值得优化的地方，是让多个 Agent 共享相同的前缀。建议设计一份统一的上下文模板：

[系统提示词] 你是团队中的 {role}。 团队目标：{goal} 你可以使用的工具：{tools} 当前用户问题：{question}

这样当多个 Agent 发送请求时，前缀部分是相同的，vLLM 的 Prefix Caching 才能发挥最大作用。如果你每个 Agent 都生成一套完全不同的 system prompt，缓存命中率会很低，88% 的加速效果基本无法复现。

10.3 批量任务必须加日志和失败重试

批量任务不是“一次性跑完就行”，要保证可回溯。建议在每个任务输出文件中记录：

• 任务 ID；
• 请求时间、完成时间；
• 重试次数；
• 消耗的 prompt_tokens 和 completion_tokens；
• 最终返回状态。

有一个完整的输出文件，才能准确判断是模型生成质量的问题，还是调度逻辑的问题。

10.4 接口服务要限制访问范围

vLLM 服务默认没有鉴权，直接暴露在公网非常危险。生产环境至少做两层：

• 在服务前面加 API Key 校验；
• 使用 HTTPS，避免明文传输用户请求。

开发阶段也建议把服务绑定到局域网，避免被外部网络扫描。

10.5 数据合规要提前设计

多 Agent 任务中，Agent 可能会读取通讯录、相册、地理位置等敏感信息。这些数据如果发送到远端 vLLM 服务，必须提前告知用户并获得授权。最稳妥的做法是：敏感数据在 iOS 端处理，只有脱敏后的文本才发送到服务端。

10.6 发布前先做效果复核

大模型生成结果有随机性，多 Agent 任务尤其容易出现“上一个 Agent 的结果污染下一个 Agent 的输入”的情况。建议在正式版本发布前，准备一组固定的测试用例，覆盖正常输入、边界输入和非法输入，每次改动代码后都跑一遍回归测试。

11. 总结

vLLM-iOS 这个方向最值得尝试的地方，不是“iOS 跑 vLLM”这个说法本身，而是它把 vLLM 的服务端加速能力和 iOS 的多智能体调度问题结合到了一起。如果你正在做 iOS 智能助手或多 Agent 类应用，先用“远端 vLLM + iOS 客户端 + 统一上下文模板”这套架构跑通，再逐步验证并发批量、Prefix Caching 和端侧推理，是比较稳的路线。

最先应该验证的功能，是单 Agent 请求能否通过 iOS 设备成功打到 vLLM 服务；最容易踩的坑也在这里——端口不通、ATS 拦截、消息格式不兼容，都会让链路卡在第一步。跑通之后，再去测多 Agent 并发、批量任务和 88% 加速的复现条件。

后续可以继续扩展的方向包括：把上下文管理从客户端挪到服务端、为不同 Agent 设计独立的缓存前缀、引入更细粒度的流式反馈、以及评估 Core ML 端侧模型是否可以承接部分低延迟任务。建议先把这套链路保存成一套可复现的测试脚本，之后换模型、换设备、换网络环境都能快速对比效果。