昨天帮甲方升级了一下本地的老模型,因为本人并不是从事运维工作,只是临时补坑,还是浪费了点时间.现在回头做个梳理,希望佬友们在用得到的时候也有个参考(感觉都比较基础,专业的大佬可以跳过不看) 模型下载: 国内环境推荐直接使用 modelscope 下载,如果是内网环境的话,可以下载完再上传到服务器.这里重点关注2个地方 模型选择 一般来说我们首先考虑显存大小,先本地使用nvidia-smi,查看本机显存 非量化模型可以有个简单的公式:显存 ≈ 参数量 × 2 ,然后基本上要留1/4以上余量提供给上下文kv cache,当然你如果已经安装完发现显存不够,可以通过量化参数–quantization降低显存要求 PS.这台服务器真让人流口水啊,也不用担心装不下的问题 模型对应的配置要求: 注意仔细阅读模型的介绍页 会有推荐的显卡,如果你的显卡等级比推荐的低,大概率就是装不了 在安装方式那里,我们会看到要求的版本,现在好像vllm部署比较多,所以我们进入模型页面对应的vllm安装方式会看到 这里就有第一个踩坑的点: 虽然他标注的vllm>=0.19.0,但是我建议你就安装对应的版本 .我昨天按文档上的安装了最新vllm版本运行后又会出现版本兼容问题,浪费了不少时间调版本(也不知道是不是vllm高版本不向下兼容的问题,反正vllm里提示transformers版本不对,然后我就问哈基米解决方案,来回升降vllm和transformers版本,最后也解决不了,这实际部署行为,大模型可信度有限) 服务器CUDA版本升级 因为服务器是N卡而且现有的服务器CUDA版本太低了,对于要求版本的vllm不兼容,所以第一步先升级cuda. 先查询你要安装的cuda版本,这里我以要装的vllm 0.19.0为例: 安装要求： OS: Linux Python: 3.10 到 3.13 NVIDIA GPU: compute capability >= 7.0 官方依据： vLLM 0.19.0 GPU 安装要求： docs.vllm.ai GPU - vLLM NVIDIA GPU compute capability 官方查询表： NVIDIA Developer NVIDIA CUDA GPU Compute Capability Find the compute capability for your GPU. 这里如果显卡不满足cap的话就只能降vllm版本,装老一点的模型了 然后开始具体安装=> 前置:停掉所有占用显卡的进程,查询指令如下 nvidia-smi --query-compute-apps=pid,name --format=csv,noheader,nounits 如果是systemd启动的话可以在列表中先找到相关的服务 systemctl list-units --type=service --state=running 然后直接kill 或者使用对应的systemctl stop xxxx停止服务和nv manager服务 # 停止 Fabric Manager systemctl unmask nvidia-fabricmanager systemctl stop nvidia-fabricmanager # 查询当前驱动和已安装的 fabricmanager dpkg -l | grep -E 'nvidia-fabricmanager|nvidia-driver' apt-mark showhold | grep -E 'nvidia|cuda' || true # 解除旧 fabricmanager 的 hold 并卸载,我本地的是nvidia-fabricmanager-550 apt-mark unhold nvidia-fabricmanager-550 nvidia-fabricmanager-580 2>/dev/null || true apt purge -y nvidia-fabricmanager-550 nvidia-fabricmanager-580 # 停止所有可能占用 GPU 的持久化服务 systemctl stop nvidia-persistenced 接着去NV官网下载对应的 CUDA Toolkit wget https://developer.download.nvidia.com/compute/cuda/12.9.0/local_installers/cuda_12.9.0_575.51.03_linux.run sh cuda_12.9.0_575.51.03_linux.run 根据提示页面输入’accept’和选择install即可,等待安装完毕 安装完再系统的全局软链接更新指向新版本的 Toolkit mv /usr/local/cuda /usr/local/cuda.bak ln -s /usr/local/cuda-12.9 /usr/local/cuda # 查询 NVIDIA 驱动版本，fabricmanager 要匹配驱动版本，不是 CUDA toolkit 版本 nvidia-smi --query-gpu=driver_version --format=csv,noheader | head -n 1 # 查询 575 server 驱动和 fabricmanager 可用版本 apt update apt-cache policy nvidia-driver-575-server nvidia-fabricmanager-575 apt-cache madison nvidia-driver-575-server apt-cache madison nvidia-fabricmanager-575 # 安装匹配版本的 server driver + fabricmanager apt install -y nvidia-driver-575-server nvidia-fabricmanager-575 # 驱动升级后必须重启 reboot #恢复管理器 systemctl daemon-reload systemctl enable --now nvidia-fabricmanager systemctl start nvidia-fabricmanager systemctl status nvidia-fabricmanager nvidia-smi topo -m 这里 注意装完驱动必须重启服务器 ,然后nvidia-smi 后看到 CUDA Version: 12.9,至此cuda升级完毕 安装升级vllm 因为原先这台机器的vllm并不是我来安装的,所以升级的时候,直接安装一套新的conda做虚拟环境管理 wget https://repo.anaconda.com/archive/Anaconda3-2024.10-1-Linux-x86_64.sh chmod +x Anaconda3-2024.10-1-Linux-x86_64.sh ./Anaconda3-2024.10-1-Linux-x86_64.sh #修改环境变量 echo 'export PATH=~/anaconda3/bin:$PATH' >> ~/.bashrc && source ~/.bashrc conda create -n vllm python=3.10 -y source ~/.bashrc && conda activate vllm #安装模型要求的vllm版本,这里替换了国内源,提高下载速度 pip install vllm==0.19.0 -i https://pypi.tuna.tsinghua.edu.cn/simple 后续就是调试vllm的启动命令了,这基本参照官方文档和问ai都能搞定,无非就是配置几个选项和上下文大小和量化指标那些 6 个帖子 - 4 位参与者 阅读完整话题
第一次开甲骨文服务器，看帖子特别难开，申请了信用卡试试，似乎一次成功了 实时过程： 申请中行visa信用卡，线上申请，线下激活（它这款信用卡限制，必须线下激活） Chrome 隐私模式进入Oracle注册页 注册信息： 邮箱：QQ邮箱 区域：日本东京 手机号：真实86手机号 地址：真实的国内家庭住址，使用英文填写 认证： 填写信用卡号，填写完点击验证立即收到扣款通知 点击关闭信用卡认证窗口，出现传闻的跑道图，等待账户初始化完成 收到邮件通知账户初始化完成 点击右键 Sign in 登录，配置二次认证（这一步不开代理太慢了，实在受不了了，开了代理） 成功进入控制台 小白一个，下一步要建实例，不知道选哪个了， 听说还要升级服务，继续研究下哈哈 12 个帖子 - 7 位参与者 阅读完整话题
6 个帖子 - 4 位参与者 阅读完整话题
各位大佬好，前几天在站内看到有佬提到 GPT 账号需要定时刷新 refresh_token 来保障账号状态，防止失效。出于保险起见，我尝试在 Sub2Api 中对批量账号进行了刷新令牌的操作，结果直接“翻车”了。特此记录一下排查过程和根因，给同样折腾 Sub2Api 和 CPA 的朋友们避个坑。 故障现象 在 Sub2Api 中触发批量刷新后，所有账号均刷新失败，且前端页面没有任何异常提示。 日志排查 通过查询数据库日志，抓取到了关键的报错信息： OpenAI 返回报错 ： Your refresh token has already been used to generate a new access token. Please try signing in again. code = refresh_token_reused Sub2API 记录状态 ： OPENAI_OAUTH_TOKEN_REFRESH_FAILED 、 token_refresh.retry_exhausted 、 token_refresh.account_refresh_failed 、 temp_unschedulable_set 根因分析 根据报错代码 refresh_token_reused ，可以明确判定： 这批 OpenAI OAuth 的 refresh token 已经被使用过或轮换过了。 OpenAI 的 OAuth 机制采用的是“一次性轮换”策略：即每次刷新成功后，服务端会下发一个新的 refresh_token ，而旧的 refresh_token 会立即作废。如果再次使用旧 token 请求，就会报上述错误。 目前 Sub2Api 里大量账号保存的 refresh_token 已经不是最新可用版本。推测原因是：之前刷新时新 token 没有成功落库，或者被并发刷新操作覆盖了。 场景复盘与处置 联想到我的这批账号同时也导出到了 CPA 平台，且目前主用 CPA。极大概率是 CPA 平台在后台触发了刷新机制，导致 token 发生了轮换 。而 Sub2Api 这边依然拿着 CPA 刷新前的“旧 token”去请求，从而引发了批量报错。 ️ 当前止损措施 虽然 Sub2Api 里的账号目前依然可以正常调用（因为 access_token 可能还在有效期内），但为了保险起见，我已经把 Sub2Api 里的这批账号全部 停止调度 了。 希望这波操作不会导致账号被风控或死号。纯经验分享，如果有分析错误的地方，欢迎各位大佬轻喷并指正！ 1 个帖子 - 1 位参与者 阅读完整话题
今天为了注册个 印度尼西亚 WhatsApp 真的折腾到心态爆炸。中午给 HeroSMS、5SIM 和 Grizzly Sms 三个平台分别充了12.65 6.03 20.42(都是最低充值金额)，结果一下午全是在浪费时间。 现在的号源质量简直没法看，都是： 账号被封禁” 请 XX 小时后再试” 请下载官方客户端”（明明就是官方版） 账号已存在 最离谱的是 5SIM，刚拿号还没点发送验证码呢，就莫名其妙跳出一条短信，0.5 刀直接被吞，白白送钱。 忙活一下午，一个号没成，最倒霉的是充值， 银行卡通过支付宝给充值接码网站好像被风控冻结了 ……这波真的是“血亏”。大家最近要接码印尼WhatsApp 的千万慎重，这几个平台目前成功率很低 反正浪费一下午我是一个成功的都没有。 4 个帖子 - 3 位参与者 阅读完整话题
在公司实习也3个多月了，其中出差了一个月，我现在都还在福州出差，但是我又是恋家比较严重的，所以出差久了就会很累很想家。我本身洁癖也很严重，讨厌出差在外的不适感。现在我们组的很多同事都在出差，基本上都会有那种出差好几个月的情况，我现在才出差两个星期我都顶不住了，我感觉我入职之后老板肯定会给我搞一个大的，出差很久的那种，很讨厌出差… 现在我这边还是跟前辈一起出的差，但是因为客户那边情况太复杂了，估计再没一个月根本搞不完，好在我有毕业答辩需要回学校，也算脱离苦海，不过我打算回学校答辩完之后就跟老板提离职，真的受不了出差的活。 我个人情况是应届生，但是是二本，并且vibe coding为主力，各位手搓大佬别笑我，我真是搓不出来，AI出来之前我在学校也是手搓大佬，但是出来之后替代性和效率实太强了，所以我就专研怎么使用AI进行高效开发了。要是我出去找一份不出差的工作，大概率是什么样的？是不是大部分都是单休，上班时间久，而且加班熬夜多啊？不过我也担心我用AI编程会不会有很多公司不接受…不知道该咋办了，心累。 5 个帖子 - 3 位参与者 阅读完整话题
<1> 背景 自动化测试代码维护这行干了挺久，以往基本是在和内部框架打交道，以往工作实属不难，只能说测试以及Debug比较耗时间精力 后来上面也想与时俱进一下，就想着结合AI搞点辅助我们工作的东西，想法是美好的 团队里有一套长期演进的内部工程体系，配置、脚本、规则和经验散在不同地方不同人。 新人要改一个东西，有时要问老同事；老同事也不一定每次都记得准，只能继续翻文件、搜历史、看代码。 于是很自然地想到：那就做一个 AI 知识库吧。 最初的预期很朴素： 把文档、规范、经验整理进去 用户用自然语言提问 系统检索相关知识 大模型组织答案 听起来没毛病，甚至很符合最初大家对 RAG 的想象。 但真正落地后才发现，内部业务知识和互联网公开文档完全不是一回事。 公开文档通常是"解释型"的：这个 API 怎么用、这个参数是什么意思、底层模块解释等。 我们的内部问题更多是"操作型"的：我要改一个现有流程、调整一个规则、关闭一个子项、增加一个步骤、定位一个历史遗留逻辑。 这两类问题看起来都叫问答，但需要的系统能力完全不同。 所以问题不是"能不能用 AI"，而是"怎么让 AI按既定思路来理解"。 本地部署ai以及在vscode基础上做一个自己的业务汇总软件再基于cline改个有基础agent功能的插件，细节不赘述。 <2> 第一阶段：上了 Dify 当时的想法 Dify 嘛： 文档丢进去 切 chunk 做向量 用户问问题，相似度召回 AI 回答 实际效果 各类实际术语听不懂 AI拿到项目不知道从何开始，直接一顿召回一顿搜本地项目文件，实际各种答非所问完全靠大模型自己发挥 Dify 这套方案适合：文档类问答，知识相对固定，用户问法相对规范，需要一直自我调整 我们的问题是：业务实操类，问法千奇百怪，业务理解需要特定思路。 其实换个说法就是：把人对这项目各方面的理解思路等等抽成skills哈哈 但是细调用Dify软件就很不方便了，索性放弃Dify <3> 第二阶段：自建路由 核心思路 先听懂意图，再谈检索 。 这一步其实不是先研究模型，而是先把自己平时遇到的需求拆开。 先把这些常见业务动作分出来，再针对每一类动作设计不同的处理路线。 然后再兼容用户真实问法。中文、英文、缩写、符号、口语表达都要算进去。如果不先统一到同一个意图，后面检索再准也没用。 最开始当然也有关键词规则，后来逐步加上 embedding 和语义分类。简单说，就是不只看用户用了哪个词，还要看这句话整体更像哪类需求。 为了提高稳定性，又加了一层小模型兜底。当前面的规则和语义分类都不够确定时，再让小模型辅助判断一次。它不是负责最终回答，而是负责把问题分到更合理的路线里。 再往后，就是把我们对项目的理解、业务维护经验、常见判断逻辑整理进 RAG。这个过程有点像把人的经验拆成一组组 skills：每类问题都有自己的判断方式、需要看的材料、不能踩的坑。 但它又不完全等同于传统 skills。传统 skills 分散在各处，后面维护起来容易散；RAG 这边有一个相对集中的知识入口，可以单独调路由，也可以单独调知识内容。对这种业务落地场景来说，反而更好维护。 <4> AI不走原定路线 路由做完后，又遇到一个很典型的问题：AI 有时不按你设计好的路线走。 很多需求其实只要进入对应路由，把输入拆好，再查对应知识，就能稳定完成。但模型有时会"觉得自己能行"，上来就直接开始自己读文件、猜结构、自己组织答案。 还有一种情况是多轮对话。用户第二句明明是在补充上一句，打个比方比如"那把它改小一点"，模型却把它当成一个全新的问题处理，完全不管历史上下文里的"它"是谁。 这类问题光靠提示词里说"请优先走 RAG"是不够的。因为模型一旦进入自由发挥状态，就很难保证每次都守规矩。 后来做法变成：先检测当前项目是否属于我们已知的业务项目。如果是，就在底层强制加规则，让它优先走固定 RAG 路线，而不是随便读文件和自由发挥。 这样做以后，系统不一定一下子变得非常聪明，但至少变得可诊断了。答错的时候可以看出来：是项目识别错了，是路由错了，是知识没召回，还是模型最后总结跑偏了。 <5> 人工汇总知识不够用易过期 走到这一步后，AI 已经能处理一些简单、固定流程的业务需求了。但新的问题也很明显：知识库不能只靠人工写。 人工总结的知识短期有用，但长期会遇到三个问题。 第一，维护成本越来越高。后续可能项目在变，文档也要跟着变，靠人手动同步迟早会漏，其实推广到别的项目也容易变。 第二，答案会逐渐不可信。知识写进去的时候是对的，不代表几个月后还对。内部项目最怕的不是"不知道"，而是系统拿着过期知识自信地指导用户。 第三，模型有时会为了补上下文读太多内容。看似更努力，实际会增加 token 消耗和服务压力，而且读得越多，越容易把不相关内容混进来。 所以后面思路又变了：不能只把项目当成一堆文档，而要把它看成一张结构网。 一个业务对象可能关联配置、规则、动作入口、脚本、命令、上下游顺序。靠纯文本相似度去猜这些关系，不稳定，也浪费。 于是开始尝试走LangChain + neo4j路线把项目内条目切离结构抽取，再把这些关系放进图谱。 图谱不是为了替代 RAG，而是给路由结果提供更精准的背景补充：这个对象在哪里、它关联哪些东西、下一步该查哪类材料。 这样原本"靠模型自己理解项目"的问题，就变成了"先由系统把结构上下文准备好，再让模型基于这些上下文回答"。 (小小的吐槽一下：其实到图谱前这个就已经基本实现功能了，最核心最主要是上面觉得要图谱才放心,因为别人好像什么王道路线就是那么走的，没办法胳膊肘拧不过大腿不是吗 手动滑稽 ） <6> 展示层也要自己做 结构抽取图谱建出来以后，本以为可以直接用数据库工具展示。实际又踩了一个坑。 neo4j数据库浏览器适合工程调试，不适合业务展示。比较好的图谱浏览能力都在企业版里， 普通版本虽然能证明"数据确实在里面"，但对普通用户来说，看到的常常只是一堆点和线。 我最开始就只是部署到容器里测试，怎么看怎么别扭以为得下个软件，结果实际还是得付费了属于是 用户不关心数据库里有多少节点，他关心的是：这个对象为什么会关联到这些东西，我要改它应该看哪里。 所以展示层也得自己做。 这个浏览器不追求通用图数据库能力，只服务当前业务： 打开后默认展示一个对象的局部关系 节点按业务类型着色 边显示关系含义 支持搜索、点击查看详情、逐步展开 隐藏原始大段内容，只展示对维护有用的信息 它的目标不是替代数据库，而是把图谱翻译成业务人员能看懂的界面。 后续如果用户能自己搜索对象、展开关系、点节点看详情，再结合 RAG 给出的解释和修改建议，就比较不戳了"。 <7> 过程中最大的几个教训 1. 不要把 RAG 理解成"文档问答" 文档问答只是 RAG 的一种最简单形态。 内部业务场景里，用户往往不是来问"这段文档什么意思"，而是要完成一个动作。动作需要结构、规则、上下文和边界。 如果只做文档问答，很容易一开始看起来能用，深入使用就暴露问题。 2. 意图识别比召回更早出问题 很多人调 RAG 时第一反应是调 chunk、调 embedding、调相似度阈值。 这些当然重要，但在操作型场景里，更早的问题是：系统有没有判断对用户要做什么。 意图错了，召回越准越危险，因为它会在错误方向上给出很完整的答案。 3. 结构化知识比堆文档更重要 文档越堆越多，不等于系统越懂业务。 有些知识应该写成说明，有些知识应该从项目里自动抽取，有些知识应该建成关系，有的知识需要把人的理解抽出来 把所有东西都塞进向量库，只会让问题变得更难诊断。 4. 展示工具会影响认可度 这是后来才意识到的。 同样一套图谱数据，如果只在数据库浏览器里展示，普通用户会觉得乱不知道干啥的；如果用业务视角重新组织，用户才会觉得"这个东西能用"。 所以展示层不是锦上添花，它会影响别人对系统成熟度的判断，也方便用户检查 9 个帖子 - 6 位参与者 阅读完整话题
各位佬友们好，最近在折腾 华为 OrangePi AIpro 20T 。为了避免外接显示器、键鼠和无线网络不稳定带来的折腾，我整理了一套“一根网线”开发方案： 通过 Windows 11 ICS 共享上网 ，让开发板借用宿主机网络；通过 静态 IP 固化 ，保证每次都能稳定 SSH 连接；最后使用 VS Code Remote - SSH 实现原生远程开发闭环。 本文目标： Win11 笔记本通过网线直连 OrangePi AIpro 20T； OrangePi 通过 Win11 共享网络访问互联网； OrangePi 固定为静态 IP，避免每次查地址； 使用 SSH 与 VS Code 远程开发； 关闭 Wi-Fi 干扰，尽量保持网络路径纯净稳定。 实测环境： 宿主机：Lenovo 82JQ 系统：Windows 11 开发板：Huawei OrangePi AIpro 20T 连接方式：网线直连 官方文档： Orange Pi AIpro 20T 官方技术文档 1. 宿主机 Win11 侧：开启 ICS 共享上网 1.1 物理连接 使用网线直连笔记本与 OrangePi AIpro 20T 的 2.5G 以太网口 。 如果宿主机只有普通千兆网口也没问题，网卡会自动协商到可用速率。 这里需要先明确网络拓扑： 互联网 ↓ Win11 的 Wi-Fi 网卡，也就是 WLAN ↓ Windows ICS 共享 ↓ Win11 的以太网网卡，地址为 192.168.137.1 ↓ 网线直连 ↓ OrangePi AIpro 20T，地址为 192.168.137.10 也就是说，Win11 上有两张网卡参与这件事： Wi-Fi / WLAN 网卡：负责连接互联网 以太网 / Ethernet 网卡：负责通过网线连接 OrangePi 注意：用于上网的 Wi-Fi 网卡和用于直连开发板的以太网网卡不是同一张。不要选反。 1.2 开启 Windows ICS 共享 按下 Win + R ，输入： ncpa.cpl 然后回车，打开“网络连接”。 找到 当前真正用于访问互联网的网卡 。 一般是正在连接 Wi-Fi 的那张网卡，例如： WLAN 这张网卡的作用是： 连接外部互联网 。 找到 用于直连 OrangePi 的有线网卡 。 一般名字类似： 以太网 Ethernet Realtek USB GbE Family Controller 这张网卡的作用是： 通过网线和 OrangePi 通信 。 右键点击 用于上网的 Wi-Fi 网卡 ，也就是通常叫 WLAN 的那张网卡，选择： 属性 -> 共享 勾选： 允许其他网络用户通过此计算机的 Internet 连接来连接 如果出现“家庭网络连接”下拉框，请选择 用于直连 OrangePi 的以太网网卡 。 也就是说： 共享来源：WLAN / Wi-Fi 共享目标：以太网 / Ethernet 这一点非常关键。 不是在直连开发板的以太网网卡上开启共享，而是在“能上网的 Wi-Fi 网卡”上开启共享，然后把共享目标选择为“直连开发板的以太网网卡”。 点击确定。 此时 Windows 通常会自动把 用于直连 OrangePi 的以太网网卡 IPv4 地址设置为： IP 地址：192.168.137.1 子网掩码：255.255.255.0 默认网关：不用管 检查方式： 右键 以太网网卡 ： 属性 -> Internet 协议版本 4 TCP/IPv4 -> 属性 确认它的 IPv4 地址是否为： 192.168.137.1 如果这里不是 192.168.137.1 ，后面 OrangePi 侧的网关配置也要相应调整。不过默认情况下，Windows ICS 一般会使用 192.168.137.1 。 1.3 放行 ICMP，方便 Ping 网关 默认情况下，Windows 可能会拦截入站 Ping 请求，导致开发板无法通过 ping 192.168.137.1 验证网关是否连通。 以 管理员权限 打开 PowerShell，执行： New-NetFirewallRule ` -DisplayName "Allow ICMPv4-In from LocalSubnet" ` -Direction Inbound ` -Protocol ICMPv4 ` -IcmpType 8 ` -RemoteAddress LocalSubnet ` -Action Allow 这个规则只允许本地子网内的设备 Ping 宿主机，比直接全局放开更稳妥一些。 2. 开发板 Linux 侧：静态 IP 固化 2.1 先确认网卡名与 Netplan 配置文件 在 OrangePi 上执行： ip -br link ip -br addr ls /etc/netplan/ 重点确认两件事： 有线网卡名是不是 eth0 ； /etc/netplan/ 下面实际的 YAML 文件叫什么。 不同镜像里，Netplan 文件名可能不一样，例如： 01-netcfg.yaml 01-network-manager-all.yaml 50-cloud-init.yaml 下面以 /etc/netplan/01-netcfg.yaml 和 eth0 为例。 如果你的文件名或网卡名不同，请替换为自己的实际结果。 2.2 备份原配置 修改网络配置前，建议先备份： sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak 如果你的 Netplan 文件不是 01-netcfg.yaml ，请把命令里的文件名替换为实际文件名。 2.3 编辑 Netplan 配置 执行： sudo nano /etc/netplan/01-netcfg.yaml 写入或修改为： network: version: 2 renderer: NetworkManager ethernets: eth0: dhcp4: no dhcp6: no addresses: - 192.168.137.10/24 routes: - to: default via: 192.168.137.1 nameservers: addresses: - 8.8.8.8 - 114.114.114.114 注意： YAML 严禁使用 Tab； 缩进必须对齐； eth0 必须换成你实际的有线网卡名； 192.168.137.10 是开发板固定 IP； 192.168.137.1 是 Win11 直连开发板的以太网网卡地址，也是 OrangePi 的默认网关； 这里的网关不是 Wi-Fi 网卡地址，而是 Win11 上那张 直连 OrangePi 的以太网网卡 地址。 2.4 应用 Netplan 配置 建议先检查配置： sudo netplan generate 然后使用： sudo netplan try 如果没有问题，再执行： sudo netplan apply netplan try 的好处是：如果网络配置写错导致连接中断，它可以自动回滚。远程 SSH 修改网络配置时尤其推荐先用它。 3. 修复 hostname 与 hosts 不一致问题 我这里遇到了一个比较奇怪的问题：执行 sudo netplan try 时出现： unable to resolve host 原因是 /etc/hostname 和 /etc/hosts 中的主机名不一致。 先查看当前 hostname： cat /etc/hostname 假设输出是： orangepiaipro-20t 那么 /etc/hosts 里也要保持一致。 编辑： sudo nano /etc/hosts 修改为类似： 127.0.0.1 localhost 127.0.1.1 orangepiaipro-20t 重点是这一行： 127.0.1.1 orangepiaipro-20t 它必须和 /etc/hostname 一致。 我这里原本是： orangepiaipro 但 /etc/hostname 里是： orangepiaipro-20t 所以导致了 unable to resolve host 。 4. 关闭 Wi-Fi，避免默认路由冲突 为了避免开发板自动连接 Wi-Fi，导致默认路由被抢、网络路径混乱，建议关闭 Wi-Fi 射频，只通过网线访问网络。 执行： sudo nmcli radio wifi off 查看状态： nmcli radio 如果后续需要重新打开 Wi-Fi，可以执行： sudo nmcli radio wifi on 这一步不是必须的，但如果你和我一样希望开发环境尽量稳定、路径尽量干净，建议关掉。 尤其是开发板自带 Wi-Fi 速度一般时，网线直连会舒服很多。 5. 连通性检查 配置完成后，在 OrangePi 上依次执行： ip -br addr ip route ping -c 4 192.168.137.1 ping -c 4 8.8.8.8 ping -c 4 www.baidu.com 判断方式如下： 5.1 能 Ping 通 Win11 网关 ping -c 4 192.168.137.1 说明 OrangePi 到宿主机的直连网络正常。 这里的 192.168.137.1 指的是 Win11 上直连 OrangePi 的以太网网卡 ，不是 Wi-Fi 网卡。 如果这里不通，优先检查： 网线是否插好； Win11 以太网 IPv4 是否为 192.168.137.1 ； OrangePi IP 是否为 192.168.137.10/24 ； Windows 防火墙是否放行 ICMP； Netplan 里的网卡名是否写错； Windows ICS 是否把共享目标选成了直连 OrangePi 的以太网网卡。 5.2 能 Ping 通公网 IP ping -c 4 8.8.8.8 说明 Win11 ICS 转发正常，开发板已经可以借用宿主机网络访问互联网。 如果能 Ping 通 192.168.137.1 ，但不能 Ping 通 8.8.8.8 ，通常是 ICS 共享没有生效。 可以尝试： 关闭共享后重新开启； 确认共享来源是 WLAN ，也就是用于上网的 Wi-Fi 网卡； 确认共享目标是直连 OrangePi 的以太网网卡； 检查 Win11 自己是否能正常上网。 重点再强调一次： 不是共享以太网给 WLAN， 而是共享 WLAN 给以太网。 5.3 能 Ping 通域名 ping -c 4 www.baidu.com 说明 DNS 正常。 如果能 Ping 通 8.8.8.8 ，但不能 Ping 通域名，大概率是 DNS 配置问题。 可以检查 Netplan 中的： nameservers: addresses: - 8.8.8.8 - 114.114.114.114 也可以执行： resolvectl status 查看当前 DNS 是否生效。 修改后重新应用： sudo netplan apply 6. SSH 远程连接 华为官方镜像默认用户一般是： 用户名：HwHiAiUser 默认密码：Mind@123 首次登录后，建议立即修改默认密码： passwd 如果后续长期使用，建议配置 SSH Key 登录，并视情况关闭密码登录。 6.1 测试 SSH 在 Win11 PowerShell 中执行： ssh [email protected] 第一次连接时会提示是否信任主机指纹，输入： yes 然后输入密码即可登录。 如果出现类似： Host key verification failed. 通常是之前连接过同一个 IP，但设备指纹变了。可以在 Win11 PowerShell 中执行： ssh-keygen -R 192.168.137.10 然后重新连接： ssh [email protected] 再次输入 yes 接受新的主机指纹即可。 6.2 配置 SSH Config 为了后续 VS Code 连接更方便，可以在 Windows 上编辑 SSH 配置文件： C:\Users\你的用户名\.ssh\config 添加： Host orangepi-aipro HostName 192.168.137.10 User HwHiAiUser 之后就可以直接执行： ssh orangepi-aipro 这样 VS Code Remote - SSH 里显示的也是 orangepi-aipro ，比一串 IP 更清晰。 7. VS Code Remote - SSH 远程开发 7.1 安装插件 在 VS Code 插件市场安装： Remote - SSH 安装完成后，按下： Ctrl + Shift + P 搜索： Remote-SSH: Connect to Host... 选择： orangepi-aipro 等待 VS Code 自动连接并初始化远程环境。 7.2 远程开发体验 连接成功后，你可以直接在 VS Code 中： 浏览开发板文件系统； 打开远程终端； 编辑代码； 安装远程插件； 运行 Python、C++、Shell 等程序； 调用板端 NPU 环境进行推理或测试。 也就是说，代码编辑、终端操作、文件管理都在宿主机 VS Code 中完成，但程序实际运行在 OrangePi AIpro 20T 上。 这种体验比外接显示器和键鼠舒服太多。 8. 高速文件传输 网线直连模式下，文件传输速度通常明显优于无线连接。 常用方式有三种。 8.1 VS Code 侧边栏拖拽 最简单。 连接 Remote - SSH 后，直接在 VS Code 文件树中拖拽文件即可。 适合传输： 小型源码； 配置文件； 脚本； 少量测试数据。 8.2 使用 SCP 从 Win11 传文件到开发板： scp .\test.tar.gz orangepi-aipro:/home/HwHiAiUser/ 从开发板拉文件到 Win11： scp orangepi-aipro:/home/HwHiAiUser/result.log .\ 8.3 使用 SFTP 也可以使用支持 SFTP 的工具，例如： VS Code SFTP 插件； FileZilla； WinSCP。 如果要传大规模数据集，建议使用 SCP、SFTP 或 rsync 一类工具，比手动拖拽更可控。 9. 常见问题排查 9.1 SSH 连不上 先在 Win11 上 Ping 开发板： ping 192.168.137.10 如果 Ping 不通： 检查 OrangePi 静态 IP 是否配置成功； 检查 Win11 以太网 IP 是否为 192.168.137.1 ； 检查是否插错网口； 检查网线； 检查 Netplan 里的网卡名是否正确； 检查 Windows ICS 的共享目标是否选成了直连 OrangePi 的以太网网卡。 如果 Ping 通但 SSH 不通，在开发板上检查 SSH 服务： systemctl status ssh 如果没有启动： sudo systemctl enable --now ssh 9.2 开发板能 Ping 网关，但不能上网 现象： ping 192.168.137.1 能通。 但是： ping 8.8.8.8 不通。 这种情况一般是 Win11 ICS 没有正确生效。 建议： 关闭 WLAN 的共享； 重新开启 WLAN 的共享； 确认共享来源是用于上网的 Wi-Fi 网卡； 确认共享目标是直连 OrangePi 的以太网网卡； 检查 Win11 自己是否能正常访问互联网。 正确关系应该是： WLAN / Wi-Fi：负责上网，开启共享 以太网 / Ethernet：负责连接 OrangePi，作为共享目标 9.3 能 Ping IP，但不能 Ping 域名 现象： ping 8.8.8.8 能通。 但是： ping www.baidu.com 不通。 这通常是 DNS 问题。 检查： resolvectl status 或者重新确认 Netplan 中的 DNS： nameservers: addresses: - 8.8.8.8 - 114.114.114.114 修改后重新应用： sudo netplan apply 9.4 Windows ICS 把 IP 改乱了 有时 Windows ICS 会比较“有自己的想法”。 如果发现直连 OrangePi 的以太网网卡 IP 不是： 192.168.137.1 可以尝试： 关闭 WLAN 共享； 手动删除以太网 IPv4 静态配置； 重新开启 WLAN 共享； 在共享目标中重新选择直连 OrangePi 的以太网网卡； 再次检查以太网 IPv4 地址。 一般重新开关一次共享就能恢复。 10. 系列总结 通过这套配置，OrangePi AIpro 20T 可以在不依赖 Wi-Fi、不外接显示器键鼠的情况下，稳定接入宿主机网络，并通过固定 IP 进行 SSH 与 VS Code 远程开发。 最终效果： 网线即网络 ：开发板通过 Win11 ICS 借用宿主机网络上网； 固定 IP ：OrangePi 固定为 192.168.137.10 ，不再反复查地址； 链路纯净 ：关闭 Wi-Fi，避免默认路由冲突； 远程开发 ：VS Code Remote - SSH 一站式完成代码编辑、终端操作和文件管理； 便于扩展 ：后续跑 Ascend NPU 推理、部署服务、同步数据集都会更顺滑。 这篇是我关于 OrangePi AIpro 20T 折腾记录的第一篇。 后续准备继续整理： 高性能仿真环境搭建； Ascend NPU 开发避坑； CANN / MindIE / Python 环境配置； 自动化部署与远程运维； 模型推理与板端服务化实践。 觉得有用的佬友可以点个赞，也欢迎在评论区交流折腾心得。 #OrangePi #华为昇腾 Linux #嵌入式开发 vscode 1 个帖子 - 1 位参与者 阅读完整话题
自己搭了个号池子，自用加给几个朋友用。看看这100个号能坚持多久。90个印度尼西亚刷的PLUS加上10个PRO。看看到底能坚持多久~ 19 个帖子 - 17 位参与者 阅读完整话题
苹果发布2026 财年第二季度财报，在服务业务增长的拉动下，盈利和营收均超出分析师预期。iPhone 销售额在近三个季度内第二次不及市场预期，也是本周四财报中唯一一项明显低于预期的核心业绩数据。（注：苹果财年与自然年不一致）财报发布后，苹果管理层召开电话会议，苹果首席执行官Tim Cook、首席财务官凯文·帕瑞克（Kevan Parekh）参加会议并回答了分析师提问。 以下为本次电话会议分析师问答环节主要内容： 摩根士丹利分析师Erik Woodring： 蒂姆，道别的话我留到下个季度再说吧，能和您一起共事很愉快。我的第一个问题是，能否请您进一步谈一谈，在前面的简报中您提到的“供应受限”到底指什么？换句话说，在三月季度中，对于iPhone和Mac产品来说，需求比供给超出了多少？另外，管理层对六月季度的业绩指引是否也反映出了这些产品线的供应限制？还是说，目前给出的六月季度指引是在“供给不受约束”的条件下给出的理想预期？ Tim Cook： 在三月季度，我们确实受到了供给限制的影响，主要体现在iPhone上，对Mac的影响相对较小。正如我们在上一次的电话会议中提到的，限制主要来自我们芯片所依赖的先进制程产能。 展望六月季度，目前我们看到的用户需求仍然处于高位，我们认为供应限制将集中体现在部分Mac机型上。整体来看，我们在供应链方面的灵活性会略低于过往常态。 具体来说，对于六月季度的Mac供应受限，我认为主要有两个因素。一是Mac mini和Mac Studio这两款产品都是非常出色的AI和智能代理工具平台，用户对这一点的认可程度要远高于我们的预期，因此总体的产品需求是高于预期的；二是市场对MacBook Neo的反响异常热烈，产品需求同样超出预期。 受MacBook Neo带动，我们看到在三月季度， Mac产品的新用户数（首次购买Mac）创下历史新高 。 展望未来，我们 预计Mac mini和Mac Studio都可能需要数月时间才能实现供需平衡。 希望这些信息能帮助你了解我们在第二财季和第三财季供应端的大致情况。 摩根士丹利分析师Erik Woodring： 我的第二个问题想问凯文。刚才在简报中您提到目前公司的“净现金趋于中性”（净零状态），未来公司不会再将“净现金”作为正式条目向大家披露了。能否请您再稍微展开讲一讲这点？比如在公司的资本回报政策方面，管理层是否考虑做出调整？目前看起来似乎没有，但能否请管理层再多与我们分享一些细节？ 另外，在简报中管理层提到的“投资”，这些投资是用来进行内生增长还是外延并购？能否请您为我们详细说一说？ 凯文·帕瑞克： 我再为大家深入阐释一下我们在简报中提到的。这其实是我们对公司资本结构的说明。一直以来，我们“调整净现金净零”的目标都运作得很好。自2018年以来，它对公司以及我们的资本结构而言都是一个非常有价值的框架指标。 但发展至今，我们认为公司已经到了一个新阶段，“将现金和债务分开评估”对我们来说是更合适的做法，这也有利于我们在利用债务和现金组合支持业务方面做出更优的决策。换言之，我们可以根据业务需求和市场环境，更灵活地进行资金配置。同时，我们也相信，在保持这种灵活性的同时，我们依然能够做到高效运作并保持一贯的审慎态度。 在此基础上，苹果仍然致力于向股东返还多余现金。正如我们之前提到的，对苹果来说，业务投资仍然是第一位的，之后才是将剩余现金回馈给股东。我认为在这方面我们一直保持着良好的效率与审慎的态度： 自项目启动以来，我们已经累计向股东返还了超过1万亿美元，其中超过8500亿美元是通过股票回购的形式实现的。 此外，我们还将股票回购授权额度提高了1000亿美元。 我相信大家可以看到，资本回报对我们来说始终非常重要。正如我们在前面的简报中提到的，这也是我们实现长期股东价值策略中的重要组成部分。 Melius Research分析师Ben Reitzes： 我的第一个问题是，最近市场上有很多关于“代理式智能手机”的讨论。说实话，我也不太确定这具体指的是什么。不过我看到有些观点提到，随着前沿AI技术的发展，AI智能体可能会推动智能手机的发展，甚至可能改变手机的形态。 所以我想请问管理层，随着这些“AI智能体”的兴起，你们是如何理解这一趋势的？这是否意味着未来会出现全新的产品形态？还是说“AI智能体”的出现会从根本上改变行业格局？或者在更宏观层面上，你们对这一趋势有什么看法？ Tim Cook： 我们不会对未来的产品路线图作出具体说明，我也不想在这方面与大家透露太多信息。不过我可以说得失，我们对iPhone产品的表现非常满意。本财季，iPhone产品实现了22%的增长，这延续了我们在第一财季的强劲表现。从去年的新品发布到今年的三月季度，可以说这是我们历史上最强劲的一次产品周期，我们对此再满意不过了。 Melius Research分析师Ben Reitzes： 关于刚才提到的供应限制等问题，蒂姆，我还有个跟进问题。目前市场上大家比较担心的是，在接下来的六月季度之后，考虑到元器件成本、行业趋势以及这些供给限制，你认为产品的利润率会如何变化？管理层是否有比较宏观的思路或原则，有助于我们理解未来的产品利润走势？ 另外，也许凯文也可以补充，管理层是否认为当前的盈利模型未来会出现较大的波动？还是说之后毛利率还是可以维持在47%至48%的区间？又或者说，管理层认为六月之后的情况并不明朗，暂时无法给出明确判断？如果管理层能从全年的维度给我们一些方向性的指引，会对我们会非常有帮助。 Tim Cook： 我具体谈一谈内存供应的问题，我认为这其实也是你这个问题的核心。我先从去年12月说起，简单为大家梳理一下时间线。 在去年的12月季度，内存价格对我们的影响其实是比较小的，这一点大家从毛利率的表现中也可以看到。我们当时提到，到了3月季度内存对我们的影响会有所加大，实际情况也是如此。在今年的3月季度，内存成本确实上升了，不过部分成本上涨被我们结转库存带来的收益抵消掉了。 展望6月季度，也就是凯文刚才在指引中提到的情况，我们预计内存成本将有显著上升，不过同样会有一部分成本会被结转库存的收益对冲。至于六月之后的情况，我们并没有给出更具体的指引。但可以告诉大家的是，我们认为在6月之后，内存成本对业务的影响会逐步加大。我们会持续评估行业情况，并且像之前所说的那样，考虑多种应对方案。 高盛分析师Michael Ng： 我的第一个问题是，随着MacBook Neo的成功上市，能否请管理层谈一谈，这款产品是如何帮助苹果在新用户群中提升产品渗透率的？比如教育市场、价格敏感型用户，或者新兴市场等。另外，从更宏观的角度来看，对于那些产品渗透率仍然较低的市场，管理层如何看待其中的机遇？公司未来的产品路线图将如何帮助提升上述市场的产品渗透率？ Tim Cook： 目前我们在MacBook Neo产品上的供给是受限的。市场反馈非常强烈，其实在产品发布之前我们就已经对它非常看好，但实际的市场热情还是超出了我们的预期。 这款产品的核心目标之一就是让Mac能覆盖更多的用户群体。我们重点关注两类用户：一类是首次使用Mac产品的新用户；另一类是已经很久没有更换设备的老用户。目前来看，我们在这两方面的表现都很好。正如前面凯文提到的，目前已经有一些学校，比如堪萨斯城公立学校，正在把学校用的电脑由Chromebook、Windows PC换成MacBook Neo。我也越来越多地听到类似的案例，不仅是在学校系统里，也有很多个人消费者。 总的来说，我们对目前的进展感到非常满意。 高盛分析师Michael Ng： 我的第二个问题是关于苹果服务业务中的广告。我想请教管理层，苹果在今年早些时候在App Store中新增了一些广告位，这些新增的广告库存是否对本季度服务业务的增长和超预期表现带来了显著贡献？ 另外，能否请管理层谈一谈你们的广告战略？尤其是今年夏天，苹果计划将广告内容引入Maps应用。对此，管理层是如何考虑整体布局的？ 凯文·帕瑞克： 在广告业务方面，我们的广告业务确实实现了同比增长。正如你提到的，我们最近在App Store的搜索结果中引入了更多广告位，为开发者提供了更多广告形式，让用户可以在他们信任的平台上带动应用下载。 另外，正如你所说，今年夏天我们将在美国和加拿大地区的Apple Maps中，在关键的搜索和发现场景中引入广告服务，为本地商家提供一种新的触达客户、帮助用户探索新地点、新位置的方式。 同时，我想强调的是，我们认为我们完全能在通过广告服务帮助各种规模的企业实现增长的同时，在尊重用户基本隐私权的前提下，依然为用户提供出色的体验，这几点对我们来说都同样重要。 美银美林分析师Wamsi Mohan： 蒂姆，你刚才提到，在六月季度之后，内存成本的影响会进一步加大，你们在规模、供应链效率以及长期建立的合作关系方面都具有优势。基于此，管理层在思考产品定位及与竞争对手的定价策略时，在当前的这种波动时期，苹果的战略重点会更偏向争夺市场份额吗？比如在竞争对手承压时不提价、甚至在大众产品线采取更积极的策略？还是说管理层会更侧重保持盈利能力？换言之，在当前阶段，管理层希望我们如何理解公司的决策？ Tim Cook： 随着内存成本的上升，我们会持续评估一系列应对方案。目前我不想就此展开更多说明。 美银美林分析师Wamsi Mohan： 我还有一个跟进问题。在“代理式AI”的大背景下，苹果是如何思考未来的变现路径？我也想结合刚才Ben的问题，管理层认为苹果会重点聚焦技术栈的哪些环节？哪些工作会更多地由内部完成？哪些又会借助合作伙伴来实现？ 目前，我们已经看到公司在一些合作关系上的初步布局。从更长期来看，未来几年苹果会在哪些领域加大投入？另外，这是否与你们此前提到的“不再致力于调整净现金净零”有关？比如，为了迎接未来“以AI为核心”的时代，管理层计划进一步建设相关的基础设施？ Tim Cook： 很显然，我们会加大投入，这一点大家也可以从我们的运营支出数据中看到。再展开来看，如果大家把研发费用、销售及管理费用分开看，就会发现我们的研发支出增速甚至明显快于公司整体的增速。 可见，无论是在产品还是在服务方面，我们确实在持续加大投资，我们在这两方面都看到了增长机遇。我们对未来的发展趋势感到非常振奋。 凯文·帕瑞克： 我想再补充一点。正如我们一直以来所说的，我们认为AI是苹果非常重要的投资方向之一。我们会在既有产品的路线图上进行常规投入，除此之外，还会 逐步增加在AI方面的投入。 Evercore ISI分析师Amit Daryanani： 我的第一个问题还是想回到iPhone产品的表现。过去几个季度，在供给受限的大背景下，公司依然实现了超20%的增长。而且从管理层给出的指引来看，这一趋势在六月季度似乎还会持续。 我想请管理层再为我们深入展开一下：在当前供给受限的背景下，推动iPhone实现如此强劲增长的关键驱动因素有哪些？另外，对于这种增长的可持续性，你们又是如何思考的？ Tim Cook： 如果大家仔细观察就会发现，推动我们增长的是iPhone 17系列。正如你所说，这种增长是在我们面临供给限制的背景下实现的。 驱动用户选择iPhone 17系列的因素大概包括：用户喜欢它的设计、性能、耐用性、相机功能，喜欢“人物居中”功能（Center Stage），以及Apple Intelligence在整个生态系统中的深度整合。 从具体的增长市场来看，我们在各个市场的表现都非常强劲：我们关注的大多数市场都实现了双位数增长，包括美国、拉丁美洲、大中华区、西欧、印度、日本以及东南亚。同时，数据显示，三月季度的换机用户数也创下了新纪录。 推动这一切的关键因素之一在于用户满意度。以美国市场为例，iPhone 17系列的用户满意度达到99%，这样的数字是非常罕见的。因此，我们对目前的形势感到非常满意。 Evercore ISI分析师Amit Daryanani： 蒂姆，我想接下来您大概还会再参加一次财报电话会。我很希望您能稍微谈一谈接下来的工作交接。 您总会提到当年接任时乔布斯给您的建议。我可能记得不是特别准确，但大意是：“不要去想我会怎么做，只需要做你认为正确的事。”在我看来，过去15年里，这条建议无论对苹果还是对股东来说，都带来了非常积极的效果。我也很想知道，如今的你会给John Ternus（苹果新任CEO）怎样的建议？帮助他在延续苹果既有优势的同时，塑造公司未来的新篇章？ Tim Cook： 在我看来，乔布斯当年给我的建议确实大大减轻了我的压力。对我而言，这条建议在过去15年里一直非常受用。 至于John，我给他的建议是，或者说我曾对他说过，他需要做出的最重要决策之一在于如何分配自己的时间。就我个人来说，我会把时间投入到对公司和用户最有价值的事情上。 同时，永远不要忘记公司的“北极星”，不要忘记公司最根本的使命。对苹果来说，我们的“北极星”就是打造世界上最优秀的产品，真正去丰富用户的生活。如果你能始终围绕这一点来思考和决策，它自然会带来出色的结果，也会让我们有能力持续打造更多产品，最终形成正向循环。 瑞银分析师David Vogt： 蒂姆，我想再回到供应链的问题上。我好像没有在管理层的简报或刚才的回答中听到，您是否确定iPhone产品在六月季度一定会受到供给限制？如果是的话，能否请您具体谈一谈，管理层如何看待苹果在确保供应方面的能力？不仅是芯片供应，也包括内存供应方面。管理层目前是否考虑采用不同于传统合作伙伴的内存供应来源？ 另外，目前看来，苹果在持续提升市场份额的情况下，你们为什么认为iPhone的供应不会大幅受限？管理层是如何保持信心的？ Tim Cook： 目前看来，三月季度和六月季度的供给限制主要来自我们用于生产芯片的先进制程节点产能，而不是内存。 至于未来的供需是否能够匹配，我今天不想做出预测。但从现实情况来看，就Mac mini和Mac Studio的供应来说，我认为可能还需要数月时间才能实现供需平衡。目前，我们并不认为当前的紧张情况会在短期内结束，但这并不是因为供应出现了什么问题，而是因为我们低估了市场需求。如大家所见，这其中涉及一定的交付周期，改善这种供需错配需要时间。 而从产品的角度来看，在六月季度，主要的供给限制将集中在Mac产品线，具体包括Mac mini、Mac Studio以及MacBook Neo。限制基本上会围绕在这些产品上。 瑞银分析师David Vogt： 关于苹果的服务业务，我还有一个跟进问题。公司的服务业务毛利率再次表现得相当强劲。考虑到服务业务内部的产品结构，以及很多不同业务都在实现双位数增长，管理层认为业务增长是否已经接近“上限”？换句话说，从盈利能力角度来看，您是否认为进一步扩大规模会变得越来越困难？ 还是说，对于某些具体业务，管理层认为仍然可以通过规模效应持续带来盈利提升？又或者在某些业务类别里，管理层认为可以通过降低亏损继续推动整个服务业务的毛利率提升？ 凯文·帕瑞克： 如大家所见，我们的服务业务组合涵盖了多种不同类型的业务，它们各自的商业模式、盈利能力以及增长速度都不尽相同。在任何一个时间点，这些业务的发展、变化都会对公司的整体毛利率产生影响。 就目前来看，我们在第二财季的服务业务毛利率环比提升了20个基点，这主要是由业务结构变化所造成的。不过，未来这种情况会如何演变其实很难做出预测。 总体来看，我们对当前的表现是很满意的。确实有一些服务业务在规模扩大之后，盈利能力正在提升。但我也想再次强调，苹果拥有非常多元化的业务组合，不同业务有不同的特征，也会以不同的速度增长。 摩根大通分析师Samik Chatterjee： 蒂姆，我的第一个问题是，在上个季度你们曾提到苹果的基础模型（Apple Foundational Models），以及“双轨策略”，即一方面与Google合作，另一方面继续在公司内部推进自研模型。 能否请您与我们分享一下最新进展？目前管理层是如何在这两条路径之间实现平衡的？另外，管理层是否认为需要进一步加大投入，同时推进这两项重点工作？ Tim Cook： 这个问题特别好。我们确实在加大投入，这一点大家从运营支出中就可以看出来。正如我之前提到的，我们的研发支出同比增长相当显著。目前我们与Google的合作进展顺利，也对目前的情况感到满意；同时，我们对公司独立推进的工作进展也同样感到兴奋。 摩根大通分析师Samik Chatterjee： 我还有一个跟进问题。凯文，相较过去几年（至少最近两年），今年产品毛利率的环比回落幅度明显较为温和。这主要是由产品结构变化驱动的吗？还是说也有汇率带来的顺风影响？能否请您为我们拆解一下，今年的毛利率表现与以往的模式相比有哪些不同？另外，能否请您为我们详细拆解一下，本财季汇率对毛利率的影响大概是多少？ 凯文·帕瑞克： 就产品而言，在第二财季，我们的产品毛利率环比大约下降了200个基点，正如蒂姆前面提到的，这主要是由于季节性规模效应的减弱以及内存成本上升。 不过，如果从更宏观的维度来看，想要理解公司整体毛利率的变化驱动因素，我可以简单梳理一下。从整体来看，公司毛利率环比提升了110个基点，这主要得益于正向的业务结构以及与关税相关成本的下降，但同时这也被季节性规模效应的减弱和内存成本上升部分抵消。 对于关税成本下降这一点，这个问题还是由蒂姆来回答，由他再做补充说明，为大家提供更多的背景和解释。 Tim Cook： 在三月季度，我们给出的49.3%的毛利率已经包含了关税相关成本的影响。不过，与去年的十二月季度相比，三月季度的关税成本有所下降，主要是因为从第一季度到第二季度，产品出货量环比有所减少。此外，我们还得益于两个顺风因素：一是IEEPA关税税率的下调为整个季度带来了正向影响，二是“122条款”的实施促使全球关税税率下调。 至于关税退税方面，我们正在按照既定流程进行申请。一旦收到相关款项，我们计划将其重新投入到美国的创新和先进制造领域。这部分资金将是新增投资，也是在我们此前已承诺的对美投资基础上的进一步投入。 凯文·帕瑞克： 最后我再补充一点关于你提到的汇率影响问题。从第一财季到第二财季，外汇因素对毛利率基本没有产生环比影响。 富国银行分析师Aaron Rakers： 我的问题有关终端市场的情况。蒂姆，能否请您谈一谈你们在中国市场看到的情况？从市场竞争角度来看，你们是否观察到，由于供给限制对竞争对手造成的影响反而为你们带来了一定优势？另外，从整体来看，对于中国市场你们有哪些看法？ Tim Cook： 我们对苹果在大中华区的表现感到非常满意。今年上半年，我们实现了33%的增长；在三月季度，营收同比增长28%，创下了我们的季度收入新纪录。这一表现的背后主要由iPhone驱动。在中国市场的iPhone销量同样创下了三月季度的新纪录。从单品来看，iPhone是中国城市市场最畅销的机型；Mac mini是中国最畅销的台式电脑；MacBook Air则是最畅销的笔记本电脑。 从整体来看，我们在各个产品线的表现都非常不错。我在今年三月份也去了中国，当时的门店客流实现了双位数增长。我们还在中国成都庆祝了苹果成立五十周年，能亲身参与到当地社区中让我感觉非常棒。 总的来说，我对今年上半年的我们在中国市场的表现感到非常满意。 富国银行分析师Aaron Rakers： 我的第二个问题与前一个类似，有关苹果在印度市场的表现。在过去几次的季度电话会上，印度市场一直是管理层的关注重点之一。管理层是如何看待印度市场的变化的？比如管理层认为iPhone在印度市场的用户基础增长如何？随着印度中产阶层的崛起，您看到了哪些机遇？总之，在印度这个庞大的移动手机市场中，管理层会如何评估整体的增长空间和机会？ Tim Cook： 我认为印度市场对我们来说意味着巨大的机遇。我们已经在当地市场持续投入了一段时间。 印度是全球第二大智能手机市场、第三大PC市场。虽然我们已经在当地取得了相当不错的成绩，但我们的市场份额并不高，这恰恰说明我们未来的增长空间非常大。 在印度市场，近几年有大量用户正迈入中产阶层，而我们目前以及即将推出的产品都能够很好地满足他们的需求。从各个产品线来看，无论是 iPhone、Mac、iPad还是Apple Watch，在印度市场，大多数消费者都是首次购买这些产品的用户，这对我们扩大用户基础非常有利。 总体来说，我对苹果在印度市场的发展前景感到非常兴奋。 查看评论
当大模型API调用成本一年内骤降超过80%，百万Token仅需几分钱时，产业竞争便不再纠结于技术指标的高低，而是回归到最朴素的价值衡量——能否在实际场景中降本增效。行业的聚光灯，从实验室的榜单，转向了真实的生产线、医院诊室、物流仓库和城市管理后台。 2026年，谁能在复杂场景中解决真问题，谁才是这场变革的主角。 5月19日至20日，以“带着AI去前线”为主题的2026 AI Partner·北京亦庄AI+产业大会在北京经开区通明湖会展中心举办。大会由北京经开区管委会指导、36氪主办、国家信创园承办，设置9场圆桌对话、22场主题演讲以及一场别开生面的“世界咖啡”AI+产业对接会。60位国内领军企业代表齐聚一堂，13家带着真场景、真预算、真痛点的需求方与36家技术方面对面碰撞。 正如36氪CEO冯大刚在开场中所说：“大多数人走进通明湖会展中心，心里想的是同一件事——不是来听AI有多厉害，是来看看AI到底能不能用、怎么用、花多少钱用，能创造多大价值。” 一位参会企业代表感慨：“以前参加AI会议，大家还在讨论‘未来能做什么’，今天在亦庄，大家直接问‘你的方案在我这条产线上能不能降本10%’。” 这种“去泡沫、验成色”的氛围，贯穿了大会的所有环节。我们从不缺谈概念的人，缺的是踩过坑、调过流程、把事做成的人。以下是本次大会嘉宾的超级金句，每一句背后，都站着一位真正带AI去过前线的人。 以下为嘉宾金句摘录：